Happy New Year!
On Twitter recently (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 manage 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. GP Preferences introduced Windows Service control under Computer Configuration\Preferences\Control Panel Settings\Services, with a different set of capabilities:
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. Essentially what happens 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 stamped onto that service along with the startup type you selected, when the policy is processed. This may or may not be desirable, depending upon your goals, and frankly, there’s no easy way around it.
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, the server service won’t be available in the list of services that you can manage and so you’re out of luck…
Preferences to the Rescue
…Or maybe not so out of luck. These days I find myself using the GP Preferences (GPP) way of managing services 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. 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. The one notable exception to GPP Services 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