How to map SharePoint users from one domain to another, complete with file history and ownership
The Scenario
A business unit of a larger company has hired my team for a SharePoint Migration Project. We’ve done a lot of upgrades from the 2003 technologies to the 2007 products, but this one has a twist. The group’s SharePoint Portal Server 2003 environment exists in a legacy Active Directory Forest. The new Microsoft Office SharePoint Server 2007 environment will be on a new Active Directory Forest. You could consider it an upgrade with a domain migration. The upgrade is fairly straightforward, but a mapping is required for the domain migration. Each user in the old domain maps to a new user account in the new domain. Each user’s permissions and file ownership in 2003 in the old domain will be transferred to the corresponding user account in the new domain in the SharePoint 2007 Environment.
The Challenge
Moving from one forest to another is a common scenario, especially in Mergers and Acquisitions, but relatively little documentation exists for this scenario in SharePoint. Apparently, there is little out of the box included to help with this besides one stsadm operation, migrateuser, for transferring permissions. Of the many vendors that offer Third Party SharePoint Migration tools, at least three don’t cover this domain migration scenario. Transferring file ownership from one user to another doesn’t even seem to be on the radar of AvePoint, Metalogix or Quest.
One Solution
One 3rd party tool does help with domain migrations and even transfers file ownership. Take a look at the following two screenshots from a Tzunami Deployer migration scenario on my test VM’s. The first is a Team Site on WSSv2 in the fictional BoscoCorp.local forest. The second is the deployed Team Site in MOSS 2007 on the fictional Popsco.local forest. In this example, there was no trust between the two forests, but the users were still correctly across domains.
Figure 1
Figure 2
The Details
Behind the scenes, Tzunami Deployer is reading information from the SPS 2003 source and writing to the SharePoint 2007 API. Tzunami support assured me that they do not write directly to the database in SharePoint 2007. Good thing, as this is a strict no-no for support from Microsoft. This limitation became especially clear when I asked why my SPS Portal site hadn’t transferred. As you can see from the above screen shots, Tzunami does an excellent job on a Team Site Migration. However, a limitation of the API prevents creation of Collaboration Portal Site Collection Templates, so this step must be completed manually. Below is a screenshot of the product. It shows the project I created for the above Team Site migration.
Figure 3
In Figure 3, you see a Site Collection, Popsco Portal, that was created in Central Admin with the Collaboration Portal Site Collection Template. The Bosco Administrator Site shown in the first two figures was moved under this Site Collection using the Deployer project shown above.
For More Information
- Migrateuser: Stsadm operation (Office SharePoint Server), Microsoft Technet, Updated: 2007-06-14
- A few notes about STSADM –o migrateuser, Todd Klindt’s Blog SharePoint MVP, 7/29/2008
- Using STSADM -o migrateuser on a re-created account, Keith Richie ShreaPoint MVP, June 27, 2008
- Tzunami Deployer, Metalogix and an apology, Ishai Sagi SharePoint MVP, February 04, 2008
Leave a Reply