Operating System
Chapter 4
Planning the Hub Site for Branch Office Environments
Planning Guide
Abstract
This chapter outlines the steps necessary to create a hub or data center site, including building and
maintaining the root and branch office domains. After completing these steps, you should be ready to
plan the staging site at which the branch domain controllers will be created.
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft
must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy
of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO
WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without
limiting the rights under copyright, no part of this document may be reproduced,
stored in or introduced into a retrieval system, or transmitted in any form or by any
means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from Microsoft, the furnishing of
this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
 2000 Microsoft Corporation. All rights reserved.
Microsoft, Windows, Windows NT, the Windows logo, Active Directory, , are either
registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries/regions.
1200
CONTENTS
INTRODUCTION .......................................................................... 1
Resource Requirements
1
What You Will Need
1
What You Should Know
1
PROCESS FLOWCHART .............................................................. 2
DATA CENTER STRATEGY ......................................................... 3
BUILDING THE ROOT DOMAIN ................................................... 5
DNS Configuration in the Root Domain
5
Operations Master Role Placement
5
Server Sizing
5
Disaster Recovery
6
BUILDING THE BRANCH OFFICE DOMAIN ................................ 7
Operations Master Role Holder
7
Bridgehead Servers
7
Populating Data
8
MONITORING AND KEY PERFORMANCE INDICATORS ............. 9
SERVER SIZING ........................................................................ 10
DISASTER RECOVERY .............................................................. 11
Related Topics
11
FIREWALLS................................................................................ 12
SUMMARY ................................................................................. 13
INTRODUCTION
In this chapter, you will plan your hub site that will contain the bridgehead servers
supporting your branch office sites.
Resource Requirements
Before beginning to plan this portion of your branch office deployment, you should
gather the personnel, programs, and other resources that you will need..
What You Will Need
You will need personnel from the following areas:




Microsoft® Windows® 2000 Active Directory™ service architecture
Windows 2000 Active Directory administration
Infrastructure administration
Network administration
What You Should Know
You will need to know how many bridgehead servers your organization will need,
based on the expected load as calculated in the previous chapter.
Active Directory Branch Office Planning Guide
4.1
PROCESS FLOWCHART
Determine Your
Data Center
Strategy
Plan the Root
Domain
Plan the Branch
Office Domain
Plan for Monitoring
Perform Server
Sizing
Create a Disaster
Recovery Plan
4.2
Active Directory Branch Office Planning Guide
DATA CENTER
STRATEGY
When deploying domain controllers for branch offices, it is best to build the data
center first. This includes installing and configuring the Domain Name Service
(DNS) infrastructure, the root domain controllers, and the bridgehead servers for the
branch domain. The rollout to branch offices often includes building the domain
controllers in a central site and shipping them to their final destination. The reasons
for choosing this strategy are:



Branch offices are usually connected through slow links to the central sites. The
initial setup of domain controllers (promotion) requires replicating the whole
directory. In many cases, this is not feasible over slow wide area network
(WAN) links.
In many cases, there are no operations staff available at the branches who can
install, configure, and verify a domain controller. Although the Windows® 2000
operating system ships with a Terminal Services component that can be used
for remote management of servers, some configuration errors might still require
manual intervention. One example of this is if the computer is configured with a
wrong IP address, which will not go through the router in the branch office.
Staging site staff install domain controllers in a central location, like a factory.
This enables them to create the domain controllers very quickly, and then ship
them out.
The location where the branch office domain controllers are installed and configured
can be a data center, but usually it is located at a staging site which may be at an
outsource or deployment partner. Therefore, during the planning stage, you must
consider that the data center, staging site, and branch offices all have different
characteristics, such as TCP/IP configuration and link speeds.
ROOT1 - GC
corp.hay-buv.com
ROOT2 - DC
corp.hay-buv.com
ROOT3 - DC
corp.hay-buv.com
HUBDC1 - DC
branches.corp.hay-buv-com
BH3 - GC
BH1 - GC
branches.corp.hay-buv.com
BH2 - GC
branches.corp.hay-buv-com
branches.corp.hay-buv.com
Site-HUB
Staging - GC
branches.corp.hay-buv.com
Site-Stage
Branch Office
Site-Branch1
BODC1
DC
Branch Office
Site-Branch2
BODC2
DC
Branch Office
Site-Branch3
Branch Office
Site-Branch4
Branch Office
Site-Branch5
BODC3
DC
BODC4
DC
BODC5
DC
In the sample branch office design, there is a single hub data center, one staging
Active Directory Branch Office Planning Guide
4.3
site, and five branch offices. The design is composed of two domains, the:


