How to Update a SharePoint User Account When They Leave the Company and Return

In this article, I'll show you how to handle a common scenario when a user leaves the company and returns later.  Many organizations delete user accounts after a period of time and when a user returns they often get a new Windows account with the same (or slightly different) account name.  SharePoint stores its own user information and associates it to a Windows account.  But rather than using the Windows account name to make the association, it uses a unique identifier called a SID.  The SID is guaranteed to be unique, whereas account names can be reused.

When someone first accesses a SharePoint site, their Windows information (including their SID) is recorded and copied into the SharePoint user store.  This information is used throughout SharePoint for things such as permissions, content authoring and user profiles.  When a Windows account is deleted, the information remains in SharePoint.  Because there can be significant history and permission configuration for a user, site administrators usually want to associate the "old" SharePoint user information with a new Windows account.  To accomplish this, you use the stsadm migrationuser operation.  I will demonstrate usage with the following scenario-based walkthrough:

John Doe has just joined the company, and IT creates a Windows account for him

A SharePoint site collection administrator grants John Doe access to the site:

 

John Doe logs in to the SharePoint site and updates his user profile:

Over the next year, John is an active SharePoint contributor and has invested hours building his profile and My Site.  Unfortunately for Litware, John finds a seemingly better position at Contoso and leaves the company.  IT disables his Windows account, and after 30 days, they delete it:

6 months pass, and John realizes Contoso isn't everything he thought it would be.  He considered moving to Adventureworks, but wasn't passionate about their product line and decides to return to Litware.  IT creates a new account for him since the old one was deleted:

John tries to access the Litware site, but receives an Access Denied message:

John contacts the site administrator and reports the problem and being a certified SharePoint administrator, he runs the migrateuser operation to link John's new Windows account with his old SharePoint information.  Note: in this example different account names are used, but when they are the same, run this command, but migrate to a bogus account such as litware\temp and then migrate from litware\temp to the new account name as outlined in this blog post.

John Doe is able to access the site and when he returns to his My Site, can see all of his old information:

 

As you can see, with stsadm, it is quite straightforward to update the association between a Windows account and a SharePoint user.

 

References and Additional Reading

• Migrateuser: Stsadm Operation (Windows SharePoint Services)
• Using STSADM -o migrateuser on a re-created account
• Security Identifier
• You receive a "Can not add the user” error message when you try to add a user to a SharePoint Portal Server 2003 portal site or to a Windows SharePoint Services Web site that is hosted on a SharePoint Portal Server 2003 portal site

Comments

• Anonymous
  August 14, 2008
  PingBack from http://housesfunnywallpaper.cn/?p=852

• Anonymous
  March 09, 2009
  Does this command also update user information that is changed in active directory and not updated on sharepoint?

• Anonymous
  March 16, 2009
  If the old user and new user is having the same LAN ID (remove from AD then create a new account with the same LAN ID, no issue at AD side) but they are actually different person, when i assign the new created AD account to sharepoint site, i got access denied page ( even i deleted the old user from the site collection ) ? any advise ? thks.

• Anonymous
  October 13, 2009
  This was just what I was lookin for.  Thanks old friend.

• Anonymous
  January 26, 2010
  Last time I checked Security Identifiers (SID) were only guaranteed to be unique within a single Active Directory domain.  This is why there are multiple technet articles on why you should Globally Unique Identifier (GUID) instead if you require a truly globally unique identifier.  Way to drop the ball again Microsoft.

• Anonymous
  February 01, 2010
  Hi, We have a user that has been given a new username, and I have followed the steps specified above. When I open one of the sites the user has access to, I can see under Site Permissions that the account has successfully changed from oldusername to newusername. The permissions are also maintained (Full Control). However, when the user tries to log in to the site, he gets the Access denied page. Do you have any idea why this is so?

• Anonymous
  August 06, 2010
  The user's dept and the designation is not showing correctly even though i modified the userprofile. Can any one help to fix this?

• Anonymous
  October 11, 2011
  In the example of a user leaving the company. Shouldn't the Sharepoint synchronization remove the SID if it no longer sees it AD? In the company I work for we hire up to 1000 people at a time for temporary work and then they are let go, then in another 6 months we would hire another 1000 people. Some of the AD User ID's get reused but and sharepoint holds onto the old SID of that user ID. If synchronization is setup correctly in SharePoint shouldn't these olds SID's get removed ???