Planning Active Directory for Branch Office

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 2 - Structural Planning for Branch Office Environments

This chapter outlines the planning considerations for deciding on the logical structure of your Microsoft® Windows® 2000 Active Directory™ service structure, including whether to partition your forest and your domain, as well as how to plan your sites. We also discuss the placement of domain controllers, global catalog servers, Operations Master roles, DNS servers and bridgehead servers. At the end of this chapter, you should understand when and why to partition your forest and your domain, and how to place the various servers in branches versus in the hub sites.

On This Page

Introduction Process Flowchart Structural Planning Domain Controller and Global Catalog Placement DNS Design Recommendations Determining the Number of Sites Summary

Introduction

This chapter focuses on the decision process necessary for deciding on a forest structure, domain structure, and site structure. We also discuss the implications those decisions have on the placement of domain controllers, global catalog servers, Domain Name System (DNS) servers, bridgehead servers and Operation Masters (sometimes called Flexible Single-Master Operations (FSMOs)).

Resource Requirements

Individuals from the following teams will be required to participate during this phase of the installation.

• Windows 2000 Active Directory Architecture

• Windows 2000 Active Directory Administration

• Infrastructure Administration

• Network Administration, to provide DNS and other network information

What You Will Need

You will need to have a thorough understanding of your corporate network, including the subnets used, the connections to central sites, the types of connection and their speeds. You will need a thorough understanding of the administrative hierarchy of your company with respect to delegation of IT tasks.

Job Aid 1 can be used to help you collect the information about your network.

In addition to information about information collected by using Job Aid 1, you will also need a tool like Visio which will enable you to graphically lay out your plan during the planning iterations you will go through.

What You Should Know

This document assumes that you have a basic understanding of Microsoft® Windows® 2000, Windows 2000 Active Directory™ service, and DNS. For more information, refer to the More Information section at the end of Chapter 1, "Overview of Planning Active Directory for Branch Office Environments."

Process Flowchart

Structural Planning

Structural planning consists of planning two elements of your Active Directory branch office environment, your forest partitioning and your domain partitioning.

Forest Partitioning

There are two reasons to partition your Active Directory environment into a forest: political/organizational/legal restrictions, and too many objects. While the first will frequently be a valid reason for partitioning, the second is unlikely.

Political/Organizational/Legal Restrictions

Many organizations have independent business units that cannot or do not want to agree on common schema and enterprise-wide resource management. In general, these organizations will deploy multiple forests. Managing two or more forests greatly increases your administration requirements and efforts and increases the requirements in a non-arithmetic way. You do not have the benefit of a single directory service without the use of a metadirectory, such as Microsoft Metadirectory Services. If a requirement for separate security boundaries exists within your corporate network, then there are two options:

• If the independent business units can acknowledge that there is no security isolation between domains in the forest and can agree on common operations and security guidelines, a single forest can be created. A central IT department can own the root domain and delegate child domains to the business units.

• If there is a requirement for security isolation between domains, or no agreements on common operations and security guidelines, then multiple forests have to be created. In many cases, regulatory requirements like banking laws enforce security isolation that can only be implemented through the use of multiple forests.

For more information on forest design guidelines, read "Design Considerations for Delegation of Administration in Active Directory" on https://www.microsoft.com/activedirectory.

Too Many Objects

It is unlikely that your organization will exceed the number of possible objects for one forest since, for all practical purposes, it is the amount of memory and disk space available that restricts the number of objects in a forest.

Domain Partitioning

The following table lists the advantages and disadvantages to creating more than one domain, which we refer to here as domain partitioning.

Advantages	Disadvantages
Defined security boundaries	Administrative overhead of managing a number of domains
Reduced domain controller database size	Increased global catalog size
Reduced File Replication System traffic	Moving users from one domain to another is more administrative effort than moving them from one Organizational Unit (OU) to another
Reduced domain network traffic due to fewer changes that need to be replicated	Increased GC replication due to increased numbers of domains
Group policies, security, and delegation only have to be defined once	Group policies, security, and delegation have to be defined in each domain

As previously mentioned, in certain circumstances, rather than having a single domain you may determine that you need more than one security boundary (for example, a part of your organization may require longer passwords).

The number of objects that you will have in your Active Directory environment may impact your domain partitioning decisions.

Impact of Using Multiple Domains on the Network

Partitioning your network into domains reduces the amount of data that is replicated during "DomainNamingContext" replication, but increases the amount of global catalog data that is replicated. Network traffic for object generation and object changes are reduced when using multiple domains. To assess how big the difference is, you need to distinguish between replication traffic for object creation and replication for object changes.

