Most policy settings that exist inside Administrative Templates by default (the ones baked into Windows when you build a Domain) have the ability to self-regulate, or to self-remove when the policy is no longer applied to a machine. When you tweak a setting inside Administrative Templates, and that GPO then filters down and applies to a workstation, what you are really doing on that client machine is modifying a registry key that lives in a special section of the registry that is unavailable to the users, so they can't edit these settings. That makes sense and lines up with everything we have learned so far, as soon as a GPO has settings and the client computer does a background refresh, those settings are put into place.

Furthermore, when you stop a GPO from applying to a machine by causing it to fall out of scope (for example, if you deleted the link to the GPO so that the GPO is no longer applied to your workstation), those settings will be reversed. That may seem like no big deal, of course it's supposed to work that way, right? Actually, this is an incredible capability that is going on under the hood. You see, those registry keys that were put into place don't know how to remove themselves, but Group Policy processing does treat these areas of the registry as special, and when the GPO no longer applies, Group Policy will know that it needs to reverse those settings. This is the under the hood procedure that allows you to force settings via GPO, and have those settings removed again by simply unlinking the GPO, or moving the computer account to a new OU, or whatever method you use that causes a GPO to no longer apply to your client machine.