Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I've got a customer needing to move their SharePoint 2010 install to a new domain, I've done some reading and looks like I can mount the content DB to a web application which I've basically setup in the same way as the current one then get into it by altering the site collection admins for its site collections. The main issue is that I believe the AD user migration will generate new SIDs for the accounts in the new domain so I will be looking at having to run something like this:

Move-SPUser –Identity olddomain\UserName - NewAlias newdomain\UserName

The customer has given their new domain the same NETBIOS domain name as the old one. I know this is somewhat a bit hypothetical at the moment but will I even be able to run the cmdlet above?

Edit: 04/09/2012 - I undertook this exercise today with some mixed results (using this post and slightly modified script where it links to http://sharepointsurfer.wordpress.com/2012/01/31/the-easy-way-to-restore-a-sharepoint-2010-content-database-to-a-different-domain/), whilst the user accounts that existed in the new domain appear to have gone through the AD Groups when attempting to execute Move-SPUser on those throw the following error:

Move-SPUser : Operation is not valid due to the current state of the object.
At line:1 char:12
+ Move-SPUser <<<<  -IgnoreSID -Identity $user -NewAlias DOMAIN\domaingroup
fcontentapprovers -confirm:$false
    + CategoryInfo          : InvalidData: (Microsoft.Share...PCmdletMoveUser:
   SPCmdletMoveUser) [Move-SPUser], InvalidOperationException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletMoveUser

This web application is just using classic mode auth and most of the topics I've found on this error related to claims based or moving to claims based auth. I've had to work around this by adding other AD groups with the same membership into the existing SharePoint groups. But this is messy.

This site is running just SharePoint 2010 SP1 at this point in time, I have read that there were some changes that came out for the move-spuser cmdlet in the June 2011 CU so if anyone is aware of that improving the situation I might apply the August 2011 or June 2012 CU.

share|improve this question

4 Answers 4

You should pass the same user name as OldUser and as NewUser, note the IgnoreSID parameter. This will get new SID from AD for that account and update that in userinfo tables.

Move-SPUser -Identity "DOMAIN\OldUser" –NewAlias "DOMAIN\NewUser" -IgnoreSID


share|improve this answer
up vote 1 down vote accepted

The actual Move-SPUser cmdlet works fine on individual users so I generally had success with that, however for AD Groups I found I couldn't use Move-SPUser on those, so I ended up having to re-nest groups with different names inside of the SharePoint groups. The main hassle with this was that I ended up creating AD groups with the same name as the ones that existed in the original domain. So it was very confusing, plenty of referencing the User table in the Web Application DB even had to run the Remove-SPUser cmdlet on some users that just didn't seem to be recognized even though the account was associated with the web app and the account was in the user table with a different SID. So in general, it was a messy process that was difficult to verify because the accounts and groups had the same name on the surface. So far I haven't had any real reported issues with the site only 1 or 2 so far, its been 3 months so far.

share|improve this answer

$farm = Get-SPFarm $farm.MigrateGroup($.oldlogin, $.newlogin)

worked for me.

I followed article: http://blogs.msdn.com/b/sowmyancs/archive/2012/01/07/migrate-users-groups-powershell-script.aspx?PageIndex=2

share|improve this answer

Hi there i think if its the same name it should be fine if it recogonises its the same domain name. I would like to know how it comes out though

share|improve this answer
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. –  Hugh Wood Dec 5 '12 at 15:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.