Managing The Windows 2000 Registry

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Windows 2000 Registry plays a key role in making Windows 2000 work. It serves as a central data repository, and it's involved in everything you do with Windows 2000 computers, from the initial boot sequence to logging in and running applications and services. For such an important component, though, there is surprisingly little documentation that explains how the Registry works, what's in it, and what it's good for. Even seasoned Windows NT administrators who are making the leap to Windows 2000 admit to being a little unsure of the Registry's inner workings.

Part of the Registry's mystery comes from the fact that its data is stored in a special format that can be read only with the tools and programming interfaces routines Microsoft provides; part comes from the strict warnings against Registry tampering plastered on page after page of Microsoft (and third-party) documentation, books, and web pages. However, since the Registry's an integral part of Windows 2000, you should be comfortable using, repairing, and modifying it if you want to administer Windows 2000 systems. The overall goal of this book is to demystify the Registry's workings and help you understand when, how, and why Windows 2000 services, applications, and operating-system components use it so you'll be better able to administer the machines under your care.

Before I plunge into the nuts and bolts of working with the Registry, let me set the stage by explaining how the Registry gained its starring role in Windows 2000. Besides being good preparation for amazing your friends with computer-industry trivia, the Registry's path to fame illustrates some of its strengths and weaknesses.

In the beginning, of course, there was no Registry. MS-DOS applications were responsible for storing their own persistent settings in configuration files. The operating system had its own set of configuration files; the most famous of these files are config.sys andautoexec.bat, which control hardware and operating system settings.

At first blush, this approach may seem reasonable. After all, applications' settings are generally private, and they don't usually affect other programs. Most components of MS-DOS itself weren't configurable anyway, so there was little need (or demand) for a better configuration mechanism. If the configuration data for a single application was lost or corrupted, restoring it was reasonably simple and could be done without affecting anything else on the computer.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before I plunge into the nuts and bolts of working with the Registry, let me set the stage by explaining how the Registry gained its starring role in Windows 2000. Besides being good preparation for amazing your friends with computer-industry trivia, the Registry's path to fame illustrates some of its strengths and weaknesses.

In the beginning, of course, there was no Registry. MS-DOS applications were responsible for storing their own persistent settings in configuration files. The operating system had its own set of configuration files; the most famous of these files are config.sys andautoexec.bat, which control hardware and operating system settings.

At first blush, this approach may seem reasonable. After all, applications' settings are generally private, and they don't usually affect other programs. Most components of MS-DOS itself weren't configurable anyway, so there was little need (or demand) for a better configuration mechanism. If the configuration data for a single application was lost or corrupted, restoring it was reasonably simple and could be done without affecting anything else on the computer.

Windows 3.0 improved on the MS-DOS approach by introducing the idea of a single, systemwide set of operating-system preference and settings data. In addition to DOS' configuration files, Windows 3.0 itself added four initialization files ( progman.ini, control.ini, win.ini, and system.ini ) that contained information about the system's hardware configuration, device drivers, and application settings. These files quickly became known as INI files, after their extension.

Microsoft chose a simple, human-readable ASCII format for INI files; not only did this ease the task of writing programs to use these files, but it also made it possible for end users to inspect and change their contents. One of the important features Microsoft wanted to deliver in Windows 3.0 was Macintosh-like customization; users wanted to be able to set their own color schemes, fonts, desktop backgrounds, and so on. By default, the Windows File Manager included a file mapping so that double-clicking an INI file would open it in the Notepad text editor, as shown in .

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The concept of a central repository that holds all the system's configuration data may strike you as a boon (since it keeps applications and services from scattering their settings in hundreds of small files buried in odd locations) or a danger (since it provides a single point of failure). The truth is somewhere in between these extremes. The Registry provides a neat, tidy way for applications, device drivers, and kernel services to record configuration data. That data can be used by, and easily shared between, the original owner or by other system components. At the same time, if the Registry is damaged, the effects can range from not being able to use a single application to not being able to boot Windows 2000 at all. (, details the backup and recovery tools you can use to keep this single point of failure from causing trouble.)

The chief role of the Registry in Windows 2000 is as a repository for configuration data. In this role, it acts as a sort of super-librarian; system components can look for their own configuration information in the Registry, then use what they find to control how they interact with other system components. The "important stuff" stored in the Registry falls into six separate categories; each category's data is gathered during a particular stage of the boot process, as shown in .

Figure 1.4: Registry data exchange

Section 1.2.1.1: Hardware configuration data

As part of the Windows 2000 boot loader's normal execution, it runs a program called ntdetect; as its name implies, ntdetect figures out what hardware exists on the computer. This configuration data is basically an inventory of five things:

