I recently had a good conversation with a fellow Group Policy MVP about the difference between policies and preferences (i.e. Group Policy Preferences). He asserted that with preferences, the “user can work around the settings (generally.)”. This got me thinking about what the difference really is between a policy and a preference, in the context of Group Policy. At the end of the day, what Group Policy delivers in terms of configurations settings are subject to the rules of the Windows OS security model. This security model is baked deeply into the OS and really covers all aspects of what you can do in Windows. With respect to Group Policy, we’re usually only concerned with managing a subset of those elements of the OS that affect a user or computer. For example, we might use security policy to grant an AD group the ability to remote desktop into all of our corporate desktops. Or we might muck with the registry to impact the behavior of a particular application. In fact, these two examples underscore the foundation of my discussion around policies vs. preferences.

Regardless of what we call it, Group Policy has two main jobs in life:

1. The first job is to help you configure Windows OS security. Those are things like user rights assignment, password policy and file system or registry permissions are squarely in the domain of configuring Windows security. These security items, once configured, cannot be “worked around” unless the user has sufficient permissions on the system (e.g. is a member of the local Administrators group or other privileged group)
2. The second job is to help configure and lock down applications. These “applications” range from things like the Windows Explorer process (i.e. remove the ability to launch cmd.exe or removing icons from the desktop) to Internet Explorer, to Microsoft Office, to 3rd party apps that “policy-enabled” themselves. This last point is key. The thing that makes these types of policy settings able to “lock down” the application, is that the application has been coded explicitly to look for the policy settings, and to configure and/or grey out that element of the application UI to prevent the user from changing it. It’s not “real” security in the strict sense, because it’s subject to the application itself obeying the policy. The key here is that it’s NOT the Windows security model that enforces the lockdown–it’s the application itself. And, what that means is that if I could find a way to get access to a locked down feature in a different way, the policy may or may not stop me. A good example of this is the fact that the policy to prevent me from launching cmd.exe does not prevent me absolutely from getting at a command prompt–it only prevents me from doing it through Explorer. This is usually good enough for most users but an intrepid coder with some time on their hands could work around this.

OK, so how does this all relate to “policies” vs. “preferences”? The bottom line is that the distinction between the two is mostly marketing, in my opinion. They needed a name to call the features that were included from the acquisition of the DesktopStandard PolicyMaker product and Preferences sounded good, because many of the things you can configure in Group Policy Preferences — the user is able to change. Take for example, drive mappings. I can define a GPP drive mapping for a given set of users, but there is nothing to stop the user from going into My Computer and removing that mapping. GPP can certainly be configured to re-apply the mapping when GP updates in the background, but there is nothing you can do to prevent the user from deleting the mapping, because Explorer was not explicitly coded to have that feature locked down when delivered by GPP.  On the other hand, there are plenty of per-Computer GPP settings (e.g. system environment variables, device restrictions, registry changes to HKLM) that a non-administrative user cannot work around by virtue of basic Windows security permissions.

So, as we can see, the distinctions are blurry and do roughly fall based on whether the setting we’re talking about is delivered per-computer, for which Windows security does not typically allow normal users to change, or per-user, which a user typically has access to modify, and whether the setting is being enforced by Windows security, or a particular application.

Here’s my bottom line. Regardless of whether you call it a policy or a preference, if it relies on Windows security to keep it enforced, then it won’t be worked around (unless the user is given privileged access to their system). If it relies on an application to keep the setting enforced, and Windows security allows the user to modify or work around the setting, then all bets are off. This holds true for both the official “policies” as well as GP “Preferences”.

Darren