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.
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 :):)) that folks have told me about.
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