The number, kind, and type of system processors
The amount of system physical RAM

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Registry offers a number of significant benefits to programmers, users, and administrators. These benefits stem from the characteristics just described.

Instead of the dozens (or even hundreds) of separate INI files typically found on a Windows 3.1 machine, Windows NT/2000 machines usually only have a few, and those typically belong to 16-bit legacy applications that can't use the Registry. Windows 2000 itself uses the Registry for its configuration data, as do almost all 32-bit applications written for Windows 9x and NT/2000. There's more to tidiness than just the reduction in clutter that comes from eliminating INI files, though. Centralizing where configuration information is stored makes it easier for administrators to back up, restore, and secure the data.

Access control for the Registry comes in two sizes. First, you can set individual workstations or servers to disallow any remote Registry connections. While this is secure, it also makes it impossible to use the System Policy Editor to set and inspect policies on that machine. A better and more fine-grained solution is to use the built-in ACL features. As I mentioned earlier, each Registry key, from the root keys on down, can have its own set of access permissions in the form of ACLs that apply to the keys.

Each access control entry (ACE) in an ACL actually has two parts: a permission (as shown in ) and the account or group name that holds the permission. You'll learn more about these permissions in . ACL permissions are usually written like this, with the holder first and the permission following:

Everyone:Read
paul:Full Control
Engineering:Full Control

Table 1.1: Registry Access Permissions
Permission

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even if you're accustomed to using Windows, the Registry may sometimes seem like a New Orleans graveyard at midnight, full of strange shadows, half-glimpsed terrors, and legendary tales of misfortune. In this vein, I want to digress a little to talk about the philosophy behind the Registry, as well as the Zen of editing and using it.

First of all comes the obligatory scare tactic. Microsoft's documentation contains many warnings about the dire consequences that can result from editing the Registry if you aren't careful and knowledgeable. Instead of repeating these warnings, I'll offer one of my own, but just once, so you won't have to keep seeing it over and over.

The Registry is a key component of Windows 2000. If you remove a necessary key or change a key's value to an out-of-range value, some programs repair the damage automatically, but others fail spectacularly. Microsoft's Registry editors immediately make changes, so there's no backing out if you make a mistake. Please don't edit the Registry on your production machines until you've read , which explains how to recover from a damaged Registry.

You can think of the Registry like one of those self-service storage warehouses that have popped up across North America like sheet-metal mushrooms. If you've never seen one, let me briefly digress: these warehouses, which usually have catchy names such as "Public Storage" or "U-Store-It," are fenced compounds filled with long, low metal buildings. These buildings are segmented into individual garages. When you rent a space, you get the magic code that opens the outer gate, and you use your own lock to secure the unit you've rented. Once you've rented it, the space is yours to use as you wish (though you're not supposed to live in them or keep anything illegal or dangerous there).

Just like the local U-Store-It, every tenant of the Registry has its own individual space, where it can store anything under the sun. Access to that space is controlled both by the operating system and the tenant who created the keys. Also like the real-world equivalent, the landlord takes no responsibility for protecting what's in individual spaces; that's up to the renter (or application). That's where the analogy stops, though. In Windows 2000, Registry keys fall into three groups:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

, was just that: it was an introduction, and it was gentle. Now it's time to get down to business and focus on how the Registry actually works. In this chapter, you'll learn how the Registry is organized, both logically and physically, and how data gets into and out of it.

Since the Registry is such an important part of Windows 2000, understanding how it's put together is crucial to learning how to use, modify, and protect its data. Let's start by examining the basic structures and concepts that underlie the Registry. Once you understand how these pieces fit together, we can move on to the data that actually lives in the Registry.

You may find it helpful to think of the Registry as a filesystem; their organizations are similar in many respects. Both have a well-defined hierarchical structure, and they both support the concept of nesting items within other items. Files are identified by names and paths. Likewise, every key in the Registry is identified by a full path that identifies exactly where to find it. Since the Registry can be shared and accessed over a network, this full path can optionally include a computer name, which works as it would for a file share. The data within a file can be interpreted by applications that understand that file type. So it is with Registry keys, whose values can be understood and used by applications, kernel services, and other Registry clients.

Section 2.1.1.1: Root keys

Root keys are like disk volumes: they sit at the root of a hierarchy and aren't contained or "owned" by any other item in the hierarchy. Windows Explorer groups all local disks together under "My Computer," and the Win95 RegEdit app does the same for Registry keys, but these groupings are fake, since the disks and root keys are actually logically separate entities. The groupings just provide a convenience for users. The six root keys that make up the Registry (see later in this chapter) are logically independent of one another; to reinforce this idea, the Windows 2000-specific Registry editor,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Since the Registry is such an important part of Windows 2000, understanding how it's put together is crucial to learning how to use, modify, and protect its data. Let's start by examining the basic structures and concepts that underlie the Registry. Once you understand how these pieces fit together, we can move on to the data that actually lives in the Registry.

