I have found in recent experience that the Quest RapidRecovery/AppAssure agent service frequently fails to start within the default Windows service startup timer (30 seconds).
I don’t believe this is simply my environment, as Quest has a knowledge article specifically addressing the problem.
This issue poses a problem especially after Windows Updates maintenance windows, because our hundreds of virtual machines will reboot, leaving our monitoring system with hundreds of alerts of stopped services, and many failed backups.
Unfortunately, Quest’s recommendation to simply increase the services startup timeout is system-wide, and not something I was willing to apply in full across my entire environment.
My first thought was to utilize the Recovery options with the Windows service, but upon quick inspection its clear this is only for failed services, and a service that isn’t started does not fall into that category.
Instead I decided to set a GPO with a service preference, with service action set to “Start Service”. This way, every time Group Policy is refreshed, if the service isn’t running it will be started.
The GPO itself has a bit of logic to address the AppAssure/Rapid Recovery upgrade we’re going through right now, which results in a service name change for the agent.
To accomplish this, I created two separate service preferences, each with some item-level targetting for registry matching to ensure it only applies if that service does exist (to avoid spamming Event Logs). This takes advantage of the fact that the AppAssure Agent doesn’t record a product version in the registry:
AppAssure Service
- Service Name = AppAssureAgent
- Match if KeyExists HKLM\Software\AppRecovery\Agent
- AND if not ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion
Rapid Recovery Service
- Service Name = RapidRecoveryAgent
- Match if ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion
