Architecture of Windows Group Policy for Windows Server 2008 and Windows Vista

Like most technology, Group Policy is very logical and predictable. The structure of Group Policy has not changed much over the years, although some of the internal mechanisms have. Because Group Policy is such a stable and reliable technology, there has been no need for major changes.

With that said, there have been some radical changes to the underlying implementation of Group Policy with Windows Vista and Windows Server 2008. Although the core dependencies have not changed, the core engine of Group Policy has changed for the better. There is now a dedicated service for Group Policy, which gives Group Policy even more stability and efficiency.

Administration of your domain-based GPOs has not changed, either. The Group Policy Object Editor is now called the Group Policy Management Editor (GPME), but its functions and those of the Group Policy Management Console (GPMC) remain the same. The core architecture for updating domain-basedGPOs is important to understand and manage, as it has always been.

Understanding the storage of Group Policy in terms of the Group Policy template (GPT) and the Group Policy container (GPC) is critical to efficient management of the GPOs, ADM files, replication, and troubleshooting. Of course, the biggest change that Windows Vista and Windows Server 2008 offer with regard to architecture is the addition of ADMX templates and the central repository.

An architecture overview cannot be complete without a rigorous discussion on replication. Replication for Group Policy is not simple, but a good summary of the subject will help you tackle most problems that arise. Replication and Group Policy are important concepts to understand when you need to troubleshoot an issue.

Finally, this chapter will review the architecture of client-side extensions (CSEs). CSEs are the soul of Group Policy settings. You will get an inside glimpse into the different CSEs, what they do, and how they function with the information provided by the GPT and the GPC.

Group Policy Dependencies

Although Group Policy is a large and complicated service and technology, it also relies heavily on other complicated services and technologies. You must understand these other services and technologies to fully understand Group Policy, especially when you encounter trouble. Understanding Group Policy’s dependencies will help you pinpoint the source of the problem, whether it be Group Policy or one of these services.

The services and technologies that Group Policy has direct dependencies on include the following:

• Active Directory

• Domain Name System (DNS)

• Active Directory replication

• Distributed File System Replication (DFSR)–formerly File Replication Service (FRS)

• DFS publishing

• Network Location Awareness (NLA)

As you can see from the preceding list, the services and technologies that Group Policy depends on are extremely important, not only to Group Policy, but to your network as a whole. Without these services and technologies, you would not have a fully functional enterprise.

Each of these services and technologies is responsible for a specific aspect of Group Policy. Understanding how each component fits into the bigger picture will help you with design, implementation, management, and troubleshooting of Group Policy.

Active Directory and Group Policy

Active Directory has the biggest role as a dependent technology with Group Policy. Most certainly, without Active Directory you would not have much of a Group Policy infrastructure to work with. Active Directory provides the foundation upon which Group Policy is embedded.

First, consider that Active Directory houses all of the user and computer objects for the domain or domains. It is these user and computer objects that Group Policy controls. Next, Active Directory creates the structure that the objects are placed within. The structure is made up of organizational units. The design of the organizational units is essential in the deployment of Group Policy–the user and computer objects located within the organizational unit where the GPO is linked, as well as those in child organizational units, are affected by the settings in the linked GPO by default.

IMPORTANT

A poorly designed Active Directory structure can make it very difficult to deploy Group Policy. It is always best to design Group Policy deployment into the initial Active Directory design. If the Active Directory design is too chaotic or disorganized, it might need to be completely redesigned before Group Policy can be correctly deployed.

A well designed Active Directory structure considers the user and computer object location within the organizational units. Because GPOs are linked primarily to organizational units, ensuring that the links are easy and efficient will help with the overall success and good design of Active Directory.

NOTE

Active Directory should be designed to incorporate two important components: Group Policy and delegation of administration should be the two driving factors for your Active Directory design. As a best practice, delegation of administration should have the highest priority, because Group Policy can be filtered to apply to only certain objects in an organization unit.

GPOs can be linked to three Active Directory components. These include the domain, organization units, and sites. If Active Directory did not contain these components, GPOs would not be able to link to them.

As a side benefit, Active Directory allows for single sign-on for user accounts, which Group Policy can leverage because each user is unique within the Active Directory domain. Because each user is unique, administrators can mold and deploy the precise security settings, desktop settings, registry values, and profile environment for each user.

NOTE

Local Group Policy objects can still be used without Active Directory, in a small business or home office environment, for example. In such cases, the Local Group Policy objects must be administered on each computer separately.

Domain Name System

You probably already know what the Domain Name System (DNS) is, but as a reminder, DNS is a distributed database that resolves DNS host names to Internet Protocol (IP) addresses. In Active Directory, DNS is the locator service that enables computers to find other computers, as well as important networking services.