You may find it helpful to think of the Registry as a filesystem; their organizations are similar in many respects. Both have a well-defined hierarchical structure, and they both support the concept of nesting items within other items. Files are identified by names and paths. Likewise, every key in the Registry is identified by a full path that identifies exactly where to find it. Since the Registry can be shared and accessed over a network, this full path can optionally include a computer name, which works as it would for a file share. The data within a file can be interpreted by applications that understand that file type. So it is with Registry keys, whose values can be understood and used by applications, kernel services, and other Registry clients.

Section 2.1.1.1: Root keys

Root keys are like disk volumes: they sit at the root of a hierarchy and aren't contained or "owned" by any other item in the hierarchy. Windows Explorer groups all local disks together under "My Computer," and the Win95 RegEdit app does the same for Registry keys, but these groupings are fake, since the disks and root keys are actually logically separate entities. The groupings just provide a convenience for users. The six root keys that make up the Registry (see later in this chapter) are logically independent of one another; to reinforce this idea, the Windows 2000-specific Registry editor, RegEdt32, shows each root key in an individual window.

In Windows 2000 and Windows NT 4.0, there are six root keys:

HKEY_CURRENT_USER

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

No two snowflakes are alike. It's not quite true to say that no two Registries are alike, but they can vary significantly from machine to machine. There's a standard set of keys Windows 2000 uses, but even this standard set varies somewhat, depending on whether the computer's running Windows 2000 Professional or a member of the Windows 2000 Server family, what optional components are installed, and how the machine's network connection is configured.

The Registry help files included with the Windows 2000 Resource Kit (as well as the material in ) explain what individual keys are for, but using that data to grasp what's important is like trying to build a watch out of a bag full of parts; it's much more instructive to examine a working watch and see how its parts relate. To provide a working watch for your entertainment, this section examines the most important subkeys of the root keys described earlier in this chapter.

HKLM 's purpose is to store all the important configuration data for the local machine. It doesn't contain any information about other machines on the network or about user-specific configuration data; instead, it's nothing but settings for the machine where it's stored. HKLM has four important subkeys.

Section 2.2.1.1: HARDWARE

All the keys and subkeys of HKLM\HARDWARE are generated by Windows 2000 at boot time and exist only in memory; they aren't stored on disk. This may seem odd, but when you consider the Windows 2000 boot process, it makes more sense. The boot loader (NTLDR.COM ) is loaded by the standard DOS boot mechanism. When it executes, it loads and starts the Windows 2000 kernel. The kernel in turn must first start up the hardware abstraction layer; the HAL provides a buffer between the gory details of hardware resources and the neatly structured system of device drivers the operating system uses to talk to hardware. For this approach to work, the HAL must register the hardware it finds, but at the time it finds those devices, it may not have found any disks to register the data on! Keeping the hardware keys in memory nicely solves this problem.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are several ways to move data into and out of the Registry; which one you use depends on what you're trying to accomplish and the amount of time you're willing to spend. Each of them is covered in more detail in later chapters.

First of all, you can make direct calls to the Win32 Registry API routines. At bottom, this is what all the other methods eventually do; the OS' security components and the undocumented internal format of the hive files ensure that the only way to load data is to use these routines. The basic process is fairly simple: you start by opening a key or subkey by its name. Once you've done so, you can do things to that key or its subkeys: you can query its value, create new subkeys beneath it, or even ask about its security settings. You can continue to use that particular key until you're done it, at which time you must close it again. Here's a small sample that shows these steps in action; it gets the computer's network name and uses it to print a welcome message. You'll learn more about programming for the Registry in C (as in this example) in the section titled in .

// Hello, World! for the Registry: gets this machine's name and prints
// it out.
#include <windows.h>
#include <winreg.h>
#include <stdio.h>

void main(void)
{
   unsigned char 	lpName[MAX_PATH] = "";
   DWORD	 nNameLen = MAX_PATH;
   HKEY 	hkResult, hStartKey = HKEY_LOCAL_MACHINE;
   LONG 	nResult = ERROR_SUCCESS;
	
    nResult = RegOpenKeyEx(hStartKey, 
	        "SYSTEM\\CurrentControlSet\\Control\\ComputerName", 
	         0L, KEY_READ, &hkResult);
    if (ERROR_SUCCESS == nResult)
    {
           nResult = RegQueryValueEx(hkResult, "ActiveComputerName", 0, 0,
                                       lpName, &nNameLen);
           if (ERROR_SUCCESS == nResult)
                printf("Hello, world, from %s!", lpName);
   }
   RegCloseKey(hkResult);
}