When objects are created in a multi-domain environment, a copy of each object is replicated to the other domain controllers in the same domain and to global catalog servers that are members of other domains in the same forest. To keep network traffic low, only a subset of the attributes are replicated to global catalog servers (global catalog servers that are domain controllers in the domain where the new object is created receive a full copy of the objects). As a rule of thumb, you can estimate that about 50% of the data of a domain naming context is replicated to global catalog servers in other domains. (For more information about Active Directory replication traffic, refer to the Microsoft Press book, "Building Enterprise Active Directory Services," from the "Notes from the Field" series.)

Object Creation

Assume a branch office deployment where 10,000 users are created and there are domain controllers in each branch. In the case where a single domain model is used, all 10,000 users are replicated over slow links to all branches. So the replication of 10,000 users is our baseline: 100% of single domain network traffic.

However, if five domains are created and the 10,000 users are distributed evenly across the five domains, if there are no global catalog servers located in the branch offices, only 2,000 users are replicated over the slow links to the branch office. This reduces the domain network traffic to 20% of the original scenario.

On the other hand, if five domains are created, and you deploy global catalog servers in the branch offices, the network traffic for 2,000 domain users (domain controller traffic) plus 8,000 users from other domains in the forest (global catalog traffic of the smaller attribute set) the traffic is reduced to 60% of its original single domain load: ((2000 out of 10000 users from the branch offices domain) = 20 %) + ((8000 out of 10000 users from the other four domains x 50%) = 40%) = 60%.

Object Change

The difference is even larger if you look at the replication traffic generated when objects are changed. Most object change operations are not replicated to the global catalog servers, for example, password changes and group memberships other then universal group memberships. (Exceptions are some attributes that do not change very often used by directory-enabled applications, such as Simple Mail Transfer Protocol (SMTP) addresses used by a messaging system.)

Consider an example of traffic caused by password changes where 100 users change their password on the same day, and all passwords are replicated to all branches over slow links. This results in network traffic of around 120 kilobytes (KB). (The formula for this calculation comes from Building Enterprise Active Directory Services book, page 161: "If P is the number of simultaneous password changes, the number of bytes replicated is: 943 x P + 29,345.") If the domain is split up into five domains, with the users evenly distributed, only 20 passwords are replicated to the domain controllers, which comes to approximately 45 KB. The existence of a global catalog in the branch plays no role here, because password changes are not replicated to global catalog servers.

While partitioning your branch office deployment into regional domains helps reduce network traffic, every new domain adds administration and configuration overhead. The disadvantages of having multiple domains are:

• Group policies have to be defined in all domains (duplication).

• Security and delegation settings do not flow between domains.

• Configuration and selection of bridgehead servers are more complex.

Overriding Planning Principle: Keep It Simple

To summarize, the overriding principle for all planning, "keep it simple", also applies to the structural plan for branch office deployments. The recommendation is to deploy a single domain if the wide area network (WAN) can support this. Should the WAN not be able to carry the load, as few domains as necessary should be used.

Another structural decision is the determination of the number of sites in the domain. By identifying sites, an administrator can control the pattern of replication traffic between domain controllers and between global catalog servers. To determine which subnets belong in which sites, you first need to identify the locations that will have servers acting as domain controllers, global catalog servers, and DNS servers.

Domain Controller and Global Catalog Placement

In branch office and other distributed environments the biggest issue is deciding where to put domain controllers and global catalog servers (GCs), and the resultant replication topology. The number of locations with domain controllers affects the planning and configuration needed. If this number is very high, (over 100), the administrator will have to configure the servers and connection objects by using scripts or third-party tools, rather than using the automated topology generation of the Knowledge Consistency Checker (KCC). Therefore determining where domain controllers have to be deployed and how many locations will have domain controllers is one of the first critical decisions in the planning process.

The number of users in a location and the services required are two factors in making this decision. Replication traffic, availability of a logon provider, and security issues are considerations which will usually result in placement of a domain controller in each branch. Under some circumstances discussed later a domain controller will not be placed in a branch, which may require additional configuration and administration.

Process Flowchart

Security Issues

Every Active Directory domain controller has a read/write copy of the domain database including all users, groups and other security sensitive information. It is important to guarantee physical security of the domain controller, so that only authorized personnel can physically access the servers. This is not always possible in branch office scenarios. It is not a good idea to put a domain controller into locations where physical security cannot be guaranteed.

Fewer Than 10 Users Per Branch

Where there are fewer than 10 users in a branch, there is typically no reason to put a domain controller into that branch. This assumes that your plan for that branch does not include services provided by Microsoft Exchange 2000 Server. Realize that logon traffic will have to go across the WAN link in this situation. For alternatives, refer to the "Alternative Solutions" section later in this chapter.

Between 10 to 50 Users Per Branch

