I see this come up quite a bit and thought I would show you how to work around the problem. I thought I had show this on my old blog a couple of years ago, but can’t seem to find it.
Scenario
A user in your organization is deleted, and re-created using the same domain and sAMAccountName. This may have been because of an accident, or a previous employee who left your organization and was then rehired.
For example, my account in the NA domain with a sAMAccountName of krichie (NA\krichie). The account was deleted and re-created with the same sAMAccountName (NA\krichie)
Because SharePoint stores SID information with the user in it’s tables, the account will no longer work until you either
1) Remove the user completely and re-add, or
2) Use the STSADM -o migrateuser command
The problem, is that if you try to use -o migrateuser such as:
STSADM -o migrateuser -oldlogin na\krichie -newlogin na\krichie -ignoresidhistory
The command will fail reporting “Cannot complete this action…Please try again”
Cause
This is because the -oldlogin and -newlogin arguments are the same. As far as stsadm -o migrateuser is concerned, there is nothing to migrate.
Solution
The solution is to migrate the user to a temporary account and then back from the temporary account to the new account with the same name such as:
STSADM -o migrateuser -oldlogin na\krichie -newlogin na\temporaryaccount -ignoresidhistory
STSADM -o migrateuser -oldlogin na\temporaryaccount -newlogin na\krichie -ignoresidhistory
MigrateUser will then see that the accounts are different and allow the operation to be performed. You then just run again from the temporary account to the new re-created account and your good to go.
HTH
- Keith
[...] 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 litwaretemp and then migrate from litwaretemp to the new account name as outlined in this blog post. [...]
Pingback by John W Powell : How to Update a SharePoint User Account When They Leave the Company and Return — August 15, 2008 @ 7:45 am
Are there some other steps after the temp trick – I ran the commands successfully but the user still has her old name in WSS…
Comment by jekora — August 19, 2008 @ 1:20 pm
Thats actually the “Display Name” on that associated record…You will have to update that as well.
migrate does not refresh the display name for the user
Comment by Keith Richie — August 19, 2008 @ 8:58 pm
When I use “Temporary” in the command line, it says “Invalid userid”. Is there any other method to sync the old and new id ?
Please help.
Comment by Vishi — August 27, 2008 @ 3:18 pm
The purpose of the placeholder text “na\temporary” was not to actually use that explicitly, but rather as a moniker to be replaced by an actual temporary account. I’ll update the post to make that more explicit
Comment by Keith Richie — August 27, 2008 @ 6:52 pm
Hi Keith,
I have a custom page that uses SPContext.Current.Web.CurrentUser.LoginName to display the login id of an user.
I have a test account in AD (xxx/testacc) that was imported to MOSS. When logged in to the custom page, the value of the SPContext.Current.Web.CurrentUser.LoginName was correctly displayed as xxx\testacc.
For some reasons, I changed the ID in AD to xxx\test and did a full import to MOSS. But when I access the custom page, the value of SPContext.Current.Web.CurrentUser.LoginName still displayed the old ID, i.e. xxx\testacc.
I’ve tried the stsadm command in one of your posts (http://blogs.msdn.com/krichie/archive/2006/08/04/688571.aspx) but I got the error “Cannot complete this action”.
Is there any other action that I’ve missed?
Appreciate your help!
Comment by Kelvin — September 16, 2008 @ 1:27 pm
By the way, I forgot to highlight that while using the stsadm command, the old and new login values were different but I still had the error. Thanks
Comment by Kelvin — September 16, 2008 @ 1:43 pm
Kelvin,
What exact syntax did you use?
Was it:
STSADM –o migrateuser –oldlogin xxx\testacc –newlogin xxx\test –ignoresidhistory
Ensuring that you included the “-ignoresidhistory” option?
Also, you mention “full import”…Do note, that MOSS Profiles have nothing to do with Site Security.
Comment by Keith Richie — September 16, 2008 @ 6:47 pm
Hi Keith,
Yea I did just that. STSADM –o migrateuser –oldlogin xxx\testacc –newlogin xxx\test –ignoresidhistory.
Not sure if it was due to the account as I’ve done a lot of testing on this account. Delete, import, update, etc
Perhaps the statement couldnt work because of that.
Anyway I re-created a brand new account (xxx\bryantay), changed the ID to xxx\btay after that and run the stsadm commandm, it worked perfectly fine but SPContext.Current.Web.CurrentUser.LoginName still displayed the same old account (xxx\bryantay)
Does this stsadm command update tp_Login in the content DB? I found out that SPContext.Current.Web.CurrentUser.LoginName actually grabs the value of tp_Login in the content DB.
Thank you once again.
Comment by Kelvin — September 17, 2008 @ 8:21 am
It does update the tp_Login, I just tested this and validated.
Also in my test, SPContext.Current.Web.CurrentUser.LoginName is returning the updated loginname.
Comment by Keith Richie — September 17, 2008 @ 8:30 pm
That’s weird.. Now I could get tp_Login updated with the command after I tried on a brand new account.
By the way, does stsadm -o migrateuser command update the values of tp_Email and the other properties in userdisp.aspx? It seems like only tp_Login is updated. If this is the case, any way that I can update what are being displayed in userdisp.aspx?
Thank you!
Comment by Kelvin — September 18, 2008 @ 12:48 pm
migrate user does not update that information. You either have to do it manually, or through code.
:)) that folks have told me about.
I have code in my old SPUserUtil for V2, and we have a feature for that, for which we are including into DeliverPoint in the future.
There is a setting if you have MOSS, that will take profile information and synch it down to the WSS Security data, but I’m not familiar with how to set it up (Nor where to go
Comment by Keith Richie — September 18, 2008 @ 7:44 pm
I’m about to migrate a SharePoint server and approx. 1000 users to another forest. From what I understand the SPUserUtil is no longer available? Is the STSADM -o migrateuser the best way to go or is there another tool that you can recommend to update the SPS-Users?
Regards,
Michael
Comment by Michael — September 24, 2008 @ 3:29 pm
It is the way to go. In MOSS, STSADM -o migrateuser takes care of the users Profile as well (In SPS2003, you had to call the additional Portal API call to make that happen).
Comment by Keith Richie — September 24, 2008 @ 8:25 pm
Hi Keith, the issue is not yet resolved even when the below commands are executed. Is there any other method to resolve the issue:
STSADM –o migrateuser –oldlogin domain\userid –newlogin domain\testid –ignoresidhistory
STSADM –o migrateuser –oldlogin domain\testid –newlogin domain\userid –ignoresidhistory
Comment by vishi — October 17, 2008 @ 3:27 pm
What exact issue is it that is the problem? Is it the stsadm command is returning an error? Or the end result is not what you expected…If the end results, what is the exact end result you’re looking for?
Comment by Keith Richie — October 17, 2008 @ 5:57 pm
Keith,
Having a similar problem. I’m trying to run the stsadm -o migrateuser command but am getting a “Unable to connect to database. Check database connection information and make sure that the database server is running.”
Database is running fine and feeding numerous business apps as well as a WSS and MOSS server on top of the dev WSS environment I’m testing the migrateuser command.
Actual command:
stsadm -o migrateuser -oldlogin xxxx\GADTest1 -newlogin xxxx\GADTest2 -ignoresidhistory
Any ideas?
Comment by Dave Gerrard — November 21, 2008 @ 12:20 pm
Not sure Dave, don’t think I’ve ever seen that problem before.
Comment by Keith Richie — November 24, 2008 @ 9:09 pm
Dave,
I’m having the same problem. Have you found a solution for it?
In the event viewer the error says it cant find the mysite db, but in the console it gives the same error as you got. Ideas?
Comment by Håvard — December 6, 2008 @ 6:56 pm
Keith,
When trying to migrate due to a change of AD, for some users I am getting “Your changes could not be saved because this SharePoint Web site has exceeded the storage quota limit”. Any ideas? Even when it works, when they log on their My Site is not the old one.
Comment by Michael — December 23, 2008 @ 7:55 am
Dave,
Ensure the account you’re running stsadm under IS a member of the local administrators group and has dbwrite access on the content databases. See http://blog.krichie.com/2008/09/11/unrestricted-access-via-sharepoint-object-model-from-console-applications/. The same applies to the account running STSADM.
Michael,
for the MySite, if theyre alias structure has changed, that may be what is causing MOSS to redirect to a new mysite url. There is a setting (Can’t remember where) that determines the URL structure for the mysite…for instance http://mysite/alias or http://mysite/fname.lastname etc It could be, that since the structure of their login alias has changed in a way that MOSS doesn’t redirect to the appropriate mysite anymore.
Comment by Keith Richie — December 23, 2008 @ 6:44 pm
Hello!!
First of all thank’s for greate blog.
But my question is – is there any way to update AD group on the sharepoint portal when it’s renamed?
With users all is ok, but when i try to apply migrateuser i get an error…
Comment by Wladymyr — January 27, 2009 @ 8:34 pm
I don’t see a way. The error clearly states that -o migrateuser cannot be used for it.
Comment by Keith Richie — January 27, 2009 @ 8:54 pm
I have an issue where the user name in AD Tax4 is fine and shows up ok in SharePoint. The name of the person logging in as Tax 4 was Paul last year and this year it is Sonia. How do I get SharePoint 2003 list of users to show Sonia’s name vs Paul’s? I have deleted the user and added them again starting with the correct email address for sonia vs Paul. It adds the acct back in again with Paul as the User listed still for Tax 4?
Hopefully you have some bright idea. If not I will end up just totally deleting the tax4 user and start with a new user acct that sharepoint has never had it it’s info.
Comment by David S — February 11, 2009 @ 1:25 am
David, is it the User Name in AD that is Tax4 or the samACcountName ? Based on your description, I’m assuming that Tax4 is the samACcountName, i.e. yourdomain\tax4 and the display name of the user was chaned from paul to sonia.
If that’s the case, SharePoint caches the display name of the user once it’s added to a site collection, and doesn’t refresh it until the user is completely eliminated from the site collection (Not just a site/web within the site collection) and added back in.
The individual user can update their information in SharePoint or the administrator can do it by visiting the siteusrs.aspx page for every site collection.
Comment by Keith Richie — February 11, 2009 @ 9:58 pm
Here’s a good one. I am trying to migrate some users permissions that had sharepoint only accounts on one domain to their newly created permanent domain accounts. When I run it first time with the -ignoresidhistory I get “Error Migrating User Profile.” and if I take the -ignoresidhistory off I get “New User account does not have valid SID history.” But here’s the kicker, if I run the -ignoresidhistory option on again for the same user it works “operation completed successfully.” I don’t get it???
Comment by Brian — March 11, 2009 @ 3:12 am
Turns out that even if I leave -ignoresidhistory on and just run it twice it works. First time getting the error migrating user profile, and then the second time it works…
Comment by Brian — March 11, 2009 @ 8:11 pm
Hi Kieth,
For some issue with our AD, I see two profile records for some of the user account. So when we do a people search, it gives two search result for the same user. At the same these users are facing error “The file exists. (Exception from HRESULT: 0×80070050)” when the go thier MySite.
I think this problem is related with SID value, how migrateuser can help me solving this issue?
Thanks,
Pat
Comment by Pat — March 25, 2009 @ 12:12 am
Pat, sounds like you migrated your accounts to a different domain, and your profile import is picking them up from the new domain, thus you have two records for the account.
You should use migrateuser from the old account to the new one, and the MySite should be able to then hook back up to the proper account.
Comment by Keith Richie — March 25, 2009 @ 9:36 pm
do you know any other causes of the command failing reporting “Cannot complete this action…Please try again” -I’m migrating between domains and about 20% of users fail with this message -I cannot see what they have in common. If I migrate to a temp account then onto the new domain the failure happens in migrating from temp to final destination, not in the first migration.
thanks
Richard
Comment by Richard — May 11, 2009 @ 10:41 pm
are you supplying the -ignoresidhistory flag?
Comment by Keith Richie — May 12, 2009 @ 7:49 pm
I’m only trying a domain migration rather than dealing with re-created accounts.
yes alway appending -ignoresidhistory – the migration fails otherwise
I’m hoping the “User Profile Sync” from bamboo solutions will tidy up data taken from AD once I have migrated -has anyone had good experiences with this?
thanks
Comment by Richard — May 12, 2009 @ 8:26 pm
It’s days like this I wish I would have done a V3 version of SPUserUtil
.
Not sure what might be going on then Richard.
I personally have not used the Bamboo Solutions solution Richard.
Comment by Keith Richie — May 12, 2009 @ 8:30 pm
Hey Keith,
I’m getting an issue with stsadm -o migrateuser -oldlogin xxx\test1 -newlogin xxx\test2 -ignoresidhistory. It says “Error migrating user profile.” The interesting thing about this account is that there are actually 2 accounts with the same login in the SQL database. My guess is that it is confusing the two accounts and so therefore cannot migrate the user. Any idea of how to get around this? Also, the two accounts cause problems with assigning metadata on import using stsadm.
Thanks.
Comment by Andrew — June 29, 2009 @ 8:33 pm
I suspect that you did a profile crawl before you started migrating accounts, therefore a profile record for test2 already exists? If so, when it tries to update the test1 profile, there is a collision because a test2 profile already exists.
You would probably need to remove the test2 profile and try again.
Comment by Keith Richie — June 30, 2009 @ 9:25 pm
Great article as for me. I’d like to read more concerning that matter.
Comment by StephanJade — October 21, 2009 @ 6:48 pm
Great post, is there any way to do a bulk user move? as in moving a hundred users or is it an individual process?
Comment by Bryguy — October 23, 2009 @ 10:43 pm
BryGuy, no way in the product itself to bulk migrate. It’s an individual process.
Of course you could script the calls to it for all of your users.
Comment by Keith Richie — November 4, 2009 @ 2:44 am
Rather interesting place you’ve got here. Thank you for it. I like such themes and everything that is connected to this matter. BTW, try to add some images
.
Comment by Passer-by — January 15, 2010 @ 12:15 am
great! thks
Comment by Niccollas — March 29, 2010 @ 8:21 pm
Thumbs up! Made good use of this today.
Comment by Henry Ong — April 6, 2010 @ 11:13 pm
Try to install the hotfix KB961176. the issue is fixed this article
Comment by Inder — July 13, 2010 @ 9:09 pm
Hi guys,
We have just lost our Active Directory and we managed to create again all users with the same login details.
Of course there are new SID so I had to run this migrateuser thing. I didn’t got any errors but unfortunately for those lists (for example tasks list) which had some data linked to users “Person and Group field” it doesn’t really re-map to the new user…
We have SP 2010…Any ideas?
Comment by calin — July 19, 2010 @ 11:48 pm
For the purpose, we had created an in-house Test environment; which is comprised of 2 “Virtual Machines”, ONE front end virtual server with Microsoft Windows 2008 and WSS 3.0 SP2 and ONE back end virtual server with Windows 2008, SQL SERVER 2008. Also, we kept the “domain name on test server exactly the same as on Live i.e. http://www.virtualpensionmanager.local” in a bid to reduce permission issues that would occur on Application restore.
We thought since domain names are same so there won’t be any issues if we manually create the users in Test AD with the same permissions as on Live AD and they will be recognized by the restored application as well. But, when we restored the application (using STSADM backup/restore) it appeared that the Test server is not recognizing those accounts manually created in its AD.
We did a some research on that and obtain an opinion from one of the experts, who informed us that there is a hidden unique id “Security ID (a.k.a sID)” associated to each user and when you manually creates a user it got change may be which might be the cause. Therefore, he suggested User Migration through ADMT v3.1 tool by Microsoft, which appears to be a very complex tool. Also, in a discussion with one of Microsoft TechNet guy he revealed that it doesn’t work for same domain names.
Someone else told me to try Stsadm Migrateuser command on the test server.
I created a user (with the same login names etc. as was on Live AD) and execute the following commands on my test server as:
stsadm -o migrateuser -oldlogin abc.local/s.wilton -newlog
abc.local/s.wilton -ignoresidhistory
Also, tried with a Temporary account with ignoreSid flag but the error is same as below
Error Message in both cases: “Cannot Complete the Action”
Please, I desperately need a solution as the deadline is approaching fast I am stuck with AD users problem from quite sometime. Please suggest me what’s the easiest possible way to migrate users from Live AD to Test AD or do something that my application start recognizing those users.
Comment by Ahmad — August 17, 2010 @ 10:04 pm
The domain name is virtualpensionmanager.local which is same for both live and Test servers however both the domains are within completely separate networks.
Comment by Ahmad — August 17, 2010 @ 10:05 pm