Restoring SharePoint WebApp

grkraj SharePoint

I have seen all kinds of issues while moving sites, webapps  from one environment to other. If your restoring a webapp on the same farm then you might get away with minimum trouble shooting but if its a different farm then you are at the mercy of google.

You can start with below trouble shooting steps.  I am assuming that you are restoring a webapp from Farm A to Farm B running with different service accounts.

  1. Backup the DB on Farm A and Restore it to SQL server of Farm B.
  2. Add all the service accounts from Farm A to Farm B and assign these accounts same permissions like that of Farm A, including local server admin permissions. DO NOT CHANGE ANY EXISTING SERVICE ACCOUNTS ON FARM B.
  3. Create a new webapp
  4. Dismount the DB on of this new webapp using Powershell  Dismount-SPContentDatabase. 
  5. Mount the restored DB using powershell  Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename

Now You should be able to open the webapp on FarmB.

You can also create the new webapp on Farm B using the restored DB instead of new DB but I have seen issues some times with this process. So I would like to create new site and then mount the existing DB.

Permissions of service accounts is the KEY here. As the DB was built on a different farm with a different account it will still look for that account during the initialization. One way to move all the service accounts which are on the sql server is below

On SSMS click View->object explorer details.  Now click on security->logins which will display all the logins on object explorer details window. Select all the logins here->right click and script to new query window. You can run this query on Farm B SQL server to duplicate the accounts. Again do not forget to verify any local admin permissions if has on Farm A and replicate it on Farm B.

2 thoughts on “Restoring SharePoint WebApp”

  1. Wow, this totally solved my problem. You are the man!

    I had a production SharePoint 2013 content database and was doing a database attach migration to an Azure DEV VM on the same domain, however using different service accounts in a least privileges model (svc_d… vs svd_p…).

    I tried adding just the SQL permissions and remounting, rebooting, no luck.

    I added all 4 production service accounts to my dev vm SQL (spsetup, spfarm, spapppool, spsupereader, spsuperuser, and myself) as sysadmin on the dev box (its a temporary Azure migration location to SPO)
    Then that didn’t work, until I dismounted the content DB, deleted the web application and re-mounted the content database. This fixed the sharepoint homepage access denied message, sorry this page is not shared with you, sharepoint subsite not loading, broken permissions, limited access issues (were due to anonymous setting on old web app in dev which was wrong), and fixed the error CatalogConfig.ReadFromPropertyBag; Catalog configurations don’t exist for site collection access denied.

    Issue is migrated content database has something in it for the old production service accounts, probably app pool or a cache account, since I do have a publishing portal. Clearing the cache in the site settings didn’t work prior.

    NICE ARTICLE! I added a lot of the above errors for SEO to your site so someone finds this first, rather than your TechNet solution link to this post.

    Like

    Reply

Leave a comment