Why do you see VSS errors when you configure SharePoint 2010 Search in least privileged mode

The information here resulted out of an engagement with one of our customers and we felt it was important to capture the knowledge so it’s not lost and can be reused.

The scenario is pretty basic, after you configure the SharePoint 2010 Search service (ie the SharePoint Server Search 14 windows service) to use a domain user account (ie a non-privileged account), you begin to see the following VSS errors in the application log:

The reason why is that VSS (which is a component of the OS) requires requires a process (ie mssearch) that will hook into the VSS framework be running as either a local admin, backup admin or local system. This is  discussed here:

Security Consideration for Writers - https://msdn.microsoft.com/en-us/library/windows/desktop/aa384605(v=vs.85).aspx

This article acknowledges that these rights may be too much and provides a mechanism (by means of a registry key - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl) to instruct VSS that a certain non-privileged account is safe.

SharePoint will add the Search Service Account to this VSSAccessControl key…but a certain sequence has to be followed to get the account fully registered when it’s changed from a privileged account to a non-privileged account.

The options are:
* Use the set-spenterprisesearchservice –serviceaccount –servicepassword cmdlet to change the Search Service Account from one account to the other.

OR

* You use the Configure Service Accounts UI in Central Admin to change the Search Service Account + run stsadm –o osearch –action start. 
* The stsadm command is needed to provision/push the account to all the necessary locations.

Last but not least, it will also be necessary to manually add the service account to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag key with full control rights to avoid an access denied VSS error with event ID 8193.

This solution is discussed in the article you already have: https://technet.microsoft.com/en-us/library/cc734219(v=ws.10).aspx.

The reason why this is necessary is due to a known issue in VSS. VSS requires the process account to have rights to this key although it is not explicitly stated in the Security Considerations for Writers article. The SharePoint product team did consult with the VSS team about this and the workaround above was deemed to be a cost-effective resolution to the problem.