Registry Overview

Microsoft® Windows® 2000 Scripting Guide

The registry is the centralized configuration database for the Windows operating system and for applications and services running under Windows. As such, it plays a vital role as the repository for computer system configuration data. The registry stores a wide range of configuration settings, from boot parameters to user desktop settings. Because these settings play a crucial role in determining how - and sometimes even if - a computer runs, managing the registry is an important aspect of Windows system administration.

You might not be aware of it, but if you manage Windows-based systems you spend a significant amount of your time reading and modifying settings in the registry. Many of the Control Panel applets, command-line tools, and Microsoft Management Console (MMC) plug-ins that you use each day perform some of their functions by reading, changing, or adding registry subkeys or entries. These tools offer a more user-friendly interface for working with the registry and provide a safeguard against misconfiguring a registry value. When you use these tools, you might not be aware that you are actually modifying the registry.

In most cases, you can use system tools to indirectly modify registry settings. However, occasionally you need to work with the registry directly, especially if you do not have system tools available that can manage those settings across an enterprise. When you need to manage registry settings across an enterprise and no system tool is available to do this, you can use scripts that leverage the WMI Registry Provider.


  • Windows Script Host also provides methods for working with the registry. However, these methods represent only a subset of the capabilities found in the Registry Provider. In addition, the Registry Provider makes it as easy to work with the registry on a remote computer as it does to work with the registry on the local computer. WSH, by contrast, is designed to work only on the local computer.

Regardless of whether you use the registry editors or a script, when you edit the registry directly, you must determine which entries or subkeys to modify and how to modify them. In contrast, if you use a system tool to modify the entries or subkeys, the tool will determine which items you can modify and will ensure that you can make only valid modifications. For example, if only 0 and 1 are valid values for a registry entry, these tools will typically not allow you to set the value of the entry to 2 or 3. Before you decide to write a script or otherwise edit the registry directly, research the use of the following configuration management alternatives:

  • Group Policy

  • Scriptable COM objects

  • Command-line tools

Given how critical the registry is to the proper functioning of the operating system and your applications, it is imperative that you back it up regularly. You should be especially diligent about backing up the registry immediately before editing it - directly or indirectly.

This chapter demonstrates how to use the WMI Registry Provider in your scripts to automate the examination, modification, and deletion of subkeys and entries in the registry. The chapter does not explain the meaning and effect of the various entries in the registry. To make use of the scripting techniques demonstrated, you must already be knowledgeable about certain subkeys or entries. Otherwise, begin by consulting a reliable source of information such as the Registry Reference on the Microsoft Windows 2000 Server Resource Kit companion CD, or on the Web at

The Registry Reference contains detailed information about where in the registry specific configuration settings are stored, what values the settings can have, and what the values mean. The Registry Reference also includes a "Change Method" section for many of the entries; these sections describe system tools that manage the entry so that you can avoid editing it directly.


  • Changing the registry with a script can easily propagate errors. The scripting tools bypass safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. Before scripting changes to the registry, test your script thoroughly and back up the registry on every computer on which you will make changes. For more information about scripting changes to the registry, see the Registry Reference on the Windows 2000 Server Resource Kit companion CD or at

Registry Editor

The registry editors Regedit.exe and Regedt32.exe are the GUI-based system tools for managing the registry. They present a view of the registry that looks similar to the Windows Explorer view of the file system.

Although you can use the registry editors to connect to and manage the registry on a remote computer, they do not provide an easy way to make the same changes across multiple registries. If you need to make such enterprise-wide changes, you should first investigate other means, such as Group Policy. If you find no other alternative, try scripts like the ones presented in this chapter.

To open the registry editor Regedit.exe

  • In the Run dialog box, type regedit, and then click OK.

Figure 16.1 shows the registry editor Regedit.exe.