4.4
Active Directory Branch Office Planning Guide
Forest root domain, corp.hay-buv.com, which has three domain controllers
ROOT1, ROOT2, and ROOT3.
Branch office domain, branches.corp.hay-buv.com, which contains the rest of
the domain controllers in the diagram.
BUILDING THE ROOT
DOMAIN
The forest root domain controllers are the first domain controllers that have to be
installed. To provide robustness, there should be at least two domain controllers in
the root domain. The first domain controller installed in an Active Directory forest is
always a global catalog server. Therefore, at least one of the domain controllers in
the root domain will be a global catalog server. The global catalog role should be
left on this computer. Additional domain controllers in the root domain should only
be domain controllers. As we will show later, there will be other global catalogs in
the data center. Therefore, adding the global catalog service to root domain
controllers is not necessary, and in fact does not provide much value.
DNS Configuration in the Root Domain
With respect to DNS services, the forest root domain will play a special role, since it
is the root of the Active Directory namespace. If the forest root domain controllers
are also DNS servers, then the DNS configuration on the forest root domain
controllers is slightly different from all other domain controllers. As explained in the
DNS configuration section, the DNS servers that are domain controllers in the forest
root domain hold a master copy of the _msdcs.<forest-root-domain> domain, which
is used to store the CNAME records used for replication. To avoid isolation of a
forest root domain controller after a configuration change, these DNS servers (or
root domain controllers) need to be configured to use another DNS server as
primary DNS server. Since there are at least two forest root domain controllers in
the hub site, they should point to each other as primary DNS server, and to
themselves as secondary DNS server.
Operations Master Role Placement
There are five Operations Master roles in the root domain, the two enterprise wide
Operations Master roles (Schema Master and Domain Naming Master), and the
three domain-wide Operations Master roles (PDC Emulator, Infrastructure Master
and RID Master). Since the root domain is usually a small domain, the roles will not
create a lot of load on the Operations Master role holders. Therefore, it is not
necessary to plan for distributing these roles to different domain controllers, except
to ensure that the Infrastructure Master is not a global catalog. It is good practice to
hold most roles on one server. If this computer needs to be taken offline for
maintenance, it is easy to transfer the Operations Master roles to another domain
controller.
Server Sizing
The root domain controllers are not expected to be under high load. The root
domain is a small domain with few changes, therefore replication is not an issue.
Few changes require the forest-wide Operations Master role owner to take action.
Whenever a directory enabled application that extends the schema is installed, the
schema extension is done on the Schema Master. Again, it is expected that this
would be an infrequent occurrence. The other task is the creation of a new domain,
where the name of the new domain has to be verified on the Domain Naming
Active Directory Branch Office Planning Guide
4.5
Master—again an operation that happens infrequently.
This makes the root domain controllers good candidates for additional tasks, such
as serving as DNS servers for the hub site. Even then, the root domain controllers
can be medium-sized computers, for example, dual-processor or single-processor
Pentium computers with 512 megabytes (MB) RAM. The storage system on the first
domain controller, the global catalog, should be designed to be big enough to hold
the partial naming context of the branch office domain, and any other domains your
organization plans to create.
Disaster Recovery
The root domain is crucial in an Active Directory forest. It is the home of the schema
and the configuration information. If all root domain controllers are lost, and
therefore the root domain is lost, the forest will not operate correctly anymore.
Although the temporary unavailability of root domain controllers does not
necessarily cause any problems to domain controllers of other domains (unless they
have additional tasks, like hosting the root DNS zone), operations that require the
root domain will not work anymore.
It is very important, therefore, to secure thoroughly at least one domain controller of
the root domain. You should back up this domain controller frequently to avoid data
loss. If there are multiple domain controllers in the root domain, it is sufficient to
back up only those that hold the Operations Master roles on a regular basis.
4.6
Active Directory Branch Office Planning Guide
BUILDING THE BRANCH
OFFICE DOMAIN
Most domain controllers from the branch office domain running in a hub site are
used as bridgehead servers. Most of the design work for a branch office deployment
centers around performance and availability of these domain controllers. However,
there are some additional considerations, such as the placement of the Operations
Master role owners and the connectivity to the staging site.
Operations Master Role Holder
The first domain controller installed in a domain holds all Operations Master roles
unless they are moved manually to a different computer. Reasons for moving a
Operations Master role are:


