Windows Server 2008: DHCP/WINS/Domain Controllers - Exploring Global Catalog Domain Controller Placement

2/21/2011 9:05:04 AM
The placement of domain controllers in Windows Server 2008 R2 is a critical factor in providing quality communication between Active Directory clients and domain controllers. Without prompt response from a domain controller, a user might have to wait several seconds to several minutes to merely log on to the network or a computer to complete booting up.

Understanding the Role of the Active Directory Global Catalog

The global catalog in Active Directory holds an indexed subset of frequently queried or accessed objects in an Active Directory forest. Not all domain controllers in the Windows Server 2008 R2 Active Directory are global catalog servers by default. That being said, when installing a new Windows Server 2008 R2 forest, the first Windows Server 2008 R2 domain controller in the forest will be configured as a global catalog server because this is a necessary service for Active Directory to function properly. Also, the DCPROMO Wizard on Windows Server 2008 R2 defaults to deploy all domain controllers as global catalog servers. Domain controllers that are not global catalog servers can be established as such through the following procedure:

Open Active Directory Sites and Services by clicking Start, All Programs, Administrative Tools, Active Directory Sites and Services.

In the console tree, click the server to which you want to add the global catalog. Do this by navigating to Sites\<SiteName>\Servers\<ServerName>. Select the desired server in the console or tree pane.

In the Details pane, right-click NTDS Settings node of the selected server, and then click Properties.

Select the Global Catalog check box on the General tab.

Click OK to finish.


To complete this process, the administrator must be a member of the Enterprise Admins group in the forest or a member of the Domain Admins group in the domain of the selected domain controller or equivalent permissions. Security best practices dictate that this process be performed with the lowest-level user account and using the Run As Administrator option to manage Active Directory Domain Services.

Placing Global Catalog/Domain Controllers

It is important to understand that global catalog objects must be physically located close to all objects in a network that require prompt logon times and fast connectivity. Because a global catalog entry is parsed for universal group membership every time a user logs on, this effectively means that this information must be close at hand. This can be accomplished by placing global catalog and domain controller (GC/DC) servers on the same WAN site or by using a process called universal group caching.

Exploring Universal Group Caching

Universal group caching is a process by which an Active Directory site caches all universal group membership locally so that the next time clients log on, information is more quickly provided to the clients and they are able to log on faster.

Universal group caching can be more effective than placing a GC/DC server locally because only those universal groups that are relevant to a local site’s members are replicated and are cached on the local domain controller. The downside to this approach, however, is that the first logon for clients will still be longer than if a local GC/DC were provided, and the cache eventually expires, requiring another sync with a GC/DC.

Examining Global Catalog and Domain Controller Placement

As illustrated in the preceding sections, decisions must be made regarding the most efficient placement of DCs and GC/DCs in an environment. Determining the placement of GC/DCs and universal group caching sites must be done with an eye toward determining how important fast logons are for users in a site compared with higher replication throughput. For many Windows Server 2008 R2 environments, the following guidelines apply:

  • Sites with fewer than 50 users— Use a single DC configured with universal group caching.

  • Sites with 50–100 users— Use two DCs configured for universal group caching.

  • Sites with 100–200 users— Use a single GC server and single DC server.

  • Sites with 200+ users— Alternate adding additional DCs and GC/DCs for every 100 users.

The recommendations listed here are generalized and should not be construed as relevant to every environment. Some scenarios might call for variations to these approaches, such as when using Microsoft Exchange Server in a site where Exchange requires close connection to a global catalog server (not a caching controller) or in single domain/single forest environments with limited sites where all domain controllers can be global catalog servers. However, these general guidelines can help to size an Active Directory environment for domain controller placement.

Examining Read-Only Domain Controllers

A concept similar to universal group caching, one of the new features for Active Directory Domain Services in Windows Server 2008 and Windows Server 2008 R2 is the Read-Only Domain Controller (RODC). An RODC server is a new type of domain controller that contains read-only replicas of the domain Active Directory database. As shown in Figure 1, this is well suited for branch offices or other locations where physical security of the domain controller can be compromised, where excessive wide area networking activity might have a negative impact on productivity, or where other applications must run on a domain controller and be maintained by an understaffed technical department or an IT department with little technical knowledge. The benefits of RODCs are a read-only Active Directory Domain Services database, inbound-only replication, credential caching, administrator role separation, and read-only DNS.

Figure 1. Sample deployment of a Read-Only Domain Controller in a Windows Server 2008 R2 environment.