Figure 16.1 Registry Editor Regedit.exe



  • In Windows 2000, there are two registry editors Regedit.exe and Regedt32.exe. Each provides a different view of the information in the registry and includes useful features not available in the other. Regedit.exe, for instance, provides powerful search capabilities, while Regedt32.exe enables the viewing and changing of access permissions.

Registry Structure

The registry, as it appears in Regedit.exe, has a hierarchical organization. Figure 16.2 identifies the elements in the hierarchy as they are displayed in the registry editors: subtrees, keys, subkeys, and the components of a registry entry. This hierarchy looks similar to the system drive letters, folders, and subfolders you find in Windows Explorer.

Figure 16.2 Registry Elements


When you view the registry in a registry editor, you see the hierarchy in a tree control in the left section of the window and the registry entries in the right section of the window. When you are using a registry editor, you typically navigate through the keys and subkeys of a given subtree until you find the entry you are interested in and then edit that entry. You rarely need to edit the subkeys themselves.


Subtrees make up the first or root level of the registry hierarchy. If you compare the elements of the registry hierarchy to the elements of the file system hierarchy, registry subtrees correspond to file system drive letters. Each subtree contains a particular category of keys, subkeys, and entries. The HKEY_LOCAL_MACHINE subtree, for instance, contains computer-specific settings, while the HKEY_CURRENT_USER subtree contains user-specific settings. Many of the changes you make to the registry involve entries contained within one of these two subtrees.

Table 16.1 lists all the subtrees in the registry along with descriptions and commonly used abbreviations. (In registry documentation, for example, you will typically see HKEY_CURRENT_USER referred to as HKCU.)

Table 16.1 Registry Subtrees





Symbolic link to HKEY_LOCAL_MACHINE\SOFTWARE\Classes

Clicking on the HKEY_CLASSES_ROOT subtree takes you to the same place you would reach by navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Classes



Symbolic link to a key under HKEY_USERS representing the current user



Information about the local computer



Information about users



Symbolic link to the key of the current hardware profile under HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\IDConfigDB\Hardware Profiles



Information about performance. Not accessible using the registry editors

No commonly used abbreviation

Keys and subkeys

Keys make up the second level of the registry hierarchy. They correspond to top-level folders located in the root directory of a file system. Keys can contain other folder-like elements known as subkeys. Keys do not normally contain registry entries other than the default entry (to be discussed later in this chapter).

Subkeys are analogous to subfolders. They can contain other subkeys as well as registry entries.


Registry entries correspond to files in a file system. Unlike subtrees, keys, and subkeys, entries are designed to store configuration data, not to categorize it. An entry consists of a name, a data type (which defines the length and format of data that the entry can store), and a field known as the value of the entry. Configuration data is stored in the value field of a registry entry.

Table 16.2 lists all of the data types that can be used in registry entries. The first four are the ones most commonly used in scripts.

Table 16.2 Registry Entry Data Types

Data Type



A string (series of characters) that ends with a null character. Strings that end with a null character are known as null-terminated strings. The Z in REG_SZ refers to the null (or zero) character.


A number that can range from 0 to 4,294,967,295.

DWORD refers to the fact that 32 bits are allocated for storing the value. Because 16 bits of storage space is known as a word, 32 bits is known as a double word (DWORD).


An array of null-terminated strings that is itself terminated by two successive null characters. This enables you to store multiple values in a single registry entry, similar to the way arrays enable you to store multiple values within a single variable.


A null-terminated string that contains unexpanded references to environment variables (%PATH%, for example).


Binary data in any form.


A number that can range from 0 to 4,294,967,295 and is stored in a format known as little-endian. (Little-endian means that the most significant byte is located on the right end of the word.)


A 32-bit number in big-endian format. (Big-endian means that the most significant byte is located on the left end of the word.)


A 64-bit number.


A 64-bit number in little-endian format (same as REG_QWORD).


A device driver resource list.


A list of hardware resources that a physical device is using. The system detects the resources and writes the list into the \HardwareDescription tree.