The next step up the evolutionary ladder of Registry access is to use a library or language that removes you from direct contact with the Registry API routines. Depending on your needs and inclinations, there are several ways to accomplish this:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By now, you've probably gotten the impression that working with the Registry is serious business. How serious it can be may not become apparent until the first time one of your Windows 2000 machines stops working because of a problem with the Registry. This stoppage may be slight--say, Office 2000 stops working--or it may be profound, resulting in the Blue Screen of Death or a lockup before the logon dialog appears.

Either way, this chapter will teach you two things: how to prepare for that eventuality, and how to recover from it smoothly when it does happen. If you're wondering why this chapter is here instead of further back in the book, the reason is simple. It's a very good idea for you to know how to restore your Registry before you learn how to edit it.

Scaring people is often a good way to get their attention. For example, you may have had to suffer through intentionally vivid films of auto accidents in drivers' education class; the rationale behind this kind of shock treatment is to blast the viewer out of his comfortable "it won't happen to me" mindset. This tactic is often effective, but, when exaggerated, it can backfire.

Instead, ask yourself a question. "Self, what would happen if my Windows 2000 machines were abducted by aliens?" Just think: all your hardware, and the data it contains, gone in a heartbeat. Sure, it's easy to disregard the risk of hardware failure, fire, theft, or Registry corruption--that won't happen to you--but aliens? Look what happened to Elvis.

Instead of panicking and running out into the streets like people do in alien-invasion movies, wouldn't it be nice if you could lean back in your chair and smile, knowing that your Registry data could easily be restored without breaking a sweat? There's nothing like that state of calmness that comes from having a known good backup of your critical data, and that's why I encourage you to read, and heed, the material in the rest of the chapter. Don't panic, but don't fall asleep, either.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Scaring people is often a good way to get their attention. For example, you may have had to suffer through intentionally vivid films of auto accidents in drivers' education class; the rationale behind this kind of shock treatment is to blast the viewer out of his comfortable "it won't happen to me" mindset. This tactic is often effective, but, when exaggerated, it can backfire.

Instead, ask yourself a question. "Self, what would happen if my Windows 2000 machines were abducted by aliens?" Just think: all your hardware, and the data it contains, gone in a heartbeat. Sure, it's easy to disregard the risk of hardware failure, fire, theft, or Registry corruption--that won't happen to you--but aliens? Look what happened to Elvis.

Instead of panicking and running out into the streets like people do in alien-invasion movies, wouldn't it be nice if you could lean back in your chair and smile, knowing that your Registry data could easily be restored without breaking a sweat? There's nothing like that state of calmness that comes from having a known good backup of your critical data, and that's why I encourage you to read, and heed, the material in the rest of the chapter. Don't panic, but don't fall asleep, either.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first step towards effectively preparing yourself to handle Registry problems is to adopt some strategies to safeguard your data. There are a number of fascinating books about the minutiae of planning for disaster recovery, but this isn't one of them, so I'll leave it to you to find out about off-site backups, fire suppression, and the other facets of preparing to deal with catastrophic failures. If you want to read more on this subject, check out the free (and very scary) Disaster Recovery Journal (http://www.drj.com). Instead, I'll present two simple concepts that will save your bacon if you implement them. While they're targeted at helping you recover from Registry failures, you can also apply them to other situations that might render your Windows 2000 machines (or any others, really) unusable or unavailable.

The cardinal rule of data protection is don't depend on a single copy of your data! Of course, this rule is usually observed in the breach. You'd probably be surprised at the number of experienced administrators who make sure to back up data on all machines on the network, then forget to back up their own personal workstation! As you'll see in , there are several ways to duplicate the Registry's contents. Whichever you choose, though, the following four principles will make sure your backup strategy works for you, instead of leading you into a false sense of security:

