Best Practice to move site from Production to UAT and vice versa

Question

I have a sharepoint 2010 production environment based on the following.

1. Domain Controller (example : myproduction.com) (Tier-1)
2. One Web Front End (Tier-2)
3. SQLServer 2008 R2 (Tier 3)

Also I have the ditto environment with same domain name at home and I've exported users from myproduction.com and imported in home environment AD.

Then took backup of content database from production sqlserver..restored back on home environment sqlserver ..created new application on home WFE..attached the restored content db (from production sqlserver).

Now when I try to access the site using designer i get access deined even though made the same user to site collection administrator ..ive solved this problem by adding the user into Application User Policy and gave it FULL rights..now i was able to access the site using SPD. BUT cannot modify any files as it says its been checkout by another user I guess its because of SID issue....

What is the best method in my scenario to move content database and make it work on home environment by bypassing user ID security?? How to use Move-SPUser in between two disconnected environments but with same user id's and domain names.

Answer 1

If you have different domain controllers on the two environments then there is no way to use the same IDs because, as you rightly point out, the SIDs differ between domains even if the username does not. Adding the UAT domain user to either a web application policy or as a Site Collection Administrator are the only ways to enable access to users on the UAT domain.

The 'Best Practice' for approving content before moving content is to set up a full Authoring farm where content changes are made in isolation and can be approved in that environment. Content Deployment jobs would then run periodically that would push the approved content to the separate production farm.

A more common approach is to make all changes on production but then have a designated group of Approvers review the content before publishing it.

Answer 2

SIDS are stored with Site Collections. @Dave-Wise's approaches would both be preferred to this for constant updates.

In your environment you could change your home domain to be different or add a domain alias. I would import your users with the alias so the domains do not match. Backup site collection and restore to your test environment. With powershell you can migrate the users from the site collection to the new domain. You can do this going back the other way as well (I personally would not like messing with the tables that much).

The below script is from http://blogs.msdn.com/b/sowmyancs/archive/2012/01/07/migrate-users-groups-powershell-script.aspx and does a bit more than a simple migrate.

Add-PSSnapin Microsoft.SharePoint.PowerShell
function MigrateUserOrGroups($migrationType, $csvFile)
{
   #Getting the SPFarm object
   $farm = Get-SPFarm

   Write-Host $migrationType
   #Checking whether the user input the type of Migration as Group
   if($migrationType -eq "Group"){
   Import-Csv $csvFile | ForEach-Object{
      Write-Host "Migrating Group" $_.oldlogin "to" $_.newlogin -ForegroundColor Green
      $farm.MigrateGroup($_.oldlogin, $_.newlogin)

       }
      }

    #Checking whether the user input the type of Migration as User
    if($migrationType -eq "User")
      {

        Import-Csv $csvFile | ForEach-Object{
        Write-Host "Migrating User" $_.oldlogin "to" $_.newlogin -ForegroundColor Green
        $farm.MigrateUserAccount( $_.oldlogin, $_.newlogin, $false )
        }      
      }

   Write-Host "Migration Completed" -ForegroundColor Cyan


   # $farm.Name
}

MigrateUserOrGroups $args[0] $args[1]