A recent thread on Mark Minasi’s forum site reminded me of a topic that comes up every once in a while–namely, how do you cleanly remove Group Policy settings from a machine that has been removed from an AD domain. The answer is to avoid the problem in the first place :). The challenge here is that, once a machine is removed from the domain, you don’t have any control over the policy settings that remain tattooed on them. In fact, Admin Template settings, which usually don’t tattoo a system under normal circumstances, end up getting stuck on machines once they’re removed from the domain, because the non-tattooing behavior of these settings requires normal domain GP processing to occur.

So how do we go about preventing these non-domain machines from getting all kinds of policies stuck on them? First off, I recommend that if you plan to remove servers or workstations from an AD domain, and you don’t plan to re-image those machines, then BEFORE you remove them, to perform some operations to do your best to remove any GP settings that are applying to the computer accounts (keep in mind that per-user settings are usually not an issue when removing a machine from a domain because those user settings only apply to the domain user’s profile, not to the computer). Here are the steps I recommend to free your soon-to-be-unjoined machines from having policy settings stuck on them!

1. Before unjoining the machines from the domain, move the machines to a “waystation” OU. That’s an OU you’ve created that has no GPOs linked to it and has the “Block Inheritance” flag set on the OU (from GPMC) to prevent upstream GPOs from applying.

Setting Block Inheritance on an OU from within GPMC

2. Once you’ve move the machine accounts into the blocked off OU, I recommend waiting a number of hours to go by before assuming all settings that will be removed, are removed. This is because the GP engine caches it’s OU location for a period of time before it realizes it’s been moved. Until this happens, you can’t be sure that the machine really knows that it’s been moved. I also recommend doing a reboot of each machine and a gpupdate /force on any machine that you’ve moved, just in case.

3. Once these steps have been done, the machine should be safe to remove from the domain.

CAVEATS

This process I’ve described has some caveats. Not all policy settings are removed just because the GPO that delivered them no longer applies. In fact, while most if not all Admin Template settings will get removed using this method, many security settings will not.  For example, Security Options, User Rights Assignment, Audit Policy and Event Logs, to name just a few, will remain as they were set in the domain, even though the GPOs that delivered them no longer apply to the machine. You would either need to re-set those security settings explicitly to the out-of-the-box defaults or accept that they will remain on the un-joined machines. In addition, applications that were deployed via Software Installation would only get removed if you specified on deployment to “remove the package when the policy is no longer in scope”. GP Preferences settings will only get removed if you used the “Replace” action on them, since only that action behaves like Admin Template settings and removes settings on each processing cycle, before re-applying them (if they are still available).

So, while there is no easy answer (short of re-imaging) to completely “clean” a machine that is removed from a domain, it’s much easier to do it if you follow these steps I’ve laid out above.

Finally, if you have already removed the machines from the domain without doing the steps above, have a look at my Clean Registry Policy freeware utility. I wrote it specifically to remove Admin Template settings that get “stuck” on a machine that is no longer in the domain. You’ll need local admin. privileges to run it but it can be helpful in scouring out Admin Template settings that were applied when the machine was in the domain.

Hope that all helps!

Darren