How to wreck your Windows network (Part 1)

If you would like to read the next part of this article series please go to How to wreck your Windows network (Part 2).


As an administrator of Windows computers in an Active Directory environment, you’re probably on the lookout for “best practices” that can help keep your network and data safe, your clients and servers well-managed, and your applications and services humming along. That’s because the security of your position at your company likely depends on your maintaining the kind of secure, reliable, and fast IT infrastructure that your company’s business can rely on 24×7, 365 days a year

Unfortunately, not all published best practices can be relied on, so in addition to seeking out best practices, you should also be on the lookout for “worst practices” or things you should definitely avoid doing. So if you want to keep your Windows environment secure, reliable, manageable and performing well, don’t do any of the things described in this short series of articles or you’ll likely end up wrecking your network.

So without more ado, let’s begin! Here are four ways you can wreck your Windows network. And to make sure each point I try to make is crystal clear, I’ll highlight each don’t in the topics below. Note that these topics are in no particular order. The real question is: how many of these have you been guilty of?

Managing policy by directly manipulating the registry

If you want to manage user accounts and computers with policies, do it with Group Policy. Don’t do it by setting registry values where policy settings are stored (HKLM\Software\Policies and HKCU\Software\Policies) directly by using scripts (either with.reg commands or via PowerShell).

Why not? Because these registry locations are just where the policy results are stored. In other words, the registry is not an authoritative source for policy, it is simply where the results of applying policies to a computer or user are stored. So if you directly edit the registry by creating or modifying values under HKLM\Software\Policies or HKCU\Software\Policies by using scripts, your registry modifications may get overwritten the next time Group Policy refreshes in your environment.

Managing policy by xcopy of Registry.pol files

Every Windows computer, client or server, has a local Group Policy Object (LGPO) located in the %systemroot%\System32\GroupPolicy folder. This hidden folder contains two subfolders, Machine and User, and each of these subfolders contains a file named Registry.pol as shown in Figure 1. These two files contain the local policy settings that are applied to the computer and user respectively.

Figure 1: Machine policy for a Windows computer.

In the old days of Windows NT 4.0 and earlier, you could export the Config.pol file (which is analogous to the Registry.pol files of more recent versions of Windows), make changes to it directly, and copy the modified policy file to other computers to directly apply policy settings to those computers.

Unfortunately old habits die hard. Don’t do this with today’s versions of Windows. Using xcopy to directly copy Registry.pol files to computers is not supported. It’s not a supported way of applying policy to Windows computers even in standalone (workgroup) environments. And it’s likely to cause the targeted computers to exhibit some unexpected behaviors because doing so overwrites any existing policy settings on the computer. And in general, you don’t ever want to ever do anything that can cause unexpected behaviors with your Windows computers. Why? Because unexpected behaviors equals unreliability, and having a reliable IT infrastructure is one of the main goals of your job as admin.

Also, when you use xcopy to directly copy Registry.pol files you’re placing the targeted computers into an unsupported state. And this means that even Microsoft Support likely won’t be able to help you if you mess up your network this way.

Let me say it again in several says to make this really clear:

  • Don’t xcopy the %systemroot%\System32\GroupPolicy folder from one computer to another.
  • Don’t create a standalone reference computer and xcopy the %systemroot%\System32\GroupPolicy folder from the reference computer to other standalone (workgroup) computers.
  • Also, don’t use Secedit.exe to export local policy settings from one standalone computer and then use Secedit.exe again import the exported settings into other standalone computers. The reason for not doing this is because Secedit.exe exports some but not all policy settings, so you’ll probably end up missing some settings, which may cause unexpected behaviors.

If you must make direct modifications to local policy settings on Windows computers, especially in workgroup environments where Group Policy can’t be used, you basically have two options:

  • Write some C++ code that leverages the IGroupPolicyObject API as described here
  • Use the utilities created by Aaron Margosis, which are described at and available from this link (and be sure to use the latest version of the utilities found at the end of Aaron’s blog post)

Disabling services to reduce attack surface

A common “best practice” with earlier versions of Windows was to recommend administrators disable any Windows services that are “not needed in their environment” in order to “reduce the attack surface” of their computers. The idea was that the more services your computers had running, the more ports on the network they were listening to, which means more doors for attackers to knock on. And if one of those services had a design flaw and could be exploited in some way…you get the idea.

So admins often made it a habit of disabling any services they thought their environment didn’t need “just to be safe”, for example:

  • Don’t need to print anything from the computer? Disable the Print Spooler service to be safe.
  • Don’t use Offline Files? Disable the Offline Files service to be safe.
  • Don’t use EFS to encrypt files and folders on the computer? Disable the EFS service to be safe.
  • Using a third-party firewall? Don’t need Windows Firewall so disable the Base Filtering Engine and Windows Firewall services to be safe.

You get the idea, and I’m sure you’ve probably done something like this in the past to “make your computer safer” because I know I have. See Figure 2 for an example of a really secure Windows computer.

Figure 2: This Windows computer is really secure! But just try to use it to get some work done…

So should you do this? No, please don’t do this. Why not? Because when Microsoft develops a version of Windows, they test it using a specific set of Windows services enabled called the Out-Of-Box (OOB) configuration. They don’t test it with the Print Spooler service disabled, or Windows Firewall disabled, so if you decide to disable any services like these that are configured with Automatic startup type, you’re treading into uncharted territory. The result is that some features may not work as advertised, or may behave in strange and unexpected ways from time to time. In other words, your computers will become less reliable than if you had simply the default services configured as they came from the box.

Let me say it another way. So you disabled the Print Spooler service to make your computer more secure? Congratulations! You’ve just made your computer less reliable!

Summary so far

  • Want to make your Windows computers less reliable? Write directly to the registry locations where policy settings are stored!
  • Want to copy local policy settings from one computer to another in a workgroup? Xcopy the Registry.pol files, cross your fingers and hope everything still works! It won’t though, something will probably break.
  • Want to make your computers really secure? Disable a bunch of services that are configured to start automatically by default. Congratulations, your computer is now more secure but less reliable (and less usable too)!

More in the next article in this series…


If you would like to read the next part of this article series please go to How to wreck your Windows network (Part 2).

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top