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:
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

Then get a farm object:
$spFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local

And finally use the
$spFarm.MigrateUserAccount("OLDDOMAIN\OLDUSERNAME", "NEWDOMAIN\NEWUSERNAME", $False)

The first parameter being the original domain name and user name
The second parameter is the new domain name\user 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["NEWDOMAIN\NEWUSERNAME"]
$spUser.Name = "NEW USER DISPLAY NAME"
$spUser.Update()

A good movie match for this post could be Face/Off directed by John Woo, the "unofficial inventor" of slow motion.

And cut!

Sometimes AD is not the preferred source for profiles information. Sometimes you feel like BDC is really a pain to configure. Sometime a colleague of yours comes with a plain CSV file which contains the perfect information in order to update your MOSS user profile information… Time for Jason to recover his identity ;)

First, let’s load the necessary assemblies:
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.Administration")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")

Then instantiate the server context and the profile manager
$spSSP = [Microsoft.Office.Server.ServerContext]::GetContext(“MySSPName”)
$spUserManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($spSSP)

Note: if you have no clue about the name of the SSP, you can check in the Central Admin web site or retrieve it from an existing web application bound to it.

Now that you have a Profile manager ready, you have to create a Profile object for each profile you wish to update. Since the code would eventually fails if no profile exists, you can also test if it exists first:
$spUserManager.UserExists("THREADSTONE\jbourne")
If it result returns “True”, you can go further, if not, you can skip that user or instead, create a new profile by executing:
$spUserManager.CreateUserProfile("THREADSTONE\jbourne ")

Then instantiate a profile object for that user:
$spUserProfile = $spUserManager.GetUserProfile("THREADSTONE\jbourne ")

And populate one or more properties:
$spUserProfile["Department"].Value = "Secret Services"

If you’re clueless about the list of properties you can update, simple retrieve them with the following command:
$spUserManager.Properties|SELECT displayName,Name

Once you’re done, save the changes using the commit method (and not update()!):
$spUserProfile.Commit()

And cut!

Greets to W. N. who inspired this post ;)