Offloading the PDC Emulator role from a busy domain controller
Separating the global catalog role from the Infrastructure Master
For branch office deployments, it is advisable not to use a bridgehead server as an
Operations Master role owner. Bridgeheads will be under a high load, and some
Operations Master operations, like password changes on the PDC Emulator for
down-level clients, will create additional load. Therefore, dedicated computers
should be used as the Operations Master role owners. These computers can also
be used as the bridgehead server for the staging sites only. The number of staging
sites should be very small, maybe one or two. Therefore, the small number of
replication partners should not generate too much replication load. Since the first
domain controller in a domain holds all of the Operations Master roles, including the
Infrastructure Master role, it must not be a global catalog server.
Bridgehead Servers
Bridgehead servers for the inbound and outbound replication to the branch offices
will experience high load, especially if replication is configured in a way that one
bridgehead server will service many outbound replication partners at the same time.
It is good practice to remove all other operations from these computers (such as the
PDC Emulator role). However, to reduce traffic between branches and the hub site,
it makes sense to ensure that branch office domain controllers only talk to one
computer in the hub site. Consider one of the following configurations:




If the branch office domain controllers are configured as global catalog servers,
the bridgehead servers should also be global catalog servers.
If the branch office domain controllers are not configured as global catalog
servers, the bridgehead servers can be domain controllers only.
If DNS runs on the branch office domain controllers, the bridgehead servers do
not need to run DNS, instead use another DNS server in the hub site.
If the branch office domain controllers do not run DNS, the bridgehead servers
should run DNS, and have a copy of the _msdcs.<forest-root-domain> DNS
zone.
Active Directory Branch Office Planning Guide
4.7
Populating Data
As much information as possible should be populated into the branch domain hub
domain controllers before the first branch site domain controllers are created at the
staging site. The critical set of data that needs to be in the directory is:



