Although the Central Administration site, STSADM.exe, and PowerShell cmdlets (in SharePoint 2010) offer different ways to achieve the same backup and restore goals, they don’t carry out their operations in the same way.
Any backup and restore operations that are carried out through the Central Administration site take place in the context of the farm’s SharePoint Timer service identity. This is due to the fact that backup and restore operations that are requested through Central Administration are submitted as timer jobs for execution. When these jobs ultimately execute, they do so in the context for the SharePoint Timer service account.
Operations that are carried out through STSADM.exe, on the other hand, execute directly within the context of the logged-in user – not the SharePoint Timer service account. For this reason, special care must be taken to ensure that STSADM.exe operations are carried out in the security context of a user that has all the necessary rights and privileges to the SQL Server databases that are targeted by backup and restore operations.
In SharePoint 2007, ensuring that a user had the necessary rights to operate directly against SharePoint’s SQL Server databases for command line operations typically caused many security and governance issues. SharePoint 2010 largely sidesteps these problems with the addition of the Add-SPShellAdmin cmdlet. Be sure to investigate this cmdlet before granting any special per-user privileges in SQL Server as it makes the process largely unnecessary.
ReTweet this Tip!
Nov 22 2010, 02:00 AM