Understanding the registry structure
Registry data: How it is stored and used
Backing up and restoring the registry
Everyone who accesses a computer, whether in a workgroup or on a domain, at one time or another has accessed the Microsoft Windows registry whether the person realizes it or not. Whenever you log on, your user preferences are read from the registry. Whenever you make changes to the system configuration, install applications or hardware, or make other changes to the working environment, the changes are stored in the registry. Whenever you uninstall hardware, applications, or system components, these changes are also recorded in the registry.
The registry is the central repository for configuration information in Windows. Applications, system components, device drivers, and the operating system kernel all use the registry to store settings and obtain information about user preferences, system hardware configuration, and system defaults. The registry also stores information about security settings, user rights, local accounts, and much more. In domains, Windows does not store information about domain accounts or network objects in the registry; these settings are managed by Active Directory Domain Services (AD DS).
With so much information being read from and written to the registry, it is not only important for administrators to understand its structures and uses; it is essential. You should know the types of data the registry works with, what type of data is stored where, and how to make changes if necessary. This is important because often when you must fine-tune the system configuration or correct errors to stabilize systems, you might be instructed to access the registry and make a particular change. Generally, the instructions assume you know what you’re doing. Unfortunately, if you attempt such a change and really don’t know what you’re doing, you could make it so the system won’t boot at all. So, with this in mind, let’s look at how the registry works and how you can work with it.
The registry is written as a binary database with the information organized in a hierarchy. This hierarchy has a structure much like a file system uses and is an inverted tree with the root at the top of the tree. Any time the Windows operating system must obtain system default values or information about your preferences, it obtains this information from the registry. When you install programs or make changes in Control Panel, these changes usually are written to the registry.
Note
I say “usually” because in Windows domains, some configuration information is written to Active Directory. For example, information about user accounts and network objects is stored in Active Directory. In addition, when you promote a member server to a domain controller, key registry settings that apply to the server, such as the default configuration values, are transferred to Active Directory and thereafter managed through Active Directory. If you were later to demote the domain controller, the original registry settings would not be restored either. Instead, the default settings are restored as they would appear on a newly installed server.
The registry’s importance is that it stores most of a system’s state. If you make preference and settings changes to a system, these changes are stored in the registry. If a system dies and cannot be recovered, you don’t have to install a new system and then configure it to look like the old one. You could instead install Microsoft Windows Server 2012 R2 and then restore a backup of the failed system’s registry. This restores all the preferences and settings of the failed system on the new system.
Although it’s great that the registry can store settings you’ve made, you might be wondering what else the registry is good for. Well, in addition to storing settings you’ve made, the registry stores settings that the operating system makes. For example, the operating system kernel stores information needed by device drivers in the registry, including the driver initialization parameters, which enables the device drivers to configure themselves to work with the system’s hardware.
Many other system components also use the registry. When you install Windows Server, the setup choices you make are used to build the initial registry database. Setup modifies the registry whenever you add hardware to or remove hardware from a system. Similarly, application setup programs modify the registry to store the application installation settings and determine whether components of the application are already installed. Then, when you run applications, the applications use the registry settings.
Current Windows operating systems don’t always store application settings directly in the registry and might, in fact, read some settings from a user’s profile. This behavior occurs because of User Account Control (UAC). Of the many features UAC implements, two key features change the way Windows installs and runs applications: application run levels and application virtualization.
To support run levels and virtualization, all applications that run on current Windows operating systems have a security token, which reflects the level of privileges required to run the application. Applications written for Windows Vista and later can have either an administrator token or a standard user token. Applications with administrator tokens require elevated privileges to run and perform core tasks. After it’s started in elevated mode, an application with an administrator token can perform tasks that require administrator privileges and write to system locations of the registry and the file system.
However, applications with standard user tokens do not have elevated privileges to run and perform core tasks. After it’s started in standard user mode, an application with a standard user token must request elevated privileges to perform administration tasks. For all other tasks, the application should not run using elevated privileges. Further, the application should write data only to nonsystem locations of the registry and the file system.
Standard user applications run in a special compatibility mode and use file system and registry virtualization to provide virtualized views of resources. When an application attempts to write to a system location, Windows Vista and later give the application a private copy of the file or registry value. Any changes are then written to the private copy, and this private copy, in turn, is stored in the user’s profile data. If the application attempts to read or write to this system location again, it is given the private copy from the user’s profile to work with. By default, if an error occurs when working with virtualized data, the error notification and logging information show the virtualized location rather than the actual location the application was trying to work with.
Many administrative tools are little more than friendly user interfaces for managing the registry, especially when it comes to Control Panel. So, rather than having you work directly with a particular area of the registry, Microsoft provides tools you can use to make the necessary changes safely and securely. Use these tools—that’s what they are for.
Caution
The importance of using the proper tools to make registry changes cannot be overstated. If there’s a tool to manage an area of the registry, you should use it. Don’t fool around with the registry just because you can. Making improper changes to the registry can cause a system to become unstable, and in some cases, it could even prevent the system from booting.
As you can see, nearly everything you do with the operating system affects the registry in one way or another. That’s why it’s so important to understand what the registry is used for, how you can work with it, how you can secure it, and how you can maintain it.
The registry is first a database. Like any other database, it is designed for information storage and retrieval. Any registry value entry can be identified by specifying the path to its location. For example, the path HKEY_LOCAL_MACHINESOFTWAREMicrosoftServerManagerDoNotOpenServerManagerAtLogon specifies a registry value you can use to enable or disable the automatic display of Server Manager at logon.
Figure 8-1 shows this value in the registry. Because of its hierarchical structure, the registry appears to be organized much like a file system. In fact, its structure is often compared to that of a file system. However, this is a bit misleading because there is no actual folder/file representation on a system’s hard disk to match the structure the registry uses. The registry’s actual physical structure is separate from the way registry information is represented. Locations in the registry are represented by a logical structure that has little correlation to how value entries are stored.
Windows Server doesn’t keep the entire registry in paged pool memory. Instead, 256-kilobyte (KB) views of the registry are mapped into system cache as needed. This is an important change from the original architecture of the registry, which effectively limited the registry to about 80 percent of the total size of paged pool memory. Now registry implementation is limited only by available space in the paging file.
At startup, 256 KB mapped views of the registry are loaded into system cache so that Windows Server 2012 R2 can quickly retrieve configuration information. Some of the registry’s information is created dynamically, based on the system hardware configuration at startup, and doesn’t exist until it is created. For the most part, however, the registry is stored in persistent form on disk and read from a set of files called hives. Hives are binary files that represent a grouping of keys and values. You find the hive files in the %SystemRoot%System32Config directory. Within this directory, you also find .sav and .log files, which serve as backup files for the registry. In Windows Explorer, you might need to enable File Name Extensions in the View pane to see full file names.
At the top of the registry hierarchy are the root keys. Each root key contains several subkeys, which contain other subkeys and value entries. The names of value entries must be unique within the associated subkey, and the value entries correspond to specific configuration parameters. The settings of those configuration parameters are the values stored in the value entry. Each value has an associated data type that controls the type of data it can store. For example, some value entries store only binary data; others store only strings of characters. The value’s data type controls this.
We can now break down the registry path HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAllowMultipleTSSessions so that it is more meaningful. Here, HKEY_LOCAL_MACHINE is the root key. Each entry below the root key until we get to AllowMultipleTSSessions represents a subkey level within the registry hierarchy. Finally, AllowMultipleTSSessions is the actual value entry.
The registry is very complex, and it is often made more confusing because documentation on the subject uses a variety of terms beyond those already discussed. When reading about the registry in various sources, you might see references to the following:
Subtrees. Subtree is the name for the tree of keys and values stemming from a root key down the registry hierarchy. In documentation, you often see root keys referred to as subtrees. What the documentation means when it refers to a subtree is the branch of keys and values contained within a specified root key.
Keys. Technically, root keys are the top of the registry hierarchy, and everything below a root key is either a subkey or a value entry. In practice, subkeys are often referred to as keys. It’s just easier to refer to such and such a key—sort of like when we refer to “such and such a folder” rather than saying “subfolder.”
Values. A value is the lowest level of the registry hierarchy. For ease of reference, value entries are often simply referred to as values. Technically, however, a value entry comprises three parts: a name, data type, and value. The name identifies the configuration setting. The data type identifies the format for the data. The value is the actual data within the entry.
Now that you know the basics of the registry’s structure, let’s dig deeper and take a closer look at the root keys, major subkeys, and data types.
The registry is organized into a hierarchy of keys, subkeys, and value entries. The root keys are at the top of the hierarchy and form the primary branches, or subtrees, of registry information. There are two physical root keys: HKEY_LOCAL_MACHINE and HKEY_USERS. These physical root keys are associated with actual files stored on the disk and are divided into additional logical groupings of registry information. As shown in Table 8-1, the logical groupings are simply subsets of information gathered from HKEY_LOCAL_MACHINE and HKEY_USERS.
Table 8-1. Registry subtrees
Subtree | Description |
|---|---|
Physical Subtree | |
HKEY_LOCAL_MACHINE (HKLM) | Stores all the settings that pertain to the hardware currently installed on the machine. |
HKEY_USERS (HKU) | Stores user profile data for each user who has previously logged on to the computer locally and a default user profile. |
Logical Subtree | |
HKEY_CLASSES_ROOT (HKCR) | Stores all file associations and object linking and embedding (OLE) class identifiers. This subtree is built from HKEY_LOCAL_MACHINESOFTWAREClasses and HKEY_CURRENT_USERSOFTWAREClasses. |
Stores information about the hardware configuration with which you started the system. This subtree is built from HKEY_LOCAL_MACHINESYSTEMCurrentControlSetHardware ProfilesCurrent, which in turn is a pointer to a numbered subkey that has the current hardware profile. | |
HKEY_CURRENT_USER (HKCU) | Stores information about the user currently logged on. This key has a pointer to HKEY_USERSUserSID, where UserSID is the security identifier for the current user and for the default profile discussed previously. |
HKEY_LOCAL_MACHINE, abbreviated as HKLM, contains all the settings that pertain to the hardware currently installed on a system. It includes settings for memory, device drivers, installed hardware, and startup. Applications are supposed to store settings in HKLM only if the related data pertains to everyone who uses the computer.
As Figure 8-2 shows, HKLM contains the following major subkeys:
These subkeys are discussed in the sections that follow.
The HKLMBCD00000000 key stores information regarding the configuration and state of the computer’s Boot Configuration Data (BCD). BCD provides a firmware-independent approach for managing the boot environment for Windows systems. As discussed in Chapter 3 you manage the BCD store by using the BCDEdit tool (and not through the related registry keys).
The BCD architecture has three main components: stores, objects, and elements. A store is a top-level component that establishes the namespace and acts as a container for BCD objects and elements. There are three general types of BCD objects:
Application objects. Describe boot environment objects such as Windows Boot Manager or Windows Boot Loader
Inheritable objects. Act as containers for elements that are shared across multiple object instances
Device objects. Act as containers for elements that describe complex devices such as a RAM disk that was created from a Windows Imaging file
Application objects have an image type and an application type associated with them. The image type specifies how the executable for the application is loaded, such as through the firmware or by a boot application. The application type specifies what the application does, and the standard application types are listed in Table 8-2.
Table 8-2. BCD application types
Application type | Description |
|---|---|
A 16-bit, real-mode application for BIOS-based systems, which can be used to restart the boot process and load a non-Windows operating system | |
Firmware boot manager | Manages the firmware boot for Extensible Firmware Interface (EFI) systems |
Ntldr | Loads versions of Windows earlier than Windows Vista on BIOS-based systems. |
Windows boot loader | Loads a particular version or configuration of Windows |
Windows boot manager | Controls boot of the system; in a multi-boot system, displays a boot selection menu to the user |
Windows memory tester | An application for performing memory diagnostics |
Windows resume application | Restores Windows to its running state when a computer resumes from hibernation |
Each BCD object has a globally unique identifier, or GUID. For example, the GUID of the Windows resume application is 5824ba7d-acee-11e1-ba52-cfa3fef36259. In the registry, the GUID sets the key path, and each object has a description entry and associated elements entries.
HKLMHARDWARE stores information about the hardware configuration for the computer. This key is re-created by the operating system each time you start Windows Server 2012 R2, and it exists only in memory, not on disk. To build this key, the operating system enumerates every device it can find by scanning the system buses and by searching for specific classes of devices, such as serial ports, keyboards, and pointer devices.
Under HKLMHARDWARE, you’ll find four standard subkeys that are dynamically created at startup and contain the information gathered by the operating system. These subkeys are as follows:
ACPI. Contains information about the Advanced Configuration and Power Interface (ACPI), which is part of the system BIOS that supports Plug and Play and advanced power management. This subkey doesn’t exist on non-ACPI-compliant computers.
DESCRIPTION. Contains hardware descriptions, including those for the system’s central processor, floating-point processor, and multifunction adapters. For portable computers, one of the multifunction devices lists information about the docking state. For any computer with multipurpose chip sets, one of the multifunction devices lists information about the controllers for disks, keyboards, parallel ports, serial ports, and pointer devices. There’s also a catchall category for other controllers, such as when a computer has a PC Card controller.
DEVICEMAP. Contains information that maps devices to device drivers. You’ll find device mappings for keyboards, pointer devices, parallel ports, Small Computer System Interface (SCSI) ports, serial ports, and video devices. Of particular note is that within the VIDEO subkey is a value entry for the VGA-compatible video device installed on the computer. This device is used when the computer must start in VGA display mode.
RESOURCEMAP. Contains mappings for the hardware abstraction layer (HAL), for the Plug and Play Manager, and for available system resources. Of particular note is the Plug and Play Manager. It uses this subkey to record information about devices it knows how to handle.
Additional nonstandard subkeys can exist under HKLMHARDWARE. The subkeys are specific to the hardware the computer uses.
HKLMSAM stores the Security Accounts Manager (SAM) database. When you create local users and groups on member servers and workstations, the accounts are stored in HKLMSAM. This key is also used to store information about built-in user and group accounts and group membership and aliases for accounts.
By default, the information stored in HKLMSAM is inaccessible through Registry Editor. This is a security feature designed to help protect the security and integrity of the system.
HKLMSECURITY stores security information for the local machine. It contains information about cached logon credentials, policy settings, service-related security settings, and default security values. It also has a copy of HKLMSAM. As with the HKLMSAM subkey, this subkey is inaccessible through Registry Editor. This is a security feature designed to help protect the security and integrity of the system.
HKLMSOFTWARE stores machine-wide settings for every application and system component installed on the system. This includes setup information, executable paths, default configuration settings, and registration information. Because this subkey resides under HKLM, the information here is applied globally. This is different from the HKCUSOFTWARE configuration settings, which are applied on a per-user basis.
As Figure 8-3 shows, you’ll find many important subkeys within HKLMSOFTWARE, including the following:
Classes. Contains all file associations and OLE class identifiers. This is also the key from which HKEY_CLASSES_ROOT is built.
Clients. Stores information about protocols and shells used by every client application installed on the system. This includes the calendar, contacts, mail, media, and news clients.
Microsoft. Contains information about every Microsoft application and component installed on the system. This includes their complete configuration settings, defaults, registration information, and much more. You’ll find most of the graphical user interface (GUI) preferences under HKLMSOFTWAREMicrosoftWindowsCurrentVersion. You’ll find the configuration settings for most system components, language packs, hot fixes, and more under HKLMSOFTWAREMicrosoftWindows NTCurrentVersion.
ODBC. Contains information about the Open Database Connectivity (ODBC) configuration on the system. It includes information about all ODBC drives and ODBC file Data Source Names (DSNs).
Policies. Contains information about local policies for applications and components installed on the system.
HKLMSYSTEM stores information about device drivers, services, startup parameters, and other machine-wide settings. You’ll find several important subkeys within HKLMSYSTEM. One of the most important is HKLMSYSTEMCurrentControlSet, as shown in Figure 8-4.
CurrentControlSet contains information about the set of controls and services used for the last successful boot of the system. This subkey always contains information on the set of controls actually in use and represents the most recent successful boot. The operating system writes the control set as the final part of the boot process so that it updates the registry as appropriate to reflect which set of controls and services was last used for a successful boot. This is, in fact, how you can boot a system to the Last Known Good Configuration after it crashes or experiences a Stop error.
HKLMSYSTEM also contains previously created control sets. These are saved under the subkeys named ControlSet001, ControlSet002, and so forth. Within the control sets, you’ll find four important subkeys:
Control. Contains control information about key operating system settings, tools, and subcomponents, including the HAL, keyboard layouts, system devices, interfaces, and device classes. Under BackupRestore, you’ll find the saved settings for Backup, which include lists of Automated System Recovery (ASR) keys, files, and registry settings not to restore. Under the SafeBoot subkey, you’ll find the control sets used for minimal and network-only boots of the system.
Enum. Contains the complete enumeration of devices found on the computer when the operating system scans the system buses and searches for specific classes of devices. This represents the complete list of devices present during startup of the operating system.
Hardware Profiles. Contains a subkey for each hardware profile available on the system. The first hardware profile, 0000, is an empty profile. The other numbered profiles, beginning with 0001, represent profiles that are available for use on the system. The profile named Current always points to the profile the operating system is currently using.
Services. Contains a subkey for each service installed on the system. These subkeys store the necessary configuration information for their related services, which can include startup parameters and security and performance settings.
Another interesting subkey is HKLMSYSTEMMountedDevices. The operating system creates this key and uses it to store the list of mounted and available disk devices. Disk devices are listed according to logical volume configuration and drive-letter designator.
HKEY_USERS, abbreviated as HKU, contains a default user profile and user-profile data for every user who has previously logged on to the computer locally. Each user’s profile is owned by that user unless you change permissions or move profiles. Profile settings include the user’s desktop configuration, environment variables, folder options, menu options, printers, and network connections.
User profiles are saved in subkeys of HKEY_USERS according to their security identifiers (SIDs). A SecurityID_Classes subkey represents file associations that are specific to a particular user. For example, if a user sets Adobe Photoshop as the default program for .jpeg and .jpg files and this is different from the system default, entries within this subkey show this association.
When you use Group Policy, the policy settings are applied to the individual user profiles stored in this key. The default profile specifies how the machine behaves when no one is logged on and is used as the base profile for new users who log on to the computer. For example, if you want to ensure that the computer uses a password-protected screen saver when no one is logged on, you modify the default profile accordingly. The subkey for the default user profile is easy to pick out because it is named HKEY_USERS.DEFAULT.
HKEY_CLASSES_ROOT, abbreviated as HKCR, stores all file associations that tell the computer which document file types are associated with which applications and which action to take for various tasks—such as open, edit, close, or play—based on a specified document type. For example, if you double-tap or double-click a .doc file, the document typically is opened for editing in Microsoft Word. This file association is added to HKCR when you install Microsoft Office or Word. If Microsoft Office or Word isn’t installed, a .doc file is opened instead in WordPad because of a default file association created when the operating system is installed.
HKCR is built from HKEY_LOCAL_MACHINESOFTWAREClasses and HKEY_CURRENT_USERSOFTWAREClasses. The former provides computer-specific class registration, and the latter provides user-specific class registration. Because the user-specific class registrations have precedence, this allows for different class registrations for each user of the machine. This is different from previous versions of the Windows operating system, in which the same class registration information was provided for all users of a particular machine.
HKEY_CURRENT_CONFIG, abbreviated as HKCC, contains information about the hardware configuration with which you started the system, which is also referred to as the machine’s boot configuration. This key contains information about the current device assignments, device drivers, and system services that were present at boot time.
HKCC is built from HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetHardware ProfilesCurrent, which in turn is a pointer to a numbered subkey that contains the current hardware profile. If a system has multiple hardware profiles, the key points to a different hardware profile, depending on the boot state or the hardware profile selection made at startup.
HKEY_CURRENT_USER, abbreviated as HKCU, contains information about the user currently logged on. This key has a pointer to HKEY_USERSUserSID, where UserSID is the security identifier for the current user and for the default profile discussed previously. Microsoft requires applications to store user-specific preferences under this key. For example, Microsoft Office settings for individual users are stored under this key. In addition, as discussed previously, HKEY_CURRENT_USERSOFTWAREClasses stores the user-specific settings for file associations.
Tip
If you don’t want users to be able to set their own file associations, you could change the permissions on HKLMSOFTWAREClasses so that users can’t alter the global settings you want them to have. For more information about registry permissions, see the Securing the registry section later in this chapter.
Now that you know more about the registry’s structure, let’s take a look at the actual data within the registry. Understanding how registry data is stored and used is just as important as understanding the registry structure.
As mentioned previously, some registry data is created dynamically during the startup of the operating system, and some is stored on disk so that it can be used each time you boot a computer. The dynamically created data is volatile, meaning that when you shut down the system, it is gone. For example, as part of the startup process, the operating system scans for system devices and uses the results to build the HKEY_LOCAL_MACHINEHARDWARE subkey. The information stored in this key exists only in memory and isn’t stored anywhere on disk.
However, registry data stored on disk is persistent. When you shut down a system, this registry data remains on disk and is available the next time you boot the system. Some of this stored information is very important, especially when it comes to recovering from boot failure. For example, by using the information stored in HKEY_LOCAL_MACHINESYSTEMCurrentControlSet, you can boot by using the Last Known Good Configuration. If the registry data was corrupted, however, this information might not be available, and the only way to recover the system is to try repairing the installation or reinstalling the operating system.
To help safeguard the system and ensure that one section of bad data doesn’t cause the whole registry to fail to load, Windows Server 2012 R2 has several built-in redundancies and fail-safe processes. For starters, the registry isn’t written to a single file. Instead, it is written to a set of files called hives. There are six main types of hives, each representing a group of keys and values. Most of the hives are written to disk in the %SystemRoot%System32Config directory. Within this directory, you’ll find these hive files:
DEFAULT, which corresponds to the HKEY_USERS.DEFAULT subkey
DRIVERS, which corresponds to the HKLMDRIVERS subkey
SAM, which corresponds to the HKEY_LOCAL_MACHINESAM subkey
SECURITY, which corresponds to the HKEY_LOCAL_MACHINESECURITY subkey
SOFTWARE, which corresponds to the HKEY_LOCAL_MACHINESOFTWARE subkey
SYSTEM, which corresponds to the HKEY_LOCAL_MACHINESYSTEM subkey
The remaining hive files are stored in individual user-profile directories with the default name of Ntuser.dat. These files are, in fact, hive files that are loaded into the registry and used to set the pointer for the HKEY_CURRENT_USER root key. When no user is logged on to a system, the user profile for the default user is loaded into the registry. When an actual user logs on, this user’s profile is loaded into the registry.
Note
The root keys not mentioned are HKEY_CURRENT_CONFIG and HKEY_CLASSES_ROOT. The on-disk data for HKEY_CURRENT_CONFIG comes from the subkey from which it is built: HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetHardware ProfilesCurrent. Similarly, the on-disk data for HKEY_CLASSES_ROOT comes from HKEY_LOCAL_MACHINE SOFTWAREClasses and HKEY_CURRENT_USERSOFTWAREClasses.
Every hive file has associated log files—even Ntuser.dat. Windows Server 2012 R2 uses the log files to help protect the registry during updates. When a hive file is to be changed, the operating system writes the change to a log file and stores this log file on disk. The operating system then uses the change log to write the changes to the actual hive file. If the operating system were to crash while a change is being written to a hive file, the operating system could use the change log later to roll back the change, resetting the hive to its previous configuration.
When you work your way down to the lowest level of the registry, you see the actual value entries. Each value entry has a name, data type, and value associated with it. Although value entries have a theoretical size limit of 1,024 KBs, most value entries are less than 1 KB in size. In fact, many value entries contain only a few bits of data. The type of information stored in these bits depends on the data type of the value entry.
The data types defined include the following:
REG_BINARY. Raw binary data without any formatting or parsing. You can view binary data in several forms, including standard binary and hexadecimal. In some cases, if you view the binary data, you see the hexadecimal values and the text characters these values define.
REG_DWORD. A binary data type in which 32-bit integer values are stored as 4-byte-length values in hexadecimal. REG_DWORD is often used to track values that can be incremented, 4-byte status codes, or Boolean flags. With Boolean flags, a value of 0 means the flag is off (false), and a value of 1 means the flag is on (true).
REG_LINK. A Unicode string specifying a symbolic link to another registry value.
REG_NONE. Data without a particular type that is displayed in Registry Editor in hexadecimal format as a binary value.
REG_QWORD. A binary data type in which 64-bit integer values are stored as 8-byte-length values in hexadecimal. REG_QWORD is often used to track large values that can be incremented, 8-byte status codes, or Boolean flags. With Boolean flags, a value of 0 means the flag is off (false), and a value of 1 means the flag is on (true).
REG_SZ. A fixed-length string of Unicode characters. REG_SZ is used to store values that are meant to be read by users and can include names, descriptions, and so on in addition to stored file system paths.
REG_EXPAND_SZ. A variable-length string that can include environment variables that are to be expanded when the data is read by the operating system, its components, or services in addition to installed applications. Environment variables are enclosed in percentage signs (%) to set them off from other values in the string. For example, %SystemDrive% refers to the SystemDrive environment variable. A REG_EXPAND_SZ value that defines a path to use could include this environment variable, such as %SystemDrive%Program FilesCommon Files.
REG_MULTI_SZ. A multiple-parameter string that can be used to store multiple string values in a single entry. Each value is separated by a standard delimiter so that the individual values can be picked out as necessary.
REG_RESOURCE_LIST. A value that stores a series of nested arrays and that was designed to store a resource list for hardware device drivers or a physical device a driver controls. The value is displayed in Registry Editor in hexadecimal format as a binary value.
REG_RESOURCE_REQUIREMENTS_LIST. A value that stores a series of nested arrays and that was designed to store a list of hardware resources for device drivers or a physical device a driver controls. The value is displayed in Registry Editor in hexadecimal format as a binary value.
REG_FULL_RESOURCE_DESCRIPTOR. A value with an encoded resource descriptor such as a list of resources used by a device driver or a hardware component. REG_FULL_RESOURCE_DESCRIPTOR values are associated with hardware components such as a system’s central processors, floating-point processors, or multifunction adapters.
The most common data types you’ll see in the registry are REG_SZ and REG_DWORD. The vast majority of value entries have these data types. The most important thing to know about these data types is that one is used with strings of characters, and the other is used with binary data that is normally represented in hexadecimal format. And don’t worry; if you have to create a value entry—typically, you do so because you are directed to by a Microsoft Knowledge Base article in an attempt to resolve an issue—you are usually told which data type to use. Again, more often than not, this data type is either REG_SZ or REG_DWORD.
Windows Server 2012 R2 provides several tools for working with the registry. The main tool, of course, is Registry Editor, which you start by typing regedit or regedt32 at the command line or in the Run dialog box. Another tool for working with the registry is the REG command. Both tools can be used to view and manage the registry. Keep in mind that although both tools are considered editors, Windows Server 2012 R2 applies any changes you make immediately. Thus, any change you make is applied automatically to the registry without you having to save the change.
Caution
As an administrator, you have permission to make changes to most areas of the registry. This allows you to make additions, changes, and deletions as necessary. However, before you do this, you should always make a backup of the system state along with the registry first, as discussed in “Backing up and restoring the registry” later in this chapter. This helps ensure that you can recover the registry in case something goes wrong when you are making your modifications.
One of the common tasks you’ll want to perform in Registry Editor is to search for a particular key. You can search for keys, values, and data entries by using Find on the Edit menu.
Don’t let the simplicity of the Find dialog box, shown in Figure 8-5, fool you—there is a bit more to searching the registry than you might think. So, if you want to find what you’re looking for, do the following:
The Find function in Registry Editor searches from the current node forward to the last value in the final root key branch. So, if you want to search the complete registry, you must select the Computer node in the left pane before you select Find on the Edit menu or press Ctrl+F.
Type the text you want to find in the Find What box. You can search only for standard American Standard Code for Information Interchange (ASCII) text. Therefore, if you’re searching for data entries, Registry Editor searches only string values (REG_SZ, REG_EXPAND_SZ, and REG_MULTI_SZ) for the specified text.
Use the Look At options to control where Registry Editor looks for the text you want to find. You can search on key names, value names, and text within data entries. If you want to match only whole strings instead of searching for text within longer strings, select the Match Whole String Only check box.
After you make your selections, tap or click Find Next to begin the search. If Registry Editor finds a match before reaching the end of the registry, it selects and displays the matching item. If the match isn’t what you’re looking for, press F3 to search again from the current position in the registry.
When you want to work with keys and values in the registry, you typically are working with subkeys of a particular key. This enables you to add a subkey and define its values and to remove subkeys and their values. You cannot, however, add or remove root keys or insert keys at the root node of the registry. Default security settings within some subkeys might also prohibit you from working with their keys and values. For example, by default you cannot create, modify, or remove keys or values within HKLMSAM and HKLMSECURITY.
The most common change you’ll make to the registry is to modify an existing value. For example, a Knowledge Base article might recommend changing a value from 0 to 1 to enable a certain feature in Windows Server 2012 R2 or from 1 to 0 to disable it. To change a value, locate the value in Registry Editor and then, in the right pane, double-tap or double-click the value name. This opens an Edit dialog box, the style of which depends on the type of data you are modifying.
The most common values you’ll modify are REG_SZ, REG_MULTI_SZ, and REG_DWORD. Figure 8-6 shows the Edit String dialog box, which opens when you modify REG_SZ values. In the dialog box, you typically replace the existing value shown in the Value Data box with the value you need to enter.
Figure 8-7 shows the Edit Multi-String dialog box, which opens when you modify REG_MULTI_SZ values. In this example, there are three string values. In the dialog box, each value is separated by a new line to make the values easier to work with. If directed to change a value, you typically need to replace an existing value; make sure you don’t accidentally modify the entry before or after the entry you are working with. If directed to add a value, you begin typing on a new line following the last value.
Figure 8-8 shows the Edit DWORD Value dialog box, which opens when you modify REG_DWORD values. In this example, the value is displayed in hexadecimal format. Typically, you won’t need to worry about the data format. You just enter a new value as you’ve been directed. For example, if the current value entry represents a flag, the data entry of 1 indicates the flag is on (or true). To turn off the flag (switch it to false), you replace the 1 with a 0.
Note
The Windows Clipboard is available when you are working with Registry Editor. This means you can use the Copy, Cut, and Paste commands just as you do with other Windows programs. If a value in a Knowledge Base article is difficult to type, you might want to copy it to the Clipboard and then paste it into the Value Data box of the Edit dialog box.
As noted previously, you can add or remove keys in most areas of the registry. The exceptions pertain to the root node, root keys, and areas of the registry where permissions prohibit modifications.
You add new keys as subkeys of a selected key. Access the key you want to work with and then add the subkey by pressing and holding or right-clicking the key and selecting Edit, New, and then Key. Registry Editor creates a new key and selects its name so that you can set it as appropriate. The default name is New Key #1.
A default value entry is associated with the new key automatically. The data type for this default value is REG_SZ. Just about every key in the registry has a similarly named and typed value entry, so don’t delete this value entry. Either set its value by double-tapping or double-clicking it to open the Edit String dialog box or create additional value entries under the selected key.
To create additional value entries under a key, press and hold or right-click the key and then select New followed by one of these menu options:
String Value. Used to enter a fixed-length string of Unicode characters. The type is REG_SZ.
Binary Value. Used to enter raw binary data without any formatting or parsing. The type is REG_BINARY.
DWORD (32-bit) Value. Used to enter binary data type in which 4-byte integer values are stored. The type is REG_DWORD.
QWORD (64-bit) Value. Used to enter binary data type in which 8-byte integer values are stored. The type is REG_QWORD.
Multi-String Value. Used to enter a multiple-parameter string. The type is REG_MULTI_SZ.
Expandable String Value. Used to enter a variable-length string that can include environment variables that are to be expanded when the data is read. The type is REG_EXPAND_SZ.
Creating a new value adds it to the selected key and gives it a default name of New Value #1, New Value #2, and so on. The name of the value is selected for editing so that you can change it immediately. After you change the value name, double-tap or double-click the value name to edit the value data.
Removing keys and values from the registry is easy but should never be done without careful forethought to the possible consequences. That said, you delete a key or value by selecting it and then pressing the Delete key. Registry Editor will ask you to confirm the deletion. After you do this, the key or value is permanently removed from the registry. Keep in mind that when you remove a key, Registry Editor removes all subkeys and values associated with the key.
You can modify the registry of remote computers without having to log on locally. To do this, select Connect Network Registry on the File menu in Registry Editor and then use the Select Computer dialog box to specify the computer you want to work with. In most cases, all you must do is type the name of the remote computer and then tap or click OK. If prompted, you might need to enter the user name and password of a user account that is authorized to access the remote computer.
After you connect, you get a new icon for the remote computer under your Computer icon in the left pane of Registry Editor. Double-tap or double-click this icon to access the physical root keys on the remote computer (HKEY_LOCAL_MACHINE and HKEY_USERS). The logical root keys aren’t available because they are either dynamically created or are simply pointers to subsets of information from within HKEY_LOCAL_MACHINE and HKEY_USERS. You can then edit the computer’s registry as necessary. When you are done, you can select Disconnect Network Registry on the File menu and then choose the computer from which you want to disconnect. Registry Editor then closes the registry on the remote computer and breaks the connection.
When working with remote computers, you can also load or unload hives as discussed in “Loading and unloading hive files” later in this chapter. If you’re wondering why you would do this, the primary reason is to work with a specific hive, such as the hive that points to Diane Prescott’s user profile because she inadvertently changed the display mode to an invalid setting and can no longer access the computer locally. With her user profile data loaded, you could edit the registry to correct the problem and then save the changes so that she can once again log on to the system.
Sometimes you might find that it is necessary or useful to copy all or part of the registry to a file. For example, if you’ve installed a service or component that requires extensive configuration, you might want to use it on another computer without having to go through the whole configuration process again. Instead, you could install the service or component baseline on the new computer, export the application’s registry settings from the previous computer, copy them over to the other computer, and then import the registry settings so that the service or component is properly configured. Of course, this technique works only if the complete configuration of the service or component is stored in the registry, but you can probably see how useful being able to import and export registry data can be.
By using Registry Editor, it is easy to import and export registry data. This includes the entire registry, branches of data stemming from a particular root key, and individual subkeys and the values they contain. When you export data, you create a .reg file that contains the designated registry data. This registry file is a script that can then be loaded back into the registry of this or any other computer by importing it.
Note
Because the registry script is written as standard text, you can view it and, if necessary, modify it in any standard text editor. Be aware, however, that double-tapping or double-clicking the .reg file starts Registry Editor, which asks you whether you want to import the data into the registry. If you are concerned about this, save the data to a file with the .hiv extension because double-tapping or double-clicking files with this extension won’t start Registry Editor. You must manually import files with the .hiv extension (or you could just change the file extension to .reg when it is time to use the data).
To export registry data, press and hold or right-click the branch or key you want to export and then select Export. You can also press and hold or right-click the root node for the computer you are working with, such as Computer for a local computer, to export the entire registry. Either way, you’ll see the Export Registry File dialog box as shown in Figure 8-9. Use the Save In selection list to choose a save location for the .reg file and then type a file name. The Export Range panel shows you the selected branch within the registry that will be exported. You can change this as necessary or select All to export the entire registry. Then tap or click Save to create the .reg file.
Figure 8-9. Export registry data to a .reg file so that it can be saved and, if necessary, imported on this or another computer.
Importing registry data adds the contents of the registry script file to the registry of the computer you are working with, either creating new keys and values if they don’t already exist or overwriting keys and values if they do exist. You can import registry data in one of two ways. You can double-tap or double-click the .reg file, which starts Registry Editor and asks you whether you want to import the data, or you can select Import on the File menu and then use the Import Registry File dialog box to select and open the registry data file you want to import.
Just as you sometimes must import or export registry data, you sometimes need to work with individual hive files. The most common reason for doing this, as discussed previously, is when you must modify a user’s profile to correct an issue that prevents the user from accessing or using a system. Here, you would load the user’s Ntuser.dat file into Registry Editor and then make the necessary changes. Another reason for doing this is to change a particular part of the registry on a remote system. For example, if you need to repair an area of the registry, you could load the related hive file into the registry of another machine and then repair the problem on the remote machine.
Loading and unloading hives affects only HKEY_LOCAL_MACHINE and HKEY_USERS, and you can perform these actions only when you select one of these root keys. Rather than replacing the selected root key, the hive you are loading then becomes a subkey of that root key. HKEY_LOCAL_MACHINE and HKEY_USERS are, of course, used to build all the logical root keys used on a system, so you could work with any area of the registry.
After you select either HKEY_LOCAL_MACHINE or HKEY_USERS in Registry Editor, you can load a hive for the current machine or another machine by selecting Load Hive on the File menu. Registry Editor then prompts you for the location and name of the previously saved hive file. Select the file and then tap or click Open. Afterward, enter a name for the key under which you want the hive to reside while it is loaded into the current system’s registry and then tap or click OK.
Note
You can’t work with hive files that are already being used by the operating system or another process. You could, however, make a copy of the hive and then work with it. At the command line, type reg save followed by the abbreviated name of the root key to save and the file name to use for the hive file. For example, you could type reg save hkcu c:curr-hkcu.hiv to save HKEY_LOCAL_MACHINE to a file called Curr-hkcu.hiv on drive C. Although you can save the logical root keys (HKCC, HKCR, HKCU) in this manner, you can save only subkeys of HKLM and HKU by using this technique.
When you are finished working with a hive, you should unload it to clear it out of memory. Unloading the hive doesn’t save the changes you’ve made—as with any modifications to the registry, your changes are applied automatically without the need to save them. To unload a hive, select it and choose Unload Hive on the File menu. When prompted to confirm, tap or click Yes.
If you want to work with the registry from the command line, you can do so using the REG command. REG is run using the permissions of the current user and can be used to access the registry on both local and remote systems. As with Registry Editor, you can work only with HKEY_LOCAL_MACHINE and HKEY_USERS on remote computers. These keys are used, of course, to build all the logical root keys used on a system, so you can work with any area of the registry on a remote computer.
REG has different subcommands for performing various registry tasks. These commands include the following:
REG ADD. Adds a new subkey or value entry to the registry.
REG COMPARE. Compares registry subkeys or value entries.
REG COPY. Copies a registry entry to a specified key path on a local or remote system.
REG DELETE. Deletes a subkey or value entry from the registry.
REG EXPORT. Exports registry data and writes it to a file.
REG FLAGS. Sets or queries the flags on a registry key. Flags that can be associated with keys include DONT_VIRTUALIZE, DONT_SILENT_FAIL, and RECURSE_FLAG.
REG IMPORT. Imports registry data and either creates new keys and value entries or overwrites existing keys and value entries.
REG LOAD. Loads a registry hive file.
REG QUERY. Lists the value entries under a key and the names of subkeys (if any).
REG RESTORE. Writes saved subkeys and entries back to the registry.
REG SAVE. Saves a copy of specified subkeys and value entries to a file.
REG UNLOAD. Unloads a registry hive file.
You can learn the syntax for using each of these commands by typing reg followed by the name of the subcommand you want to learn about and then /?. For example, if you want to learn more about REG ADD, you type reg add /? at the command line.
By now, it should be clear how important the registry is and that it should be protected. I’ll go so far as to say that part of every backup and recovery plan should include the registry. Backing up and restoring the registry usually isn’t done from within Registry Editor, however. It is handled through the Windows Server Backup utility or through your preferred third-party backup software. Either way, you have an effective means to minimize downtime and ensure that the system can be recovered if the registry becomes corrupted.
You can make a backup of the entire registry very easily at the command line. Just type regedit /e SaveFile, where SaveFile is the complete file path to the save location for the registry data. Following this, you could save a copy of the registry to C:BackupsRegdata.reg by typing regedit /e c:ackups egdata.reg. You would then have a complete backup of the registry.
You can also easily make backups of individual root keys. To do this, you use REG SAVE. Type reg save followed by the abbreviated name of the root key you want to save and the file name to use. For example, you could type reg save hkcu c:ackupshkcu.hiv to save HKEY_CURRENT_USER to a file in the C:Backups directory. Again, although you can save the logical root keys (HKCC, HKCR, HKCU) in this manner, you can save only subkeys of HKLM and HKU by using this technique.
Okay, so now you have your fast and easy backups of registry data. What you do not have, however, is a sure way to recover a system if the registry becomes corrupted and the system cannot be booted. Partly, this is because you have no way to boot the system to get at the registry data.
You create a system state backup to help you recover the registry and get a system to a bootable state. The system state backup includes essential system files needed to recover the local system and registry data. All computers have system state data, which must be backed up in addition to other files to restore a complete working system.
Normally, you back up the system state data when you perform a normal (full) backup of the rest of the data on the system. Thus, if you are performing a full recovery of a server rather than a repair, you use the complete system backup and system state data to recover the server completely.
That said, you can create separate system state backups. The fastest and easiest way to do so is to use Wbadmin, the command-line counterpart to Windows Server Backup. You create a system state backup using Wbadmin by entering the following command at an elevated command prompt:
wbadmin start systemstatebackup –backuptarget:StorageDrive
Here, StorageDrive is the drive letter for the storage location, such as:
wbadmin start systemstatebackup –backuptarget:d:The registry is a database, and like any other database, it works best when it is optimized. Optimize the registry by reducing the amount of clutter and information it contains. This means uninstalling unnecessary system components, services, and applications. One way to uninstall components, services, and applications is to use the Uninstall Or Change A Program utility in Control Panel. This utility allows you to remove Windows components and their related services safely in addition to applications installed using the Windows Installer. In Control Panel, tap or click the Uninstall A Program link under the Programs heading to access the Uninstall Or Change A Program utility.
Most applications include uninstall utilities that attempt to remove the application, its data, and its registry settings both safely and effectively. Sometimes, however, applications either do not include an uninstall utility or, for one reason or another, do not fully remove their registry settings. This is where registry maintenance utilities come in handy.
At the Microsoft Download Center on the web, you’ll find a download package for the Microsoft Fix It Portable. This download package includes several files and a helper application designed to be installed on removable media so that you can easily use Fix It Portable on any computer that has a problem. Learn more about this program and get the downloadable executable at http://support.microsoft.com/mats/Program_Install_and_Uninstall/. At the Microsoft website, instead of choosing Run Now, click the advanced options and then click the download option to save the executable file. After downloading, run the executable file and follow the prompts to create the Fix It Portable folder. Then copy this folder to the computer with a problem and run the Launch Fix It application.
In addition to being able to clear out registry settings for programs you’ve installed and then uninstalled, you can use this utility to recover the registry to the state it was in prior to a failed or inadvertently terminated application installation. This works as long as the application used the Windows Installer.
Note
Fix It Portable replaces the Windows Installer Clean Up Utility and Windows Installer Zapper. The program requires Windows PowerShell and the Microsoft .NET Framework 3.5 to be installed. Fix It Portable uses the Windows Diagnostics and Troubleshooting framework to resolve problems.
Fix It Portable can remove registry settings for applications that were installed using the Windows Installer. It is most useful for cleaning up registry remnants of applications that were partially uninstalled or for which uninstall failed. It is also useful for cleaning up applications that can’t be uninstalled or reinstalled because of partial or damaged settings in the registry. It isn’t, however, intended to be used as an uninstaller. Use it when the normal uninstallation process fails.
Note
Keep in mind that the profile of the current user is part of the registry. Because of this, Fix It Portable will remove user-specific installation data from this profile. It won’t, however, remove this information from other profiles.
To use Microsoft Fix It to uninstall and clean up a program, complete the following steps:
If you’ve already run the installer package for Microsoft Fix It, you can start this utility by running the Launch Fix It executable. The utility can run from removable media.
Locate the Fix Problems With Programs That Can’t Be Installed Or Uninstalled troubleshooter and then click the related Run Now option.
When the troubleshooter starts, select the option that enables you to select the fixes to apply.
Next, specify that you are having a problem uninstalling a program. Windows will then diagnose the problem by checking the update information in the registry.
Select the program you want to uninstall from a list of installed programs and then click Next.
When asked whether you want to uninstall and clean up, click Yes, Try Uninstall. At the end of the uninstall process, you can view and save a troubleshooting report.
Application installations can fail during installation or after installation. When applications are being installed, an InProgress key is created in the registry under the HKLMSOFTWAREMicrosoftWindowsCurrentVersionInstaller subkey. If installation fails, the system might not be able to edit or remove this key, which could cause the application’s setup program to fail the next time you try to run it. Running the Program Install And Uninstall Troubleshooter for Microsoft Fix It clears out the InProgress key, which should enable you to run the application’s setup program.
After installation, applications rely on their registry settings to configure themselves properly. If these settings become damaged or the installation becomes damaged, the application won’t run. Some programs have a repair utility that can be accessed just by rerunning the installation. During the repair process, the Windows Installer might attempt to write changes to the registry to repair the installation or roll it back to get back to the original state. If this process fails for any reason, the registry can contain unwanted settings for the application. Running the Program Install And Uninstall Troubleshooter for Microsoft Fix It also clears out the rollback data for the active installation. Rollback data is stored in the HKLMSOFTWAREMicrosoftWindowsCurrentVersionInstallerRollback key.
Any running installation also has rollback data.
When an application can’t be successfully uninstalled, you can attempt to clean up its settings from the registry by using the Program Install And Uninstall Troubleshooter for Microsoft Fix It. Because the current user’s profile is part of the registry, user-specific settings for the application will be removed from this profile.
The registry is a critical area of the operating system. It has some limited built-in security to reduce the risk of settings being inadvertently changed or deleted. In addition, some areas of the registry are available only to certain users. For example, HKLMSAM and HKLMSECURITY are available only to the LocalSystem user. This security, in some cases, might not be enough, however, to prevent unauthorized access to the registry. Because of this, you might want to set tighter access controls than the default permissions, and you can do this from within the registry. You can also control remote access to the registry and configure access auditing.
One of the best ways to protect the registry from unauthorized access is to prevent user access to the registry in the first place. For a server, this means tightly controlling physical security and allowing only administrators the right to log on locally. For other systems or when it isn’t practical to prevent users from logging on locally to a server, you can configure the permissions on Regedit.exe and Reg.exe so that they are more secure. You could also remove Registry Editor and the REG command from a system, but this can introduce other problems and make managing the system more difficult, especially if you also prevent remote access to the registry.
To modify permissions on Registry Editor, access the %SystemRoot% folder, press and hold or right-click Regedit.exe, and then select Properties. In the Regedit Properties dialog box, tap or click the Security tab, as shown in Figure 8-10. Add and remove users and groups as necessary and then set permissions as appropriate. Permissions work the same as with other types of files. You select an object and then allow or deny specific permissions. See Chapter 19 for details.
To modify permissions on the REG command, access the %SystemRoot%System32 folder, press and hold or right-click Reg.exe, and then select Properties. In the Reg Properties dialog box, tap or click the Security tab. As Figure 8-11 shows, users and administrators can use this command by default. Add and remove users and groups as necessary and then set permissions as appropriate.
Keys within the registry also have access permissions. Rather than editing these permissions directly, I recommend you use an appropriate security template. Using the right security template locks down access to the registry for you, and you won’t have to worry about making inadvertent changes that will prevent systems from booting or applications from running.
That said, in some limited situations, you might want to or have to change permissions on individual keys in the registry. To do this, start Registry Editor and then navigate to the key you want to work with. When you find the key, press and hold or right-click it; select Permissions or select the key and then choose Permissions on the Edit menu. This opens a Permissions For dialog box similar to the one shown in Figure 8-12. Permissions work the same as for files. You can add and remove users and groups as necessary. You can select an object and then allow or deny specific permissions.
Many permissions are inherited from higher-level keys and are unavailable. To edit these permissions, you must open the Advanced Security Settings dialog box by tapping or clicking the Advanced button. As Figure 8-13 shows, the Advanced Security Settings For dialog box shows the current owner of the selected key and enables you to reassign ownership. By default, when you reassign ownership, only the selected key is affected, but if you want the change to apply to all subkeys of the currently selected key, choose Replace Owner On Subcontainers And Objects.
Caution
Be sure you understand the implications of taking ownership of registry keys. Changing ownership could inadvertently prevent the operating system or other users from running applications, services, or application components.
Figure 8-13. Use the Advanced Security Settings For dialog box to change the way permissions are inherited or set and to view auditing settings, ownership, and effective permissions.
The dialog box also has three tabs:
Permissions. The Inherited From column on the Permissions tab shows where the permissions are inherited from. Usually, this is the root key for the key branch you are working with, such as CURRENT_USER. You can use the Add and Edit buttons on the Permissions tab to set access permissions for individual users and groups. Table 8-3 shows the individual permissions you can assign.
Auditing. Enables you to configure auditing for the selected key. The actions you can audit are the same as the permissions listed in Table 8-3. See the Registry root keys section earlier in this chapter.
Effective Access. Shows you which permissions would be given to a particular user or group based on the current settings. This is helpful because permission changes you make in the Permissions tab aren’t applied until you tap or click OK or Apply.
Table 8-3. Registry permissions and their meanings
Permission | Meaning |
|---|---|
Allows user or group to perform any of the actions related to any other permission | |
Query Value | Allows querying the registry for a subkey value |
Set Value | Allows creating new values or modifying existing values below the specified key |
Create Subkey | Allows creating a new subkey below the specified key |
Enumerate Subkeys | Allows getting a list of all subkeys of a particular key |
Notify | Allows registering a callback function that is triggered when the selected value changes |
Create Link | Allows creating a link to a specified key |
Delete | Allows deleting a key or value |
Write DAC | Allows writing access controls on the specified key |
Write Owner | Allows taking ownership of the specified key |
Read Control | Allows reading the discretionary access control list (DACL) for the specified key |
Hackers and unauthorized users can attempt to access a system’s registry remotely just as you do. If you want to be sure they are kept out of the registry, you can prevent remote registry access. One way that remote access to a system’s registry can be controlled is through the registry key, HKLMSYSTEMCurrentControlSetControlSecurePipeServersWinreg. If you want to limit remote access to the registry, you can start by changing the permissions on this key.
If this key exists, the following occurs:
Windows Server 2012 R2 uses the permissions on the key to determine who can access the registry remotely, and by default, any authenticated user can do so. In fact, authenticated users have Query Value, Enumerate Subkeys, Notify, and Read Control permissions on this key.
Windows Server 2012 R2 then uses the permissions on the keys to determine access to individual keys.
If this key doesn’t exist, Windows Server 2012 R2 allows all users to access the registry remotely and uses the permissions on the keys only to determine which keys can be accessed.
Windows Vista and later Windows versions disable remote access to all registry paths by default. As a result, the only registry paths remotely accessible are those explicitly permitted as part of the default configuration or by an administrator. In Local Security Policy, you can use Security Options to enable or disable remote registry access. With Windows Vista and later Windows versions, the following additional security settings are provided for this purpose:
Network Access: Remotely Accessible Registry Paths
Network Access: Remotely Accessible Registry Paths And Subpaths
These security settings determine which registry paths and subpaths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the Winreg registry key. A number of default paths are set, and you should not modify these default paths without carefully considering the damage that changing this setting might cause.
You can follow these steps to access and modify these settings in the Local Security Settings console:
Open Local Security Policy. If you enabled Show Administrative Tools as a Start setting, you see a related tile on the Start screen. Another way to do this is by pressing the Windows key, typing secpol.msc into the Apps Search box, and then pressing Enter.
Expand the Local Policies node in the left pane and then select the Security Options node.
In the main pane, you should now see a list of policy settings. Scroll down through the list of security settings. As appropriate, double-tap or double-click Network Access: Remotely Accessible Registry Paths or Network Access: Remotely Accessible Registry Paths And Subpaths.
On the Local Policy Setting tab of the Properties dialog box, you see a list of remotely accessible registry paths or a list of remotely accessible registry paths and subpaths, depending on which security setting you are working with. You can now add or remove paths or subpaths as necessary. Note that the default settings are listed on the Explain tab.
Note
Windows Server 2012 R2 has an actual service called the Remote Registry service. This service does, in fact, control remote access to the registry. You want to disable this service only if you are trying to protect isolated systems from unauthorized access, such as when the system is in a perimeter network and is accessible from the Internet. If you disable the Remote Registry service before starting the Routing And Remote Access service, you cannot view or change the Routing And Remote Access configuration. Routing And Remote Access reads and writes configuration information to the registry, and any action that requires access to configuration information could cause Routing And Remote Access to stop functioning. To resolve this, stop the Routing And Remote Access service, start the Remote Registry service, and then restart the Routing And Remote Access service.
Access to the registry can be audited, as can access to files and other areas of the operating system. Auditing enables you to track which users access the registry and what they’re doing. All the permissions listed in Table 8-3 can be audited. However, you usually limit what you audit to only the essentials to reduce the amount of data that is written to the security logs and the resource burden on the affected server.
Before you can enable auditing of the registry, you must enable the auditing function on the system you are working with. You can do this either through the server’s local policy or through the appropriate Group Policy Object (GPO). The policy that controls auditing is Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy. For more information on auditing, see Chapter 19.
After auditing is enabled for a system, you can configure how you want auditing to work for the registry. This means configuring auditing for each key you want to track. Thanks to inheritance, this doesn’t mean you have to go through every key in the registry and enable auditing for it. Instead, you can select a root key or any subkey to designate the start of the branch for which you want to track access and then ensure that the auditing settings are inherited for all subkeys below it. (This is the default setting.)
Say, for example, you want to audit access to HKLMSAM and its subkeys. To do this, you follow these steps:
After you locate the key in Registry Editor, press and hold or right-click it and select Permissions or select the key and then choose Permissions on the Edit menu. This opens the Permissions For SAM dialog box.
In the Permissions For SAM dialog box, tap or click the Advanced button.
In the Advanced Security Settings dialog box, tap or click the Auditing tab.
Tap or click Add to open the Auditing Entry For SAM dialog box. Click Select A Principal to open the Select User Or Group dialog box.
Type the name of a user or a group account. Be sure to reference the user account name rather than the user’s full name. Only one name can be entered at a time.
Tap or click Check Names. If a single match is found for each entry, the dialog box is automatically updated and the entry is underlined. Otherwise, you’ll see an additional dialog box. If no matches are found, you’ve either entered the name incorrectly or you’re working with an incorrect location. Modify the name in the Name Not Found dialog box and try again or tap or click Locations to select a new location. When multiple matches are found, in the Multiple Names Found dialog box, select the name or names you want to use and then tap or click OK.
Tap or click OK. The user or group is added as Principal, and the Auditing Entry For dialog box is updated to show this. Only basic permissions are listed by default. Click Show Advanced Permissions to display the special permissions, as shown in Figure 8-14.
Use the Applies To list to specify how the auditing entry is to be applied. The options include the following:
This Key Only. The auditing entries apply only to the currently selected key.
This Key And Subkeys. The auditing entries apply to this key and any subkeys of this key.
Subkeys Only. The auditing entries apply to any subkeys of this key but not to the key itself.
Use the Type list to specify whether you are configuring auditing for successful access, failed access, or both and then specify which actions should be audited. The events you can audit are the same as the special permissions listed in Table 8-3.
Repeat steps 4 through 9 to configure auditing for other users or groups.
The auditing entries are applied to subkeys by default through inheritance. If you want to replace the auditing entries on all child objects of this key with this key’s auditing entries, select Replace All Child Object Auditing Entries With Inheritable Auditing Entries From This Object.
Tap or click OK twice.