IP subnets of all hub and branch office subnets
Active Directory sites
Site links (these must be created, even if the Inter-Site Topology Generator
(ISTG) is disabled and manual connection objects are used)
In addition, users and groups should already be present in the directory. Group
changes add significantly to replication traffic, so the fewer groups that have to be
created after domain controllers are deployed to remote offices, the smoother the
deployment will be. Creation of other objects such as printers and file shares does
not generate as much replication traffic. Therefore it is not critical to create these
objects before creating and deploying the branch domain controllers.
4.8
Active Directory Branch Office Planning Guide
MONITORING AND KEY
PERFORMANCE
INDICATORS
The data center or hub is the heart of the branch office deployment. The stability of
Active Directory depends on the availability of services in the data center. If a
bridgehead server is unavailable, it can potentially affect hundreds of branch offices.
Typically, a short period where replication cannot occur does not affect users.
Logon services, as well as other services running on branch office domain
controllers (file and print services, for example) will still work, and users will not
notice a difference. However, if replication stops for a long time, backlog will
increase. This will put the bridgehead server under a high replication load when it is
re-connected. A branch office that has been disconnected from the hub site for a
long time can result in the branch office domain controller no longer being usable.
This happens when the domain controller is disconnected for more than 60 days
((the default tombstone lifetime) or when two domain controllers are out of touch for
twice the password change period.
To avoid this be sure to monitor the Performance Monitor counters for Active
Directory discussed in Chapter 9, “Post Deployment Monitoring of Domain
Controllers” of the Active Directory Branch Office Deployment and Operations
Guide on your bridgehead servers.
In addition to that, the Resource Kit tool Repadmin.exe should be used on a daily
basis to determine the status of replication:


Replication errors for each naming context (Repadmin /showreps should return
“no error” for all naming contexts.
The length of the replication queue (Repadmin /queue) should be examined. If
the queue starts growing, this indicates that the bridgehead servers are
receiving more replication requests than they can currently handle and are
becoming overloaded.
Note: For more information about monitoring your environment, refer to Chapter 9, “Post Deployment
Monitoring of Domain Controllers,” of the Active Directory Branch Office Deployment and Operations
Guide.
Active Directory Branch Office Planning Guide
4.9
SERVER SIZING
The bridgehead servers need to be the most powerful computers. The faster a
bridgehead server is, the more concurrent replication partners it can serve.
Essentially this means that if you have a powerful bridgehead server, you need a
low number. if they are slow computers, you need a higher number of bridgehead
server to ensure replication to all branch offices.
Planning Chapter 3, “Planning Replication for Branch Office Environments,” gave a
formula to determine the number of bridgehead servers. One of the key factors is
how many concurrent replication sessions can be supported by one bridgehead
server. Performance factors that can affect the load a bridgehead servers can
handle are:







CPU type and speed
Number of CPUs
Memory
Number of RAID partitions
Number of disks
Speed of disks
Amount of L2 cache
Note that for smaller domains ( < 20,000 users ), storage systems do not play a
significant role for performance, since most information can be held in the cache.
4.10
Active Directory Branch Office Planning Guide
DISASTER RECOVERY
All bridgehead servers running in the data center serve critical roles—either for
replicating to the branches (bridgehead servers), or replicating to the staging site.
Therefore, it is critical that services are not interrupted for a significant length of
time.
Assuming that you have planned your replication topology for redundancy and
failover, you will face one of two situations when a bridgehead server fails:


Disk failure or disk corruption
Hardware failure
If you do not have redundant connections and the branch is now disconnected from
its hub server, then you will have to determine how long the users who are
dependant on that server can remain out of touch. If you are comfortable with users
being disconnected, restore the server. If not, you must create additional connection
objects to another hub server.
There are two strategies to plan for recovery when a bridgehead server goes down:


Fix the hardware and restore the data from tape
Keep a hot-spare bridgehead server in the data center
If you have a hot-spare site, make sure that it is included in the topology, so that
you know replication works to that site, and you are not faced with troubleshooting
replication problems to that site at the same time you are trying to recover from
another disaster.
Related Topics
For more information about disaster planning, refer to Chapter 10, “Disaster
Recovery for Branch Office Environments,” of the Active Directory Branch Office
Deployment and Operations guide ,as well as the following white papers:


Active Directory Disaster Recovery White Paper
High Availability Operations Guide: Implementing systems for reliability and
availability, by Microsoft Consulting Services, Manufacturing and Engineering
Practice
Active Directory Branch Office Planning Guide
4.11
FIREWALLS
Usually there are no firewalls between branch offices and the hub sites. However,
there might be cases where firewalls are necessary, especially when branch offices
are connected directly to the Internet. If firewalls are used, and Active Directory
needs to replicate through the firewalls, two different solutions are possible:

Create a virtual private network (VPN) tunnel between the branch and the
data center

Use IPSEC for the communication between domain controllers that need to
replicate through firewalls
For more information about configuring domain controllers to use IPSEC, refer to
“Configuring IPSec for Active Directory Replication over Firewalls,” located at:
http://www.microsoft.com/ISN/Columnists/P63623.asp
4.12
Active Directory Branch Office Planning Guide
SUMMARY
In this chapter we discussed the considerations for planning the operations of the
hub or data center site. We covered how to place the DNS servers and the
Operations Master roles. We also discussed the necessity of populating the branch
domain before you begin the installation of the domain controllers for the branches.
The computers that you have chosen as bridgehead servers should have the
appropriate capacity to fulfill their roles.
Active Directory Branch Office Planning Guide
4.13