If you've used Windows 95 or previous versions of Windows NT, you've already seen the Registry at work. When you double-click a file on your Windows 95 desktop or in Windows NT 3.5+'s File Manager to launch an application, entries in the Registry enable Windows NT Server to launch the correct application. One category of Registry entries creates associations between file extensions and the application that can display and, in most cases, edit a particular type of file. But the Registry does much more than launch the appropriate application for a particular document type.
This chapter covers the following:
The Registry keeps track of everything you can imagine it keeps track of, and much more. Most of the administrative tools you use to configure Windows NT Server and keep it running smoothly alter Registry entries. The following sections briefly describe how Windows NT uses the Registry.
The Registry is the one place that stores virtually everything that needs to be known about your hardware, operating system, and the users who may log on to the system. The Registry stores the following types of information:
Under Windows 3.x, the settings described in the preceding section were maintained in many different files. System-wide settings were kept in one of the following files:
If you're an administrator or a power user of a Windows 3.1x machine, you probably use the SysEdit application to open the first four of these files at once. SysEdit provides a convenient editing environment for text-based system configuration files.
Also, 16-bit Windows applications often have a configuration (also called an initialization) file. Most applications use APPNAME.INI for this purpose, but some applications use alternative file names and extensions. For example, REG.DAT provides OLE server information and file extension associations. You use the RegEdit application to edit REG.DAT. When you need to change or view the settings for an application, the first task is to guess what file the settings might be in and then what utility to use to edit the file.
Windows NT's Registry keeps everything in one place. You can view any and all of these settings by using one tool-the Windows NT 4.0 Registry Editor, which is derived from the Windows 95 RegEdit application. The Registry is arranged in a logical and straightforward way that clearly distinguishes among the following three classes of settings:
Although you continue to use a variety of different tools to change Registry values in Windows NT 4.0, don't underestimate the value of using just one tool to view any of the settings. It can be a bit intimidating to navigate such a large collection of settings and configuration information, but understanding the structure and content of the Registry is very important when administering Windows NT Server 4.0.
Both Windows NT 4.0 and Windows 95 use Registry files, but the internal (binary) structure of the Registry files varies between the two operating systems. The difference in file structure is the primary reason that Microsoft couldn't provide an automatic upgrade utility from Windows 95 to Windows NT 4.0 when Windows NT 4.0 was released, although upgrading from Windows 3.1+ to Windows NT 4.0 is supported. (Upgrading creates or preserves the Registry information for installed applications.) The capability to automatically upgrade from Windows 95 to Windows NT 4.0 is more important for the Workstation than the Server version, because servers seldom are required to run various desktop applications.
Changing values of entries in the Registry can cause your server to be unstartable. Rather than change Registry entry values directly, you should use one of the following tools to change these values:
9.1
Applications in the Administrative Tools program group that manipulate Registry values.
9.2
Control Panel tools that make changes to the Registry.
In many important ways, the Windows NT Registry is the same as the Windows 95 Registry. Certainly, the concepts are the same. The same tools and applications read from and write to the Registry, and the Registry Editor is similar. However, the names for specific collections of information stored within the Registry aren't identical. Nonetheless, experience with the Windows 95 Registry is readily transferable to Windows NT Server 4.0's Registry.
Understanding the Registry requires you to learn another new vocabulary. The Registry is made up of keys, some of which have subkeys. Keys have value entries, and groups of keys and their value entries are gathered into a hive.
A key is a named collection of information, just as a folder is a named collection of files. The Registry is arranged in a hierarchy quite similar to a folder tree. At the top of the hierarchy are the following five keys (also see fig. 9.3):
Each key is discussed in individual sections later in this chapter.
9.3
The five top-level Registry keys.
Just as a folder in a file system can have subfolders, a key can have subkeys; and, just as a subfolder is itself a folder, a subkey is a key, another named collection of information. Each key can have many subkeys, each of which can have many subkeys, and the hierarchy can be many levels deep.
By convention, key and subkey names are gathered into full names and separated with backslashes that appear like folder path names. An example is a key called HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\FloppyDiskPeripheral. The FloppyDiskPeripheral key is a subkey of the 0 key, which is a subkey of the DiskController key, and so on, up to the top-level key, HKEY_LOCAL_MACHINE. Key names, by the way, can contain spaces, just as spaces are permissible in Windows 95 and Windows NT 4.0's long file names (LFNs).
To continue the analogy of a file structure further, a key can contain both value entries and subkeys, just as a folder can contain both files and subfolders. Value entries in keys resemble files in folders. A value entry contains the information to examine or change, just as a file contains the data you display or edit. A key can (and often does) support more than one value entry.
A value entry has three components:
The following sections describe each of these components.
Microsoft chose names for most value entries that are reasonably comprehensible; you probably can guess what CurrentUser, InstallDate, LogFilePath, and DiskCacheSize contain without any need for documentation. Much of the information is added to the Registry when you install programs on the system, and application vendors may not choose sensible or easy-to-understand names.
When there's only one value entry in a key, it's possible-but not necessarily wise-that the programmer who added the key left the name unassigned. When omitting a single value name, the Registry Editor shows (Default) in place of the missing value entry name. This practice is quite common in the file association entries of the HKEY_CLASSES_ROOT key. Use the name of the key to understand the information in the value entry.
The data type must be one of the following five allowable data types:
The REG_EXPAND_SZ symbols correspond to environment variables-for example, %PATH% expands to the value of the PATH environment variable. Most environment variables also are stored in the Registry, but they aren't all under the same key. Some environment variables are in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment key, and others appear under HKEY_CURRENT_USER\Environment. Environment settings in AUTOEXEC.BAT aren't stored in the Registry, but some applications modify both AUTOEXEC.BAT and the Registry during installation, so many of your environment variables are accessible from the Registry.
The value of the value entry is a number or a string according to the type. Binary numbers are almost impossible to read in the Registry Editor, but specific tools, such as Windows NT Diagnostics (discussed in its own section later in this chapter), can display these value entries in a more meaningful format.
A hive is a single key with all its subkeys and value entries. Six keys, each discussed later in this chapter, are the six standard hives in the Windows NT 4.0 Registry:
A hive is a collection of keys, subkeys, and values stored in a single file. Each hive file has an associated log file that's used to ensure that the hive file isn't corrupted by a partial update.
Hive files and their associated log files are stored in the \Windows\System32\Config folder, except for user information, which is in \Windows\Profiles\username, one folder for each user. The hive and log file names are as follows:
The reason for pairing hive and log files, as mentioned earlier, is to ensure that the Registry can't be corrupted. For example, if a power failure should occur as your change to a value entry is written, the value might be changed, but the date stamp might still contain the old date and time, or the size of the entry might not be correct. The hive and log approach guarantees that these types of errors don't happen.
When it's time to write out changes to a hive file, Windows NT inserts a few extra steps. First, Windows NT writes to the log file the new data and instructions for where the data goes. After this data is safely written to the disk, Windows NT writes a special mark at the beginning of the hive file to indicate that the file is being changed. The changes are written to the hive file and, on completion, the mark is removed. If a power failure or other serious problem occurs during the process, Windows NT notices when opening the file that the "being changed" mark exists, re-creates the changes from the log file, and then removes the mark. This process maintains the consistency of the hive file.
The relationship between the hive and log files is similar to that between SQL Server's device and log files. Log files record all transactions (operations that modify database values) since the last backup. In the event of a failure that requires restoration of the backup copy, the backup copy is loaded, and then the transaction log is run against the database to add the post-backup entries. In the case of SQL Server, log files are stored on a physical device (disk drive) separated from the device containing the database(s). Windows NT hive and log files are stored on the same disk.
The SYSTEM hive is loaded so early that a simpler process is needed. SYSTEM.ALT is just a copy of the SYSTEM hive file. The changes to SYSTEM aren't logged, but the "being changed" mark is still used. After SYSTEM is written, SYSTEM.ALT is written in the same way. If a power failure occurs while writing SYSTEM, Windows NT will notice the "being changed" mark and use SYSTEM.ALT as a safe backup. Of course, the changes that were being made when the failure occurred are lost.
It's not possible to list all the keys in your Registry, because every time you install hardware or software, keys are added. It's not even possible to list all the keys in the Registry of a typical machine running Windows NT Server and no applications; publication limits on page count preclude such a listing. It's also not useful to provide a list of all Registry keys; once you know roughly where to look, it's quicker to use the Registry Editor to search for the exact key or value entry. Thus, this section doesn't attempt to describe all Registry keys, but it suggests appropriate locations to search for particular classes of Registry entries.
As mentioned earlier in this chapter, HKEY_LOCAL_MACHINE contains system-wide hardware information and configuration details. This key has five important subkeys, four of which are so important that they are located in the standard hive list you've already seen. In addition to SAM, SECURITY, SOFTWARE, and SYSTEM (the standard hive subkeys of HKEY_LOCAL_MACHINE), there's also a HARDWARE key.
SAM is an acronym for Security Account Manager. This key contains the database of user and group information, as well as security information for the domain.
SAM has one subkey, again called SAM, which contains two subkeys-Domains and RXACT. RXACT doesn't ordinarily contain anything, but Domains has two subkeys-Account and Builtin.
Don't attempt to change any value in the SAM key or its subkeys with the Registry Editor. You could leave a user's account unusable. Utilize User Manager to make the changes, as described in Chapter 12, "Managing User and Group Accounts."
See "Working with User Manager for Domains," (Ch 12)
The entire HKEY_LOCAL_MACHINE\SAM key is also accessible as HKEY_LOCAL_MACHINE\SECURITY\SAM. Changes you make in one key are immediately reflected in the other key.
This key contains policies as well as a link to the SAM database. The subkeys are Policy, RXACT, and SAM. This material is discussed in more detail in Chapter 13, "Sharing and Securing Network Resources."
See "Understanding NTFS Permissions," (Ch 13)
This key is where system-wide configuration information is stored for each software product installed on the computer. For example, if you install Visual C++ 4.0, there's a key called HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Developer\Directories with two value entries. One value entry, Install Dirs, holds the name of the directory the program was installed into. The other value entry, ProductDir, holds the name of the main directory to be used by the product.
Nothing in the Developer subkey contains any user-specific settings; user-specific entries are stored elsewhere in the Registry, under HKEY_CURRENT_USER\SOFTWARE, discussed later. For example, user-specific Developer Studio settings would be in the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Developer key.
The Registry must be updated if you move software from one location to another-for example, between fixed-disk drives in the same machine. Thus, it's usually quicker and easier to uninstall the software, and then reinstall the software in the new location. Depending on the application, many different keys may need to be modified to point to the new drive or folder. Let the uninstall and reinstall software do the work, and heed the general rule: never change the Registry by hand.
The SOFTWARE key is organized by the name of the company that makes the software. Several keys are present, even if you haven't installed any applications. They include the following:
This key contains information used during startup that can't be fully determined by Windows NT Server until startup is over. All but two of the subkeys of SYSTEM are called control sets. The Select and Setup subkeys are not control sets, but rather are used by Windows NT to choose which control set to use on startup.
A control set is all the information needed to start the system. Two to four control sets are kept in SYSTEM, with names such as ControlSet001 and ControlSet002. There's also a CurrentControlSet, which is linked to one of the other control sets. This allows you to switch back to a control set that works if you (or an application you run, or a system crash) make changes to the Registry that prevent the computer from starting.
Fortunately, during startup you have a chance to press the space bar to use the Last Known Good menu, a specific control set. The subkey that implements the Last Known Good feature, called Select, has four value entries:
You may sometimes see a Clone subkey in the SYSTEM key. This subkey is used to build that LastKnownGood value. During startup, the current control set is copied into Clone. If the startup succeeds, Clone is copied into LastKnownGood.
If your Registry is corrupted, choosing the Last Known Good menu during startup makes it possible to bring Windows NT Server up so that you can (or might be able to) correct the problem that caused the corruption. Your Registry might become corrupted for various reasons, but bad sectors on your fixed disk or (far more frequently) user errors are usually the culprits. If you edit your Registry by hand and make a serious mistake, you may leave your server unbootable. Using Last Known Good saves you from a complete reinstall.
Although every boot problem is different, here's a typical pattern:
- A power failure or hardware error requires a reboot, or you perform a routine reboot after changing Registry entries with the Registry Editor or some other tool.
- The system doesn't boot into Windows NT Server.
- You power down, and on powerup watch for the Last Known Good prompt.
- You press Space to use the Last Known Good control set.
- You examine both the current control set and the failed one to see what's different, and what changes you need to make to your current configuration (if any) that will achieve the effect you originally wanted without preventing a successful boot.
If you make changes to any of the control sets discussed in this section (other than CurrentControlSet) within the Registry Editor, you can void the insurance that these keys provide for you. Use Server Manager or Control Panel's Devices, Network, Server, or Services tool. Use the Registry Editor to look at entries, not change them.
Each control set contains two subkeys-Control and Services. The exact subkeys in each key vary, but the typical subkeys in the Control subkey are as follows:
BootVerificationProgram. Use this key to tell the system how to define "succeeded" if you don't want to use the default definition. Be sure you know what you're doing before you alter this key value. ComputerName. This subkey contains the ComputerName and ActiveComputerName subkeys. Change the values of these subkeys only with Control Panel's Network tool. ServiceGroupOrder. This lists the order in which groups of services should be started. GroupOrderList. This subkey lists the order to start services within a group. HiveList. This subkey contains the location of the hive files, usually \WINDOWS\SYSTEM32\Config. Do not change. Keyboard Layout. With its subkeys, this subkey defines the keyboard language layout. You change it with Control Panel's Regional Settings tool. Lsa. This is used by the local security authority. Do not change. NetworkProvider. This subkey defines the network provider. You change it with Control Panel's Network tool. Nls. This subkey defines national language support. Change it with Control Panel's Regional Settings tool. Print. With its subkeys Environments, Monitors, Printers, and Providers, the Print subkey defines the printers and printing environment for the system. You can change it with Print Manager. PriorityControl. This subkey defines the priority separation. Change it with Control Panel's System tool. ProductOptions. This shows the product type (for example, Winnt). Do not change. SessionManager. This subkey contains global and environment variables. Its Environment and MemoryManagement subkeys can be changed with Control Panel's System tool; do not change the others. Setup. This contains hardware choices. Change it with Windows NT Setup. TimeZoneInformation. This subkey contains time zone settings. You change it with Control Panel's Date/Time tool. Virtual device drivers. This contains information about virtual device drivers. Do not change. Windows. This subkey contains various paths needed by the system. Do not change. WOW. This contains options for running 16-bit applications. Do not change.
The Services subkey of each control set has a hundred or so subkeys, so these subkeys aren't listed here. The Services subkeys describe device drivers, file system drivers, service drivers, and other hardware drivers. Use Windows NT Diagnostics to view the information in these subkeys. Utilize User Manager or Control Panel's Devices, Network, or Services tool to change the information in these subkeys.
Finally, the Setup subkey of HKEY_LOCAL_MACHINE\SYSTEM is used by Windows NT Setup. Don't change the Setup subkey values.
All the information in the HARDWARE key is written into the Registry during startup, disappears when you shut down the machine, and then is recalculated and rewritten during the next startup. That makes it meaningless to change HARDWARE values in an attempt to solve a system problem, and that's also why the HARDWARE key isn't stored in a hive. To view HARDWARE key values in a more readable format, use Windows NT Diagnostics.
The HARDWARE key contains the following subkeys:
Description. Describes the hardware recognized automatically by the system. DEVICEMAP. Points to the location in the Registry where the driver for each device is located. Typically, this is in the Services subkey of one of the control sets. RESOURCEMAP. Points to the location in the Registry where the driver for each resource is located. Typically, this is in the Services subkey of one of the control sets.
Windows NT implements hardware profiles, which make it simple for users to switch a number of settings related to hardware at once. For example, a laptop user might have "docked" and "mobile" profiles, with the mobile profile using a lower density screen, different color scheme, and so on. This is unlikely to be of interest on a server, which usually keeps the same hardware configuration at all times. To implement this feature, Windows NT no longer assumes that there's only one set of hardware settings; this new key holds the current settings. Behind the scenes, changing your hardware profile from mobile to docked involves copying the docked profile into this HKEY_CURRENT_CONFIG key. Hardware profiles primarily are of interest to users of Windows NT Workstation 4.0.
This key, which is linked to HKEY_LOCAL_MACHINE\SOFTWARE\Classes, contains
file association and OLE and ActiveX server information. The file association
keys all have a name that starts with a period (.) and represents a file
extension, such as .BMP or .TXT. Each key has one value entry, typically
with no name, that contains the name of a key for the application that
will launch files with that extension. To change file association keys,
use the File Types page of Explorer's Options property sheet by choosing
Options from the View menu (see fig.
9.4).
9.4
Associating file types with applications.
The OLE-related keys have names that don't start with the period character. The subkeys vary from application to application, but all have a CLSID subkey for the OLE Class ID. One important value entry is shell\open\command, which contains the command line to be used when a file of this type is opened by double-clicking a file in Explorer. For example, the value item HKEY_CLASSES_ROOT\Word.Document.6\shell\open\command has the value c:\MSOFFICE\WINWORD\WINWORD.EXE /w on those few installations of Windows NT Server that run desktop applications. Other subkeys cover the behavior of the application as an OLE server. For example, HKEY_CLASSES_ROOT\Word.Document.6\protocol\StdFileEditing\Verb\0 has the value Edit, an OLE verb.
Don't edit these values unless specifically directed to do so by your application vendor or Microsoft. You could leave the application unusable.
This key stores all the profile information that's current to the user who's logged on to the server at the moment. A user profile is a collection of keys that contains all the information about one user. The current user profile information overrides prior user profile settings in HKEY_LOCAL_MACHINE. The subkeys of HKEY_CURRENT_USER, none of which you should change with Registry Editor, are as follows:
Console. Defines the base options, window size, and so on for character-based applications such as Telnet. Control Panel. All the user-specific information set by Control Panel (colors, wallpaper, double-click rate, and much more). Environment. Environment variables set with Control Panel's System tool. KeyboardLayout. This user's keyboard layout. Change with Control Panel's Keyboard tool. Printers. The printers installed for this user. Change with Print Manager. Software. All the settings (options, preferences, customizations, recently opened files, window sizes, and more) for all the software that this user has access to. The structure of this subkey is the same as the HKEY_LOCAL_MACHINE\SOFTWARE key, but the names of the keys under the product name and of the value entries are different. These entries are all changed by the applications that use them.
When a user logs on, his profile is copied from HKEY_USERS into HKEY_CURRENT_USER. If the correct profile for the user isn't found, the default profile (discussed in the next section) is used.
The HKEY_USERS key contains all the active user profiles, each under a key with the same name as the user's Security ID string. HKEY_USERS also contains a .DEFAULT subkey with all the default settings for a new user. The subkeys under each user and under .DEFAULT are the same as those listed in the preceding section for HKEY_CURRENT_USER.
In many of the preceding subkey sections, you read warnings against modifying Registry values. Sometimes, however, you need to know the value of a Registry setting, particularly a hardware setting. One way to look at all your hardware-related Registry settings at once is to use WINMSD, the Windows NT Diagnostics utility. As the name implies, this utility helps you diagnose the behavior of your system by examining a variety of settings at once. To run WINMSD, from the Start menu choose Programs, Administrative Tools, and Windows NT Diagnostics. WINMSD gathers various settings into nine tabs (see fig. 9.5):
Version. Operating system information. including version number, build number, serial number, and registered owner. System. Processor and BIOS information. Display. Display type, settings, and drivers.
9.5
Checking Windows NT version data in the Windows NT Diagnostics utility.
Drives. All fixed, removable, and remote drives, arranged by type (floppy, local hard drive, CD-ROM, remote hard drive) or drive letter. Memory. System memory and paging files. Services. Running or Stopped status for all system services or devices. Resources. Ports, mouse, floppy drives, and other system resources. Environment. Environment variables. Network. Domain, workgroup, access level, and what user is logged on now. Network settings and statistics are also available.
If you aren't sure which Control Panel tool or Registry key to use to check a Registry value, use WINMSD. WINMSD is quick, and you can't accidentally change a value. If you want to keep a record of the settings described in the preceding list, use the printed reports from WINMSD rather than compile a written list from values displayed by the Registry Editor.
It's very important to back up the Registry often, and especially before you change anything to try to fix a problem. Some of the Registry information is saved on the emergency repair disk, but not all. The following are four different ways to back up the Registry:
From within the Registry Editor, choose Sa ve Key from theRegistry menu and save the key to alternate media (diskette, tape, or a drive elsewhere on the network). To restore from this backup, choose Restore Key from the Registry Editor'sRegistry menu.If you back up to tape using Windows NT Backup, mark the Backup Local Registry check box in the Backup Information dialog, and the Registry will be backed up to tape with regular files. To restore from this backup, use Windows NT Restore. Use REGBACK.EXE or REPAIR.EXE, programs included in the Windows NT Resource Kit, to back up Registry files. To restore the Registry, use REGREST.EXE or REPAIR.EXE. From another operating system, copy the files in the C:\Winnt\System32\Config folder (if you didn't install into C:\Winnt, adjust this folder name accordingly) to alternate media. Also copy the user information hives from each C:\Winnt\Profiles\username folder. To restore the Registry, use that other operating system to copy the backups into those folders again.
The Registry Editor is the best way to get a feel for the hierarchical nature of the Registry. Experienced users can also utilize the Registry Editor to edit the Registry, when there's no other way to accomplish certain changes. It's not available from the Start menu, directly. From the Start menu choose Run (or use an MS-DOS prompt), and then type regedt32 to run the Registry Editor. When it first starts, the Registry Editor displays the five topmost keys, as shown earlier in figure 9.3.
In figure 9.3, the subkeys under each key are collapsed, and each is represented by a single line in the right pane. Figure 9.6 shows an expanded subkey.
9.6
Expanding a Registry key to display subkeys.
To expand a collapsed key or to collapse an expanded one, perform one of the following four actions:
Double-click the name of the key. Single-click the + sign (for a collapsed key) or - sign (for an expanded key) in the file folder to the left of the key name, if present. With the key name selected, press Enter. With the key name selected, choose E xpand One Level orCollapse Branch from the Registry EditorTree menu.
The right pane of each window displays the value entries. For each value entry, three pieces of information, separated by colons, are provided: name, type, and value. Figure 9.7 shows the value entries for Notepad, the simple text editor supplied with Windows NT. Some of the value entries (such as lfFaceName) are strings, whereas others (such as lfPitchAndFamily) are binary numbers. If the value of a value entry hasn't yet been set, the Registry Editor displays (value not set).
9.7
Displaying some primary settings for Notepad in the HKEY_CURRENT_USER\Software\Microsoft\Notepad key.
As mentioned earlier in the chapter, an entry of (Default) in the name column means that the value entry doesn't have a name. A (Default) entry is always displayed, so every key appears to have at least one value entry.
To adjust the relative sizes of the panes, click the border between
the panes and drag the border left or right. To change the value of a value
entry, double-click somewhere on its line; this action is the same as choosing
Binary, String, DWord,
or MultiString (as appropriate) from the Edit
menu, described in a later section.
Be very careful when deleting or editing value entries. There is no undo for these operations.
In addition to the mouse manipulations described in the preceding section,
you can move through the Registry with commands arranged into eight menus:
Registry, Edit, Tree,
View, Security, Options,
Window, and Help. These menus are familiar
to experienced Windows users. The following sections describe Registry
Editor's menus.
The Registry menu handles the tasks normally found
on a File menu. Because a Registry spans more than one file, it's inappropriate
to name this menu File.
Following are the Registry menu's 11 commands:
Open Local opens the five top keys of the Registry on this computer.Close closes the Registry. If you have two Registries open (one for this computer and one for a remote computer), the Registry that owns the key that is in the top window is closed.Load Hive brings a saved hive into the HKEY_USERS or HKEY_LOCAL_MACHINE key. One of these keys must be the top window to enable this command.Unload Hive removes the hive that was loaded by the Load Hive command.R estore loads key values from a saved hive. They can't be unloaded afterwards.Sa ve Key saves a hive for later use by the Load Hive or Restore commands.Select Computer opens a remote Registry.Print Subtree prints one key and all its subkeys and value items. Some keys can generate hundreds of pages of printout, so use this menu item with care.P rinter Setup brings up the usual Printer Setup dialog.Save Subtree As saves a selected key or subkey and all its subkeys and value entries into a text file. This may be more convenient than printing a paper copy of the subtree.E xit closes the Registry Editor application.
The commands on the Edit menu let you change Registry
values. (Exercise extreme caution when changing Registry values.) If
possible, use the appropriate specific tool to make the change after using
the Registry Editor to determine what value change must be made.
The Edit menu has the following seven commands:
Add Key lets you create a new key under the currently selected key.Add Value lets you create a String Value, Binary Value, or DWORD Value under the currently selected key.Delete deletes the selected key or value entry.Binary brings up a dialog for editing a binary (REG_BINARY) value.String brings up a dialog for editing a string (REG_SZ or REG_EXPAND_SZ) value.D Word brings up a dialog for editing a double word (REG_DWORD) value.Multi String brings up a dialog for editing a multiline string (REG_MULTI_SZ) value.
The Tree menu controls the way in which the tree of
keys and subkeys is displayed. The four commands are as follows:
E xpand One Level shows the subkeys directly under the selected key or subkey.Expand Branch shows all the subkeys under the selected key or subkey.Expand All shows all the subkeys under all the keys in the top window.Collapse Branch hides all the subkeys under the selected key or subkey.
The View menu gives you control of the appearance of
the Registry Editor interface. The View menu offers the
following eight commands:
Tree and Data shows the tree of keys and subkeys in the left pane, and the value entry names, types, and values in the right pane.Tree Only shows only the tree of keys and subkeys.Data Only shows only the value entry names, types, and values.Split moves the mouse pointer to the border between the panes and lets you adjust their relative sizes without having to hold the mouse button down.Display Binary Data brings up a dialog that displays binary data in a more readable form.R efresh All redraws both panes in all windows to reflect changes that may have been made in other applications.Refresh redraws both panes in the top window to reflect changes that may have been made in other applications.Find Key brings up a dialog to search for a key or subkey by name.
The Security menu controls access to Registry keys.
Use of these menu items to restrict access to Registry keys is discussed
later in the section "Restricting Access to Registry Keys." The
following are the three choices of the Security menu:
Permissions brings up a dialog to set permissions on the selected key and its subkeys.Auditing brings up a dialog to arrange monitoring of access to certain keys and subkeys.Owner is used to change the ownership of a key.
The Options menu controls various options and settings
within Registry Editor. The following are the five menu items:
Font allows you to change the font in which the information is displayed.Auto Refresh toggles the automatic refreshing of key information. This can be useful if a lot of other applications are running that might change the Registry, but it slows the Registry Editor considerably.Read Only Mode prevents changes to the Registry and is a useful safety feature when you're using the Registry Editor to examine values you don't plan to change.Confirm on Delete, another useful safety feature, toggles the confirmation of all deletions.Save Settings on Exit toggles the saving of all these settings when you leave the editor.
The Window menu controls which window is the top one
and how the windows are arranged. The number of menu items varies with
the number of open windows, but always includes one item for each open
window, plus the following three items:
Cascade resizes and moves all the open windows into a cascade of equal-sized windows.Tile resizes and moves all the open windows so that they are all the same size and cover the Registry Editor window without overlapping each other.Arrange Icons aligns the icons of minimized windows at the bottom of the Registry Editor window.
Registry Editor help isn't extensive. The Help menu
has only the following four choices:
Contents lets you look through the contents of the Help file.Search for Help On is used to search the Help file or its index for keywords.How to Use Help explains the Help subsystem.About Registry Editor displays the usual product information and some system information, such as amount of free memory.
Occasionally, you may need to view or change a setting on another computer that's not located with your Windows NT Server computer. Fortunately, Windows NT Server can view and edit Registry entries of other computers running Windows NT or Windows 95. As well, you can edit the Registry of your server from another Windows 95 or Windows NT machine.
Rather than travel to the computer with the problem or tell the user to make the change with another tool, you might choose to edit the Registry remotely from your computer in at least the following situations:
The user can't tell you what's wrong and can't search through the Registry to report what settings have been changed. The user doesn't have the authority or the skill to change a Registry value, even when you can dictate the necessary keystrokes by telephone. The problem is so quick to fix, and the remote computer is so far away (in another building or another city) that it's not worth the time for you to go to the computer. The problem is one that makes the remote computer very hard to use. An example is when the background and foreground text colors have been set to the same color so that no one can read the text in dialogs.
Of course, you can't just take over the Registry of any other computer on your network and start changing values. Preparation is involved, especially if the remote computer is running Windows 95.
If the remote computer is running Windows 95, you must enable user-level security and remote administration from that computer's Control Panel. First, use the Network tool's Access Control page, and select User-Level Access Control. Then use the Password tool's Remote Administration page and mark Enable Remote Administration of This Server. Finally, on the Network tool's Configuration page, mark Add the Microsoft Remote Registry Services.
The details of this process are covered in Chapter 10, "Configuring Windows 95 Clients for Networking," and in the Windows 95 Resource Kit Help, included with the CD-ROM version of Windows 95.
If you're trying to manipulate a Windows NT Registry from a Windows 95 machine (perhaps to fine-tune the departmental server from your desktop), you must add the Microsoft Remote Registry services and arrange user-level access; however, you don't need to enable remote administration of the Windows 95 machine. No preparation is required on the Windows NT Server machine.
If you need to manipulate the Registry of one Windows NT machine from another (any combination of Windows NT Server and Windows NT Workstation), no preparation is required.
To edit from an NT machine, start Registry Editor, and use the Registry
menu's Select Computer command to open windows with the
HKEY_LOCAL_MACHINE and HKEY_USERS keys of the remote computer to the left
pane. Then inspect or change the keys and value entries of the remote computer.
The changes take effect immediately, so use extra care-especially if the
remote computer is in use while you are changing the Registry. You might
want to save this task for a time when the remote machine is not in use,
or arrange such a time with your users.
From a Windows 95 machine, start Registry Editor and choose Connect
Network Registry from the Registry menu to open the remote
Registry. You can then inspect or change the keys and value entries of
the remote computer. As mentioned earlier, take great care. This is especially
true when changing settings on a departmental server-a large number of
users could be inconvenienced with a single keystroke.
You can restrict users' ability to change Registry values in a number of ways. Such restrictions should be part of an overall security plan that allows users to access only those administrative features they need.
First, don't provide Administrator access to non-administrators. You can restrict the access of non-administrator users to the Registry. You also should consider deleting Registry Editor and Policy Editor from client computers. (On Windows NT machines, delete the files Regedit.exe and Poledit.exe from the C:\Winnt folder, and the file Regedt32.exe from the C:\Winnt\System32 folder. If Windows NT wasn't installed into C:\Winnt, use the folder name into which it was installed.) You can administer clients from the server, which usually is in a location with more physical security than the rest of the network.
Regedit.exe is the Windows 95-style Registry Editor. It has less functionality than Regedt32, the Registry Editor discussed in this chapter.
To control access to individual keys, you can add or remove names from the Access Control List (ACL) for each key. If you care enough about a particular key's value to restrict access, you should audit access to the key, or audit failed access attempts.
Excessive access restrictions can make applications unusable or the system unbootable. Always make sure that the Administrator has access to all keys. Always back up the Registry before implementing any security restrictions.
The process of restricting access involves several different administrative tools. Follow these steps:
In User Manager for Domains, choose Policies Audit, and make sure that Audit These Events is selected. Select Success or Failure, or both, for File or Object Access. Within Registry Editor, select the key for which you want to restrict access, and then choose Owner from theSecurity menu. Figure 9.8 shows the Owner dialog. If you aren't the owner of a key, you can't change permissions for that key. As administrator, you can change the owner to yourself, but you can't return ownership unless the original owner gives you Full Control permissions on the key.
9.8
Displaying the owner of a Registry key with the Owner dialog.
After you confirm or take ownership of the key, choose Permissions from theSecurity menu. The Registry Key Permissions dialog is used to assign permissions to the groups listed (see fig. 9.9). To add another group, click Add; to remove a group, click Remove. When the permissions for this key are correct, click OK.
9.9
Setting access permission with the Registry Key Permissions dialog.
The available permissions are as follows:
Full Control. Users in the group can view, change, take ownership, and change permissions. Administrators and the System group should have Full Control on every key. Special Access. Users in the group can view and change the key. Read. Users in the group can only read the key. Choose Auditing from theSecurity menu to arrange auditing of key access. This brings up the Registry Key Auditing dialog (see fig. 9.10).
9.10
Setting auditing choices in the Registry Key Auditing dialog.
From the Registry Key Auditing dialog, select the types of accesses you want to be logged for each group. You may not want to log successful accesses at all because there may be a large number of accesses. For example, many keys are updated every time a user runs an application, and each update may generate several log entries. Logging failed accesses allows you to discover applications that are no longer working for users, or users who are trying to change keys for which they have no permission. The types of access audits are as follows:
Query Value. An attempt to learn the value of the key. Set Value. An attempt to change the value of the key. Create Subkey. An attempt to make a subkey within the key. Enumerate Subkeys. An attempt to list the subkeys of this key. Notify. Notification events from the key. Create Link. An attempt to create a link within a key. Delete. An attempt to delete the key. Write DAC. An attempt to change the permissions (Discretionary Access Control) on a key. Read Control. An attempt to learn the permissions on a key.
To view the audit logs, from the Start menu choose Programs, Administrative
Tools, and Event Viewer. From the Log menu choose Security
to see a list of the logged events. Figure 9.11 shows a sample list. These
entries aren't very helpful beyond the user name; double-click one to see
details like those in figure 9.12. These entries were generated as follows:
Auditing was turned on in User Manager for Domains. In Registry Editor, auditing was turned on for both success and failure for any access to keys under HKEY_USERS\the-SID-of-the-account-in-use-at-the-time\Software\Microsoft\Notepad. In Notepad, the font was changed, and then Notepad was closed. In the Event Viewer, the menu item Log Security was chosen.
9.11
Event Viewer's Security log listings for Registry events.
Even at a cursory glance, figure 9.12 shows that the Notepad key was changed. Further investigation could narrow down the source of a user's trouble quite easily. For example, if you're logging only failures, you might relax security restrictions so that the operation no longer fails.
9.12
Viewing Security log entry detail for opening a Registry key object.
At the beginning of this chapter, you learned that the Registry is a place to store the sort of settings and configuration values once contained in CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, and APPNAME.INI files for individual applications. Applications written for Windows NT or Windows 95 use the Registry to determine settings and configuration values.
16-bit applications written for Windows 3.x run under Windows NT but, obviously, such applications aren't Registry-aware. To run, 16-bit applications need their APPNAME.INI files to contain settings and configuration values. The setup programs of Windows 3.x applications often modify WIN.INI and SYSTEM.INI, and create an APPNAME.INI file for the application. As a result of the Windows NT Setup process, you find WIN.INI and SYSTEM.INI files in \Windows\System32, the system root directory. These files don't affect the behavior of Registry-aware programs at all, but affect the behavior of older 16-bit applications.
As a rule, 16-bit applications don't need to reside on a Windows NT 4.0 server, unless the server shares these applications with client PCs. If you must run 16-bit Windows applications on the server, you need to be aware of the interaction of Registry and .INI file entries.
A developer can access the information in an .INI file in two ways. If the programmer has chosen the "brute-force" method of opening the file and reading through it, the application operates completely independently of the Registry. However, Microsoft provides a set of Windows API functions to look up values in an .INI file, and most developers use these Windows API .INI file functions because they simplify programming. Under Windows NT, these .INI file functions have the same name as under Windows 3.x, but for certain specific keys the functions operate on the Registry rather than on an .INI file. This means that 16-bit programs, written by developers before the Registry existed, store their configuration entries in the Registry.
The HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\IniFileMapping key maps .INI file entries to Registry keys. Figure 9.13 shows the win.ini subkey and its value entries. The value for each value entry is the Registry key to which it's mapped (note that each key may have a number of value entries). The strings USR and SYS stand for the keys HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE\Software, respectively. Also, three symbols-!, #, and @-may be present as the first character of the value.
9.13
Displaying the mapping of WIN.INI entries to Registry keys.
In all cases, a request to read from or write to the .INI file is translated into a request to read or write a Registry entry, but if one of these characters is present, the connection is made even tighter. The meaning of each of the three symbols is as follows:
! means that, as well as write the value to the Registry, the value should be written to the .INI file. # means that when a user first logs on to Windows NT, the value should be initialized from the .INI file. @ means that if the mapped key doesn't contain the value entry being requested, the request fails rather than goes to the .INI file.
It's possible to use Windows NT Server 4.0 with only a vague idea of the Registry and the purpose it serves-at least until a Registry-related problem arises. As a network administrator, you must know what information is stored in the Registry and how to change Registry entries when necessary. It's important to understand how dangerous it can be to edit Registry values with the Registry Editor, and why, despite the danger, you occasionally must use the Registry Editor to alter values.
Many of the remaining chapters in this book touch on the Registry from time to time, but the following chapters elaborate on Registry entries:
Chapter 8, "Installing File Backup Systems," explains the tradeoffs between different types and formats of backup systems, and how to manage server backup operations to ensure against lost Registry data in case of a fixed-disk failure. Chapter 12, "Managing User and Group Accounts," covers the issues of user administration and security that affect the user-related keys of the Registry. Chapter 16, "Distributing Network Services with Domains," covers additional Registry-related security issues.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
