November 25, 2013

Beware of Restore-SPSite Requirements

2053 Views

Overview

You have SharePoint 2010/2013 Farm deployed. In the same SharePoint Farm, you are trying to back up a site collection and restore on to either a different site URL or managed path or different web application.  You are doing this using following PowerShell commands:

  • Backup-SPSite
  • Restore-SPSite

Meanwhile in the process, your Backup-SPSite will work successfully, but while executing the Restore-SPSite you might get following errors:

  • Restore—SPSite : The operation that you are attempting to perform cannot be completed successfully. No content databases in the web application were available to store your site collection. The existing content databases may have reached the maximum number of site collections, or be set to read—only, or be offline, or may already contain a copy of this site collection. Create another content database for the web application and then try the operation
  • Restore-SPSite : Access is denied. (Exception from HBESULT: 0x80070005 ( E_ACCESSDENIED))

Cause

Condition for Site Restore

  • When you back up a site collection and restore within the same Web Application, you will need a separate Content Database to restore to. Refer this MSDN Article. Same site collection (will have same SiteID GUID)

If a site collection is backed up and restored to a different URL location within the same Web application, an additional content database must be available to hold the restored copy of the site collection.

Condition for Site Delete

  • Now if you are backing and restoring to be served from different URL, then you are looking at deleting the site collection before you are restoring the site collection. Starting in SharePoint 2010, the Site Collection deletion process has been changed. Refer to Bill Baer's blog here.

Condition for Site Restore

  • When you are set with above conditions and trying to restore site collection now you are greeted with the Access Denied warning.
  • This happens when the user login you are using to login to the SharePoint Server (RDP), this is usually the Farm Admin, is not one of the restoring site collection primary or secondary administrator.

Resolution

  • You are going to be performing this operation on the SharePoint Server, using the Farm Administrator account.
  • Your current site collection owner is not the farm admin.
  • In this case, set your farm admin as Primary/Secondary administrator (This will be temporary until your restore operation is complete)
  • If you did not do this and went ahead and already deleted the site collection and you have no back up, still no worries, follow further steps.
  • But at least know who is the Primary or Secondary site collection administrator.
  • Backup your site collection using the Backup-SPSite.
  • If you need to delete the site collection because you are trying to move the site collection, then you will need to delete the backed up site collection from SharePoint.
  • So before you go ahead and delete, ensure you have backed up the Content Database that contains this site collection.
  • If you delete site collection using Remove-SPSite, the site collection will be deleted permanently.
  • If you delete site collection from the Central Administration or using   Remove-SPSite with -GradualDelete option the site collection will be marked for deletion, and will be deleted based on the timer job "Gradual Site Delete".
  • You could list the sites marked for deletion by running Get-SPDeletedSite and follow with Remove-SPSite
  • You could force the timer job Run Now to delete pending the site collection that are marked for deletion
  • At this stage your site is removed successfully.
  • Now you are trying to restore your site collection
  • Use Restore-SPSite PowerShell command to restore.
  • If you are coming across the Access Denied error, that means your Site Collection Primary or Secondary owner is not one of the Farm Admin.
  • In that case, ( If you did not rest the site collection Primary or secondary admin to the Farm admin before the backup), follow below option:
  • Find out who was the primary/secondary site collection administrator
  • Temporarily, make the above site collection administrator a farm admin, provide rights (I gave full rights until Restore was successful) to the restoring Content Database.
  • Have the site collection administrator Login to the SharePoint Server farm (This is the only way, because you did not reset the site collection owner to farm admin before the backup)
  • Then run the Restore-SPSite
  • Now remove the user from farm admin and remove the SQL Full rights on the content database
  • If you had the Site collection administrator reset to Farm admin prior to back up, then set the appropriate business users to the site collection administrators

2 Replies to “Beware of Restore-SPSite Requirements”

  1. Hi

    Regarding the Access Denied error even I am getting this even though I have run through this

    $admin = "domainsp_install"
    Get-SPSite -Limit All | %{Set-SPSite $_ -OwnerAlias $admin -SecondaryOwnerAlias}

    I think I am getting errors due the user Id stored in the backup file that don’t match the dev domain I have created for this HNSC.

  2. Sorry, couldn’t let this rest…the comment “If you are coming across the Access Denied error, that means your Site Collection Primary or Secondary owner is not one of the Farm Admin.” is simply not correct. There is no site level permission requirement on the site collection owners when using backup-spsite or restore-spsite commands, as they do not interact with the web object (I.E. spweb, which actually performs a login to the website, opposed to spsite which logs into SQL). If you are getting the error, SQL permissions are generating that access denied, not SharePoint, as shown here: Access is denied. (Exception from HBESULT: 0×80070005 ( E_ACCESSDENIED)) (this is an error from the SQL database). If you add a new user to the farm admin database after the fact, they will be able to perform this action only because adding them to the farm admin group grants them permissions on the databases that exist. SharePoint doesn’t automatically add accounts other than the designated farm account to all content databases by default. If you need access, simply login to SQL and grant db_owner to the account you are using. There is no reason to ever give a site collection admin FARM admin rights. Ever.

Leave a Reply

Your email address will not be published. Required fields are marked *