Planning Active Directory for Branch Office

Chapter 4 - Planning the Hub Site for Branch Office Environments

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.

On This Page

Introduction
Process Flowchart
Data Center Strategy
Building the Root Domain
Building the Branch Office Domain
Monitoring and Key Performance Indicators
Server Sizing
Disaster Recovery
Firewalls
Summary

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.

Process Flowchart

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.

In the sample branch office design, there is a single hub data center, one staging site, and five branch offices. The design is composed of two domains, the:

• 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 Masteragain 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.

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.

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.

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.

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.

Disaster Recovery

All bridgehead servers running in the data center serve critical roleseither 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

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:

https://www.microsoft.com/serviceproviders/default.mspx

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.