5

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.

1
  • 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
    – naijacoder
    Aug 22, 2012 at 6:11

4 Answers 4

5

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

0
1

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.

1
  • Pretty sure you could still use the STSADM command for group migration "stsadm –o migrategroup –oldlogin Domain\group –newlogin Domain\group" you need to ignore the SID's with your MoveSPUser PS commaind by adding –IgnoreSID and not sure if but Move-SPUser has an -AssignmentCollection for group migration as well. Also @McaZac 's solution is a good one for moving groups!
    – Shane Gib.
    Apr 9, 2018 at 17:23
1

$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

1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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