Restoring Sharepoint Subsite - SMSP 6 [ Edited ]

[#1]

I'm trying to restore a subsite from a site collection using SMSP 6 and I'm getting the following error log:

Path:Farm(Farm)\Microsoft SharePoint Foundation Web Application\SharePoint - spdev.domain.com443\DomainSP_Content1_sharepointdbsrv-dev,Status:Successful;
Path:https://spdev.domain.com,Status:Successful;
Path:helpdesk,Status:Failed;
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED));

I've made sure to give appropriate access to agent service account.

Anyone having this issue or ideas?

[#2]

Yes, I'm seeing this issue as well.  Also have a customer who's seeing it.  I see it while restoring at the item level.

Mon Apr  4 21:12:49 CDT [n6040-01a: app.log.err:error]: NA-SP2010: Item Version Level Restore SMSP 6.0: (10052) Restore: Plan: Full Farm Backup - Item Job: RS20110404211113 Control Agent: NA-SP2010 Farm: Farm(NA-SP2010:SHAREPOINT_CONFIG) SharePoint Version: SharePoint 2010 Components: 1 Start Time: 2011-04-04 21:11:13 Finish Time: 2011-04-04 21:14:50 Types of restore used: item in place restore Exceptions:

Mon Apr  4 21:12:49 CDT [n6040-01a: app.log.err:error]: NA-SP2010: Item Version Level Restore SMSP 6.0: (10052) Restore: 0 Exception Details: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Statistical Result: 1 MB data, 1(0) site collections, 0(0) sites, 0(0) lists, 0(0) items.

I've read over numerous articles on the NOW about which service accounts need which permission at either a SharePoint level and/or a SQL level and/or OS level.  I'm curious which access you've given your agent service account.

[#3]

I had the problem too.

Either set the smsp service account on the application pool or change the credential for the smsp agents active on the sharepoint servers. For my company it was easiest/best to change the credentials on the smsp agents and use the farm admin account used to install and configure sharepoint. After the change restores work.

[#4]

I found out the solution to my problem with restoring individual items while overwriting existing.  The trick was to set the SnapManager for Sharepoint Agent service to run as the same user that the SharePoint 2010 Timer service is running as.  In my case, when I installed SQL and then SharePoint, I used sql2008 as the service account for the SQL 2008 installation and sp2010 for the Sharepoint 2010 service account.  Through the SMSP interface, Control Panel -> Control Service -> Agent Monitor (tab) -> Configure.

[#5]

Thanks for the feedback but I'm still getting the "ACCESS DENIED" error.  Here are my settings:

I have a service account called svc_spapp and it has the following (based off of KB ID:3012702):

• Local Admin permissions on each server
  
• Farm Admin
  
• On each Server it has the following "local security policy" additions:
  
  • Log on Loca
    
  • Log on as Batch Job
    
  • Log on as a Service
    
  • Log on with System Interactively (could find this in Windows Server 2008 R2)
    

• "Log on As" rights for the Sharepoint 2010 Timer service
  
• Service account for the Web Application Pool
  

On the SQL side this account has:

• SYSADMIN
  
• PROCESSADMIN
  
• SECURITY ADMIN
  
• DB OWNER FOR ALL DATABASED managed by SMSP
  

I'm being able to mount the DB and obtain the data, it just doesn't look like it has the access to restore the file/site within the site collection.

[#6]

I’d also check the other permissions like “view server state” permission on the SQL server, as well as the DBO permissions on each individual database.

Reena

[#7]

I added "view server state" and made sure that svc_spapp has the DBO schema for all Sharepoint DBs.  Still failed.

[#8]

Are you doing an in-place restore or out of place? The other suggestion is to enable the logs at the debug level and check the Media Service and Member Agent logs from the Log Manager.

Reena

[#9]

Also check this KB article, check the Id settings in the IIS manager.

https://kb.netapp.com/support/index?page=content&id=2015278

Reena

[#10]

I faced the same problem, and following the same KB shown by Reena, I was able to solve. It's a limitation on Microsoft IIS, so you have to use the same account you used to install SP.