Make regular backups: If you back up data only at irregular intervals, you run the risk of losing an indeterminate amount of data. Ask yourself this: if you had to reload your Registry tomorrow from the most recent backup, how recent would it be? Would it reflect all the configuration and user account changes you've made since that last backup? (Hint: as often as the Registry's contents change, the most likely answer is probably a rueful "no.")

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The very phrase "emergency repair disk" sounds ominous, like something the crew aboard the ill-fated Mir space station might keep close at hand. In fact, the ERD (as it's usually called) is a terrific insurance policy that can protect you from a number of potential Registry mishaps, up to and including losing the password to your Administrator account. However, ERDs won't do you any good unless you keep them up to date; you must also be careful to keep close physical control over them, since they contain a good bit of sensitive data that could potentially make it easier to compromise a machine.

Remember, ERDs can be used only to repair the Registry under Windows NT, not Windows 2000. If you've migrated to Windows 2000, you can (and should) still make ERDs using Windows 2000 Backup, but you don't use them to repair the Registry.

An ERD is nothing more than a FAT-formatted floppy containing a subset of data needed to recover some of the system's configuration. A Windows NT ERD includes data from several Registry hives; when you create an ERD, you're actually making a backup copy of the Registry's most essential data in a form that Windows NT can directly use to replace damaged or missing keys. Windows 2000 ERDs don't include this Registry data, but you get the same functionality by backing up Windows 2000 Registry data using the Windows 2000 Backup application and storing it on a floppy or other backup media.

Both the Windows 2000 and NT ERDs keep copies of additional useful data:

The configuration files used to run DOS and Win16 programs (autoexec.nt and config.nt).
A copy of the current setup log file, setup.log. This file tracks the list of files installed during Windows 2000's setup phase, including a checksum; this log file enables setup, repair, service pack, and hotfix installers to know whether they're replacing the right files or not.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You probably remember from of , that each hive of the Registry is stored in a separate file. While it might seem reasonable to assume that you can just back up these files as though they were Word documents or some other innocuous file, the harsh reality is that you can't. The NT kernel always keeps the Registry data files open, so ordinary backup software won't be able to back them up. However, there are ways to successfully duplicate the files for safekeeping; we explore three ways in the remainder of this section.

In you learned that the Registry's made up of several hives, which are actually files that live on your disk. They're normally stored in the System32\Config subdirectory of your system volume; you can always find the correct location by examining the value of HKLM\SYSTEM\Control\CurrentControlSet\hivelist.

If you change to System32\Config (or wherever your files are) and get a directory listing, you'll see five files whose names match the hives listed in : DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM. (The other hives, SID and HARDWARE, aren't stored here.) The hive files themselves don't have extensions on them, but there are other files with the same names that do have extensions. Files whose names end in .LOG contain log and auditing information for the corresponding hive, while files with the .SAV extension keep backup copies of Registry transactions so a hive can be automatically restored if the system crashes. Finally, there's one file with its own unique extension: SYSTEM.ALT contains a transaction log of the SYSTEM hive. If the computer crashes, the boot loader can automatically replace the SYSTEM hive with SYSTEM.ALT if the latter has more current data.

You can back up any or all of them; however, as long as you're going to the trouble of backing them up at all you should back them all up. Special note to the curious: you can't rename, move, or delete these files while the operating system is running, since the kernel owns them and is holding them open for exclusive access; other applications that try to modify the files cause a sharing violation when they try.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that you know how to back up your Registry, the next logical step is to learn how to restore it. You need to be comfortable enough doing this that the prospect doesn't scare you; no one looks forward to repairing a damaged Registry, but it shouldn't be frightening either. Practice until you're comfortable with the approaches described in the rest of the section.

Restoring the Registry from a manual backup isn't useful in all circumstances, since to restore the hive files you must be able to boot your machine and gain access to Windows 2000's boot partition, as described earlier in the chapter. Once you've booted your machine into DOS, Linux, or some other OS that gives you access to the partition where your hive files are stored, all you need to do is copy the backup copies over to the original hive directory. (Of course, you have to uncompress them first if they're compressed!) Reboot into Windows 2000, and you're done.

While this approach is appealingly simple, it has its disadvantages. Apart from requiring that you be able to boot into another OS, it has the drawback of being indiscriminate. When you restore a hive, you'll be restoring everything in the hive. This can have the unwanted consequence of removing changes you wanted to keep while fixing whatever problem originally required you to use a backup.

Restoring a Registry backup with Windows 2000's backup utility is fairly painless. It's not smart enough to check whether you're restoring to the same machine you backed up from, so you must be careful to avoid installing the wrong Registry (including the SAM database and HKLM\SECURITY subtree) on the wrong machine.

Earlier in the chapter, you saw , which shows NTBACKUP 's user interface. To make a backup, you had to select a drive (and its subfolders and files) to back up. Guess what? To restore from a backup, you do the opposite and select a tape to use for the restoration. Here's how the process works:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the first three chapters, you learned what the Registry is, how it functions, and how to safeguard it against accidental damage or loss. Now that you've absorbed this basic knowledge, the real fun starts: now you learn how to modify the Registry's contents. In later chapters, you'll learn how to use the powerful RegEdt32 application, as well as how to write your own programs that find, store, and modify Registry data. As a departure point, though, let's start with RegEdit, a simple, easy-to-use tool that will help you get familiar with the mechanics of navigating and editing the Registry.