Where there will be between 10 to 50 users in the branch, one or more domain controllers may be needed in the branch; the number will depend on what services are needed in that branch. At least one domain controller should be placed in the branches where applications rely heavily on Lightweight Directory Access Protocol (LDAP) searches or on Active Directory, or where Group Policy is used to configure the clients.

Usually, the service of a domain controller can be combined with other roles such as DNS, DHCP, File and Print (F&P) services, or Microsoft Internet Information Services (IIS). Role combination should always take into account the expected load and the planning for load balancing between the available domain controllers.

More Than 50 Users Per Branch

As mentioned earlier, one major reason to put a domain controller in the branch is to keep the logon traffic local at the branch and not traverse the WAN. If the domain controller is also a global catalog server, then address book lookups are also local and do not go across the WAN.

In branches with more than 50 users you will probably want one domain controller performing the domain services (such as domain controller, global catalog, DNS, DHCP) and one or more servers to handle the applications and/or the File and Print (F&P) services. A single domain controller-depending on its replication schedule, the change rate and size of the changes-might well be capable of running F&P and other services in the branch.

Replication Traffic

Every domain controller needs to replicate its Domain Naming Context, the Schema Context and the Configuration Context in order to function properly. A change to any of these has a different effect on the replication traffic that the domain controller sends over the network.

Domain Naming Context

The Domain Naming Context includes all user, group and computer objects in the domain as well as information about Group Policy objects. Changes in Active Directory are replicated on a per-attribute basis. Consider that group membership is a multi-valued attribute and replicated as a whole. Changes to Group Policy objects not only trigger Active Directory replication, they also are reflected in increased File Replication service Sysvol replication traffic.

Schema Naming Context

The partial list of attributes replicated to global catalog servers is defined in the schema. If an attribute is added to the set of attributes replicated to global catalog servers, that change will trigger a full replication of the global catalog. If these changes are expected to happen very frequently, network connectivity to all locations with global catalog servers will have to be evaluated carefully to determine whether those connections can handle a full rebuild of the partial naming contexts for the remote global catalog server. Another strategy would be to lock down the schema, and allow schema extensions only in batches defined by a committee in charge of schema changes.

Configuration Naming Context

The Configuration Naming Context contains all information about the structure and configuration of the forest. Changes need to be replicated throughout the forest to ensure proper functionality of the forest. Thus changes in group nesting, for example, are replicated throughout the forest to all global catalog servers.

Availability of a Logon Provider

If it is necessary for users or applications to log on at the branch, then a domain controller must be placed in the branch so that the branch can operate autonomously if the WAN link fails. The requirement for autonomous operation will not be met without a branch domain controller. This is because cached credentials only work for workstation logon, not for accessing server shares or for application logons. For other methods of supporting a low number of users in Branch Offices, see the following section. A better situation is where there are two domain controllers in the branch. When you are deciding on hardware purchases where the single domain controller in the branch does not have enough capacity for the load placed on it, remember to consider failover scenarios. It may be better to place a second domain controller in the branch, which could take over when the first fails, rather than adding capacity to the first domain controller.

Alternative Solutions When No Domain Controller Is Placed in the Branch

If neither the primary logon service at the local branch nor the WAN link is available, users cannot be authenticated by a domain controller or use domain accounts for access to the local File and Print server. There are two ways to ensure access to local File and Print (F&P) services in this situation. You can create local user and group accounts on the member server in the branch, or use Terminal Services.

Local Users and Groups on Member Servers

If no domain controller is deployed to the branch, you can create local user and group accounts on the member server in the branch. Put the global groups of domain users into the member server local groups or groups. In addition, create an "Offline Users" group on the member server whose members are local users (also created on the member server locally). Give the same permissions to "Offline Users" as to the local groups containing the global groups. When a domain controller is available the user gets his ticket from the domain controller. If the WAN link is down, users still can access their resources on the local server using their local accounts in the "Offline Users" group.

The drawback of this solution is that the duplicated user and group accounts have to be managed by the administrator, and users have to synchronize passwords manually between their domain user account and their member server local user account. Usually, users are not willing to accept an environment with this level of complexity. The alternative is a Windows Terminal Services client/server configuration.

Terminal Services

Instead of using a Windows workstation and accessing the server over the network (which requires a logon at the server and requires a domain controller), users invoke their Windows Terminal Services Client to connect to the local Terminal Server. The Terminal Server forwards logon requests over the WAN to the next available domain controller in the hub site. If for any reason the link to the hub site is down, users can still log on with their cached credentials and access resources local to the server.

By using the Terminal Services solution, you ensure that users can always work locally on the Terminal Server. Even if the users print documents, or save files on a network share that is locally available on the Terminal Server, this is still a local operation. The access check for these resources does not require an additional logon. Even if the network link is not available, users can log on to the Terminal Server using cached credentials, work on a Windows-based terminal and use all applications installed on the server, and use all resources on the server.

