How to reset Group Policy after a virus

How To Reset A System’s Local Group Machine Policies to "Fresh Out Of The Box"

Group policies are the way to control a 2000, XP or 2003 system. But they have something of a black box-ish feel to them in that they’re hard to troubleshoot despite the XP and 2003 "resultant set of policy" (RSOP) tools. But even then, RSOP tools are most useful in an Active Directory-based domain with centralized group policies, and not everyone has an AD.

Sometimes I want to take a system and wipe it clean of any domain or local group machine policies, to essentially reset its state to "just installed." As policies live in several places, that’s not as easy as it sounds. Here’s what I’ve found useful.

There is no one single place where policies live. When you fire up gpedit.msc or Local Security Policy (secpol.msc), then you’re directly tweaking items in many parts of the Registry, as well creating or modifying data in \windows\system32\GroupPolicy. (It’s a hidden directory, so set Folder Options to show hidden files and folders if you want to look in it. And if you’re running Windows 2000, then the directory is \winnt\system32\GroupPolicy.)

Most of the changes to machine policies seem to live in HKEY_LOCAL_MACHINE\Security and HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft, as well as a file named Registry.pol in \windows\system32\GroupPolicy\Machine. Here are the basic steps that I’ve found allow me to reset a system to almost new:

Reset HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft to an out-of-the-box state by restoring a copy taken from a freshly-installed system.

Delete \windows\system32\GroupPolicy\Machine\Registry.pol, if it exists.

Run the Setup Security template.

Here’s more detail on the rollback steps.

Every XP, 2003 and 2000 system includes a security settings template at \windows\security\templates\setup security.inf. (Again, 2000 systems will use \winnt, not \windows.) Apply the template from the command line like so:

In that command — which should be typed as all one line — you’re telling secedit to use a template named "c:\windows\security\templates\setup security.inf" to create a security database called "junk" and to overwrite any existing security databases called "junk." We’re only doing this because secedit can’t directly apply a security template; it must first create the security database, and then it applies the security database.

This command make take a bit of time to run; run Task Manager and you’ll see secedit.exe in the list of running processes while it’s working. (Or leave off the /quiet and it’ll yammer at you while it’s working.)

Applying that template will reset many security settings, but not, unfortunately, all. For example, software restriction policies will not be rolled back, and IPSec filters won’t be restored to their initial state just by running "setup security.inf." To roll those back, we’ll restore a Registry key, HKLM\Software\Policies\Microsoft. That’s the key where most of the policy information lives. The easiest way to roll back most of policies, then, is to restore this key to its pristine state. And the easiest way to do that is to grab a HKLM\Software\Policies\Microsoft key from a newly-installed system, or for that matter one that hasn’t had any policy work done on it. (But before you do all this work, check your system — if you never messed with IPSec or software restriction policies then simply applying the template might have done the "policy reset" trick for you.)

The easiest way to do that is to open up Regedit on your newly-installed system and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies, where you’ll see a folder icon labeled "Microsoft." Right-click it and choose Export, then point Regedit at someplace to put the file. For my example, I’ll call it policies.reg, but you can put it anywhere you like — just remember wherever you put it. I then copy the policies.reg file to the computer that I want to reset policies on; for the sake of example, let’s say that I store it in c:\oldreg.

Now, I don’t want to just apply that Registry file to my system, as .reg files really only merge information into the Registry — I want to reset that part of the Registry altogether. So before I apply policies.reg to my system’s Registry, I’ll first delete the current HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft key in the Registry. (As always, PLEASE be careful when messing with the Registry!) You can either do that by opening up Regedit, navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Policies, clicking on the Microsoft folder and pressing Del, or you can do it from the command line:

reg delete hklm\software\policies\microsoft /f

Now I’m ready to apply the Registry fixes either by double-clicking on policies.reg, or from the command line like so:

regedit /s c:\oldreg\policies.reg

Finally, zap \windows\system32\GroupPolicy\Machine\Registry.pol either from Explorer or from the command line. Restart and the policies are gone! Let’s wrap that up into a step-by-step:

First, export the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft key from a "virgin" system; call the file policies.reg and store it on the system that you want to reset in a directory named c:\oldreg.

Second, create a batch file with the following lines in it, or just copy the lines from this document. Save the file, calling it resetpol.cmd. Store it and policies.reg on a floppy somewhere so they can be easily transported to any other system that might need its policies reset. If your system is a Windows 2000 system, then type "\winnt" where you see "\windows" below.

How does this advice vary if you want to remove domain-based policies? Well, the best way to wipe out all domain-based policies is to simply unjoin the workstation from the domain. That seems to un-do most of the policies. But if you’ve got a system that’s not connected to the domain — perhaps a laptop — and you just want to be free of domain policies temporarily, then follow the above advice. Of course, you’ve got to be a local administrator to do any of this policy un-doing.

One final note: each of those commands resets a part of policies. But they may not reset them all — that’s why I said "almost new." If you’ve created a custom policy that "tattoos" the Registry, then there’s no way to roll back those changes unless you’ve documented what the policies did in the first place; then you can reset the affected Registry keys one at a time. So be careful with those Registry tattoo-ers!