Chapter 18
Understanding the Registry
The Registry is one of those pervasive items in Windows NT that plays an enormous role in making everything work. It is also often the biggest source of mystery for neophytes and experts alike. If you ever plan on doing anything more than a cursory amount of system administration, you will need to become familiar with the Registry, how it works, and how to make changes to it. The sooner you develop this knowledge, the more it will benefit you and the more proficient you will become at your job.
This chapter provides an overview of the Windows NT Registry, including how to examine and change data recorded in the Registry with programs such as the Registry Editor and Windows NT Diagnostics.
NOTE:The Windows NT Registry database contains thousands of items. For the best coverage of what each setting does, refer to the first volume of the Windows NT Resource Kit, the Windows NT Resource Guide.
By the end of this chapter you should have the tools and knowledge you need to be comfortable working with the Windows NT Registry database—one of the basic skills necessary for administering Windows NT systems.
The Windows NT Registry Database
Windows NT stores all its configuration information in a hierarchical database called the Registry. The Registry contains user, application, hardware, and operating system information, and replaces the .INI files from Windows 3.x. It also provides configuration security and multiuser support in a more extensible and adaptable framework than is provided in Windows 3.x.
The first thing you must know about the Registry is that making invalid changes to it can result in system instability or complete failure of the operating system to boot. Whenever Microsoft support personnel issue tech notes describing changes that must be made to the Registry to fix a problem or implement a desired feature, they are always careful to include a lengthy disclaimer indicating the making changes to the Registry could make a system unusable and should only be done by knowledgeable people. Most responsible authors also include such a statement by way of disclaimer.
WARNING: Using the Registry Editor to make changes to the Registry can result in unexpected results when misused. You should fully understand how to use the Registry Editor and the exact purpose of any changes before making them. Even if you fully understand what changes you are making, there is still the possibility that you might make a mistake because the Registry doesn't use any form of syntax or validity checking when you make changes. Therefore, you should also have a recently updated copy of your systems Emergency Repair Disk (ERD), as well as an understanding of how to recover from failed attempts at editing the Registry, which is discussed later in this chapter.
Now that I've put in that disclaimer, I think it's also important to note that it is much easier to recover from mistakes while editing the NT Registry than it is while editing the .INI files with Windows 3.x. Also, many sources, including some Microsoft documentation, say that you should never need to make direct changes to the Registry because most changes that must be made can be effected through other, less perilous utilities. This is true of your average user. There is no reason that an average user should need to make changes. However, as a system and network administrator, you must understand how to make the changes, because you will need to edit the Registry occasionally to keep your system working properly.
NOTE:Many people are surprised when I tell them that Windows 3.x also contains a Registry. However, the Windows 3.x Registry is not very sophisticated and plays a much smaller role than does the NT Registry. The Windows 3.x Registry only contains information on the OLE classes, as well as associations that link file extensions (such as .DOC) to applications.
Looking at Design Goals for the Registry
When Microsoft programmers designed Windows NT, they recognized the need for a better way to manage configuration information than the simple .INI files used in Windows 3.x. In particular, they needed a means of providing certain functionality that could not be provided by the .INI files, including the following:
- Single repository for configuration information. If you've been burdened with the task of managing Windows 3.x systems with many different software packages, then you're familiar with the trouble of locating the often buried and hidden configuration files for different parts of the operating system or software packages. For a particular application, the information might be stored in the SYSTEM.INI, WIN.INI, or an .INI created by the application itself and stored in the C:\WINDOWS, C:\WINDOWS\SYSTEM, or even in the application's own directory. Worse yet, configuration information for a particular application might even be stored in more than one location. The NT Registry database alleviates this problem by providing a single place for applications to register configuration settings.
- Support for multiple users on a single computer. With .INI files, it is difficult to provide users with their own set of personalized options. With .INI files, all users on a single computer are forced to share configuration information, which often leads to a lot of annoyances; if one user makes a change to fit his or her preference, it affects all other users on the computer. NT's security paradigm requires a user to have a confidential set of preferences. The Windows NT Registry supports each user having his or her own preferences for both operating functions and applications.
- Granular security for configuration settings. With Windows 3.x, many different configuration settings are set in a single .INI file. To provide security, or some degree of configuration management, you must choose one of two methods: Either protect the entire .INI file and prevent users from changing it, or don't protect the .INI file, permitting users to make any changes. There is no finer level of granularity. However, with the Registry, you can protect each entry in the Registry database with an access control list (ACL), which lists the exact rights granted to any users or groups to a particular Registry value, permitting you to grant read-only access to guest users but a higher level of access to domain users, for example.
- Multiple levels of hierarchy. One of the restrictions of the .INI files is that they permitted only two levels of hierarchy. Within a specific .INI file, you can specify a section name and then include several entries under each section. There is no extensibility to provide further nesting of entries. For example, in the SYSTEM.INI file, there is a section called [boot], which contains several entries, such as shell, network.drv, drivers, and so on. You cannot create a new section that is subordinate to [boot], and this is a great limitation, especially as software is becoming increasingly complex. With the NT Registry, however, you can create deeply nested sections, so that you can organize configuration information in a more logical manor.
- Inclusion of rich data types. With .INI files, you can use only standard ASCII text for all entries. This limits the type of data that can be stored in the .INI files, thereby limiting their usefulness. In contrast, the NT Registry supports extended data types, including not only standard human-readable text, but also binary data, which can even include executable code segments. In addition, Registry information can be stored in 16-bit Unicode format, instead of simple 8-bit ASCII representation.
NOTE:Windows NT still supports the use of .INI files, particularly for programs that are still not written to take advantage of the Registry. In particular, .INI files must be maintained for 16-bit Windows applications because the Win32 API is needed to access the Registry. Because Microsoft heavily favors the use of the Registry, and because Windows 95 also uses a Registry database, Microsoft has made it a requirement for programmers to use the Registry for storing information if they want the Windows 95 logo on their package.
Examining the Structure of the Registry
The Registry database uses a hierarchical format with five main branches. Before going any further, let's look at some of the vocabulary used when dealing with the Registry:
- Root key. There are five main, or root, keys in the Registry database. These contain information that is specific to either the user or the computer. Think of a root key as being similar to a partition on the local computer, that is, c:, d:, e:, f:.
- Subkey. Each root key contains one or more subkeys. If the root key is like a partition on the computer, a subkey is like a folder or directory on that computer. Each subkey can have one or more subkeys under it, similar to the nesting of directories on your hard drive.
- Value entry. Continuing our analogy, a value entry is like a file. Whereas root keys and subkeys are good for organizing information, it is the value entry that actually contains the data. Value entries contain three pieces of information: a name, a data type, and a value. These are discussed subsequently.
- Hive: A hive consists of a particular set of keys, with their dependent subkeys and value entries, contained in the Registry. The hive is stored in a single file in the %SystemRoot%\system32\config directory, along with an associated .LOG file.
NOTE:People commonly misunderstand the difference between a Registry hive and a root key. Quite simply, root keys are at the highest level and are made up of one or more hives. However, some root keys, such as HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, and HKEY_CURRENT_CONFIG don't actually have their own hives, but rather point to information stored in other hives.
Root Keys in the Registry
As mentioned previously, the Registry is made up of five root keys, each represented as a subtree of the Registry itself. Each root key contains subkeys and value entries that contain all the configuration information for the NT system and its users. The five root keys are listed and described in Table 18.1.
Table 18.1. Registry root keys.
| Root Key | Description |
| HKEY_LOCAL_MACHINE | This is the root key that contains the most interesting information. It contains information on the hardware such as processor type, bus architecture, video, and disk I/O hardware. It also contains software information for the operating system, including information on device drivers, services, security, and installed software. |
| HKEY_CLASSES_ROOT | This key is similar to the functionally limited Registry included with Windows 3.x. It contains information on files associations (matching a file extension to an application), as well as acts as the repository for OLE classes. This root key points to data stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Classes subkey. |
| HKEY_CURRENT_USER | This key contains the profile information for the user currently logged onto the console. It contains user-level preferences for the operating system, as well as for applications installed on the computer. This key is a pointer to one of the subkeys stored in HKEY_USERS. |
| HKEY_USERS | This key contains a pointer to the hive for the user currently logged on at the console , as well as a pointer to the hive for the default user. In neither case does HKEY_USERS contain profiles for users who log on remotely. |
NOTE:Functionality for this key has changed in Windows NT 4.0. In previous versions, this key contains the profiles for all users who had logged on at the console of the computer. However, because of the changes to the user profiles in NT 4.0, much of the functionality of this hive has changed, and its usefulness is now mostly to support backward compatibility for programs that access this hive directly.
| HKEY_CURRENT_CONFIG | This is a new root key in Windows NT 4.0. It contains the current hardware configuration information, as specified by the current hardware profile. It actually points to the same contents as the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current subkey. |
Locating an Entry in the Registry
Whenever you need to make a modification to the Registry, you will need the path to the value entry, just as you would need to know the path to locate a disk resource. The Registry path for locating a resource contains the following:
- The name of the root key
- The name of each subkey
- The name of the value entry
For example, to locate the value that sets the current maximum size the Registry can grow to, you would need to know the following:
- The root key name: HKEY_LOCAL_MACHINE
- The name of each subkey:
- SYSTEM
- CurrentControlSet
- Control
- The name of the value entry: RegistrySizeLimit
The path for locating this Registry value entry is commonly written as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RegistrySizeLimit.
NOTE:This value entry might not exist on your system. If it does not exist, the default maximum registry size of 12MB is used. This key might exist on Windows NT 4.0 computers on which you upgraded from previous versions of NT Server, or if you had previously used the System Control Panel to change the maximum Registry size.
Knowing this path permits you to locate the value entry. Each value entry has a data type and value. If a value entry already exists, you can use Registry Editor to see its data type. However, if you need to create a new value entry, you must know the correct data type. For instance, the data type for RegistrySizeLimit is REG_DWORD, and the value can be between 4MB and 102MB.
NOTE:Here is a perfect example of where you should not use the Registry Editor to make changes. The Registry Size Limit can be set using the System Control Panel, which is the method you should use. Because the Registry Editor does not perform any verification when you enter a new value, you could enter a value that causes problems. Fortunately in this instance, if you set the value too high, you won't cause any major problems, and if you set the value too low, NT will automatically default to 4MB, which is the smallest value permitted for this entry. However, making changes to many other value entries could cause system failure if you were to enter an invalid value.
The information for setting a value entry is often written in the format
name:data type:value
For instance, if you used the System Control Panel applet to change the maximum Registry size to 20MB, the complete information for the RegistrySizeLimit value entry would be as follows:
RegistrySizeLimit:REG_DWORD:0x1400000
NOTE:By default, the Registry Editor uses hexadecimal notation for displaying numbers, as indicated by the 0x preface on the value 0x1400000, which is equal to 20,971,520 bytes in decimal notation—or 20 megabytes. Remember, one megabyte equals 1,024 times 1,024 bytes. When using the Registry Editor, you can view numeric entries in decimal, hexadecimal, or binary format.
Windows NT recognizes five data types for Registry entry values. These values are shown in Table 18.2.
Table 18.2. Data types for Registry entry values.
| Data Type Name | Description |
| REG_BINARY | Binary. A value entry of this data type contains machine-readable information. You should never have to edit this type by hand. Many of the value entries of type REG_BINARY have to do with hardware configuration on the system and appear under the HKEY_LOCAL_MACHINE\HARDWARE subkey. An example is HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\Component Information:
Component Information:REG_BINARY:00 00 00 00 ... |
| REG_DWORD | Double word. The double word data type represents a number up to 4 bytes long (traditionally one word is 2 bytes). By default, this data type is displayed in hexadecimal format, although you can also display it in binary or decimal format. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RegistrySizeLimit uses the REG_DWORD data type:
RegistrySizeLimit:REG_DWORD:0x1400000 |
| REG_SZ | Readable text. Values entries of type REG_SZ contain human-readable text and often involve a description or identification. This is a common data type. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner is an example of a value entry that uses a REG_SZ data type:
RegisteredOwner:REG_SZ:Jason Garms |
| REG_EXPAND_SZ | Expandable data string. An expandable data string is similar to a standard REG_SZ, except that it contains a system variable that will be replaced when it is accessed by an application. For instance, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath is defined as type REG_EXPAND_SZ:
DevicePath:REG_EXPAND_SZ:%SystemRoot%\Media
When a program accesses this key, however, it will not get the string "%SystemRoot%\Media" but rather "C:\WINNT\Media"—if you installed Windows NT in the C:\WINNT directory. |
| REG_MULTI_SZ | Multiple string. A value entry of this type contains a list of values, separated by NULL characters. For example, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Sources is of type
REG_MULTI_SZ:Sources:REG_MULTI_SZ:WinsCtrs Winlogon Userenv ... |
NOTE:There is a sixth data type you might see in use in the Registry, REG_FULL_RESOURCE_DESCRIPTOR. It is not listed in Table 18.2 because you cannot create value entries or edit existing values of this type. Most value keys of this type appear in the HKEY_LOCAL_MACHINE\HARDWARE subkey. For example, HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\Configuration Data, which is shown using the Registry Editor in Figure 18.1, is of data type REG_FULL_RESOURCE_DESCRIPTOR.
Figure 18.1
You can't create or edit data types of REG_FULL_RESOURCE_DESCRIPTOR.
NOTE:The maximum size for any single Registry value entry is 1MB.
Registry Hives
A hive is a discrete set of keys, subkeys, and value entries contained in the Registry. Each hive is stored in a single file in the %SystemRoot%\system32\config directory, along with an associated .LOG file. Figure 18.2 is an Explorer window for %SystemRoot%\system32\config, showing the Registry hives and their log files.
Figure 18.2
Each Registry hive corresponds to a particular file and .LOG file in the %SystemRoot%\system32\config directory.
The Registry hives and their associated files are shown in Table 18.3.
NOTE:There is a Registry value entry that is used to point to the location of all the Registry hives: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist. It should not be modified.
Table 18.3. Registry hives and their files.
| Registry Hive | Associated Files |
| HKEY_LOCAL_MACHINE\SAM%SystemRoot%\System32\config\SAM | %SystemRoot%\System32\config\SAM.LOG |
| HKEY_LOCAL_MACHINE\SECURITY | %SystemRoot%\System32\config\SECURITY%SystemRoot%\System32\config\SECURITY.LOG |
| HKEY_LOCAL_MACHINE\SOFTWARE | %SystemRoot%\System32\config\SOFTWARE%SystemRoot%\System32\config\SOFTWARE.LOG |
| HKEY_LOCAL_MACHINE\SYSTEM | %SystemRoot%\System32\config\SYSTEM%SystemRoot%\System32\config\SYSTEM.LOG |
| HKEY_USERS\.DEFAULT | %SystemRoot%\System32\config\DEFAULT%SystemRoot%\System32\config\DEFAULT.LOG |
| HKEY_CURRENT_USER | %SytemRoot%\Profiles\%UserName%\NTUSER.DAT
%SytemRoot%\Profiles\%UserName%\NTUSER.LOG |
NOTE:The HKEY_LOCAL_MACHINE\HARDWARE key is a dynamic subkey that is generated every time Windows NT is booted by the NT hardware recognizer (NTDETECT.COM) and the NT kernel. Although HKEY_LOCAL_MACHINE\HARDWARE is technically a Registry hive, it is stored as an internal structure in the system's memory rather than on disk. In the event of system failure, no valuable data is lost because it is reconstructed from scratch during each system boot.
NOTE:Sometimes people have a hard time relating the root keys to the Registry hives. Remember, there are five root keys, but they don't all have corresponding hives. This is because the root keys HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, and HKEY_CURRENT_CONFIG actually point to information stored in other hives.
Fault Tolerance with the Registry Log Files
Each Registry hive has a corresponding log file, as shown in the Figure 18.2. The log files are provided to ensure the stability of the Registry database, even in the event of a system failure during a Registry update. This procedure works in much the same way that NTFS ensures the stability of the file system in the event of a system failure.
When an update is made to the Registry, NT records the beginning of it in the appropriate hive's log. It then proceeds through the update by recording what change is being made, as well as how to roll back the change to the original state. This information is recorded in the log for each Registry property being updated. When all properties are updated, the change is committed and recorded in the log. At this point—and only at this point—is the transaction complete. If there is a power outage or system failure before the transaction is marked as being complete, when the NT reboots or the system failure is repaired, the NT uses the information in the hive's log file to roll back the transaction to a stable state.
NOTE:Many people get mistaken ideas about what is being described here. When you make a change that affects multiple Registry entries, NT does not ensure that they will all be updated, or that none of them will be updated. What it does guarantee is that for any discrete transaction, either the entire transaction will succeed, or none of the transaction will succeed.
For example, if you modify an existing key and the computer is turned off in the middle of updating the Registry, you will not get a new value with an old time stamp. Or if you were adding several users to the ACL on a Registry value entry and the power failed, you would not get some of the users listed in the ACL to the exclusion of others. You would get none of them if the transaction failed, or all of them if the transaction was committed before the power failure.
The HKEY_LOCAL_MACHINE\SYSTEM hive is an important part of the NT boot process, so it cannot be left in an unstable state when the system is booted. To protect against this possibility, NT keeps an alternate copy of the HKEY_LOCAL_MACHINE\SYSTEM hive in a file called %SystemRoot%\System32\config\SYSTEM.ALT.
When you make changes to the Registry that affect the HKEY_LOCAL_MACHINE\SYSTEM hive, the changes are first applied to the actual system hive, then to the alternate hive. If there is a system failure during the updates to the alternate hive, there is no problem, and after the system boots, NT updates the alternate hive to again be an exact copy of the actual system hive. However, if there is a failure during an update to the actual system hive, when NT reboots it detects that the system hive is dirty, so instead it boots using the alternate hive, which is in an older but stable state. It then rolls back changes to the original system hive.
This kind of fault tolerance helps to ensure that NT will always boot up clean, no matter what might occur.
Recovering the Registry Using the Last Known Good Configuration
Much of the information necessary for Windows NT to start up is stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet subkey. If you—or a program on your system—make invalid changes to one of the value entries in this subkey, your system could fail to boot. Or, if it does boot, it could prevent you from logging on.
To help protect against these kinds of accidental problems, NT keeps copies of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002.
If your NT system fails during startup and you suspect it has something to do with a Registry change you just made or a device you just installed, you can tell NT to use the backup version of the control set by pressing the SPACE BAR during the boot process when NT displays the message Press spacebar NOW to invoke Last Known Good Menu.
When you invoke this option, you lose any changes made to the Registry since the last time a user successfully logged on to the system.
NOTE:It is only after a user successfully logs on to the console of an NT system that the NT boot process is determined to be a success and the last known good configuration information is updated.
Using the Registry Editor
The Registry Editor is the primary tool used to directly manipulate the Registry database. By default, when you install Windows NT, no icon is created for the Registry Editor. In fact, to make things a little more complicated, Microsoft included two different Registry Editors with Windows NT 4.0, REGEDT32.EXE and REGEDIT.EXE. For many common functions, you can use either of these tools; however, REGEDT32.EXE is the correct tool for use with Windows NT.
The REGEDIT.EXE tool is actually the same version of the Registry Editor that ships with Windows 95. Although it supports a few interesting features that you can take advantage of, it has numerous shortcomings for use with Windows NT. There are many occasions on which you could even use both versions of the Registry Editor side by side.
NOTE:Actually Microsoft programmers had included two Registry Editors with Windows NT 3.5 and 3.51 as well. The difference is with 3.5 and 3.51, they included the Windows 3.x version of the Registry Editor. When an unsuspecting administrator looked for the NT Registry Editor and accidentally stumbled across the 3.x version instead, it was very noticeable, so he or she continued looking until they found the correct program, REGEDT32.EXE. However, with Windows 4.0, they also included the Windows 95 Registry Editor, which looks very similar to the Windows NT Registry Editor, and it can even perform most of the actions that people need. Thus, the administrator might not notice the difference.
NOTE:To make matters worse, if you upgraded to NT 4.0 from Windows 3.x, or from a Windows NT 3.x version that had been upgraded from a Windows 3.x version, NT 4.0 leaves the Windows 3.x limited Registry Editor, which is also called REGEDIT.EXE. If this happens and you want to install the Windows 95 version, you can copy it from the NT installation CD. You must copy REGEDIT.EXE, REGEDIT.HLP, and REGEDIT.CNT to the %SystemRoot% directory. This will replace the existing Windows 3.x version.
TIP:You should use REGEDT32.EXE to make any changes to the Registry database. However, there are uses for the Windows 95 REGEDIT.EXE program as well.
The two major advantages of the Windows 95 REGEDIT.EXE follow:
- Enhanced find capabilities. The REGEDIT.EXE program enables you to perform finds using information found in the key or subkey name, the value entry name, or even data contained in the value itself, as shown in Figure 18.3.
Figure 18.3
REGEDIT.EXE has better find support than REGEDT32.EXE.
This is far superior to the basic find support in the REGEDT32.EXE program, which only enables you to search for keys and subkeys. REGEDT32.EXE does not enable you to perform searches based on value entry names or actual data values.
- Full Windows 95 user interface support. The REGEDIT.EXE program takes full advantage of the Windows 95-style interface. It enables you to view all the root keys in a single window, much like the Explorer-style interface, but unlike the REGEDT32.EXE program, which still uses the old Windows 3.1-style interface and displays each root key in a separate window. Also, REGEDIT.EXE makes use of right-clicking. You can right-click a subkey to delete it, rename it, perform a find, and many other functions. One of the most useful features of right-clicking a subkey is the option to Copy Key Name, as shown in Figure 18.4. This enables you to get all the spelling and punctuation correct if you need to copy the subkey to another location.
Figure 18.4
You can right-click to copy the full name of the subkey with all the correct spellings and syntax.
The two main limitations of the REGEDIT.EXE tool when used with Windows NT 4.0 follow:
- Lack of security interface. Because the REGEDIT.EXE tool was made for Windows 95, which lacks a means of protecting the Registry, the REGEDIT.EXE tool does not have any options for viewing or modifying Registry security provided by Windows NT. This also means that you have no means of configuring auditing for Registry data.
- Lack of support for the REG_MULTI_SZ, and REG_EXPAND_SZ data types. Windows 95 does not support the REG_MULTI_SZ or REG_EXPAND_SZ data types. This means that if you use the REGEDIT.EXE utility to view value entries of type REG_MULTI_SZ or REG_MULTI_SZ, they are displayed as type REG_SZ. Also, you cannot use the REGEDIT.EXE utility to create value entries of type REG_MULTI_SZ or REG_EXPAND_SZ.
- Only basic printing support provided. The printed output generated by the REGEDIT.EXE program is rudimentary at best. For better and more accurate Registry output, use REGEDT32.EXE.
Creating a Registry Editor Icon
As mentioned earlier, there is no icon created for either version of the Registry Editor when Windows NT is installed. You invoke the Windows 95 Registry Editor by typing REGEDIT from the Start | Run menu and the Windows NT version of the Registry Editor by typing REGEDT32.EXE from the Start | Run menu.
To create an icon that is visible to all users who log on to the NT Server console, follow these steps:
- Right-click the Start button and choose Open All Users. An Explorer window appears.
- Double-click the Programs icon in the Explorer window shown in Figure 18.5. This brings up another Explorer window.
Figure 18.5
The All Users profile contains a Programs icon, which contains common Start menu items for all users who log on to the system's console.
- Double-click the Administrative Tools icon. This brings up an Explorer window that shows existing shortcuts to many of the NT administrative tools, as shown in Figure 18.6.
Figure 18.6
The Administrative Tools folder contains shortcuts to many of the common NT administrative tools.
- From the File menu, choose New, then choose Shortcut. The Create Shortcut window appears.
- Type REGEDT32 into the Command Line box, then click the Next button. Click the Finish button.
- Close all the Explorer windows.
REGEDT32 now appears with all the other administrative tools in the Start menu, as shown in Figure 18.7.
Figure 18.7
The shortcut to the REGEDT32 utility now appears with the rest of the shortcuts in the Start menu.
NOTE:To create a shortcut to the Windows 95 version of the Registry Editor, repeat this procedure and type REGEDIT instead of REGEDT32 in step 5.
Using the Registry Editor
Now that you have an understanding of some of the basic concepts behind the Registry, let's look at how to use the Registry Editor tool to browse through and make changes to the Registry.
NOTE:Because REGEDT32 is the correct method of editing the Registry (rather than REGEDIT), this section focuses on using REGEDT32.
Open REGEDT32 from the shortcut you created in the previous section or type REGEDT32 at the Start | Run prompt. When REGEDT32 opens, it displays the five root keys, each in its own individual window, as shown in Figure 18.8.
Figure 18.8
Each root key is displayed in its own window.
TIP:If you want to simply browse through the Registry without making changes, you could choose Options | Read Only Mode to avoid making accidental modifications.
To see the Registry Editor in action, let's look at a real-world example. The most common use you'll find for the Registry Editor (aside from just looking around and seeing where everything is) is to change default settings in Windows NT to settings that are better suited to your particular environment.
By default, whenever you send a print job with Windows NT, it generates a print job audit in the System Log, as shown with the Event Viewer in Figure 18.9.
Figure 18.9
Windows NT generates an audit each time a print job is completed.
Perhaps in your particular environment, this is a nuisance and you'd like to disable it. Well, there is no simple method of making this change, at least not using the normal administrative tools such as Print Manager or the Printer Wizards. So you look it up in the Microsoft TechNet CD-ROM reference to see if there is a method of disabling this print audit, and you come across TechNet article Q115841, "Turning Off Print Job Logging in the System Log."
It tells you to go to the subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\Print\Providers and create a new value entry as follows:
EventLog:REG_DWORD:0
To make this modification, follow these steps:
NOTE:To perform the following procedure, you must be logged on as a user with local administrative rights.
- Open the Registry Editor.
NOTE:When you open REGEDT32.EXE, the root keys are each listed in their own window, and the windows are cascaded, as shown above in Figure 18.8. However, for easier viewing, you should maximize the HKEY_LOCAL_MACHINE on Local Machine window, by either double-clicking its title bar or clicking its maximize icon. The screen should now look similar to Figure 18.10.
Figure 18.10
Maximize the root key window for easier viewing.
NOTE:The ability to display multiple document windows within a single program window, such as with the Registry Editor, is called the Windows Multiple Document Interface (MDI). I find that this is often a confusing point and worth pointing out. Often when I explain to someone that they should maximize the MDI child—the HKEY_LOCAL_MACHINE window in the example above—they mistakenly maximize the MDI parent window instead—the Registry Editor, in this case.
- Now you must go down the Registry tree to locate the value entry specified in the TechNet article. Double-click the SYSTEM entry on the left side of the HKEY_LOCAL_MACHINE on Local Machine window. Continue traversing the tree in this method until you end up at the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers subkey, as shown in Figure 18.11.
Figure 18.11
Locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers subkey.
- When you're there, make sure you've selected the Providers entry on the left side of the window. This displays a few entry values on the right side of the window, including the EventLog value key you are looking for.
- One of the first things you'll probably notice is that the EventLog value entry already exists, although the knowledge base article said that you need to create it, don't worry. It is not uncommon for the knowledge base article to contain information that does not match your system. If you look back at the TechNet article, you'll see that it's pretty old and specifically covers NT version 3.1. (My copy of the article is dated September 19, 1994.) This is a good lesson, because Microsoft continuously updates and makes changes to the default Registry settings. Although the article is old and Microsoft has since changed NT so that the EventLog value entry exists by default, the article is still good. This example demonstrates' that it still works.
NOTE:Microsoft is continuously changing the default values in the Registry, as well as which keys exist by default and which do not. However, if you understand the process, you can determine the correct course of action when making changes to the Registry.
- To gain experience working with the Registry Editor, go ahead and delete the existing value entry and re-create. First, note the current value of the EventLog value entry. It is probably 0x1f (or 31 in decimal notation). Also note that the value entry is defined as a REG_DWORD data type.
- Click the EventLog entry in the right side of the window. It should now be highlighted. Choose Edit | Delete, or push the Delete key on the keyboard. You will be warned that the value entry will be deleted and asked to confirm the delete.
- Click Yes. The entry value should be gone from the list on the right.
- Now go ahead and create the new value entry. Make sure the Providers subkey is still highlighted in the left side of the window and choose Edit | Add Value. The Add Value dialog box should appear as shown in Figure 18.12.
Figure 18.12
The Add Value dialog box is used to specify the value entry name and data type for a new value entry.
- Type EventLog in the Value Name field.
- Take a quick look through the Data Type pick list. You'll see that you can define the value entry as one of five data types (see Table 18.2). Choose the type REG_DWORD, as per the directions in the knowledge base article. The completed Add Value dialog box is shown in Figure 18.13.
Figure 18.13
The value name and the data type are entered using the information given in the TechNet article.
- Click OK. This will bring up the DWORD Editor dialog box, shown in Figure 18.14. You can enter information here in hexadecimal, decimal, or binary.
CAUTION:By default, the DWORD Editor dialog box expects data to be entered in hexadecimal format.
Figure 18.14
The DWORD Editor dialog box is used to enter the 4-byte DWORD value.
- Type in a 0 (zero) into the Data field, as specified by the directions in the TechNet article, and click OK.
The EventLog value entry with a value of 0 should now appear in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers subkey, as shown in Figure 18.15.
Figure 18.15
The newly created EventLog entry appears on the right side of the window.
Now test the system this to see if the knowledge base article is correct. This change doesn't take effect right away because most system components only read their Registry configurations when they start up. You could restart the computer to see if it works, or, you could simply stop and then restart the print spooler, which is the piece of software that generated the event log entries. At a command prompt, issue the command net stop spooler and then net start spooler.
Open WordPad or Notepad, type a few characters, and then print it. Next, open the Event Viewer and look at the System Log. Is there an entry for the print job you just sent? There shouldn't be. Next, restore the EventLog value entry to its original setting to see if the print job auditing returns. Follow these steps:
- If you closed REGEDT32, reopen it and relocate the EventLog value entry.
- Double-click the EventLog value entry. This brings up the DWORD Editor dialog box. The Data field should contain a 0. Change this back to 1f (that is, hexadecimal 1f, which is 31 in decimal notation), as shown in Figure 18.16.
Figure 18.16
Change the EventLog value entry back to hexadecimal value 1f.
- Click OK. You should see the change reflected in the right side of the Registry Editor window, which should show the following:
EventLog:REG_DWORD:0x1f
Let's find out if this has in fact re-enabled the print job auditing. From a command prompt, issue the command net stop spooler and then net start spooler.
Open WordPad or Notepad again, type a few characters, and then print it. Reopen the Event Viewer and look at the System Log, or if you still have the Event Viewer application open, press the F5 key to refresh the display. Was a print job audit created for the job you just sent? There should be one similar to that shown in Figure 18.17.
Figure 18.17
Setting EventLog to 0x1f tells the print spooler to generate a print job audit.
Finding Registry Information
Now that you've see the basic workings of the Registry editor, let's move on to something more advanced. The Registry is a large and complex database. It is not always possible to find things unless you know exactly where to look.
Fortunately, REGEDT32 includes a find facility, albeit an overly simplified one.
NOTE:When you are trying to locate a value entry but don't know the name of any of its parent subkeys, or if you are trying to find a value entry and you only know its data value, use the Windows 95 REGEDIT.EXE command. It includes a more full-featured find command.
In the previous example, you had to locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers subkey. Rather than navigating through the multiple subkeys, you could have simply used the View | Find Key menu option key to quickly locate it.
When you choose the View | Find Key menu option, the Find dialog box appears, as shown in Figure 18.18.
Figure 18.18
You can find a subkey using its whole name or a portion of it.
TIP:The find command works using your current location in the Registry database. It will only search the currently selected root key, and only from the point selected in the left side of the root key window. To search the entire root key, scroll to the top of the window and select the root key's name—HKEY_LOCAL_MACHINE, for example.
So if you want to locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
\Print\Providers subkey, you could choose View | Find Key and enter Providers in the Find What field. For a faster find response, select the Match Whole Word Only option. If you are unsure of the exact subkey name, you could enter a portion of the name, in which case you would not select the Match Whole Word Only option. Click the Find Next button. If you started at the top of the HKEY_LOCAL_MACHINE root key, then you would end up with HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Telephony\Providers, which is not what you were looking for. So click the Find Next button again, and this time, the correct subkey is located, as shown in Figure 18.19.
Figure 18.19
Find can be used to quickly locate a subkey.
Securing and Auditing Information in the Registry
As part of the NT security system, you can also provide discretionary access control to discrete Registry value entries.
NOTE:You must use the REGEDT32 utility for creating and editing security settings in the Registry. The Windows 95 REGEDIT utility does not include the necessary support for NT's security subsystem.
The security for Registry keys, subkeys, and value entries is supported regardless of the file system where the Registry database is stored.
NOTE:You can secure Registry information even if the Registry files are located on a FAT partition.
WARNING:If the NT system files are located on a FAT partition, then anyone who is logged on to the system's console can delete any of the NT system files. Although they cannot make changes to or delete individual Registry entries, they can delete entire Registry hives.
Assigning permissions in the Registry Editor is similar to doing so in the File Manager or NT Explorer. To view permissions on a subkey, follow these steps:
- Open the Registry Editor (REGEDT32.EXE).
- Select Windows | HKEY_LOCAL_MACHINE on Local Machine to bring the HKEY_LOCAL_MACHINE root key to the front.
- Click the SOFTWARE subkey, as shown in Figure 18.20.
Figure 18.20
Select the SOFTWARE subkey.
- Choose Security | Permissions. This brings up the Registry Key Permissions window, shown in Figure 18.21.
Figure 18.21
The Registry Key Permissions window looks similar to the File Manager and NT Explorer interfaces for setting security permissions.
NOTE:Permissions in the Registry can be set only on keys and subkeys. They cannot be set for individual value entries.
For each user or group listed in the ACL, you can set the permissions to Read, Full Control, or Special. The Special permissions are shown in Figure 18.22.
Figure 18.22
You can assign a discrete level of permissions using the Special Access setting.
- Use the Add button to add users or groups to the ACL, or use the Remove button to remove existing access control entries (ACEs).
- If you want the changes to propagate down the Registry tree, choose Replace Permission on Existing Subkeys.
WARNING:Making changes to the security permissions of Registry subkeys can result in system failure or other unpredictable problems.
- When you have made the changes you want, click OK.
If you assign Special Access to subkeys in the Registry, you can specify any of 10 discrete settings, summarized in Table 18.4.
Table 18.4. Summary of Special Access permissions for Registry security.
| Permission | Explanation |
| Query Value | Specifies that the assigned user or group can read the setting of a value entry located in the subkey. |
| Set Value | Specifies that the assigned user or group can set the value of a value entry located in the subkey. |
| Create Subkey | Specifies that the assigned user or group can create a subkey located in this selected Registry subkey. |
| Enumerate Subkeys | Specifies that the assigned user or group can identify all the subkeys in the selected subkey. |
| Notify | Specifies that the assigned user or group can receive audit notifications generated from this subkey. |
| Create Link | Specifies that the assigned user or group can create a symbolic link to the selected subkey. |
| Delete | Specifies that the assigned user or group can delete the selected subkey. |
| Write DAC | Specifies that the assigned user or group can modify the discretionary access control (DAC) list for the selected subkey. |
| Write Owner | Specifies that the assigned user or group can take ownership of the selected subkey. |
| Read Control | Specifies that the assigned user or group can read the security information associated with the selected subkey. |
Auditing Registry Keys
With the Registry Editor (REGEDT32.EXE), you can also assign specify auditing on certain subkeys. This is done much the same way as enabling auditing on an NTFS partition using the File Manager or NT Explorer.
NOTE:To audit Registry subkeys, you must be auditing File and Object Access, as specified in the system's audit policy in the User Manager for Domains.
When using the Registry Editor to select a subkey, you can select the Security | Auditing menu option to specify auditing on that subkey. This brings up the Registry Key Auditing window, shown in Figure 18.23.
Figure 18.23
The Registry Key Auditing window is used to specify auditing for a particular subkey.
If you select the Audit Permission on Existing Subkeys option, the audit properties you specify in this window will also be applied to all subkeys beginning at the selected subkey.
You can use the Add button to specify users and groups from the local domain account database or from any trusted domains. When you have added all the users and groups you want to audit to the list, you can specify the events to audit for each user or group by clicking that particular entry and specifying events from the list of checkboxes, as shown in Figure 18.24.
Figure 18.24
Using these options, Everyone on the system will generate an audit event when they access the HKEY_LOCAL_MACHINE\SYSTEM subkey.
CAUTION:For some applications, the Registry is accessed frequently. Auditing these subkeys might create sufficient system overhead that it could adversely affect system performance, not to mention that it will quickly fill up the Security Log.
Using the Registry Editor Remotely
One of the great strengths of the Registry Editor, and of Windows NT, is the capability to remotely access and edit the Registry database. From a Windows NT machine, you can use the Registry Editor (REGEDT32.EXE) to connect to a remote system running Windows NT.
Using REGEDT32, choose the Registry | Select Computer menu option. This will display a browse window, enabling you to locate a remote computer.
Using the browse box, select the computer whose Registry you want to view, or type the computer's name into the Computer field.
You are now connected to the remote computer's HKEY_LOCAL_MACHINE and HKEY_USERS root keys.
NOTE:Remember, the other root keys are simply links to other subkeys, either in the HKEY_LOCAL_MACHINE or the HKEY_USERS root keys.
When you are finished viewing or making changes to the remote computer's Registry, select the Registry | Close menu option to close the connection to the remote Windows NT system.
NOTE:When you connect to a remote NT system's Registry, you are granted the level permission determined by your user account and the privileges granted to it on the remote system.
Summary
This chapter explains the Windows the Windows NT Registry, as well as the primary tool used for editing the Registry—the Registry Editor (REDGEDT32.EXE).
In learning about the Registry, you learned about the terminology used to describe the pieces of the Registry, including hives, root keys, subkeys, and value entries. In addition, you learned about the information that makes up a value entry. This chapter then shows you where the NT Registry hives are stored and how the hives and the root keys are related.
After a brief discussion of the fault-tolerant capabilities of the Registry database, the chapter continues with a look at the two Registry Editor utilities included with Windows NT and a discussion of which utility to use to get the job done right. You learned about using the Registry Editor for browsing the Registry database, as well as creating, deleting, and modifying Registry value entries through a hands-on example. You also learned how to use the find capabilities of the Registry Editor for locating subkeys.
Then you learned about setting security permissions and auditing on Registry subkeys. The chapter concludes with a brief look at using the Registry Editor to view and edit the Registry on a remote computer running Windows NT.
| About us | Categories | New Releases | Most Popular | Web Tutorial | Free Download | Drivers |
|
