On Twitter/X I saw a thread about managing Windows Services using Group Policy. 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, there are multiple ways to solve a problem–some better than others. Services is another example of that. When Microsoft introduced GP Preferences, they provided Windows Service control under Computer Configuration\Preferences\Control Panel Settings\Services, with a different set of capabilities from the legacy System Services area. Confused?
Managing Services with GP Preferences
Depending upon your goals, using one or the other area within GP may be more appropriate–the TL;DR here is that GP Preferences is more likely to be your friend when it comes to service management.
How to Choose?
Each of the policy areas above has capabilities and limitations. These are useful to understand before deciding which to use. 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–this is an important point. That’s a big limitation that you may want to avoid (I usually do). That being said, this is one of the few management planes for actually controlling service permissions, short or direct editing of the registry–so it’s not absolutely useless! What happens with this policy area is that 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 configured onto the service along with the startup type you selected, when the policy is processed by computers. Depending upon your goals that may not be a good thing. And, 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 for the Win
I find myself using the GP Preferences (GPP) way of managing services (and many other things) more often than not, given its flexiblity. Specifically, the GPP Services area provides you with the functionality you wanted in regular policy, without most of the downside. And as a bonus it has a fair bit of extra functionality (e.g. item-level targeting inherent in GPP). Namely, you can:
- Control Service Startup Type
- Stop, start or restart a service when the policy applies (not exactly something you’d want to do in policy, but it can potentially come in handy)
- Set the service account information (i.e. the logon) on the service (but not the password)
- Set the wait timeout on a service operation
- Set the recovery options for a service–stuff like how many times to try to automatically restart the service if it stops and how long to wait
- Control an arbitrary service, as long as you have the service name–more flexible than system services here for sure!
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–ironic, isn’t it? 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 maybe needed to modify the 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. You can certainly specify a service account, but since Microsoft closed a vulnerability in the way service account passwords were encrypted and stored in SYSVOL, the feature to also input the service account password is no longer available. You’ll have to set service account passwords a different way, sadly. Or, use this feature for those accounts that don’t require a password, such as LocalSystem.
Also, if you want to use the GPP Services area for services that are not defined on the machine where you’re editing the policy, you need to know the internal name (not the service friendly name) of the service that you want to manage, and enter that in the Service name dialog. In my screen above, the internal service name is 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 on a given 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.
Darren