A device driver's list of possible hardware resources that it or one of the physical devices it controls can use. The system writes a subset of this list into the \ResourceMap tree.


A Unicode symbolic link. Used internally; not used by applications.


No defined value type.

Each registry subtree, key, and subkey has a default entry. Default entries are of the string data type, which is denoted REG_SZ. If a default entry does not contain a value, a registry editor displays the value as (value not set). When you create a subkey, a default entry with (value not set) is automatically added. You can change the value of the default entry using the methods of the Registry Provider. Note that, in contrast, the RegWrite method of the WshShell object does not allow you to modify the value of the default entry.

Registry files

The registry is composed of several sources of data. These sources include some of the files in the folder systemroot\System32\config. Each file that houses some portion of the registry is known as a hive. The list of hive files is stored in the registry itself.


  • The registry editors hide some portions of the registry, including a subtree related to performance counters. These items are not accessible because you should never directly modify them. Incorrectly configuring these values could seriously degrade the performance of your computer.

Listing 16.1 contains a script that displays the locations of the registry hive files. It retrieves the information from registry entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist subkey. The techniques used in this script are explained later in this chapter.

Listing 16.1 Listing the Files That Make Up the Registry


Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."

Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
 strComputer & "\root\default:StdRegProv")
strKeyPath = "System\CurrentControlSet\Control\hivelist"
objReg.EnumValues HKEY_LOCAL_MACHINE, strKeyPath, _
 arrValueNames, arrValueTypes
For i=0 To UBound(arrValueNames)
 Wscript.Echo "File Name: " & arrValueNames(i)
 objReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath, _
 Wscript.Echo "Location: " & strValue

When the preceding script runs under CScript on a Microsoft® Windows® 2000 Professional-based computer, information similar to the following appears in the command window:

Location: \Device\HarddiskVolume1\WINDOWS\system32\config\SECURITY
Location: \Device\HarddiskVolume1\WINDOWS\system32\config\SOFTWARE
Location: \Device\HarddiskVolume1\WINDOWS\system32\config\SYSTEM
Location: \Device\HarddiskVolume1\WINDOWS\system32\config\DEFAULT
Location: \Device\HarddiskVolume1\WINDOWS\system32\config\SAM
File Name: \REGISTRY\USER\S-1-5-20

Note that there are no file extensions on the file names.

Constants Commonly Used in WMI-based Registry Scripts

Most of the scripts in this chapter use the WMI Registry Provider, and many use constants that specify a subtree or an entry data type. These constants are expressed as hexadecimal values for subtrees or as integer values for entry data types.

Hexadecimal values for subtrees

Many of the Registry Provider methods require, as the first parameter, a hexadecimal value indicating the registry subtree that the method should act upon. Table 16.3 lists the registry subtrees and the hexadecimal values used to represent them within Registry Provider methods.

Table 16.3 Registry Subtrees and Corresponding Hexadecimal Values













In your scripts, you can use either the hexadecimal values or a constant that has been set to the appropriate value. For example, you might set a constant named HKEY_USERS to &H80000003:

Const HKEY_USERS = &H80000003

In your scripts, you would then use the constant to access the subtree rather than the hexadecimal value. The constant HKEY_USERS is likely to be more meaningful for someone reading and maintaining your script than the value &H80000003 would be.

Integer values for registry entry data types

When you use Registry Provider methods that work with the data types of registry entries, you have to translate between the common string representation of the data type, such as REG_SZ, and the integers that the Registry Provider uses to refer to the data types. Table 16.4 lists the registry data types and the corresponding integers that you need within your scripts.

Table 16.4 Registry Data Types and Corresponding Values

Registry Data Type












In other words, when you query a registry entry for its value type, WMI will return one of the integers shown in the preceding table. If you want to display the value as a string, you will have to do the conversion yourself. For example:

If intDataType = 1 Then
    strDataType = "REG_SZ"
End If