Chapter 11: Active Directory Settings in the Registry

Overview

Nature, it seems, is the popular name for milliards and milliards and milliards of particles playing their infinite game of billiards and billiards and billiards.

--Piet Hein
Grooks. Atomiriades

Nature, in general, and contemporary computing technologies, in particular, are extremely complex. When you dive into the details, your corporate network - comprising hundreds of servers and thousands of client workstations with their individual configurations - will seem like "milliards and milliards and milliards of particles". These particles can take on lives of their own, interacting with one another (sometimes in unpredictable ways) as if playing an infinite game of "billiards and billiards and billiards". This can drive to despair even the most dedicated and qualified system administrator! As outlined in Chapter 1, the introduction of the system registry was mainly intended to eliminate this administrative nightmare. The registry concept was an attempt to improve system manageability from a single source - the registry database, which provides a foundation for all system-wide hardware and software parameters and all custom user settings that exist in Windows. The registry's advantages and disadvantages were discussed in depth, and in the end, this approach proved successful. Today, the Windows-user community takes for granted the existence of the registry and its presence in all operating systems of the Windows family.

Gradually, however, it became evident that the registry alone is not sufficient. Although some difficulties were eliminated, other problems arose. New types of applications appeared, such as Enterprise Resource Planning (ERP), which required directory services to be implemented. For the moment, nearly every company has at least one directory service, and, in many cases, several directories of information. Traditional directory services were based on the X.500 standard for a hierarchical, extensible data store. Today, many other types of directories can be found that don't fit the X.500 model. In addition to ERP, typical directories within companies include network operating system (OS) directories such as Novell Directory Services (NDS) and Microsoft Windows NT 4.0's Security Account Manager (SAM) database.

As far back as 1996, Microsoft began asking its largest enterprise customers which improvements were most needed in the next release of its OS. It became evident that corporate clients had two urgent needs: implementation of the global directory service and reduction of the cost of managing and maintaining Windows NT desktops and servers in large enterprise environments.

To address these needs, Microsoft has implemented Active Directory (AD), a new global directory service that could be considered an extension of the machine-based registry. It is the most significant addition introduced with the release of Windows 2000 into the Windows NT product line. Perhaps most noticeably, AD replaces the SAM database as a repository for domain security principals, such as users and computers. But it does much more than that. Being an extensible, hierarchical directory service, AD provides a solid foundation for developing directory-enabled applications (i.e., applications that use the directory as a store and a source of information to facilitate many types of value-added computing).

Note 

As outlined in Chapter 9, although the SAM database has been replaced by the Active Directory (AD) database, it still retains its importance. First, the SAM database is now part of AD, and AD serves as a kind of "super-registry", storing all user and machine information as well as a host of other objects, including group policies and applications. Second, SAM continues to store local accounts, and, if your computer is running Windows 2000, Windows XP, or Windows Server 2003 and does not participate in a domain, the SAM database remains the main storage of the user- and group-account information. Among other things, it is important to note that the Directory Service Restore Mode Administrator password, which is separate from the Administrator password stored in Active Directory, resides in the local SAM (%SystemRoot%\System32\Config\SAM).

In Windows 2000 and Windows Server 2003 domains, AD now serves as a central repository of all types of user and machine information, as well as of all other objects, such as printers, shared volumes, group policies, and, of course, applications. So, what about the registry? Did it retain its importance? How does it fit within this new pattern? The best way to understand these new concepts is to think about the system registry as a non-replicated database present on any local machine running Windows NT/2000/XP or Windows Server 2003. Then, think of AD as a centralized, replicated registry extension, providing the following enhancements and advantages:

• New capabilities for managing domain users and client computers.

• Active Directory-based Group Policies that make it possible to create centralized security templates to control Registry security on all computers and devices in AD domains.

• Software installation features that allow the administrator to centrally manage application installations and thus manage how registry modifications are made to computers and users. Application deployment through the Windows Installer technology provides a new way of distributing registry changes to computers and users.

• The Class Store - a set of AD objects that acts like a centralized version of the HKEY_CLASSES_ROOT key of the local registry.

These new features come with some challenges. They directly affect the system registry and influence your ability to modify the registry or troubleshoot registry problems. In this chapter, I will concentrate on these new interrelationships, including AD features that help you modify and manage the local registry on a computer running Windows 2000/XP or Windows Server 2003.