While either solution provides the users with some offline capability, the Terminal Services solution is preferable since it is easier to maintain and scales well with the server hardware.

Placing Global Catalog Servers

As a general rule, designate at least one domain controller in each site as a global catalog server. Use the same failover and load distribution rules that you used for individual domain controllers to determine whether additional global catalog servers are necessary in each site.

Single Domain Environment

In a single domain, single location environment, a user logon request does not require a global catalog server to process a logon request, since no domain controller knows more than the global server. You should, however, still designate additional global catalog servers. Clients seek global catalog servers for search operations. Also, having global catalog servers already in place allows the system to adapt gracefully if you add more domains later.

Recommendation: In a single domain, multi-location environment with hubs, each hub site must contain one or more global catalog servers. In addition, you should place a global catalog server in branches with more than 50 users. Though this configuration is sufficient to run a single domain environment, the best practice is to configure all domain controllers as global catalog servers, (except for the Operations Master holding the infrastructure master role) since this will not add to database size or replication traffic.

Native Mode Domain

A native mode domain, where all domain controllers are Windows 2000 domain controllers and the domain has been irrevocably switched to native mode, allows the usage of universal groups. When processing a logon request for a user in a native-mode domain, a domain controller sends a query to a global catalog server to determine the user's universal group memberships. Since you can explicitly deny a group access to a resource, complete knowledge of a user's group memberships is necessary to enforce access control correctly. If a domain controller of a native-mode domain cannot contact a global catalog server to determine universal group membership when a user wants to log on, the domain controller refuses the logon request.

The following registry key can be set so that the domain controller ignores the global catalog server failure when expanding universal groups:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Lsa \IgnoreGCFailures

The domain controller still tries to connect to the global catalog server, however, and the timeout for that query must expire. For more information on using this registry key, refer to article 241789 in the Microsoft Knowledge Base.

Multiple Domain Environment

In a multi-domain environment, global catalog servers are required to process a user logon request. If there is no global catalog server in the site, the domain controller in the site has to contact a global catalog server in the hub site to retrieve universal group information. This creates two issues: 1) if the WAN is not avail the logon fails and 2) if the WAN is available, additional network traffic is needed between the branch and the hub. If it is mandatory that users log on at all times, then you must deploy a global catalog server to the site. This means in a multi-domain hub and spoke environment, each hub should contain at least two global catalog servers, in case one global catalog server fails. In addition, depending on the applications and the available network bandwidth to and in the branch site, it might be necessary to designate a global catalog server in that branch. There should be at least one global catalog server in sites with more than 50 users.

Now that you know where you need to place domain controllers and global catalog servers, let's look at where we decided to place domain controllers and global catalog servers in the sample environment.

Looking at the above diagram, you will notice that all servers are domain controllers. In addition, one root server (Root1), the staging site server (Staging), and all bridgehead servers (BH1, BH2, and BH3) are global catalog servers. There are no global catalog servers in the branch offices because all branches have fewer than 50 users and there are no Active Directory aware applications, such as Microsoft Exchange 2000 Server, in use in the branch offices yet.

Now that you have determined where to place your domain controllers and global catalog servers, you can now consider the placement of your DNS servers.

DNS Design Recommendations

The availability of a DNS server directly affects the availability of Active Directory. Clients rely on DNS to find a domain controller, and domain controllers rely on DNS to find other domain controllers for replication. Even if you already have DNS servers deployed on your network today, you may need to adjust the number and placement of servers to meet the needs of your Active Directory clients and domain controllers.

As a general rule, place at least one DNS server in every site. The DNS servers in the site should be authoritative for the locator records of the domains for the domain controllers in that site. This will ensure that clients do not need to query DNS servers off-site to locate a domain controller in their own site.

The recommended configuration that satisfies all requirements is therefore to use Active Directory integrated DNS, store the locator records for a domain's zone within the domain itself, and run the Windows 2000 DNS service on one or more domain controllers in each site where those domain controllers are placed.

