Once you understand Group Policy storage and structure, the next step is to learn the distinction between Group Policy and Group Policy Preferences (GPP). At a high level, both mechanisms deliver configuration to Windows, but they operate very differently because of how the Windows security model works. I still recall a conversation with a Group Policy MVP more than fifteen years ago who asserted that when it came to GPP, “the user can generally work around the settings.” That is a good place to start when comparing these two.
- Policies are enforced and typically stored under the Policies registry keys, where ACLs prevent standard users from changing them.
- Preferences write to the same registry locations applications use, so they don’t lock down the UI and users can change them if they have sufficient rights; however, they can be configured to reapply during subsequent Group Policy refreshes.
At the end of the day, Group Policy settings still must follow Windows’ built-in security rules. Those rules control almost everything Windows does. With Group Policy, we’re typically just managing the small slice of those rules that affect users or computers.
For example, we might use a security policy to let an Active Directory (AD) group log into all company desktops via Remote Desktop, restrict who can log on locally to a server, or require a minimum password length across the domain. On the other hand, we might change a registry setting to control how an app behaves, set a default homepage in a browser, map a network drive, or adjust power settings on laptops. Those examples get at the core difference between policies and preferences.
Two Primary Jobs of Group Policy
Regardless of what we call it, Group Policy has two main jobs:
- 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. Once applied, they cannot be bypassed unless the user has sufficient privileges on the system (for example, membership in the local Administrators group).
- The second job is to help configure and lock down applications. These Applications range from File Explorer restrictions, browser configuration, Microsoft Office policy settings and third-party applications that have been designed to honor Group Policy. These settings are enforced by the application itself, not by the Windows OS. The application reads the policy value and is designed to disable or hide the corresponding user interface. That means if a user finds another way to reach a restricted feature, the policy may not stop them.
Examples of Group Policy Preferences (GPP)
When comparing policies and preferences, the strength of enforcement depends on who is doing the enforcing: the Windows OS or the application itself. When Microsoft acquired DesktopStandard’s PolicyMaker in 2006 and integrated it into the Windows platform in 2008, they intentionally chose the word “Preferences” because these settings can, in many cases, be changed by the user after they are applied.
Interestingly, a Group Policy example can help illustrate how Preferences-like behavior shows up even within “true” policies. Take an Administrative Template setting that blocks launching cmd.exe through Explorer. While it closes off that specific path, it doesn’t eliminate every way of getting a command prompt. For most users, the restriction is effective, but a determined person with sufficient knowledge (and often local admin rights) can often work around it.
A true GPP example is 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 File Explorer 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. That’s 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, local user and group configuration, registry changes to HKLM) that a non-administrative user cannot work around, by virtue of basic Windows security permissions. So while we can say that GPP can “often” be worked around by the user, it is definitely not always the case.
Conclusion
Here’s my bottom line. Regardless of whether you call it a policy or a preference, if it relies on Windows OS 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 traditional Group Policy settings as well as GP “Preferences”.