After creating a new GPO and then heading into Group Policy Management Editor in order to put some settings inside that GPO, you will notice that both the Computer Configuration and User Configuration sections of Group Policy have two main tiers of settings. There are true Policies, which we have been working with so far, and then each node also contains a Preferences folder, which includes many other settings. You can see the distinction in the following screenshot:
Policies force things to happen, no matter what the user wants. Preferences, on the other hand, are often reversible by the user. So preferences are a good way of configuring settings that will make life easier for the user, but you need to ultimately be OK with the fact that those changes and settings could be changed again manually by the user, if they want to do so. There are some settings that exist in both Policy and Preferences, so this can be a distinguishing factor when deciding how to build your GPO – whether you want to enforce something as a policy, or take the more flexible approach of configuring that setting to a particular default status, understanding that it could later be changed.
You learned in the previous chapter that built-in Microsoft policies, when applied to machines, are stored into special locations in the registry that make those settings both tamper-proof as well as automatically reversible. These policy settings are automatically removed when a GPO no longer applies to a machine or user (if they fall "out of scope" of the GPO), and the user cannot sidestep these policies even if they are pretty tech-savvy.
Preferences stick around! Group Policy preferences (as well as some ADMX-based policies) are not stored in this protected section of the registry and, as such, are able to be usurped. They are put into place on a machine, and those settings then remain in place until they are changed by the user, or until another GPO overwrites them. This means we need to be careful about what we deploy at the preference level, and know that if we want to reverse a preference, we need to make a new preference that changes the setting back to original.
This is ultimately why we call them "Preferences" – you aren't guaranteed that they will be put into place, nor removed from places, when you want them to be. So in general, if there is some setting that you find where you could set it via Policy or Preference, it makes more sense to go with the built-in policy.
By default, Preferences will reapply during every Group Policy background refresh. This differs from policies which only reprocess the GPO when changes are noticed. So keep this in mind when choosing to utilize preferences, because they can increase the amount of work that your machines have to do every 90 minutes during that background refresh cycle. When looking to implement a preference, make sure to search around and find out whether there is a corresponding policy setting that could be used instead. Test both and discover what behaves best in your environment.
Preferences can often be used in place of traditional policy-based logon scripts. Historically, Group Policy administrators would accomplish things such as user configuration settings, mapped network drives, and environment variables by scripting them and configuring Group Policy to run that script each time the user logs in. While this still works today, the running of that script during login is certainly slowing down the logon process. Perhaps the settings you are configuring are items that don't need to be reprocessed during every boot. Maybe they are simple settings that, once configured the first time, can be left alone in the future. These scenarios are use cases where you would prefer Preferences over Policies, which could perhaps even enable you to ditch those old logon scripts.