Distributing Registry Changes

Whenever I talk or write about using registry changes to troubleshoot problems, people ask the same question: "How do I make a registry change on multiple computers without traveling to each machine?" To distribute registry modifications across the network, you can use one of three methods: imported registration (.reg) files, regini.exe, or group or system policies.

Before I discuss these options, I'm compelled to give the usual warning: Messing with the registry is dangerous. Don't try any of these suggestions unless you're comfortable with the registry and you qualify as a power user. Before you begin, you can use regedit.exe to export a key as a backup measure. The exported file carries the .reg extension. Importing the file back into the registry is a quick way to repair the damage if your manipulation of the key causes problems. (Even if you prefer to work with regedt32, you should open regedit first and export the key you're going to tweak. Regedit's export and import features are easier to use than regedt32's equivalent backup procedures.)

You can apply many user and computer restrictions through Group Policy Editor (GPE—in Windows 2000) or System Policy Editor (SPE—in Windows NT and Windows 9x). This article assumes that those resources don't already include the changes you want to make and that registry tweaks are your best option.

Option 1: Create or Export Registration Files
You can distribute .reg files that users can then import into the registries of target computers. All you need to do is create—or use regedit to export, then edit—the .reg files, then distribute them. (Registration files have one serious shortcoming, however: They can't delete anything in the registry. See the sidebar "A Registration File Drawback," for details about this limitation.) Format the registration file's contents as follows:

<RegistryEditorVersion>
<Blank line>
[<RegistryPath>]
"<DataItemName>"="<DataType>:
<DataValue>"

RegistryEditorVersion is whichever version of regedit.exe you're using. This entry identifies the file as a registration file. Regedit automatically adds this information when you export a .reg file, but you must manually enter the information when you create a .reg file. For Win2K, the RegistryEditorVersion is Windows Registry Editor Version 5.00; for NT 4.0, the version is Regedit4.

Blank line identifies the beginning of a new registry path. (Each individual key or subkey is a new registry path.) When you export a key, the .reg file displays a blank line before each key or subkey. If you have multiple keys in your .reg file, blank lines can help you examine and troubleshoot the contents. (Microsoft's instructions state that the blank line is necessary. However, when I create .reg files and inadvertently forget the blank lines, the files still merge successfully.)

RegistryPath is the path to the key that holds the values you're importing. Enclose the path in square brackets, and separate each level of the hierarchy by a backslash—for example, [HKEY_LOCAL_ MACHINE\SOFTWARE\Policies\Microsoft\ Windows\System]. A .reg file can contain multiple registry paths.

When the bottom of the hierarchy that you enter in the path statement doesn't exist in the registry, you're creating a new subkey. Registry files' contents are sent to the registry in the order in which you enter them. Therefore, if you want to create a new key and a subkey below that key, be sure to enter the lines in the proper order. (However, the only reason to create new keys is because you've written software that looks for those keys. Creating new keys isn't a task you perform for system maintenance.)

DataItemName is the data item you want to import. When a data item in your file doesn't exist in the registry, the .reg file adds it (with its value). When a data item does exist, the value in your .reg file overwrites the existing value. Quotation marks enclose the name of the data item. An equal sign (=) immediately follows the name of the data item.

DataType (i.e., the imported item's data type) immediately follows the equal sign, unless the data type is of REG_SZ (REG_SZ types are strings). For all data types other than REG_SZ, a colon immediately follows the data type. Table 1 shows the entries for five common data types. (Nine data types exist, but the types in Table 1 are likely to be the only ones you'll use for system maintenance.) For information about these data types, see the sidebar "Registry Data Types," page 70.

DataValue (i.e., the value you want to import) immediately follows the colon and must be in the appropriate format (i.e., string or hexadecimal—use hex format for binary data items). You can enter multiple data-item lines for the same registry path. For example, the data-item lines

"GroupPolicyRefreshTime"=dword:
00000014
"GroupPolicyRefreshTimeOffset"=
dword:0000000f

reflect the hex entries that these data items require: 00000014 is the hex equivalent of 20, and 0000000f is the hex equivalent of 15. If you're uncomfortable with hex or other nonreadable data, restrict your .reg file creation efforts to items that are neither binary nor hex format.

The registry doesn't have a Boolean data type (although it should, and I can't believe Microsoft hasn't gotten around to this yet). However, Boolean type data is usually a DWORD (4 byte) or String (2 byte) item type in the registry. If you're using your .reg file to change values, check the data item in the registry to make sure you match the data type. You don't need to enter the full string in your .reg file; you can omit leading zeros for all numeric values.

Figure 1 shows a sample .reg file that you can use to get rid of the Start menu's Documents item. (You probably won't find many users who miss the Documents menu item or even notice that it's gone. If a user wants to keep the Documents menu, don't send the file to that person.)

   Previous  [1]  2  3  4  5  6  Next