Well, I had a great time at NASA a few weeks ago. Many thanks to Ben and Joe for help with this post. The guys (and gal – Yea! To Nancy) are pretty talented and sharp.
When we were discussing Shared Services, we decided to try to implement it in a parent/child farm environment. We had to do a number of things to get this running and are left with some quandaries which we don’t know how to solve. This post is about what we did to get inter-farm shared services working. We didn’t have time to test various permutations of these efforts, so I’ll make some comments where I think it is warranted. Here is what we did to get this going. By the way, note that this was in a test environment, not production. They have over 60 forests here, so inter-forest, multi-farm configurations is a must in this environment.
- We elevated our domain and forest to the highest levels – Windows 2003 native mode. Not sure if we needed to do this, but we did. I suspect, in retrospect, that this isn’t at all required in order to successfully implement shared services across farms.
- We setup two-way trusts between the domains in which both SharePoint farms were installed. Again, I’m thinking that a one-way trust wherein the domain hosting the parent farm (in this case, trainsbydave.com) trusts the domain hosting the child farm (in this case, student10.nasa.gov).
- We had our DNS servers replicate their zones to each other as secondary zones.
- We created a domain local group and added in the sqlservice and administrator accounts from both domains. Then we made this group the SharePoint Administrative Group in Central Administration (Figure 1).
Figure 1
- We then added both the administrator and sqlservice accounts to the Direct Access to Search Service in the trainsbydave farm’s central administration (Figure 2). Note that we had to use the NetBios name instead of the DNS-based domain name (Grrr……)
Figure 2
- On the SQL Server, we added the sqlservice account from the child domain with the dbcreator and dbsecurity rights. Interestingly enough, all this action did was give this account public access to the configdb for the parent farm. So we made the child domain’s sqlservice account a dbowner on the configdb for the parent farm.
Thereafter, we were able to connect the child farm to the parent farm by having the child farm administrator enter the parent farm’s SQL server name and configuration database name in the child farm’s central administration.
One of the changes that occurred was use the Manage Personal Sites page (Figure 3). One this page, the parent farm’s administrator must select how to handle user profiles across domains. Since this was a test environment that somewhat mirrored their real environment, we decided to use the domain_username convention and that seemed to work just fine.
Figure 3
One of the things that didn’t seem to work was search scopes. After implementing this inter-forest, parent/child farm topology, the search scopes in the child farm didn’t work as expected. The source groups from the parent farm didn’t appear in the child farm and search queries were difficult to get working.
Audiences worked fine over the trusts and shared services seemed to work pretty well relative to audiences. Since we did have a two-way trust between domains, we found that we were able to create a domain local group in the parent domain and add a global group from the child domain into the parent domain’s domain local group. We then assigned that group to an audience and we found that after the profiles were imported correctly and the audiences were compiled, that the child domain’s group membership was enumerated individually in the audience.
Speaking of importing profiles, we found that we had to enter the domain’s netbios name in the name of the new connection, but then use the DNS name of the domain in the distinguished name for the connection string. That was somewhat frustrating.
Figure 4
All in all, this was a good experience and we wanted to share our thoughts out here with you all. Please post any questions that you might have. Thanks.