For Active Directory networks, DNS has entries called Service Resource Records (SRVs) that are associated with different networking services. These include entries for Lightweight Directory Access Protocol (LDAP), Transmission Control Protocol (TCP), and Kerberos. These SRVs help computers in the Active Directory domain find the servers that are functioning as domain controllers. At a domain controller, they might get a listing of Group Policy Objects, update their Kerberos ticket, find a resource, and so on. When DNS is not working properly or is misconfigured, computers will not be able to use DNS to find this information. At this point, Group Policy will fail to work properly; all updates and refreshes will cease until DNS is functioning properly again.

DNS is also used for Distributed File System (DFS). DFS can be used within Group Policy to share applications or other resources. When a GPO is configured to direct a desktop or user to a DFS distribution point for accessing software, the computer must use DNS to find these installation points. If DNS is not configured properly, the computer will never find the DFS distribution point and the software will not be installed or updated.

Finally, DNS is important for managing Group Policy. As you will see later in this chapter, domain controllers are the computers that store GPOs. Therefore, when you are managing a GPO, a domain controller must be contacted. If DNS is not functioning properly, a domain controller cannot be found and an error will occur when trying to update or view a GPO.

Replication

One of the more significant tasks of Group Policy is to ensure that each GPO is synchronized with each domain controller. Domain controllers are the command center of GPO distribution. As you will see a little later in this chapter, a GPO is not just a single entity. It is really made up of two separate parts: the Group Policy template (GPT), which is stored in the SYSVOL of each domain controller, and the Group Policy container (GPC), which is stored in Active Directory, again on each domain controller.

Both portions of the GPO must be replicated to every domain controller within the domain. If the GPOs do not synchronize to all domain controllers after a change is made, strange behavior will occur. This behavior might include differing settings on two desktops that should have the same settings, errant settings on a server caused by a missing GPO setting, failure to apply policy altogether, or a desktop that is not secure because of a failure of the GPO to replicate.

As you can see, replication is a significant factor for Group Policy. There is a small concern with Group Policy replication, however. The GPO is made up of two different parts, but the SYSVOL replication and the Active Directory replication are not driven or supported by the same replication technology.

SYSVOL replication is controlled by either the Distributed File System Replication (DFSR) or the File Replication Service (FRS), depending on the domain functional level. Domain controllers running Windows 2000 or Microsoft Windows Server 2003 cannot take advantage of DFSR for replication of the SYSVOL, so they must still use FRS. Windows Server 2008 does support DFSR for SYSVOL replication, but all domain controllers must be running Windows Server 2008 to take advantage of this new technology. If any domain controllers in the domain are running Windows 2000 or Windows Server 2003, the Windows Server 2008 domain controllers must also use FRS to support the limitations of the older operating systems.

Active Directory replication is not controlled by DFSR or FRS. Instead, Active Directory replication is controlled by its own replication service. Active Directory replication is responsible for replicating the entire Active Directory database, not just the GPC. Because changes occur with the other objects in the database more than the GPC, the technology and details of replication were designed for those other objects more so than for Group Policy. With this said, the replication of Active Directory is quite complex, with many moving parts and considerations. Later in this chapter, an in-depth overview of Active Directory replication will explain how it affects and controls the GPC.

DFS

Another service that Group Policy depends on is DFS. You might miss this service unless you consider how DFS assists Group Policy in many different areas. If you think that DFS publishing can assist Group Policy when software is delivered through a GPO, you are correct. However, Group Policy does not depend on this service in this regard–DFS is simply an enabling service in this scenario.

So, how exactly does DFS function with Group Policy as a dependant service? DFS is the service that makes the SYSVOL on the domain controllers available. Every domain controller has the SYSVOL shared. There are two folders named SYSVOL, and only one of them is shared. The path to the shared SYSVOL is C:\Windows\SYSVOL\Sysvol.

This share is not a routine share. Rather, it is a domain-based DFS share. This type of share is very useful in situations in which all computers in the domain need to access the same resource. If you are not familiar with domain-based DFS, it has some significant advantages.

With domain-based DFS shares, all computers access the share by using the domain name, instead of the domain controller’s NetBIOS computer name or DNS fully qualified domain name (FQDN). Therefore, all computers that communicate with SYSVOL on the domain controllers (every computer in the domain) do so by using \\domainname\sysvol.

Although this might seem simplistic and limited in rewards, the power is in the technology behind the scenes. With this form of communication to the domain controller and SYSVOL, the names of the domain controllers are irrelevant. Domain controllers can be added, removed, changed, taken offline, brought back online, and so on without the existing connections and mapped drives. As long as there is at least one domain controller online for the computers to access, the computers on the network will be able to communicate with the domain-based DFS share.

This is possible because domain-based DFS shares are accessed through DNS. SRV records that help the computer find the nearest domain controller are automatically registered in DNS. The nearest domain controller is relative, because DNS uses Active Directory sites, which represent physical networks. When a computer receives a list of domain controllers from DNS, the domain controllers in the computers’ sites are listed first, followed by the other domain controllers.

This process and technology allows computers to receive the GPT information for the GPOs from the domain controllers. The process is very efficient for both keeping track of the domain controllers and allowing the computers on the network to find the closest domain controller to retrieve the Group Policy information from SYSVOL.