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