Manage connections across domains in multiple forests
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2007-06-05
Some scenarios require the ability to connect to directory services across multiple forests.
Organizations often plan multiple forest deployments for the following reasons:
Service autonomy: Operational requirements indicate that services must be implemented by a particular division rather than for an entire organization, for example, geographically distributed deployments.
Service isolation: Legal or operational requirements indicate a complete separation of services is required. Hosted environments, with each customer deployment hosted on a different forest, are one example.
Data isolation: In some scenarios, organizational data is shared, but important data can only be viewed by certain people in the organization. This is relatively common for financial services companies.
Some multiple forest deployments are unplanned, and are the result of unexpected changes in the structure or business needs of the organization. Examples of those deployments include:
Mergers and acquisitions: Two or more previously distinct companies join, and users across the new organization must be able to find and collaborate with each other.
Divestitures: A previously unified domain for a single company plans to split into two or more organizations, requiring migration to two or more forests. During the migration, some level of temporary collaboration and personalization is required across the new forests.
Test forests: A hosted deployment is being tested before implementation. For most purposes, services must be distinct, but users on the test forest might still need to view information about people in other forests.
Grassroots deployments: A division within an organization has created a separate forest without central IT planning, and must be integrated into the overall deployment. During integration, some level of collaboration and personalization is required, depending upon whether the grassroots deployment is eliminated or becomes a new planned and supported forest within a unified IT plan.
While service autonomy, service isolation, and data isolation are also factors in multiple shared services provider (SSP) scenarios in Microsoft Office SharePoint Server 2007, the relevant services are different and the decision to use multiple forests is distinct from the decision to use one or more SSPs.
Directory services are one of the key services affected in all of these potential scenarios. Depending upon the scenario, you make connections to all forests in the organization that share personalized data. Directory information is then available across the shared services provider (SSP) to enable collaboration, find information about people across the organization, or target particular information to different audiences within the organization. All services other than the shared services for Office SharePoint Server 2007 retain the same degree of autonomy and isolation that existed prior to the deployment of Office SharePoint Server 2007. How much information is shared, how it is shared, and the duration for which it is shared depends upon the specific scenario.
By default, Office SharePoint Server 2007 can be configured to connect to the directory services in the current domain or forest and import directory service information from those sources. To add connections to multiple forests, you select the custom option and then configure a connection for each forest with directory information that you want to import. This enables you to import user profiles for users across multiple forests, and target and personalize content to any or all of those users.
Import connections to forests might become unnecessary over time, either because users are consolidated into fewer forests, or because there is no longer a business need to connect to certain users. Connections across forests can be removed the same way any import connections are removed. For more information, see Remove import connections.
Select people and groups across multiple forests
Additional steps might be necessary to select users across multiple forests by using the Select People and Groups dialog box, also known as the People Picker Web control. If the application pool account for a Web application has access to the other forests, that Web application will have access to personalized information, and all users in the connected forests will appear in the People Picker for the Web application. If the application pool account does not have access but the target domain or forest is trusted by the current domain or forest, you must run the Stsadm command-line tool for the People Picker on every Web application in the server farm. If the target domain or forest is not trusted by the current domain or forest, you must first run Stsadm to configure a password for all servers in the server farm where the Web application is configured. The password must be the same for all servers in the farm, and unique for each server farm. After configuring the password, you run Stsadm on every Web application in the server farm.
To manage directory service connections across multiple forest domains, you can perform one or both of the following procedures: