As companies get acquired or you migrate off different platforms to AD, there can be quite a mess in terms of Domains and Forests.  Lots of ambitious IT folks try and keep a handle on this and consolidate domains quickly as things change.  This is a great idea, and keeping things simple is definately the way to go.

What some IT folks have run into is the evil nemesis: SharePoint.  Specifically the fact that SharePoint keeps its own database of users based on a combination of domain\username and SID.   When a user is migrated from domain to domain, both the domainname\username and SID change and SharePoint needs to be updated or there will be a mismatch of SharePoint’s database and Portal, Team and MySite ACL’s won’t be accurate making them inaccessible.

Alas, SPS and WSS SP2 expose a migrate function in the API.  STSADM.EXE has a migrateuser switch that allows you to migrate WSS users.  SPS of course rarely supplies any meaningful command line tools for migration.  But, Keith Richie has written a tool called SPSUserUtil, included on the SharePoint Utility Suite that uses the object model to allow you to migrate users from the command line.

In our scenario, we were migrating batches of users every night and needed to make a smooth transition within SharePoint.  So, we ran through these basic steps each night:

1. The AD guys supplied a list of accounts (text file) that will be moved each night in domainname\username format  Call the file: PhaseNUsers.txt

3. Prep the accounts in AD using a tool from Quest Software that copies the account to the new domain, migrates SID history and disables the account in the new domain.

4. Run SPSUserUtil against the SPS Infrastructure to get a list of users for all portals.  Repeat this process for each portal by replacing the URL with the real URL, because of a small bug in Keith’s app you need to run it both on the top site and subsites and combine them together.  Command line examples:

1. Main Site: SPSUserUtil.exe -o analyze -url http://companyweb -usermap mainportal.xml –r

2. SubSites: SPSUserUtil.exe -o analyze -url http://companyweb -usermap subsites.xml -r –ac

5. Concatenate mainportal.xml with subsites.xml to form PhaseNSPS.xml

6. We wrote a small parsing app that runs through the XML output from the steps above and edits the newloginname=""  field with the new domain credentials.  Example of our app:

1. SPSUserXML.exe PhaseNSPS.xml PhaseNNewUsers.xml PhaseNUsers.txt NEWDOMAINNAME

7. Now that you have an XML file with the new domain name, run SPSUserUtil against the SPS Infrastructure using the following command:

1. SPSUserUtil.exe -o migrate -url http://companyweb -usermap PhaseNNewUsers.xml

8. Validate SPS, Team sites, and MySites are working with one of the migrated users.

Make sure and test this in your scenario, but it should give you a jumpstart on fighting with SharePoiont during domain consolidations.