The RegEdit included with Windows 2000 is a direct descendant of the first version, which shipped with Windows 3.1. That first RegEdit couldn't do much because there was so little in the Registry. In the intervening years, Microsoft has added a great deal of data to the Registry, but RegEdit itself hasn't progressed too much beyond its original capabilities. Sure, it uses the Win32 common controls, so it looks like a modern application, and it's been rewritten as a 32-bit application for Win9x and NT/2000--but overall, it's still the flat-blade screwdriver of Registry editing tools: ubiquitous but of limited capability.

Let me start by pointing out the useful and desirable things RegEdit doesn't do:

It has no undo or journaling capability, so there's no easy way to back out of an unwanted change or keep an auditable record of changes made.
It is completely innocent of any understanding of Windows 2000's security features, so you can't view or change permissions or ownership settings for keys.
You can only create and edit binary, string, and DWORD values. When you view other data types, they're displayed as binary data.

While this list may seem like a harsh assessment, remember how valuable a flat-blade screwdriver can be. It can be a punch, a prybar, a chisel, a spacer, a mallet (albeit a small one), plus it can drive screws. Likewise,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The RegEdit included with Windows 2000 is a direct descendant of the first version, which shipped with Windows 3.1. That first RegEdit couldn't do much because there was so little in the Registry. In the intervening years, Microsoft has added a great deal of data to the Registry, but RegEdit itself hasn't progressed too much beyond its original capabilities. Sure, it uses the Win32 common controls, so it looks like a modern application, and it's been rewritten as a 32-bit application for Win9x and NT/2000--but overall, it's still the flat-blade screwdriver of Registry editing tools: ubiquitous but of limited capability.

Let me start by pointing out the useful and desirable things RegEdit doesn't do:

It has no undo or journaling capability, so there's no easy way to back out of an unwanted change or keep an auditable record of changes made.
It is completely innocent of any understanding of Windows 2000's security features, so you can't view or change permissions or ownership settings for keys.
You can only create and edit binary, string, and DWORD values. When you view other data types, they're displayed as binary data.

While this list may seem like a harsh assessment, remember how valuable a flat-blade screwdriver can be. It can be a punch, a prybar, a chisel, a spacer, a mallet (albeit a small one), plus it can drive screws. Likewise, RegEdit can do some very valuable things: it allows you to search the Registry for a value or key, and these searches can be local or remote. It provides a nicely unified display of all the root keys, allowing you to quickly browse and compare values in different roots. Finally, its limited functionality makes it easy to understand and use.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I have a weakness for power tools--the more powerful, the better! One thing I've learned is that it's a good idea to spend some time getting accustomed to a new tool before starting a real project with it. This break-in period helps me get familiar with how the tool works, teaches me how it feels as I use it to saw, drill, or whatever, and gives me some confidence that I won't screw up whatever I'm working on.

In the same vein, allow me to present the user interface for RegEdit. As you read through this section and its successors, you'll gain an understanding of how RegEdit looks, feels, and works, but the best way to cement that knowledge is to launch it and experiment: practice moving around, searching for things, and exploring the Registry. Even after you've mastered the skills needed to administer the Registry, you'll still find RegEdit's search abilities to be quite useful in your everyday administration.

