[Important News!]
I’ve kicked off a new project/band where I’m creating music with a heavier techno/metal sound called binarywaste. You should check it out by clicking right here!
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
Keith Richie 
Are there some other steps after the temp trick – I ran the commands successfully but the user still has her old name in WSS…
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
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.
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
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!
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
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.
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.
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.
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!
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.
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
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).
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
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?
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?
Not sure Dave, don’t think I’ve ever seen that problem before.
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?
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.
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 https://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.
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…
I don’t see a way. The error clearly states that -o migrateuser cannot be used for it.
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.
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.
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???
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…
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: 0x80070050)” when the go thier MySite.
I think this problem is related with SID value, how migrateuser can help me solving this issue?
Thanks,
Pat
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.
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
are you supplying the -ignoresidhistory flag?
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
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.
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.
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.
Great article as for me. I’d like to read more concerning that matter.
Great post, is there any way to do a bulk user move? as in moving a hundred users or is it an individual process?
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.
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 :).
great! thks
Thumbs up! Made good use of this today.
Try to install the hotfix KB961176. the issue is fixed this article
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?
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.
The domain name is virtualpensionmanager.local which is same for both live and Test servers however both the domains are within completely separate networks.
Hi Keith, how can we update the Display name? I have used the stsadm tool to migrate users from one Domain to a new Domain but they still disply as OldDomain\username?
The migrated accounts appear to have the correct access, however we would like to have display names correct for housekeeping.
We have the exact same issue.
SP 2010 Foundation and using STSADM to migrate user accounts when the AD accounts are moved from one domain to another.
Issue is that in one site collection, the display name of the migrated account is “OLDDOMAIN\OLDACCOUNT” and not “First name, Last name” as it was previously. Strangely when we move to other site collections within the same web app, the display name is correct.
Any hints?
Kenneth,
There is a seperate record kept for the user in each site collection. The display name is derived from the membership store (in this case AD) the first time it is added to a site within the site collection.
It would appear to me, that at some point when the account was originally added, it used that as the display name more than likey when an issue with AD was going on, and the display name could not be retrieved. Just a guess of course.
When you use STSADM migrate, it does NOT change the display name of the account. I would just visit this one site collection and change it manually.
Keith,
I am trying to migrate groups using SPFarm.MigrateGroup but am getting the dreaded “Your changes could not be saved because this SharePoint Web site has exceeded the storage quota limit” error. Is there any way to capture what site is sending back this error? I think it’s being caused because it’s trying to change a group that has access to all of our MySites, and it’s hitting a MySite that is at its storage limit. The thing is, we have thousands of these and I don’t know which one is causing it. Is there any way to get under the hood of MigrateGroup()?
Thanks,
Patty
Patty,
Look in your servers event logs and you should find an error/warning about a site exceeding qouta (Sorry don’t have the exact event format at hand).
Execute stsadm -o enumallwebs and save it’s output to a file.
Take the Site GUID listed in the event error and search for it in the enumallwebs output and you should be able to pinpoint the problem site
Thanks, Keith! Should I look on the web servers or the app server? (we have a farm with 2 web servers, one app server, and one db server).
Patty
Check them all 🙂
Is there a what to convert Domain Groups? Like say “\Domain Users” to “\Domain Users”.
I was recommended this web site through my
cousin. I am not sure whether or not this submit is written
by him as nobody else understand such designated approximately my difficulty.
You’re incredible! Thank you!
Oh my goodness! Impressive article dude! Many thanks, However
I am experiencing issues with your RSS. I don’t understand the reason why I can’t join
it. Is there anybody else having similar RSS issues?
Anyone that knows the answer will you kindly respond?
Thanks!!
I have a question about your blog entry. In my situation, the user’s login username actually changes within AD. For example, xyz91 becomes xyp91 (marriage, divorce, bored with name, etc.).
I can’t do a migrateuser before the new account is created, because it won’t exist and I don’t want the user to lose the ability to use SharePoint.
However, when I have tried to do it after the user’s login has changed, I have gotten an error because the old name no longer exists.
In your example above, I presume that the temporaryaccount and kritchie co-existed.