Automated Registry Updates

The ability to remotely perform registry updates on multiple computers is useful in all sorts of situations. When something in the registry configuration compromises security, quickly performing registry updates is an important security measure. Remotely updating multiple computers' registries is also helpful when you need to apply a custom OS change to a set of systems or apply an additional registry entry so that software operates properly. Whatever the reason, performing registry updates centrally is crucial in midsized to large networks.

The Microsoft Resource Kit Group recently asked me to write a series of scripts for the "Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II," which you can download from http://www.microsoft.com/downloads/details.aspx?familyid=c0dbeb7e-d476-4498-9f6c-24974fb81f1e&displaylang=en. One of the scripts that I wrote, ApplyReg.vbs, remotely updates the registries of multiple computers. Although you can use the Reg utility with the Add parameter to perform remote registry updates, Reg works for only a limited set of registry keys. In contrast, ApplyReg.vbs doesn't impose any key limits. The script performs registry updates against a list of computers that you provide, then it creates a report that notes whether each computer's set of registry updates was successful.

ApplyReg.vbs relies on several technologies: Active Directory (AD), Active Directory Service Interfaces (ADSI), Windows Management Instrumentation (WMI), Windows Script Host (WSH) 5.6, and VBScript. (If you want to use a Perl script to apply registry updates, see "Checking Remote Registries," May 2002, http://www.winnetmag.com, InstantDoc ID 24540, for information about using Perl to work with the registry.) Let's look at how to prepare for ApplyReg.vbs (including how to test the script), how to run the script in production, and how the script works.

Preparing to Use the Script
Microsoft's registry mantra goes something like this: "Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system or even require you to reinstall Windows. If you must edit the registry, back it up first." If you didn't recognize the importance of this message before, believe it now. ApplyReg.vbs is capable of editing—and damaging—the registry on thousands of computers in minutes.

In keeping with Microsoft's registry warning, before you use ApplyReg.vbs in a production network, you need to test and retest the script in a lab. The test systems should accurately represent the production computers targeted for the registry update.

ApplyReg.vbs relies on AD to determine the host name or NetBIOS name of the computers in which it will apply the registry update. Therefore, make sure that all test computers, including the computer that will run ApplyReg.vbs, are members of an AD domain. After you configure the test systems, you need to either download or create several files:

You need to download ApplyReg.vbs from the Windows & .NET Magazine Web site at http://www.winnetmag.com. (Enter 40714 in the InstantDoc ID text box, click the Download the Code link, and download the 40714.zip file.)
You need to create a registry (.reg) file that contains the registry updates you want to apply. I've included a sample registry file named AAA123Test!!!.reg, which is in the 40714.zip file. You can use this sample file to take ApplyReg.vbs for a test run. This registry file, however, is only a sample file. Don't apply it to computers in a production network. If you're unfamiliar with the format of a registry file, see the sidebar "The Registry File Format" and review the contents of AAA123Test!!!.reg.
You need to create a text (.txt) file that contains a list of computers to update. In this input file, list the target computers by their distinguished names (DNs). Place each DN on a separate line, enclose each DN in quotation marks, and append a comma after the ending quotation mark. Do not include blank lines. At the top of the input file, enter a column heading, such as Distinguished Name. Figure 1 shows an example of a valid list. Adding the column heading and adding the trailing commas are important; otherwise, ApplyReg.vbs might not work correctly.

An alternative to manually creating the input file is to use the script ComputerSearch.vbs to programmatically generate a valid list for ApplyReg.vbs to read. The "Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II" download includes ComputerSearch.vbs. The guide's "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" section describes how to create and run ComputerSearch.vbs. ComputerSearch.vbs will generate a properly formatted input file that contains the DNs of the computers in your domain.

Previous [1] 2 3 4 Next

Can this same script be used to just reada remote registries and generate a report?

rsharma November 25, 2003

Where is the link to the 40714.zip file referneced above. I can not find any such link.

Steven Sutherland November 27, 2003

Enjoyed the article, I think ApplyReg.vbs could become(IS)a valuable utility.
However, after I entered 40714 (Enter 40714 in the InstantDocID text box, click
the Download the Code link) I'm unable to find this link on the page. What am I overlooking ?? My co-worker has the subscription and she doesn't see it either.

Michael Radzymski December 03, 2003

I could not find the 'download the code' link mentioned in this article....

Dale December 03, 2003

In what situation would you use ApplyReg.vbs, and how common is it use in networks.

lewis bailey December 04, 2003

Since most environments are not strictly microsoft ad, how would you modify the script to use netbios names instead of using the fqdn?

Louis January 08, 2004

I very much enjoyed this article about updating remote registries. I am always looking for articles like this that show more advanced scripting because I write a lot of VBScripts. I reviewed ApplyReg.vbs and just want to make a couple of remarks. 

When I write scripts that perform actions on a series of remote computers, I also have a function that checks whether the remote computer is reachable. Instead of using Ping and reading the output to determine whether the remote machine answered, I prefer to use the Win32_PingStatus WMI class, which is available in Windows XP and Windows Server 2003, for a couple of reasons. First, I think that this method is a more elegant approach to this task. Second, we work in an environment with computers in 5 different countries in Europe, all of which use their local language on their machines. Writing a script that reads the output of a command-line command is difficult when multiple languages are involved.

The other thing I would like to mention is that NetBIOS or Fully Qualified Domain Names (FQDNs) are always easier to remember than distinguished names (DNs). I wrote scripts that used a text file with server NetBIOS names as the input file. I then used ADO to make an Active Directory (AD) search when I need the DN of the server. Because a small function looks up the DN, you don’t have to prepare the input file that you suggested with the DN already in the text file. Using a function to get the DN has another slight advantage: You can reuse the function in every script that requires a DN.

A note from Ethan: I’m aware of the Win32_PingStatus class, and I agree with you that this is the best approach. Just to give you some history, I specifically choose the approach I took because the Windows Resource Kit team originally asked me to write these scripts and the team told me that I must make the tool work in a pure Windows 2000 environment. I couldn't even rely on having a Windows XP client for running the script. As a result, I went with the non-localized approach of reading the "reply from..." message. Your approach is much better when you can assume that one client is running Windows XP.
You make another great point about using DNs instead of FQDNs or NetBIOS names in the script. Again, a little history is in order. The goal was to take the output from another script as the input for the ApplyReg script. The output from the other script was the DNs of all domain controllers in a domain. If you get a chance, take a look at the two white papers that I reference in the article. The scripts, including ApplyReg, were written specifically to support the security goals delineated in the white paper.

Stefan January 22, 2004

Hi!
I´ve enjoyed a lot reading this article because it helped me very much.
I just have one question to make to you that is what if a computer in my network is not available at the time i´m updating the registry´s, the script creates a loop that when the machine is available it sends the new keys or if not how can i resolve this issue???

Thanks a lot!!!

Mario Raposo March 03, 2004

Can this script be used to change permissions on reg keys?

JC May 18, 2004

Ethan--excellent script, I am now using it all the time.

One problem however... When the CreateDWORD subroutine converts the hex value using CInt, it can't handle large numbers. For example, it will fail converting the hex value '00010000', and therefore will not write that value to the registry. I resolved this by changing CInt to CLng.

mvanwely August 19, 2004 (Article Rating:

)

See More Comments 1 2

You must log on before posting a comment.

If you don't have a username & password, please register now.