Windows Rights Management Services, Microsoft SharePoint Products and Technologies, and Forest Boundaries
I recently was asked about the possibility of implementing Windows Rights Management Services with Microsoft Office SharePoint Server 2007 in a resource forest, or otherwise, the Microsoft Office SharePoint Server 2007 deployment was in a forest other than that where the users reside (login forest). In this particular scenario, a one-way non-transitive trust was implemented, which provided an isolation boundary between the resource and login forest. Microsoft Office SharePoint Server 2007 is generally supportive of the resource forest concept (see posts tagged Cross-Forest Hosting) however, with the Windows Rights Management Services (RMS) cluster in a forest other than that of the resource forest, problems will surface in that SharePoint will need to obtain a RMS user certificate / RAC (from the /_wmcs/certification pipeline) that is trusted by the RMS Licensing pipeline(s) configured in SharePoint 3.
Moving site collections between domains is not a common operation, but occurs frequently enough to provide some prescriptive guidance. User Accounts SharePoint maintains the security identifiers of user accounts as opposed to just usernames, as a result, when restoring a site collection to a farm in a domain other than that where the original source site collection was located, those usernames are no longer recognized regardless as to whether or not those usernames were recreated in the target domain.
While on vacation, yes working ;-), I was asked to look into an issue where Excel Calculation Services was deployed in a cross-forest environment; specifically where Excel Services is deployed on server A residing in Forest 1 and the clients requesting workbooks reside in Forest 2. Forest 2 does not trust Forest 1; however, Forest 1 trusts Forest 2. The Excel Calculation Services topology in this scenario was fairly basic where Excel Web Access, Web Services, and the Calculation Services are distributed across two network load-balanced web front-end servers and Excel Calculation Services and any UDF assemblies are hosted on a separate application server also servicing the Office SharePoint Server Search indexing service.
People Picker works both cross-domain and cross-forest in one and two way trust environments. People Picker will issue queries to all two-way trusted domains and two-way trusted forests to search People & Groups out-of-the-box. *People Picker uses the Windows SharePoint Services Web Application logon identity to access the target domain/forest. If the Web Application pool does not have access to the target domain/forest, People Picker will need to be configured to use an account with access to the target domain/forest using the following STSADM operations:
- I haven’t revisted this post in awhile and thought I would include some additional information on the topic; in response to dkbobe’s questions surrounding updating the user information; you can use the SPUserUtility to update the tp_Login column to reflect the new domain - more information on this tool can be found at Keith Richie’s blog @ http://blogs.msdn.com/krichie. I was pleased to see my mention in Joel Oleson’s SharePoint Blog on the Impacts of Renaming a Resource Forest on SharePoint Servers; I’m hoping to elaborate more here as there is little documentation on this topic; at least from the perspective of impacts to SharePoint services.