It's common for SharePoint administrators to get a request to update someone's name in SharePoint as a result of marriage. The trusty STSADM migrateuser command has been around since MOSS 2007 as a method to update references from the old account to the new account.
In my experience, AD admins tend to rename existing accounts as opposed to creating new accounts and decommissioning old ones. Once the account has been renamed, migrateuser can be used in the following fashion to update the SharePoint profile data:
stsadm.exe -o migrateuser -oldlogin domain\originaluserlogin -newlogin domain\newuserlogin
Sometimes this command will return a message "
New user account does not have valid SID history.". If this is the case, you can add the
-ignoresidhistory argument and cross your fingers that you get a response "
Operation completed successfully."
If you do not get a successful message, you may instead see this:
Value cannot be null.
Parameter name: userProfileApplicationProxy
Many search results will point you towards verifying that you are a farm administrator, and of course you are in the farm administrator group, so you brush this off and move on. Some results point towards a promising PowerShell command Move-SPUser:
Move-SPUser -Identity domain\originaluserlogin -NewAlias domain\newuserlogin
Unfortunately for me I recieved the error:
The parameterless Read method can only be used when this instance was initialized with an SPUser object.
Using Get-SPUser to store the user login in a $user variable to be passed into Move-SPUser returned yet another error:
You must specify a valid user object or user identity.
So the old user doesn't exist in the web anymore, yet when I view the user profile for the user in the User Profile Service in Central Administration, the old login name is still displayed next to all the updated profile information. Somewhere the old login is still hanging around, so back to
migrateuser!
The solution for me was indeed related to the account used to run the migrateuser command. Evidently being a farm administrator is not enough, you need to use the
FARM Account. To find out exactly what this account is, open up Central Administration and click on
configure service accounts under the Security heading.
Select Farm Account from the drop down box, and the page will refresh and list an account name in the bottom drop down box. This is the account you need to
log in to the SharePoint server. I tried using the Run As Another User command on the SharePoint Management Shell and that did not work, you will get a message
Access Denied when you do that. When you login to the server, right click SharePoint Management Shell and choose Run as Administrator.
Hopefully this time you will breathe a huge sigh of relief as you see the coveted
Operation completed successfully message.