If you've ever used Windows Explorer (or even the old-style Windows File Manager), you'll feel instantly comfortable with RegEdit 's interface (shown in ). The application's window is divided vertically. The left pane (which I'll call the key pane from now on) shows a tree representing the Registry's hierarchy, while the right side (the value pane) shows the values associated with whatever key is selected in the key pane. You can adjust the relative widths of the two panes by dragging the gray bar that divides them.

Figure 4.1: RegEdit's interface

The value pane is further subdivided into two columns. The first, known as the name column, shows the value's name, while the second (the data column) shows the value's actual contents. You can change the width of these columns by clicking and dragging the divider bar in the header at the top of the value pane.

By default, RegEdit 's main window includes a status bar across its bottom margin; when the status bar is visible, the full path of the currently selected key appears there. This provides a quick reference if you need to make a note of a particular key.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first thing you should learn to do with RegEdit is to browse around the Registry and see what's there. The Explorer-style interface makes the Registry's data very "discoverable"; that's a fancy way of saying you can start off with a high-level view, then see as much or as little detail as you like as you become more comfortable with the Registry's structure.

RegEdit follows the standard Windows conventions for keyboard navigation--not surprising when you consider that the key pane itself is built with the standard tree-list control. When an item is selected, it is highlighted using the standard system highlight color, and you can maneuver about by using the keys shown in .

Table 4.1: Navigational Keys for RegEdit
Key	When Used in...	Action
Tab	Key or value panes	Switches focus between the key and value panes
Return	Value pane	Opens selected item for editing
Up/down arrows	Key or value panes	Moves focus to the next or previous item in the current pane
Left/right arrows	Key pane	If selected item has subkeys, expands (left arrow) or collapses (right arrow) it; if not, moves to next or previous item

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RegEdit allows you to connect to the Registry of any Windows NT or 2000 machine on your network. Of course, there are two caveats: you must have permission to do so, and the remote machine must be configured to allow remote Registry access. In particular, Windows 2000 machines must have the Remote Registry Access service installed and running (the same is true for Windows 9x machines, by the way).

From within RegEdit, you connect to other machines with the Registry→ Connect Network Registry...command. You then see a small dialog box that prompts you for a computer name to attach to. This dialog box also contains a Browse button; clicking it displays a network browser window (similar to the one in Windows Explorer) that allows you to poke around your LAN to find the machine you want to connect to. Once you've identified the machine you want to reach, RegEdit opens its Registry and displays its root keys in the key pane. Your local machine's root keys are under the My Computer icon; other machines' keys appear under folder icons with their names, as shown in .

Figure 4.2: Remote Registries and local Registries

While you're connected to a remote computer's Registry, you can browse keys subject to whatever permission the remote Registry's owner has imposed. Depending on those same permissions, you may be able to modify, create, or remove keys; before doing so, of course, you should make sure that you have both a good backup of the target machine and permission from its owner.

Because RegEdit doesn't dynamically update the Registry, you'll quickly become practiced at the skill of using the View→Refreshcommand (or the F5 key, its accelerator) to force RegEdit to update the portion of the Registry you're viewing.

RegEdit often fails to allow access to the various root keys of remote Registries even when they are displayed (whereas

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of RegEdit 's best features is its ability to search the Registry for a particular key or value. For example, let's say that you want to find where the Dial-Up Networking (DUN) service stores its list of phonebook entries. You could go to Microsoft's Knowledge Base and look it up, but the fastest way to find your answer is to use RegEdit 's search function to look for entries whose contents match the name of one of your phonebook entries.

There are a few things you need to know about how searches work. Searches are case-insensitive, so you don't have to pay attention to proper capitalization. By default, searches are substring searches, not literal searches. Searching always starts with the "first" root key, which in RegEdit 's case means that all searches have to plow through HKCR first. Finally, the search process accepts only ASCII text and looks only in string values. That makes it impossible to find all the values whose DWORD value is 0x220 or to find data stored in values of type REG_BINARY.

You activate the Find command with the Edit→Find menu command. You then see the dialog box shown in .

Figure 4.3: RegEdit's Find dialog

Finding values is pretty straightforward: if you want to search the entire Registry, just type your search string into the "Find what" field and click the Find Next button. Of course, you can be more selective by using the four checkboxes in the Find dialog:

The "Look at Keys" checkbox (on by default) tells RegEdit to look for the specified string in the names of keys. Searching for "software" would thus find HKLM\SOFTWARE, HKCU\Software, HKU\.DEFAULT\Software, and perhaps other keys whose names contain "software" in some form or other.
The "Look at Values" checkbox (on by default) instructs RegEdit to search for your string in the names of values, too; searching for "User" with this checkbox set might find HKCR\DAO.User, HKLM\Software\SMIME\Users, and HKCU.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you want to print all or part of the Registry, you're in luck: RegEdit can produce a printout that contains the full path, subkeys, and values of the key you select. The Registry→Print... command allows you to print the entire Registry or any subset of it, using the dialog box shown in .

Figure 4.4: RegEdit's Print dialog box

The "Print range" group gives you a convenient way to filter the keys you print. Selecting the All radio button will (as you'd expect) print the entire Registry. I don't recommend doing this unless you have a very fast printer with a very large paper tray. The "Selected branch" button is a better alternative; with it, you can choose a single subkey to be printed.

RegEdit's printed output is pretty rudimentary. It doesn't have any way to print page headers or footers, and its output isn't indented or otherwise formatted to make it more readable. For quick reference, you may find it more useful to export a portion of the Registry (as described in later in this chapter), then print it using your favorite text editor.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By now, you probably have a good feel for the Registry's structure. Once you're comfortable navigating the Registry with RegEdit, it's time to move on to the mechanics of working with keys and values in the Registry. RegEdit has a complete suite of commands for creating, modifying, deleting, and renaming keys and values. However, it doesn't have a safety net, so be sure to limit your initial experimentation with editing to changes you can back out if necessary--and don't forget the backup strategies you learned in .

Even though it was mentioned before, it bears repeating: there's no convenient way to undo changes you make when editing the Registry with RegEdit. Make sure you've developed and are executing a Registry backup strategy. If you're not, please go back and read before you start editing anything.

Now is also a good time to mention a few things that RegEdit can't do. Chief among them is the fact that it can't directly edit or create values that aren't of one of the three types it supports: DWORD, binary, and string. You can edit values of these other types, but you have to do so by viewing and editing the hex bytes that make up the binary version of the data--not a task to undertake lightly! This limitation makes it harder to edit REG_MULTI_SZ or REG_EXPAND_SZ values, which are fairly common; it's also a problem if you try to modify the more obscure data types discussed in in . As a practical matter, this isn't a huge hindrance, since most Registry values use one of the three types RegEdit supports.

In Knowledge Base article Q155267, Microsoft warns against using RegEdit to edit Registry data on a Windows NT machine. That's because RegEdit wasn't designed for, and doesn't understand, some of the data types supported by Windows NT and 2000. You'll be OK if you stick to editing DWORD and REG_SZ values.

RegEdit would have been a much better application if it had full Clipboard support, allowing you to cut, copy, and paste keys and subkeys, especially when you're viewing more than one machine's Registry from a single instance of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of RegEdit 's unique features is its ability to store Registry data in a human-readable format, then import data in that same format to repair or recreate existing data, or even create new keys and values. Better still, you can create your own files, so you can automate Registry changes needed for your particular network or computing environment. You can also store multiple sets of Registry data and switch between them as needed. This is often useful for system administrators who need to develop their own management tools.

The .REG file format is simple to understand. Fortunately, that makes it simple for programs to parse, too; in , you'll see some Perl scripts that manipulate .REG files. In the meantime, let's examine the format that RegEdit uses so you'll be able to make sense of it when you see it.

Here's a snippet gleaned from my desktop machine's Registry:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser]
"Type"=dword:00000020
"Start"=dword:00000002
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,79,73, \
	74,65,6d,33,32,5c,73,65,72,76,69,63,65,73,2e,65,78,65,00
"DisplayName"="Computer Browser"
"DependOnService"=hex(7):4c,61,6e,6d,61,6e,57,6f,72,6b,73,74,61,74,69, \
	6f,6e,00,4c,61,6e,6d,61,6e,53,65,72,76,65,72,00,4c,6d,48,6f,73,74, \
	73,00,00
"DependOnGroup"=hex(7):00
"ObjectName"="LocalSystem"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Linkage]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Linkage\Disabled]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters]
"MaintainServerList"="Auto"
"IsDomainMaster"="FALSE"

