I have a path based site collection on my dev farm. It shares a content database with other site collections on the dev farm. My domain account is the site collection administrator and is also a farm administrator (via AD group membership, I belong to an AD group that is a farm administrator).
I want to back up this site collection, and restore in on the prod farm as a HNSC. This is on the same domain. My same domain account is prod farm admin as well. I would like to use a new content database for this site collection on the prod farm.
My domain account is a domain admin, and is an admin on all sql server's involved and on all servers involved.
So I log into one of the WFE on the dev farm as my domain account, run shell admin as administrator, and execute:
Backup-SPSite https://portal-dev/sites/contracts -Path C:\backup\contracts.bak
Now I log into one of my prod farm WFE servers as my domain account, run shell admin as administrator, and execute:
New-SPContentDatabase "SP_Content_Portal_Contracts" -WebApplication "https://portal"
Restore-SPSite https://contracts.contoso.com -Path '\\spdev01\c$\backup\contracts.bak' -HostHeaderWebApplication https://portal -Force -ContentDatabase SP_Content_Portal_Contracts
I then get this error:
Restore-SPSite : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
+ CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite: SPCmdletRestoreSite) [Restore-SPSite], UnauthorizedAccessException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreSite
I have read many posts about this error and about this process, but I believe I have covered everything they indicate needing to do and am still seeing this error.
Looking in the logs I see this slightly different error message:
System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED)), StackTrace: at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean
isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock) at
Microsoft.SharePoint.Administration.SPSiteCollection.Restore(String strSiteUrl, String strFilename,
Boolean bOverwrite, Boolean bGradualDelete, Boolean hostHeaderAsSiteName, Boolean preserveSiteId) ...
What is causing this error?
The same error occurs if I try to restore to a path based site collection on the prod farm.
Note that when I created the content database, it created it with my domain account as the owner. So my login is associated with the 'dbo' user in that database. I can not create a new user for my login, nor can I manually add 'dbo' to the 'SharePoint_Shell_Access' role as some suggest. The user is however 'owner' so i would hope that would be enough. Still, for a test, i re-assigned the owner of the database to another admin account, and created a new user for my login, which was added to the 'SharePoint_Shell_Access' role, and the error remained unchanged.
As more clues (or red herrings) ... I thought I would forego my preference of a new content database, and use the existing content database. To do this I executed the above restore command, without specifying any content database. In that case I get a different error:
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 again.
The common wisdom for this is that the content database already has a site in it with the new site's name/GUID (which it does not) and that possibly that site is deleted but still in the content database. There is no site with this name in any content database, and there are no sites returned when I execute get-SPDeletedSite.
I can create a new host named site collection with a new content database on the prod farm without any problems.
This is a brand new prod farm, so perhaps there is something fundamentally wrong here.
Also please note the SQL server is a SQL Server 2014 Availability Group.
