In a file system, the root objects are disks, which contain folders and files. A single folder can contain an arbitrary number of other folders and files; each folder or file has a name. By combining the names of the folders that enclose a file, we can construct a path that unambiguously names only one file on the disk, so that C:\Windows\Mapi32.dll and C:\Winnt\Mapi32.dll are completely separate files, for example.
The Windows 2000 registry is organized much like a file system, except that the vocabulary needed to describe it is somewhat different. At the root of the registry structure are the root keys (likened to a disk in a file system). Each root key contains several subkeys (folders); in turn, these subkeys contain other subkeys and values (the registry equivalent of files). Like files, each value has a name that must be unique in the subkey or folder that encloses it; each value also has an associated data type that governs what kind of data it can hold.
Any registry value can be identified by specifying its full path, starting at the root. For example, the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Security\ObscureWireDataFormat specifies a particular value in the Security subkey that belongs to Microsoft Exchange Server. Figure 36-1 shows an annotated section of the Windows 2000 registry so that you can identify the root keys, subkeys, and values in it.
Figure 36-1. The three separate components of a registry value.
When you open the My Computer icon on your desktop, you always see certain items, such as icons that represent the logical disk volumes on your computer. The same is true of the registry. When you open it with a Registry Editor, you'll always see the same set of root keys. Each root key has a distinct purpose:
In the Windows 2000 documentation, Microsoft identifies only two registry root keys: HKLM and HKU. Since HKCU, HKCC, and HKCR are actually pointers to subkeys of HKLM and HKU, this is technically correct, but you might be confused if you're used to the idea of five separate root keys. To avoid that confusion, we'll use the old-style notation.
REAL WORLD HKCR in Windows 2000
One important registry change in Windows 2000 involves HKCR. In Windows NT 4 and earlier, the data in HKCR is the same for all users. In some ways, this was a reasonable design decision for Microsoft to make—all users on the machine have access to the same set of installed OLE components and file mappings.
However, one common complaint from administrators whose users have to share machines is that two users' preferred associations might differ. If one user chooses Netscape Navigator as the preferred Web browser, that modifies HKCR; if another user later sets Internet Explorer as the preferred browser at the same machine, that undermines the original choice. More importantly, the ability for users to change these values reduces system security in two ways: it allows users to change associations for other users (increasing the risk of introducing malicious code), and it forces administrators to remove permissions from HKLM\SOFTWARE\Classes, since all users need access to it.
In Windows 2000, Microsoft changed this behavior so that HKCR actually contains data from two sources: the user's profile (where user-specific customizations are stored) and HKLM\SOFTWARE\Classes, where systemwide settings live. Users can register and unregister COM components, change file associations, and so on without affecting other users, and you can adjust permissions on HKLM\SOFTWARE\Classes so users can't tamper with the systemwide settings you want them to have. Each user's unique settings are stored in the Usrclass.dat file, which is treated like its own registry hive. (See "Where Data Goes on Disk" later in the chapter for more details on hive files.)
Within these root keys, several subkeys are noteworthy. Because each root key has so much information under it, you'll usually hear these individual subkeys referred to—after all, HKLM\HARDWARE and HKLM\SOFTWARE don't have much in common except their root key.
The HKLM\HARDWARE subkey stores information about the hardware found in the system. All of the values stored here are held only in RAM, not on disk, because of the device driver ordering problem mentioned earlier. When the hardware recognizer starts, it enumerates every device it can find, both by walking the system buses and by searching for specific classes of devices like parallel ports or keyboards. Three major subkeys live under HKLM\HARDWARE:
Additional subkeys can exist, depending on the configuration of your machine. For example, systems that support the Advanced Configuration Power Interface (ACPI) will have an ACPI subkey that contains information about the specific ACPI subfeatures that the computer supports.
Just because Windows 2000 includes the Active Directory directory service, don't assume that no vestiges of the Security Accounts Manager (SAM) have survived. When you create local accounts or groups on a Windows 2000 machine, they are stored in HKLM\SAM, just as they are in Windows NT. However, you can't normally view or change data in this subkey, and it is mostly useful for compatibility with earlier Windows NT code that expects SAM to exist. The programming routines that access SAM data have all been revamped to use Active Directory data when it exists, or SAM when no Active Directory server is present.
HKLM\SECURITY contains a lot of security information, as you might expect. Its format isn't documented, and you can't do anything in the subkey. However, the system caches logon credentials, policy settings, and shared server secrets in this subkey. The SECURITY\SAM subkey contains a copy of most of the data from HKLM\SAM.
REAL WORLD Look, but Don't Touch!
If you're feeling adventurous and want to see what's in HKLM\SAM and HKLM\SECURITY, you can open these keys by running Regedt32 in the LocalSystem security context. The easiest way to do this is to use the At command to schedule Regedt32 to run in an interactive session. Just schedule it to run a minute or so into the future, like this:
at 12:34 /interactive regedt32.exe
That command tells the system to schedule Regedt32 to run one minute from now (this being written at 12:33); when it runs, the system scheduler service will launch the application, so it runs in the LocalSystem context instead of the context you're logged on as. While this is an interesting way to see what's in these subkeys, be forewarned of two things. First, you won't be able to make much sense out of the values in these keys, since they're intentionally obfuscated. Second, and more importantly, remember that changing any of these values will provoke unintended and probably undesirable consequences. In other words, look, but don't touch.
The HKLM\SOFTWARE subkey serves as the root location for applications and system components to store their machine-wide settings. For example, HKLM\SOFTWARE\Microsoft\EnterpriseCertificates contains keys that hold the certificate trust lists (CTLs) and trusted CA certificates for this machine—individual users' CTLs and trusted CAs are stored elsewhere. Individual programs, control panels, and the like can create their own subkeys under HKLM\SOFTWARE; the de facto standard is for each vendor to create its own top-level key (for example, HKLM\SOFTWARE\Intel) and then create subentries beneath that key.
The most interesting parts of this subkey are HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion (which stores much of the GUI preference data; it's named the same as the corresponding key under Windows 95/98) and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. This latter subkey is significantly expanded in Windows 2000; for example, there are new keys for automatic server recovery handling, the Encrypting File System, the Security Configuration Editor, Terminal Services, and other new goodies.
When you boot Windows 2000, the last action in the boot phase is to update the registry to reflect which set of controls and services was last used for a successful boot. CurrentControlSet always points to the set of controls actually in use on the system. If you look under HKLM\SYSTEM, you'll see many ControlSetXXX keys. Each ControlSetXXX subkey represents a control set that existed at one time, whether or not it was successfully used to boot. CurrentControlSet is just a pointer to the most recent successful boot set, but because it isn't easy to determine which set that was, the OS and applications use CurrentControlSet instead.
Beneath this set are four keys whose names carry over from earlier versions of Windows NT, although their guts are somewhat different in Windows 2000:
Windows 2000 dynamic disk volumes (discussed in Chapter 14) are a neat technical achievement and a boon to administrators, but they depend on having information about the current configuration of the logical volumes on disk. Applications (and snap-ins, like the Disk Management snap-in) get this information from the Logical Volume Manager service; in turn, this service stores its list of mounted and available devices in the MountedDevices subkey.
Although programs and services that use the registry don't have to understand how registry data is stored, administrators do—that way you'll know where data is stored, how the registry handles different types of data, and which files need to be safeguarded as part of your backups. You don't need to understand the internal format that the registry tools use, but you should understand the basic data types and storage locations.
Each value in the registry (Microsoft calls them value entries) has three parts: a name, a data type, and an actual value. For example, if you see a Microsoft Knowledge Base article that talks about some key—\REG_SZ:HKLM\SYSTEM\CurrentControlSet\Services\Replicator\Parameters\GuardTime, for example—you're seeing a complete definition of a value entry (although it's always nice to see a full path for values, so you know where to add or remove them).
Seven data types can be used to store data in the registry. Actually, only two of these types are used for most registry data: REG_DWORD and REG_SZ. The seven types are as follows:
In day-to-day administration, what you'll need to know about these data types is mostly restricted to understanding the difference between REG_DWORD and REG_SZ values. A REG_DWORD value whose contents are 0 (the numeric value for zero) is different from a REG_SZ whose contents are "0" (the character "0"). If you need to add a new registry value (perhaps because a Microsoft Knowledge Base article recommends doing so), you'll have to ensure that you get the type right, or you might have problems with the components that use the value.
Some registry keys and values are volatile, in the original sense of the word—they aren't persistent and can evaporate at any moment. As an example, none of the data in HKLM\HARDWARE exists anywhere on disk; that entire subkey and all its contents reside entirely in memory. Every time you boot a Windows 2000 machine, that subkey is created anew, and when you shut it down, its contents disappear.
Volatile keys are useful for data that doesn't need to stay around between reboots, but most of the data stored in the registry would be pretty useless if it weren't persistent. Imagine having to reconfigure all your preferences and settings after every reboot of your desktop machine—that would get old fast. The majority of registry keys are disk-based, meaning that their contents are held in structures on disk. When a key's contents are updated, the version on disk is updated too.
Even though disk-based keys are eventually stored on disk, Windows 2000 maps them into the paged memory pool (an area of memory whose contents can be written to the pagefile when not being used) to provide more efficient access. The registry size limit, discussed later in this chapter, regulates how much registry data can be stored in the paged pool.
Microsoft uses the term "hive" to refer to a group of keys and values that belong together. A hive can be a root key, or it can be a subkey; for example, HKCC is a hive (even though it's just a pointer to part of HKLM), and so is HKLM\SAM. The important concept to remember about hives is that a hive is a self-contained unit that can be loaded and unloaded independently of other hives.
Windows 2000 uses six hives: DEFAULT (corresponding to HKU\.DEFAULT), SAM (HKLM\SAM), SECURITY (HKLM\SECURITY), SOFTWARE (HKLM\SOFTWARE), and SYSTEM (HKLM\SYSTEM). The sixth hive, which corresponds to the contents of HKCU, is better known as a user profile—a user profile is really just a hive that is loaded into the registry when the user logs on and unloaded at logout.
Each hive exists in its own file on disk (the files have the same names as the hives), along with a separate log file that acts as a journal of all changes made to that hive. Hive files don't have extensions, and the system keeps them open all the time—that's why you have to use a special-purpose backup tool like Windows 2000 Backup or ARCServe to back them up.
So, where do these hive files live? As with so many other Windows 2000-related questions, the answer is a hearty "It depends." In this case, the answer depends on which hives you're talking about. The big five (DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM), along with their .LOG files, are stored in the System32\Config subfolder of the Windows 2000 Install folder.
The location of the user profile files (Ntuser.dat and Ntuser.dat.log for the logged-on user, Default and Default.log for the default user) depends on which operating system was on the machine before Windows 2000. Machines that were upgraded from Windows NT 4, or those on which Windows 2000 was cleanly installed, keep these profiles in the Profiles\Username subfolder of the system root folder. (Each user has his or her own subfolder.) For machines that were upgraded from Windows 95 or Windows 98, profiles are stored in a folder named for the user in the system's Documents and Settings folder.