Pushing Out Security Settings that are Configured in the Registry


Unless you have been living under a rock, you have been watching the IT community stand up and take notice of all of the security issues that keep rising up, day after day. One of the most prevalent areas where you have seen the ever rising attention to security is within Group Policy. Group Policy is one of the core operations that is performed by Windows Active Directory. Within the past two years, Microsoft has doubled the number of Group Policy settings that they ship with the operating system. There are now nearly 1700 settings in a standard Group Policy. The emphasis on most of the Group Policy settings is security.

New applications are constantly being provided to help protect against the spyware, viruses, worms, malware and other malicious code that is running through our networks and the Internet. Microsoft and other companies are trying to develop solutions as fast as they can, but the core problem is still not being addressed.

The core problem to many of the security issues on a Windows computer is that the baseline security is not configured properly. When you get a computer installed for the first time, it is no where near as secure as it could, or should be. Even if you go through every Control Panel setting and Group Policy option, you won’t get the computer to the baseline security that you desire.

The only way to get a Windows computer to a security level that will be near bulletproof is to make additional Registry changes that are not exposed through any interface, except Regedt32.exe. There are many ways to get these Registry changes completed on every computer in the enterprise, but some are certainly more efficient than others.

The Reality of the Problem

You might be thinking that there are not that many Registry settings that can help protect your computer. The reality of the overall problem becomes very prevalent when you start researching and investigating the abundance of “Registry hacks” that are discussed in the Microsoft Knowledge Base articles.

Another place that you might find Registry related security fixes is within the newsgroups. For example, I monitor a Group Policy question board and the last question that I had was with regard to controlling USB devices. A quick search on the Internet says to modify the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsbStor Registry value to control a USB device. If you do an exhaustive search through any existing tool that is provide by Microsoft, you will not find a way to control this value without manually updating the Registry. Let’s first take a look at updating the Registry manually for these security related settings.

Manual Configurations

Most administrators use the Regedt32.exe tool to modify the Registry on their Windows 2000, XP and Server 2003 computers. There are other tools out there, but this one comes built-in to the operating system. Most of you reading this article have used Regedt32.exe multiple times this week, if not today alone.

The complexity of manually updating the Registry is not in using the tool. The complexity of updating the Registry manually comes when you have to update every computer in the organization. Imagine that you have 10 domain controllers, 100 servers and 1000 clients. A single Registry change would require you to modify 1110 computers. You might be able to do this from a single console, but it would require 1110 remote Registry connections to get the job done. If another Registry value needed to be changed, that would require another 1110 remote alterations. As you can see, this method is not efficient, nor one that should be attempted for global Registry value changes.

Using Scripts

A solution to the clumsy manual Registry alteration method is to script the Registry value. There are many options for configuring scripts. You can even create a *.REG file, which can function in a batch file or even locally to update Registry values.

If you want to take the more sophisticated approach, you can use tools that create robust scripts that can then be referenced in logon scripts, Group Policy scripts and more. These might include VB scripts, Java scripts, or even proprietary scripting language.

The use of scripts is very common and is also very powerful. There is almost nothing that you can’t do within a script. The rub of deploying security sensitive configurations through a script is the fact that scripts need some action to occur in order for the script to run. This might be the computer starting up, restarting, or the user logging on. If the computer is already started and the user has already logged on, the script won’t automatically execute. This is the case even if the script is configured in a Group Policy.  

Custom ADM Templates

It would sure be great if there was some way to configure Registry changes so that the automatic background refresh mechanism in Group Policy could make those changes dynamically. Well, that solution is available. Microsoft has had the capability to deploy Registry changes from a central location since Windows 95/NT System Policies.

The Registry changes are configured in files name Administrative (ADM) Templates. These templates use a very simple coding syntax to establish the correct Registry path, value and value data that needs to be changed. The ADM templates also create the graphical interface that appears in the Group Policy Object Editor so the administrator can easily see and set the policy.

These ADM templates are not extremely difficult, as you can see in the sample shown in Figure 1.

Figure 1: Sample of a custom ADM template.

One of the main problems associated with ADM templates is when they get large. When they get large, they can cause an overload in replication of the Group Policies that they are associated with. Another problem with ADM templates is that you must know the syntax for the files. When the files get large, the structure of the code can get a bit confusing and mistakes are more prone to occur. A final issue with ADM templates is the way the Group Policy Object Editor interface deals with certain areas of the Registry. If you create an ADM template for a Registry value that does not fall within the “Microsoft approved” area of the Registry, you will need to jump through some hoops for that setting to show up in the editor interface.

PolicyMaker Registry Extension

We have seen that manual editing of the Registry is very inefficient. Using scripts requires knowledge of a scripting language and they are event driven. ADM templates take advantage of the Group Policy background refresh, but they have other limiting features. One solution that solves all of these problems, but still has all of the benefits, is called PolicyMaker Registry Extension. This is a free product that can be downloaded and deployed for your entire organization.

This tool fixes two of the most troubling issues that the other solutions can’t. First, the tool does not require that you code anything! The tool allows you to browse to the desired Registry value, as shown in Figure 2.

Figure 2: PolicyMaker Registry Extension allows you to browse for the correct Registry entry.

The other aspect that is beneficial is the ability for the tool to make any Registry value entry, even those that Microsoft ADM templates deemed as unsupported or not approved. This includes all Registry values that fall outside of the “Policies” subkeys, binary Registry entries and multi-valued entries.


It is not a matter of if, but a matter of when will you need to deploy Registry settings to alter security related aspects of your Windows computers. Knowledge bases after knowledge bases describe Registry values that must be changed in order for computers to be secure. There are many ways to approach the configuration of these Registry values, but some methods provide more efficient and secure results. Manually updating Registry values for a corporate environment is really not a plausible solution. Using scripts to deploy the Registry settings is an option, but one that might leave the computer unchanged until the user decides to logoff or the computer is required to restart. ADM templates are a great solution for ensuring the change will occur within a short period of time due to Group Policy refresh, however the templates can become too large and cause other administrative issues. By far the best cheap solution is to use the PolicyMaker Registry Extension. This solution solves all of these problems and fixes the limitations that Microsoft hard wired into the ADM templates with regard to certain Registry types.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top