With the early days of SharePoint, changing user accounts in order to reflect user changes in Active Directory after domain migration, migration or split was a nightmare.
With WSS2/SPS2003 and assuming you have compiled the excellent SPSUTIL tool , the situation was much better though not perfect (Anthony, the other Windows Director, suffered a lot from this in a previous job actually, who did not?).
With the WSS3/MOSS era, STSADM now comes with the built-in command “–o migrateuser” in order to do the job. So why bother turning this command into PowerShell? Simply because it greatly eases the automation since you can write custom scripts to scan AD, parse XML or CSV and finally update your SharePoint content DB’s accordingly. The code is incredibly simple, just like the command is:
First, load the assemblies as usual:
Then get a farm object:
$spFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local
And finally use the
$spFarm.MigrateUserAccount("OLDDOMAINOLDUSERNAME", "NEWDOMAINNEWUSERNAME", $False)
The first parameter being the original domain name and user name
The second parameter is the new domain nameuser name
And the third is Boolean indicating sidhistory on the new user should be used or not.
Keep in mind that while this code will modify the “Account” attribute of a user through the farm, it will not change the “Name” attribute. %If you wish to change this name and you’re lucky enough to operate MOSS, you can rely on the profile import process (see my previous post for some Powershell automation), if, on the other hand, you run WSS3, you’ll have to go through extra code that does some iterations in all your sites and modify the contents of the list named “User Information List” in each of them. The Powershell to update the list would look like:
$spUser = $spWeb.SiteUsers["NEWDOMAINNEWUSERNAME"]
$spUser.Name = "NEW USER DISPLAY NAME"
A good movie match for this post could be Face/Off directed by John Woo, the "unofficial inventor" of slow motion.