On Twitter (sorry, I can’t bring myself to call it ‘X’) there was a thread about managing Windows Services using GP. The poster talked about using the setting area under Computer Configuration\Policies\Windows Settings\Security Settings\System Services to control Windows Service startup settings (e.g. Automatic, Disabled, Manual, etc.), as shown here:
Managing Windows Services via Policies
As with many things in Group Policy land, there are multiple ways to solve a problem–some better than others. GP Preferences introduced Windows Service control under Computer Configuration\Preferences\Control Panel Settings\Services, with a different set of capabilities from the legacy System Services area:
Managing Services with GP Preferences
Depending upon your goals, using one or the other area within GP may be more appropriate.
Which to Use
Each of the policy areas above has specific capabilities, and limitations, that are useful to understand before deciding which to use. As an example, the Security Settings\System Services area allows you to set the startup type for a given service, but when you do that, you’re also required to set the permissions on the service. It’s not possible to just set the startup type here. That’s a big limitation that you may want to avoid. Essentially what happens is when you set the startup type, it also stamps default permissions on the service, as shown here:
Default service permissions when setting startup type
If you just leave this default set of permissions, they will get stamped onto that service along with the startup type you selected, when the policy is processed by computers. This may or may not be desirable, depending upon your goals, and frankly, there’s no easy way around it–at least not that I would recommend.
The other limitation in this particular policy area, is that the list of services you’re presented with to manage, is fixed, and is based on the machine you’re currently running the GP Editor on. Let’s say you’re trying to manage the startup type of a service that runs on a set of servers, but you’re editing the GPO on a workstation that doesn’t have that service installed. In that case, that server-based service won’t be available in the list of services that you can manage and so, in general you’re out of luck unless you want to be mucking wtih the underlying settings storage file directly, which most people don’t.
Preferences to the Rescue
…Or maybe not so out of luck. I find myself using the GP Preferences (GPP) way of managing services (and many other things) more often than not. Specifically, the GPP Services area provides you with all the functionality you wanted in regular policy, without most of the downside and a fair bit of extra functionality (e.g. item-level targeting inherent in GPP). Namely, you can:
- Set Service Startup Type
- Stop, start or restart a service
- Set the logon as information on the service (but not the password)
- Set the wait timeout on a service operation
- Set the recovery options for a service
- Control an arbitrary service, as long as you have the service name.
As shown here:
So GPP Services can do almost everything you might want to do to a service except set the permissions on the service. For that, you still need to use the policy-based approach described above. That said, I would argue that in 30+ years of managing Windows systems, I probably needed to modify the default permissions on a Windows service less than 5 times.Another notable exception to GPP Services (and policy-based System Services as well) is that you can no longer control the service account password on the service. You can certainly select a service account, but since Microsoft closed a vulnerability in the way service account passwords were encrypted and stored in SYSVOL, this feature is no longer available. You’ll have to set service account passwords a different way, sadly.
Also, if you do want to use the GPP Services area for services that are not defined on the machine where you’re editing the policy, you simply need to know the internal name of the service that you want to manage, and enter that in the Service name dialog. In my screen above, that’s the internal name of SDMGPAAAudit. You can get a service’s internal name simply by using the PowerShell-based Get-Service cmdlet, which provides the name (internal name) and DisplayName (friendly name) of all services installed on a system.
So, for most service management tasks, GP Preferences is the way to go and the old policy-based approach is only useful if you need to manage service permissions!
Thanks for reading,
Darren