When Win2K boots, you have the option of pressing F8 to enter the safe mode menu. From here you can choose the "Last Known Good" configuration, just as in NT 4.0. This option gives you the opportunity to back out any configuration changes you might have made to your system that rendered it unbootable or unusable. Note, however, that this only includes changes made to Registry keys under HKLM\System\CurrentControlSet. It doesn’t include changes to other Registry subtrees that may have caused problems. However, because all service and driver definitions installed on your Win2K system are kept under the System key, this is the most likely area for trouble to occur. If there are problems that prevent you from booting Win2K, you can choose the "Last Known Good" configuration. In effect, this choice loads another CurrentControlSet that was saved from the last time you successfully booted prior to your configuration change (for more information on Last Known Good, see "Backing Up and Securing the Registry and Manipulating Hives and Keys").
The System key is home to several other important pieces of your configuration: namely, the Mounted Devices, Select and Setup subkeys. With Win2K comes support for dynamically mounting and dismounting drive volumes. Information about what devices are available for mounting is kept in the Mounted Devices key. The Select key is used to tell Win2K which CurrentControlSet is the current one and which one to use if the user selects Last Known Good. The Setup key contains information about the current status of a setup or upgrade process.
A new subkey found on Win2K systems is related to the new Safe Boot options for system startup. Specifically, under System\CurrentControlSet\Control, you find a new subkey called SafeBoot. Under SafeBoot are two subkeys: Network and Minimal. When you press the F8 key during system boot and are presented with the Safe Mode menu, you see an option for booting into Safe Mode both with and without networking enabled. These two keys under the SafeBoot key define what drivers and services are loaded in each scenario. Additionally, within the SafeBoot key, you see a value called Alternate Shell, which defines what shell environment is loaded during Safe Boot mode. In the default case, it is usually cmd.exe rather than Explorer.exe.
HKEY_USERS
HKU contains just a few subkeys, depending upon how many users are logged on at the machine. The first subkey you see under HKU is the .Default key. In NT 3.5x, this key contains the default profile for a new user who does not already have a profile logging into the NT device. In NT 3.5x, user profiles are made up of Registry entries only, rather than containing Registry entries and file folders in the style of current 4.0/Win2K profiles. In Win2K, users largely ignore the .Default key. If Win2K users lack a profile upon logging in, they get the default profile located in C:\documents and settings\Default User.
Win2K services can run under the security context of either the LocalSystem account or a valid Win2K user. Valid Win2K user accounts, even those logged on as services, use the Default User profile if they do not already have one. However, the LocalSystem account does not use Default User. Instead, it uses the contents of .Default as its profile when logged on via a service. This may not seem important for most services, which don’t usually use profile information. However, you may have a service that does care about this information. In that case, making modifications to .Default affects the profile of LocalSystem. Win2K also uses the .Default key to control the look of the desktop when no one is logged into the system.
The only other thing you find in HKU is related to currently logged-on users. Namely, if a user is logged on to a Win2K workstation or server, either interactively (i.e., from the console) or as a service, the Registry part of that user’s profile is stored under HKU according to its SID. Remember that the SID is the user’s unique identifier within either the SAM or the AD. Figure 6 shows an example of HKU, including the .Default key and two users’ SIDs.
You see two SIDs because the first one (which ends in 1000 and 1000_Classes) represents a service — in this case the Clipbook Server — that is using a valid Win2K user account as its startup ID. The second SID (which ends in 500 and 500_Classes) represents the currently logged-on user at this workstation — in this case, the Administrator account.
As I mentioned earlier, the Classes associated with each SID comprise the user-specific Class registrations Win2K now keeps. Each user ID stored under HKU has its corresponding Classes key, as Figure 6 shows. Storing this information on the per-user basis is tightly integrated with the whole Win2K notion of reducing the cost of maintaining users and machines.
Note: When you install a Win2K application, any file associations and COM registrations that belong to that application get installed in the user-specific Classes key, unless the application installation specifies machine-based installation only. This lets users roam from workstation to workstation, carrying application information with them as they go.
HKEY_CURRENT_USER
HKCU is not a "real" subtree, but it represents the Registry portion of the user profile for the user who is currently logged on at the console of a Win2K server or workstation. When a user logs on, the file — ntuser.dat — is loaded into the Registry under HKU\<SID>, as discussed previously. HKCU is an alias that references the location. Changes made to HKU\<SID> are automatically reflected in HKCU because they are the same keys and values.
You may wonder why; the best answer I can find so far is that it is easier to refer to the current user’s settings as HKEY_CURRENT_USER than as HKEY_USERS\<SID>. An important aspect of HKEY_CURRENT_USER is the security associated with the keys and subkeys within this subtree. I discuss Registry security in more detail later in the chapter, but for now remember that the user or group with security access to this subtree and its associated keys and subkeys corresponds to the "Permitted to Use" right that you define for a given user profile through the System Control Panel Applet (or by right-clicking My Computer and selecting Properties from the Context Menu).
For example, let’s say that you have a profile for user Jsmith stored in the Active Directory Domain called Master1.com, and you have assigned Master1.com\Jsmith as "Permitted to Use" for a given user profile. If you examine the security on the subtree HKEY_CURRENT_User for that user profile, you see that Master1.com\Jsmith has Full Control rights to the subtree. For user profiles to be loaded and accessed by users, they must have security permissions that provide rights to HKEY_CURRENT_USER — either via their user ID or a security group to which they belong. Without these rights, users’ profiles become inaccessible, and so — in effect — do their desktops.
HKEY_CLASSES_ROOT
As mentioned above, HKEY_CLASSES_ROOT is a subtree that is an alias of another key within HKLM — specifically HKLM\Software\Classes. Specifically, HKCR is a merging of both HKLM\Software\Classes and HKCU\Software\Classes. This is new with Win2K. The idea here is that HKCR represents the classes registered for both machine and user in one subtree. The way the merging works is that HKCU\Software\Classes is first loaded into HKCR. Then, all immediate subkeys of HKLM\Software\Classes that do not duplicate previously loaded keys from HKCU are loaded. The resulting subtree is HKCR. For example, suppose HKCU contains HKCU\Software\.acf, with no subkeys, and HKLM contains HKLM\Software\Classes\.acf\PersistentHandler. In HKCR, the resulting entry would be simply HKCR\.acf, because the key in HKLM conflicts with the one already found in HKCU. Of course, because HKCR is an amalgam of machine and user keys, it has meaning only to a user or application running interactively on the machine.
Note: With Win2K, HKCR represents the classes registered for both machine and user in one subtree.
So, what is HKCR’s role? This important subkey holds your Win2K system’s Explorer shell file associations, as well as Object Linking and Embedding (OLE) and Component Object Model (COM) class registrations. OLE is actually a particular implementation of COM, so when I refer to one or the other, I speak generically of COM. When you click on a .doc file, Win2K looks in Classes to find out what application to launch for .doc files and where that application resides. If you use applications that leverage OLE/COM objects and ActiveX controls, then it is the Classes key that provides the registrations for the various components an application may call.
If you are familiar with COM concepts, you know that classes are simply pieces of functionality and data that a program can call at runtime to perform a specific task. A COM component can include one or more classes. For example, the behavior of a button on a form might be defined by a class. When that button class is invoked by an application and the user clicks the button, the functionality defined by that class is executed. Classes are identified in the Registry by Class IDs (CLSIDs). CLSIDs are easy to spot because they are stored by their Globally Unique Identifier (GUID), which is represented as a 32-character hexadecimal number.
The GUID is a 128-bit number that is said to be unique across all systems. Its uniqueness derives from the fact that the creation of a GUID generates a large random number, thereby reducing the chances of duplication to an almost infinitesimally small percentage. OLE/COM Classes and Interfaces use the GUID to uniquely identify themselves to an application. The AD also uses GUIDs to uniquely identify objects in the Directory, much the same way SIDs did in NT 4.0 (SIDs are also still in use in the Active Directory). Figure 7 shows an example of a GUID within HKCR. In this case, the GUID — 02C7E642-7E04-11D0-9D99-00A0C908DB96 — is registered as an Internet Explorer ActiveX control called the "Glow Effect." All Class GUIDs within HKCR are found in HKCR\CLSID.
HKCR is home to more than just Class GUIDs. At the top of HKCR, you find all of the file extensions that are registered on this system. For example, if you have installed Microsoft Word, you see the .doc extension registered. If you drill into this key, you find an associated Program Identifier, or ProgID. A ProgID is Win2K’s way of wrapping a familiar name around the unfamiliar COM GUID. In the case of .doc files, depending upon the version of Word you have installed, it refers to a ProgID in HKCR named Word.Document.X, where X is the version number of Word. Under the Word.Document.X key, you find references to the Class ID that Word has registered for use with .doc files. Under this ProgID key, you find directions on the location from which Word is to be launched, which is used when the user double-clicks a .doc file (Figure 8). You also find other information, such as which icon should represent .doc files in the user interface.
In HKCR, there are other important subkeys you should know. First, the AppID subkey (HKCR\AppID) houses information related to DCOM components registered on a system. DCOM is an extension of COM that lets components distributed across multiple Win2K machines communicate with one another. DCOM components use their own security model to determine under which security context the component can be instantiated and who can start or access a particular DCOM component. This information is stored in the AppID key on a per component basis. You see both GUIDs and ProgIDs kept within AppID, depending upon how they were written.
The next important subkey in HKCR is the Interface subkey (HKCR\Interface). Each registered COM component includes a number of Interfaces that define pieces of functionality within that component. Interfaces are further broken down into methods, properties, and constants. Interfaces use GUIDs to uniquely identify themselves in the Registry. One or more Interfaces, with their associated methods, properties and constants, define a COM component.
The final important subkey in HKCR holds Type Library definitions (HKCR\TypeLib). The Type Library is a programming aid to assist a COM developer in identifying which registered Interfaces are available for a given COM Component at runtime and when the object is instantiated. Type libraries are typically stored in a compiled binary file that ends with a .tlb extension.
HKEY_CURRENT_CONFIG
HKCC is the alias for the HKLM\System\CurrentControlSet\Hardware Profiles\Current key. What it represents is the set of current options chosen for a given hardware profile. Hardware profiles, a legacy of NT 4.0, give the user an opportunity to define different hardware configurations for different machine states. They are most useful with laptops, which occasionally use docking stations. In this case, you can define a hardware profile for the docked state, which might include additional hardware devices, such as CD-ROM drives and network cards. In the undocked state, these devices are not available, and you would not want to try and load their device drivers. At boot-up time, NT-based systems offer the option of choosing a different hardware profile by pressing the space key during the loading of the OS. Hardware profiles are defined by accessing the System Control Panel applet or by right-clicking My Computer and selecting the Properties tab.
Although Win2K supports Plug-n-Play, the Hardware Profiles feature may still be useful for configurations in which devices are not Plug-n-Play capable. When you define a hardware profile from the System applet, the resulting information is stored in HKLM\System\CurrentControlSet\Hardware Profiles. At boot time, when you choose an alternate hardware profile, that information is stored in the Current key, and the defined drivers are loaded. HKCC is the alias for this Current key.
REGISTRY DATA TYPES
As I mentioned previously, Registry values can be of several different data types, which define the type of data that can be stored in that Registry value. If you are familiar with programming concepts, you recognize that the Registry data type is equivalent to a declared variable type, such as character string, integer, or long. In Figure 2, you saw a value type of REG_EXPAND_SZ. The Win2K Registry supports seven different data types, which are listed in Table 1, with descriptions of the kinds of data they accommodate.
The last two value types, REG_FULL_RESOURCE_DESCRIPTOR and REG_FULL_ RESOURCE_LIST, are found only in the Hardware key of HKEY_LOCAL_MACHINE. Rarely would you ever encounter or have the need to change either of these data types in your day-to-day Win2K administration.
You may encounter other types of values. For example, you may see the value types REG_NONE and REG_UNKNOWN, which relate to data held in the SAM and Security subtrees. You may also see a value of type REG_LINK, which represents a symbolic link, rather than a real value. Such value types are normally created and accessed via Registry APIs. That is, the WIN32 APIs associated with the Registry let you create and modify values of these types, but programs like Regedt32 do not expose them when you manually create new values. It is unlikely that you would need to manipulate them, but they are there. The other five types can be manipulated with varying degrees of ease.
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
