MSFT Documentum connector and TCS Troubleshooting


MSFT Documentum connector and Custom Security Trimming (TCS) Troubleshooting

 

Summary:

With the release of the Feb 2012 CU for FAST Search PFE has been supporting the SharePoint  Documentum connector with custom security trimming in FAST Search. This guide is an expanding set of data points I have run into while troubleshooting.

Official documentation:

Configure TCS support for the Documentum connector (FAST Search Server 2010 for SharePoint)

http://technet.microsoft.com/en-us/library/hh857341.aspx

My post on the subject:

Enable custom security trimming with FAST Search for Sharepoint and Documentum

http://blogs.msdn.com/b/kristopherloranger/archive/2012/03/02/enable-custom-security-trimming-with-fast-search-for-sharepoint-and-documentum.aspx

 

Pre reqs:

First thing it is absolutely imperative that the technet pre-reqs are filled as the connector is very stringent on pre-reqs.

http://technet.microsoft.com/en-us/library/ff756030.aspx

 

It is recommended that this hotfix be installed:

http://support.microsoft.com/kb/2459111

 

Recommended but not necessary, DCTM connector SP1 update:

http://www.microsoft.com/download/en/details.aspx?id=26608

 

EMC assembly DLLS:

These files should be installed on the SharePoint crawler component server in

%local%\emc-dfs-sdk-6.5\emc-dfs-sdk-6.5\lib\dotnet

In the GAC as well as the FAST FS4SP server in %FASTSEARCH/bin/

Right click on the files and look at properties, you should see

"6.5.0.231  - AKA6.5 SP2  12/5/2009"

This has caused most of the problems I have seen in the field.

 

  • Emc.Documentum.FS.DataModel.Core.dll, version number 6.5.0.231
  • Emc.Documentum.FS.DataModel.Shared.dll, version number 6.5.0.231
  • Emc.Documentum.FS.runtime.dll, version number 6.5.0.231
  • Emc.Documentum.FS.Services.Core.dll, version number 6.5.0.231

 

 

 

Security Sync Crashing or not downloading user ACLs

The logging for the Security Sync service can be to debug for more information on your issue in the  %FASTSEARCH/bin/Microsoft.SharePoint.Search.Extended.Security.TrimmingSync.exe.config file. Adjust the logLevel, restart the service and the logFilename settings
here. By default, this log file should be at this location:

 %FASTSEARCH%\var\log\SecTrimmingLog.txt

  

Networking:

Since most environments you will be going over multiple networks a very quick networking test is from the FS4SP sync node check this file then run the below telnetcommand:

 telnet dctm.contoso.com 443

<hit enter a few
times and you should receive something back>

 Ç♥?fPS…

 

You can find the system to test in you $FASTSEARCH/bin/Microsoft.Sharepoint.search.extended.security.trimmingsync.exe.config

<!-- DataSource: Documentum Settings -->

  <DataSource.Documentum

    login="fastsearch"

    password="******"

    repository="DCTM_dev"

    dfs="https://dctm.contoso.com/dctm/services" />

 

 

All users(with a login) are seeing all documents:

Aka security is not working.

Overwrite attribute:

Make sure you have edited %FASTSEARCH%\etc\CustomSecurityTrimming.xml file:

<param name="OverwriteOutputAttr" value="1" type="int"/>

Changing this from the default value “0” will alter the behavior and strip away any other values that may have been set earlier in the pipeline stage which usually includes NT style authentication.

Note:

If you have this problem and change the value you will have to run a full crawl again once this value (or index-profile) is changed.

 

Index-profile:

If you have a custom IP you may have the docacl field set to not index, this needs to be an index able field.

FASTSEARCH/index-profiles/index-profile-fs14

    <field fullsort="no" lemmatize="no" index="yes" result="no" substring="0" separator="no" decimal-precision="3" max-result-size="64" max-index-size="1024" vectorize="no"
type="string" default-result="yes" tokenize="delimiters" name="docacl" description="The ACL (security) attributes for this document" />

 

Are we getting DCTM ACLs in the FiXML?

Run a Get-FASTFixml on a known DCTM document and look for “bcondocacl”

Here we see 4 claims, the 1st being an NT ACL and the other 3 being DCTM, this is what it would look like if we had the Over write attribute set to 0 marked above. We Just want to see the ACLs similar to these.

     <context name="bcondocacl"><![CDATA[ ?
winaeaqaaaaaaaacaaaaaaa  
winzo3218nb1hi3b1f3xw15ldnrqws2lupfygkltmn4rwc2bpmnwgc1lnomjrhugqkmebavkvcij4jesvczon1xazlsovzwk3q
winzo3218nb1hi3b1f3xw15ldnrqws2lupfygkltmn4rwc2bpmnwgc1lnomjrhugqkmebavkvcij4jesvczmrwwczdnnfxa
winzo3218nb1hi3b1f3xw15ldnrqws2lupfygkltmn4rwc2bpmnwgc1lnomjrhugqkmebavkvcij4jesvczmzqxg4dtojrwq
? ]]></context>

Get-FASTFiXML script:

http://gallery.technet.microsoft.com/scriptcenter/14105abb-29da-43fd-90f4-ac12f1a0233a

 

 

Are you even getting ACL information from the DCTM server?

Turn on FFDDumper, instructions on TechNet:

 http://technet.microsoft.com/en-us/query/hh285835#debug_log

Open the files FFDDumper is creating, you are looking for docacl fields with GUIDs similar to this:

34972762-7E3F-4F4F-AE5C-5ABBA92EC530:Return.DocumentumACL:31

 

Feeding Pipeline:

These two points should be added automagically when running the enable security trimming powershell script during install, always a good point to double check.

Check your pipeline to make sure the processing is set, this should be set here: 

%FASTSEARCH%\etc\config_data\DocumentProcessor\OptionalProcessing.xml

<processor name="CustomSecurityTrimming" active="yes"/>

Check the following in the pipelin configuration:
%FASTSEARCH%\etc\pipelineconfig.xml

 <!-- Added for custom security trimming -->

<processor name="CustomSecurityTrimming" type="general">

<load module="processors.CustomSecurityTrimming" class="CustomSecurityTrimming" />

</processor>

<processor name="DocumentSecurityUnknown"/>

<processor name="CustomSecurityTrimming"/>

<!-- Generate index data (fixml) from processed MPs -->

Note: If you make changes here, execute the following command psctrl.exe reset or restart FastSearch for SharePoint 2010

 

 

Machine.config security and sync problems:

By default the crawler machine.config is different than the custom security sync patch config, they should both have the setting. 

 %FASTSEARCH/bin/Microsoft.SharePoint.Search.Extended.Security.TrimmingSync.exe:

<security mode="Transport">

C$\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config:

<security mode="Transport">

 

SamWorker Log

Also you can turn on the debug logging for the authorization worker by opening the PowerShell for FAST search for SharePoint 2010 and issue
the following command:

Set-FASTSearchSecurityLogLevel -DefaultLogLevel Debug

The log file is located at:
%FASTSEARCH%\var\log\syslog\authorization-worker_<HOSTNAME>.log

Comments (0)

Skip to main content