Although an RODC can replicate data from domain controllers running Windows Server 2003, it can only replicate updates of the domain partition from a Windows Server 2008 or Windows Server 2008 R2 domain controller running within the same domain. Because RODCs cannot perform outbound replication, they cannot be a source domain controller for any other domain controller. In contrast, writable Windows Server 2008 R2 domain controllers and Windows Server 2008 domain controllers can perform inbound and outbound replication of all available partitions. Thus, they do not require the same placement considerations required by RODCs.

Because an RODC can replicate the domain partition only from a writable Windows Server 2008 R2 or Windows Server 2008 domain controller, careful planning is required. The placement of an RODC and writable Windows Server 2008 R2 domain controllers is important as their deployment might be affected by the site topology and network constraints; each RODC requires a writable Windows Server 2008 R2 domain controller for the same domain from which the RODC directly replicates. This requires a writable Windows Server 2008 R2 domain controller be placed in the nearest site that contains a direct site link to the site in the topology that includes the RODC, as illustrated in Figure 11.22.

An RODC server contains the same objects and attributes as a writable domain controller with the exception of user passwords. The difference between an RODC server and the writable domain controller is that changes that originate locally are not made to the RODC replica itself but are forwarded to a writable domain controller and then replicated back to the RODC server. Also, the Active Directory administrator can determine or limit which user account password or credentials can be cached on a remote RODC. This improves security by reducing the risk or exposure of the read-only Active Directory database on the RODC.

Active Directory administrators might also specifically configure an RODC to cache user credentials. The first time a user attempts to authenticate to an RODC, the RODC forwards the request to a writable domain controller. When authentication is successful, the RODC requests a copy of the user credentials. By default, the RODC does not cache the passwords of any domain users so administrators must modify the default password replication policy for the RODC to allow the RODC to authenticate users and their computers when the WAN link to the hub site is unavailable. The active Password Replication Policy determines if the credentials are allowed to be replicated and cached on the RODC. The next time that user attempts to log on, the request is directly serviced by the RODC. This occurs until the RODC is informed by the writable domain controller that a user credential change has occurred. In the scenario, end-user productivity is vastly improved because of the efficient logon process. Connectivity issues commonly experienced by branch offices such as poor network bandwidth or WAN latency are mitigated because the user is authenticated on the locally deployed RODC. Because the RODC only performs inbound replication, network traffic is also reduced. To allow a user account’s password to be cached on a Read-Only Domain Controller, the user will need to be added to the default “Allowed RODC Password Replication Group” or the user can be added specifically to the Password Replication Policy on the specific Read-Only Domain Controllers.

RODCs also help reduce security risks and administration tasks associated with branch office servers. Because Active Directory Domain Services also manages a list of all credentials stored on RODCs, if an RODC is compromised, administrators can force a password reset for all user credentials stored on that RODC. To further mitigate security risks, RODCs cannot operate as an operation role holder (Flexible Single Master Operations [FSMO]) because this role requires writing of information to the Active Directory database. Also, RODCs cannot act as a bridgehead server because bridgehead servers are designed to replicate changes from other sites.

Another feature of RODCs is delegation of installation and management task to non-administrative personnel at a branch office. Nontechnical branch office personnel can perform an installation by attaching a server to the RODC account that a domain administrator has previously created. This eliminates the need to use a home office staging site for branch office domain controllers. This feature also eliminates the need to send installation media and a domain administrator to branch locations, which reduces the cost of server setup and improves setup time at branch locations.

  •  Windows Server 2008: DHCP/WINS/Domain Controllers - Planning, Migrating, and Maintaining WINS
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Installing and Configuring WINS
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Reviewing the Windows Internet Naming Service (WINS)
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Securing DHCP
  •  Windows 7 : General Maintenance Tools (part 3) - Checking Your Disks for Errors & Optimizing Disk Performance
  •  Windows 7 : General Maintenance Tools (part 2) - Cleaning Up Your Disk Drives
  •  Windows 7 : General Maintenance Tools (part 1) - Updating Your Computer
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Exploring Advanced DHCP Concepts
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Implementing Redundant DHCP Services
  •  Windows Server 2008 : DHCP/WINS/Domain Controllers - Enhancing DHCP Reliability
    Video tutorials
    - How To Install Windows 8

    - How To Install Windows Server 2012

    - How To Install Windows Server 2012 On VirtualBox

    - How To Disable Windows 8 Metro UI

    - How To Install Windows Store Apps From Windows 8 Classic Desktop

    - How To Disable Windows Update in Windows 8

    - How To Disable Windows 8 Metro UI

    - How To Add Widgets To Windows 8 Lock Screen

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
    programming4us programming4us