The first line in the file identifies the file as a .REG file. If this string's present, RegEdit attempts to interpret the rest of the file as a set of keys and values; if it's not present, RegEdit complains that the file you're importing isn't really a .REG file.

The next interesting line identifies the full path to a key. In this case, the key is HKLM\SYSTEM\CurrentControlSet\Services\Browser. There are two noteworthy things about this key path. It's enclosed in square brackets (which

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even though I've been talking about using RegEdit as a standard Windows application, it also supports several command-line options that let you to import and export Registry data from scripts, batch files, or the command line. Both switches run RegEdit as a background process. The export process is quiet; the import process displays a completion dialog, just as it does when you use the Registry→Import Registry File...command.

You tell RegEdit to export data with the /e command-line switch. The command looks like this:

regedit  /e targetFile  [registryPath]

targetFile: This specifies where RegEdit should write its data. You can specify any path, filename, and extension so long as it's not a UNC path.
registryPath: This optional parameter tells RegEdit what to export. If you omit it, the entire Registry is exported. If you specify a key, that key and all its subkeys are exported. The path must be a complete path, including a root key, and you must spell out the name of the root key.

If you want to dump the contents of HKLM\Software\metrowerks to a file named warrior.reg, you can do it like this:

regedit /e c:\dist\hklm\warrior.reg HKEY_LOCAL_MACHINE\SOFTWARE\metrowerks

The simplest way to import data using RegEdit is to specify the name of the file you want imported on the command line, like this:

regedit warrior.reg

RegEdit happily imports the file's entire contents and presents a confirmation dialog when done. Alternatively, you can force RegEdit to replace the entire contents of the Registry

Table of Contents

Section 1.2.1.1: Hardware configuration data

Section 2.1.1.1: Root keys

Section 2.1.1.1: Root keys

Section 2.2.1.1: HARDWARE