none
Two different SharePoint environements with same User Id's and move content database

    Question

  • I have two environments Production and Home which replicates production exactly, and obviously the two environments must never communicate between each other as production is in office and other one is my home virtual environement. I have created same users accounts in my home virtual enviroment domain controller which exisits in my office production environment.

    Then I have taken a backup of content database from production and restore it into my home environment web application. for example i have a a user "domain\joshua" who is site collection administrator on production and same domain\joshua exist on my home environement DC and when I try to log in through SharePoint Designer with same user in home environment it says "Access Denied" ...then I went into home environment Central Administration and User Policy..added joshua there and gave him FULL rights..then I was able to access the site contents using designer.

    But when I try to open masterpage or any file I get "File has been checked out by someone else" ...

    I've heard about Move-SPUser but dont know how to use in between production to home environment. Can anyone guide me how to use it with ignoreSID switch ...would appreciate if someone can give me step by step instruction or a guidance how to use it to resolve my problem.

    Monday, July 30, 2012 10:15 AM

Answers

  • It sounds like the domain you have at home was not made by exporting your production Active Directory, and instead you created a new domain with the same name. In this case, even though the users have the same account name (domain\joshua) they do not have the same security identifyer (SID) as they were created in two different domains and thus SharePoint (and other applications like Exchange) treats them as a different user.

    Move-SPUser is indeed the cmdlet that will resolve this for you. After restoring and attaching the content database in your home farm, run Move-SPUser on all users in a way similar to this (you may have other requirements):

    $users = Get-SPUser -Web "http://URLtoSharePoint"
    
    foreach ($user in $users) {
    
    	# Assumming all users have the same login name in home domain
    	Move-SPUser -Identity $user -NewAlias $user.UserLogin -IgnoreSID
    
    }

    This script gets a list of all the users in a site collection and then for each user, uses Move-SPUser to reassociate the user with the user in your home domain. The script might fail on some built-in or system accounts (NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\authenticated users, SHAREPOINT\system) but that's OK. The -IgnoreSID parameter tells SharePoint to ignore the SID history and just resolve the account that is provided.

    Move-SPUser will update a given user throughout the entire farm, so you only need to run it once per user. If you have multiple site collections you should run it in each to make sure you update all users in the farm.


    Jason Warren
    Infrastructure Specialist


    Monday, July 30, 2012 2:37 PM

All replies

  • It sounds like the domain you have at home was not made by exporting your production Active Directory, and instead you created a new domain with the same name. In this case, even though the users have the same account name (domain\joshua) they do not have the same security identifyer (SID) as they were created in two different domains and thus SharePoint (and other applications like Exchange) treats them as a different user.

    Move-SPUser is indeed the cmdlet that will resolve this for you. After restoring and attaching the content database in your home farm, run Move-SPUser on all users in a way similar to this (you may have other requirements):

    $users = Get-SPUser -Web "http://URLtoSharePoint"
    
    foreach ($user in $users) {
    
    	# Assumming all users have the same login name in home domain
    	Move-SPUser -Identity $user -NewAlias $user.UserLogin -IgnoreSID
    
    }

    This script gets a list of all the users in a site collection and then for each user, uses Move-SPUser to reassociate the user with the user in your home domain. The script might fail on some built-in or system accounts (NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\authenticated users, SHAREPOINT\system) but that's OK. The -IgnoreSID parameter tells SharePoint to ignore the SID history and just resolve the account that is provided.

    Move-SPUser will update a given user throughout the entire farm, so you only need to run it once per user. If you have multiple site collections you should run it in each to make sure you update all users in the farm.


    Jason Warren
    Infrastructure Specialist


    Monday, July 30, 2012 2:37 PM
  • Jason thanks alot for the script let me run it and will revert back to ya. Sounds like this is the cmdlet I was looking for...I hope it will solve all my designer problems also.

    Monday, July 30, 2012 2:56 PM
  • Jason, I executed your script and now I am getting "Access Denied" when I tried accessing my portal. I did "iisreset" and also added domain\josh as site collection administrator which he was before and added domain\josh in user policy of web application and granted FULL rights but same result. what should I do now? I was reading about the problem and came across this post please validate is this my problem?

    http://blogs.msdn.com/b/rcormier/archive/2012/02/24/interesting-side-effects-of-the-move-spuser-powershell-cmdlet.aspx

    Friday, August 03, 2012 8:01 PM
  • Where there any exceptions when you ran it? You said you have a backup of the content, right?

    Jason Warren
    Infrastructure Specialist

    Friday, August 03, 2012 9:19 PM
  • well i had to move the users on different domain through ur script. 
    Thursday, September 06, 2012 5:50 AM