Cannot use a local account to run SQL Backup Agent on cluster

Category: Troubleshooting & error messages
Date: 10 Jun 2009
Product: SQL Backup
Versions: 5

SQL Backup can be installed on a Microsoft Cluster Server because the installation is cluster-aware. By default, it installs the SQL Backup Agent service on both nodes using the a cluster administrator account from the cluster's Active Directory domain as the service startup user. If the SQL Backup Agent startup account is changed to a local computer security account, the SQL Backup console cannot connect to the cluster SQL server and upon right-clicking the failed server registration and selecting 'Properties', the following message is displayed:

GetSID Fail

The issue is caused by the fact that the SQL Backup Agent Service and the sqbutility extended stored procedure used by SQL Backup communicate using shared memory. The access control entry for the communication requires sqbutility to retrieve the security identifier (SID) for the startup account of the SQL Backup Agent service in order to apply the correct security restrictions. The virtual SQL Server resource of the cluster cannot return the security identifier because it cannot resolve SIDs using the local computer name alias (a dot) because this is filled in with the virtual server name and not the name of the node on which the SQL Backup Agent is currently running.

It is not recommended to run the SQL Backup Agent service as a local computer user on either node of the cluster server.

If there is an absolute need to configure the SQL Backup Agent to use a computer account from the local node as a startup account, it can be done forcefully by modifying the registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLBackupAgent\ObjectName

This key contains the name of the startup user for the service. Replacing the dot with the computer name of the cluster node will allow the SQL Backup console to connect to the service and run backups without error.

For instance, changing

.\sqlbackup

to

NODE1\sqlbackup

will work around the problem.