Each network connection through which a computer is expected to perform DNS name resolution must be configured with a preferred DNS server and should be configured with at least one alternate DNS server. Preferred and alternate DNS servers should be in the same site as the computer, or (if there are no DNS servers in the computer's site), in the site which is connected to the computer's site with a persistent low-cost connection. You may also configure a domain controller to point to itself as the preferred or alternate DNS server.

Domain controllers will also periodically check that their own locator (for example SRV) records are correct. To do this the domain controller verifies its own locator records on a DNS server that is authoritative for its own DNS zone, and also for the forest-wide records in the Active Directory root domain (or the DNS zone used by the root domain).

Distributing the Forest-Wide Locator Records

Each domain controller in the forest registers two sets of locator records: a set of domain-specific records that end in <DNS domain-name>, and a set of forest-wide records that end in _msdcs.<DNS-forest-name>. The forest-wide records are of interest to clients and domain controllers from all parts of the forest. For example, the global catalog server locator records, and the records used by the replication system to locate replication partners, are included in the forest-wide records.

For any two domain controllers to replicate with each other, including two domain controllers from the same domain, they must be able to look up forest-wide locator records. For a newly created domain controller to participate in replication, it must be able to register its forest-wide records in DNS, and other domain controllers must be able to look up these records. For this reason, it is vital that forest-wide locator records be available to every DNS server in every site.

If the DNS servers have persistent fast connections to the DNS servers authoritative for the _msdcs.<DNS forest-name> domain, then no special configuration is needed. If not, you have two options. You can create a separate zone for _msdcs.<DNS-forest-name> DNS domain, and replicate it to all DNS servers in the enterprise using standard zone transfer or you can create a separate zone called _msdcs.<DNS-forest-name>, and replicate that zone to every DNS server. If you are using Active Directory integrated DNS, you can place the primary copy of this zone in the forest root domain along with the <DNS-forest-name> zone. You can then replicate the zone to secondary DNS servers outside the domain using standard DNS replication. The domain controllers or DNS servers in non-root domains will host read-only copies of the source zone.

If a branch office is connected via dial-up lines to the hub sites AND the branch office contains one global catalog server or at least two domain controllers for the same domain, then there should be a DNS server in that branch office which hosts a secondary _mscdcs<DNS-forest-name> zone so that forest-wide records are available locally and there is no need to generate WAN traffic in this instance.

Generally, it is not sufficient to replicate the zone to only one DNS server per site. If a DNS server does not have a local copy of the _msdcs.<DNS-forest-name> zone and is not configured to forward queries, it must use DNS recursion to look up a name in that zone. For a DNS server to perform recursion, it contacts a DNS server that is authoritative for the root of the namespace (a DNS root server) and proceeds down the delegations in DNS until it finds the record in question. If there is no DNS root server or forwarder in a site, and the links between that site and other sites are down, a DNS server cannot perform recursion or forwards. Thus, it will not be able to find any DNS servers that are authoritative for _msdcs.<DNS-forest-name>, even if those DNS servers are in the same site. The solution is to replicate the zone to two DNS servers in the site, and configure each to point to the other as its preferred DNS server and point to itself as the alternate.

The "Island" Problem

The so-called "island" problem occurs when a domain controller that is the primary DNS server for the domain, points to itself as the preferred or alternate DNS server for the zone _msdcs.<DNS Forest-name>. The typical scenario for this configuration is a domain controller in the forest root domain, which is also a DNS server using Active Directory integrated DNS. In the case of a configuration change, such as changing the IP address of the domain controller, the update of the forest-wide locator records only happen on the local domain controller. Normally, this change is replicated to all other domain controllers.

One of the domain controller locator records, CNAME record, or alias, is used for finding the IP addresses for replication partners. Replication internally uses the globally unique identifier (GUID) of domain controllers to find replication partners. This CNAME record of a domain controller uses the GUID as an alias name mapped to the fully qualified DNS name of the domain controller.

If a domain controller now changes its configuration in a way that affects the CNAME, and only updates this change in its own local DNS server, then this change never reaches other domain controllers. The reason is that if Active Directory integrated DNS zones are used, DNS relies on replication to update DNS zone information. But if domain controllers cannot find replication partners due to changes in DNS, the changes cannot be replicated.

To avoid this scenario, if the forest root domain controllers are DNS servers authoritative for the _msdcs.<DNS forest-name>, a primary server in the forest root domain should not point to itself as the preferred DNS server. It should point to another forest root DNS server. Domain controllers in all other cases will not be affected by the "island" problem, because even if they point to themselves as preferred DNS servers, they will always update the records needed for replication on a DNS server that is authoritative for the root zone.

The "Island" Problem Example

Root1.corp.hay-buv.com is the first domain controller in a forest. It is configured to point to itself as a preferred DNS server. It is the DNS server that is primary for the Active Directory integrated zone, corp.hay-buv.com, including _msdcs.corp.hay-buv.com.

A second server running Windows 2000, Root2, is running the DNS service, which is about to be the promoted to a domain controller. Root2 is also configured to point to itself as a preferred DNS server.

During promotion, the Active Directory integrated zone, corp.hay-buv.com, is replicated to Root2. Upon restarting the new domain controller, Root2.corp.hay-buv.com, the DNS server loads its copy of the zone, corp.hay-buv.com, from its own copy of Active Directory. After promotion, when it registers its DNS entries for the very first time, Root2's Net Logon service registers its SRV records with its own DNS server service. Root2 will never register with Root1, always with itself only, and the records never replicate to Root1, because Root1 does not have a record in its copy of DNS that shows that Root2 is a domain controller. So Root1 will never replicate from Root2.

Explanation: When Root2's Net Logon service attempts to register DNS records it finds that its preferred DNS server (Root2.corp.hay-buv.com, itself) is authoritative for the zone corp.hay-buv.com and registers the records with the local DNS server. One of those records is the CNAME record for <DsaGuid>._msdcs.<ForestName>. Other domain controllers (in this case Root1) attempting replication from Root2 will search for this CNAME record, but since each is its own DNS server, which is authoritative for the zone corp.hay-buv.com., none of them will ever find this CNAME record. Therefore they never will be able to replicate the records registered on Root2.corp.hay-buv.com.

Configuration to Avoid "Island" Problem

If a domain controller points to itself as preferred or alternate DNS server, AND if the local DNS server is the primary server for the DNS domain _msdcs.<DNSForest-Name>, (that is, it is in the root domain), you will need to reconfigure its preferred DNS server prior to restarting it. After promotion, but before restarting, an administrator should configure the domain controller with preferred and alternate DNS servers that are primary for the domain _msdcs.<DNSForest-Name>, but not with itself. Any other domain controller in the forest can be configured to point to itself as a DNS server.

Configuration of DNS SRV Records Published by Net Logon

Clients search for a nearby domain controller using site-specific domain controller locator records. Only if there are no domain controller entries for a client's site will the client query for and accept other domain controllers. By default, each domain controller publishes its site specific and generic SRV records.

Finding a Domain Controller in the Hub

In the branch office scenario, it is important that clients that cannot find a domain controller in their own site find a domain controller in their hub site, but never a domain controller in another branch or hub. In many deployments, clients from one branch cannot connect to machines in another branch, because the network is not fully routed (for example one-way dial-up lines are used). Even if connectivity is possible, however, it is still undesirable to initiate network connections between branches. Such network traffic would always go through the hub site; therefore it is better to restrict the traffic to branch-to-hub only.

To avoid the situation where clients in one branch contact a domain controller in another branch, the Net Logon service on all branch office domain controllers must be configured to publish only site specific locator records, but not generic domain controller locator records. The result is that only the hub domain controllers publish the generic locator records in addition to their site-specific records. Clients that cannot find a domain controller in their own site will now only find generic domain controller locator records for hub domain controllers. To limit the domain controllers that are found, you will have to configure Net Logon with the following files, and registry edits.

Net Logon Configuration Files

The ability to configure Net Logon with regard to which domain controller locator records to register was added in SP2 of Windows 2000.

Net Logon Registry Editing

To prevent Net Logon on a domain controller from attempting dynamic updates of certain DNS records, use Regedt32.exe to configure the following registry value:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netlogon \Parameters
Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ

In this value, specify the list of mnemonics corresponding to the DNS records that should not be registered by this domain controller. The list of mnemonics includes those in the following table:

Mnemonic	Type	DNS record
Dc	SRV	_ldap._tcp.dc._msdcs.<DnsDomainName>
DcAtSite	SRV	_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>
DcByGuid	SRV	_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>
Pdc	SRV	_ldap._tcp.pdc._msdcs.<DnsDomainName>
Gc	SRV	_ldap._tcp.gc._msdcs.<DnsForestName>
GcAtSite	SRV	_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>
GenericGc	SRV	_gc._tcp.<DnsForestName>
GenericGcAtSite	SRV	_gc._tcp.<SiteName>._sites.<DnsForestName>
GcIpAddress	A	_gc._msdcs.<DnsForestName>
DsaCname	CNAME	<DsaGuid>._msdcs.<DnsForestName>
Kdc	SRV	_kerberos._tcp.dc._msdcs.<DnsDomainName>
KdcAtSite	SRV	_kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName>
Ldap	SRV	_ldap._tcp.<DnsDomainName>
LdapAtSite	SRV	_ldap._tcp.<SiteName>._sites.<DnsDomainName>
LdapIpAddress	A	<DnsDomainName>
Rfc1510Kdc	SRV	_kerberos._tcp.<DnsDomainName>
Rfc1510KdcAtSite	SRV	_kerberos._tcp.<SiteName>._sites.<DnsDomainName>
Rfc1510UdpKdc	SRV	_kerberos._udp.<DnsDomainName>
Rfc1510Kpwd	SRV	_kpasswd._tcp.<DnsDomainName>
Rfc1510UdpKpwd	SRV	_kpasswd._udp.<DnsDomainName>

The recommended configuration in a branch office deployment is as follows:

• On all branch office domain controllers, add all entries that do not have "AtSite" as part of the mnemonic, to the value of the registry key, except the DsaCname.

On hub domain controllers, do not use the registry key. This allows the domain controller to register all records.

DNS Registration Storage Limitations

In addition to the reasons already given for restricting how domain controllers register their SRV records, when Active Directory integrated DNS zones are used in large deployments, the storage limitations of attributes will come into play. DNS registrations are stored in multi-valued attributes. Active Directory has a limitation for non-linked multi-valued attributes such that a maximum of 850 values can be saved per object. This is different from linked-multi-valued attributes, such as groups, that can hold many more values (in Windows 2000, up to 5,000 values). For small deployments, the Net Logon configuration is optional and optimizes service location. For deployments with more than 800 domain controllers, this configuration is mandatory because of the storage limitation for non-linked multi-valued attributes

If, for example, more than 850 domain controllers try to register services for the same domain, this limitation will be reached. If Net Logon is configured correctly (so that branch office domain controllers will register entries only on a per-site level, but not on the domain level) this limitation will be moved from a per-domain level to a per-site level, and thus allows thousands of domain controllers to register services. There is no meaningful configuration that requires more than 800 domain controllers in the same site.

The DNS configuration before the fix is applied looks like this:

The DNS configuration after the fixes are applied and the registry entries made looks like this:

Disabling AutoSiteCoverage Registration in DNS

Another situation that requires configuration of SRV records results from not having a domain controller in a particular site. This may happen because there are no users needing constant logon access, or because replication to the site might be too expensive or too slow. To ensure that a domain controller can be located in the site closest to a client computer, if not the same site, Windows 2000 automatically attempts to register a domain controller in every site by using an "autositecoverage" algorithm. The algorithm determines how one site can "cover" another site when no domain controller exists in the second site. By default, the process uses the replication topology.

The algorithm works as follows. Each domain controller checks all sites in the forest and then checks the replication cost matrix. A domain controller advertises itself (registers a site-related SRV record in DNS) in any site that does not have a domain controller for that domain and for which its site has the lowest-cost connections. This process ensures that every site has a domain controller even though its domain controller may not be located in that site. The domain controllers that are published in DNS are those from the closest site (as defined by the replication topology).

In the branch office scenario, any computer from other sites should not discover branch office domain controllers. A client should always communicate with a local domain controller, and if that is not available, use a domain controller in the hub site. To achieve this:

1. Disable AutoSiteCoverage on all of the domain controllers, not only for the branch domain controllers, but also hub domain controllers.

2. Do not register generic records as described above.

If both of these configurations (1. and 2.) are performed, then all-site clients will discover the local domain controller if it is available, or its hub domain controller (if no local domain controller is available).

In the unusual scenario when a site with a domain controller for some domain is closer to another site than the central hub, the administrator has the ability to configure that domain controller with the specific ("close") sites to be covered using the following registry values: SiteCoverage, GcSiteCoverage. Alternatively, the administrator can use the following Group Policy settings:

• Sites Covered by the domain controller Locator DNS SRV Records

• Sites Covered by the global catalog server Locator DNS SRV Records

• Sites Covered by the NDNC Locator DNS SRV Records

However, physical proximity or network performance are not the only criteria. If firewalls or dial-on-demand lines do not allow traffic in this direction, incorrectly applied site-coverage will be bad for clients, since they will fall back to an unreachable domain controller, and not to the hub.

Registering Name Server Records

In addition to registering SRV records, DNS servers auto-register Name Server (NS) records. These records enable clients to locate which DNS servers are authoritative for a domain. Many companies, however, use a hidden DNS server. A hidden DNS server can only be found or used by clients that explicitly point to that DNS server for name resolution. They are not specified as a DNS server authoritative for a domain through an NS record. For branch office deployments, it is important that there are not too many DNS servers registered via the NS record. If the list of servers with an NS record is too big, it creates too much network traffic in response to client NS queries. Clients in branches should also only be able to find DNS servers in data centers when there is no DNS server in the branch, if they do need to query for a DNS server via the NS record.

To configure a DNS server so that it does not auto-register its NS record, the following registry key can be used:

HKLM/System/CCS/Services/DNS/Parameters
REG_DWORD DisableNSRecordsAutoCreation

There are two value choices for this entry:

0x0 The server automatically adds NS record corresponding to itself when loads a zone from the Active Directory.

0x1 The server does not add NS record corresponding to itself when loads a zone from the Active Directory.

By default the value doesn't exist, which is functionally equivalent to the 0x0 case.

DNS Registration and Dial-On-Demand Links

Another aspect of branch deployment that affects DNS deployment and configuration is a dial-on-demand link between a branch and the hub. A dial-on-demand connection is a common configuration of a branch-hub connection. In this case, DNS registrations have to travel over the dial-up links, which adds to the network traffic over these slow links. It also might open the line, even if no other application is using the line at this point in time. To control how often domain controllers refresh their DNS records, use the DNS refresh interval of the Start of Authority (SOA) record.

Besides the initial DNS registration, the DNS scavenging feature, which removes records from DNS that are older than a specific interval, needs to check from time to time to see whether the client for that registered record is still in place. This also causes recurring network traffic.

One good practice to keep traffic to the dial-on-demand line from going up is to deploy a DNS server to the branch and let domain controllers register their entries locally. However, as shown above, some records need to be registered in the _msdcs.<DNS forest-name> domain. This can only be done on a primary DNS server for this domain. In most branch office deployments, primary DNS servers for the _msdcs.<DNS forest-name> domain are only located in the data-centers or hub sites. Even if the zone containing the _msdcs.<DNS forest name> domain is transferred to the local DNS server as a secondary zone, the local DNS server cannot be used for record registration, because all registrations need to be made on a primary DNS server for this domain. Again, use the DNS refresh interval of the SOA record to control how often domain controllers refresh their DNS records.

DNS Client Configuration

Clients and domain controllers should be configured with at least two DNS server IP addresses: a preferred local server, and an alternate server. The alternate server can be in the local site, or it can be remote if you trust your network to handle the failover. Examining our sample scenario again, you will notice that none of the root domain controllers have themselves as their preferred DNS server and that all other domain controllers have a different DNS server as their alternate.

For more information about placing and configuring DNS servers to support Active Directory, refer to the "Distributed Systems Guide" in the Windows 2000 Server Resource Kit.

Determining the Number of Sites

The number of sites is influenced by the following three key factors:

• Number of independent locations

• Available network connectivity between domain controllers (This directly influences the decision on when to create a new site.)

• Number of locations with and without domain controllers

Although in some of the following special scenarios we present, it makes sense to create a site even if there is no domain controller deployed locally, you will usually create a site only if a domain controller is deployed locally. Users need domain controllers to log on to the network and use network services like File and Print services. If no domain controller is available, users can still log on to their workstations using cached credentials. The access to any network services like file servers, however, is not possible through cached credentials, as is discussed elsewhere in this guide.

It is not necessary to deploy a domain controller to a branch in any of the following scenarios:

• Users can do all of their work from their own workstation, and no network services are necessary.

• Terminal Services can be used in the branch, allowing users to run applications on the server and use server servicessuch as home directories, shares, and printer servicesprovided by that server. Logon using cached credentials can be used when Terminal Services is used.

• The WAN is 100% reliable, and user logon traffic over the WAN would be less than Active Directory replication traffic.

Realize that logon traffic may become greater than replication traffic with a small number of users (even as few as 10 users). This is influenced by the fact that Active Directory replication traffic is very efficient, providing WAN-friendly components like data compression (to around 10% to 15% of the original data volume) and replication schedules.

Administration factors that also have to be considered are:

• A local domain controller must be deployed and configured correctly.

• Replication traffic volume to branches must be monitored very closely (both Active Directory and FRS replication).

Overall, the more domain controllers that are deployed, and the more sites that are created, the more complex the environment is. This adds to overall management and monitoring tasks, not only for the branch office domain controllers, but also for the mission critical bridgehead servers. The cost of physically securing the branch domain controller should also be taken into account.

In many cases centralizing domain controllers in data centers will be more cost efficient than deploying domain controllers to all locations, even if the costs for network traffic appear to be higher at first glance. Only a good Active Directory namespace plan with a thorough cost analysis provide the best result.

Exchange Server Placement

If you need a domain controller in the branch for Exchange 2000 or other services, then you need to consider FRS, domain controller, and global catalog server replication. global catalog server placement is an issue in small branches; if the global catalog server is large then the replication traffic it generates is often more than the traffic of occasional global catalog server lookups by the clients. In the case of a small branch with occasional lookups and a large global catalog server, it would be better to place the global catalog server in the hub rather than putting it in the branch. For very small branches with reasonable link speeds to the hub, it may very well be feasible to put the server running Exchange into the hub also.

For more information about Exchange 2000 requirements, refer to the Exchange 2000 Server Resource Kit and the Exchange 2000 Server Upgrade Series, both of which are available on the Internet at:

https://www.microsoft.com/technet/prodtechnol/windows2000pro/deploy/upgrdmigrate/default.mspx

Summary

This chapter should have helped you decide whether to partition your forest, and your domain, and where to place domain controllers, global catalog servers, DNS servers and Operations Masters. In addition, you should now know which servers should be placed in which sites, and the configuration necessary to ensure that traffic is optimized between the branches and the hub. The diagram for the sample scenario in this guide, showed how the domain controllers, global catalog servers, DNS servers, and Operations Masters were placed in the sample environment. Now that you have planned your logical structure of hubs and branches, the next chapter will focus your planning on the replication issues and configuration that result from your design.