Moving content database to new domain (Move-SPUser behaviour)

Question

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 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.

Answer 1

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

Source

Answer 2

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.

Answer 3

$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

Answer 4

I got the same error you describe because there were no trust available between the old domain and the new domain. To overcome the error one need to instantiate the old user object with the web attribute to avoid getting an array of the same user instead of an item. Like this:

$user = Get-SPUser -Identity "OLD_DOMAIN\old_username" -Web https://site_collection_url

Then you should be able to run the Move-SPUser with IgnoreSID attribute to update the user information list as well.

Move-SPUser -Identity $user -NewAlias "NEW_DOMAIN\new_username" –IgnoreSID

If this doesn’t work, it may be that the new Web App uses claims, and you need to add the horrific Claims Prefix i:0#.w| before the username.

Move-SPUser -Identity $user -NewAlias "NEW_DOMAIN\i:0#.w|new_username" -IgnoreSID