Planning Active Directory for Branch Office

Chapter 5 - Planning the Staging Site for Branch Office Environments

This chapter outlines the considerations for setting up a staging site prior to your branch office deployment. At the end of this chapter you should understand the best practices for installing and managing a staging site, the replication topology and connectivity requirements, and the related documentation that is required.

On This Page

Introduction
Process Flowchart
Best Practices for Building a Staging Site
Configuring the Replication Topology
Capacity Planning
Software Installed on Domain Controllers
Monitoring
Summary

Introduction

In this chapter you will plan your staging site for use in the staging of branch office domain controllers. Your staging site can either be a separate site in your data center that you use for preparing new domain controllers, or can be contracted out to a third-party company that your organization uses to build new domain controllers.

Resource Requirements

Before you begin to plan this portion of your branch office deployment, you will need the following personnel, programs, and other resources.

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 the bridgehead servers and the PDC emulator in your organization, based on the plan you created in the previous chapter. For the sample scenario, the hub site would appear as follows:

Process Flowchart

Best Practices for Building a Staging Site

Before building a staging site, it is a good idea to pre-stage, or install a computer in a location with good network connectivity to an existing domain controller. In the scenario depicted here, the staging site domain controller has good connectivity to HubDC1, an existing domain controller. Installation includes not only the installation of the operating system but also the installation of the directory service. There are two reasons for pre-staging domain controllers:

• When hundreds of computers have to be manufactured, it is best to do this in one location with proven processes, tools, and experienced personnel on hand.

• Setting up a new domain controller significantly increases replication traffic for the initial setup of Active Directory. In many branch office scenarios, the slow links between the branches and the data centers do not have the bandwidth which would allow the initializing replication necessary for Active Directory.

Staging Site Requirements

A staging site has to fulfill a set of requirements to ensure that the manufacturing and deployment of domain controllers are successful. These requirements include:

• One or more permanent domain controllers in the staging site that can be used as a replication source for the new domain controllers.

• A permanent network connection between the staging site and hub site.

• Enough space, network connectivity and capacity to allow installed domain controllers to remain online until they are finally shipped to their destination.

Replication Source

The domain controller in the staging site can be used by servers to replicate the existing directory, while the Active Directory Installation Wizard runs. If the wizard is run by starting dcpromo.exe without parameters (or by invoking it from the Configure Your Server Wizard), the administrator cannot choose which existing domain controller should be used as the source. If the Active Directory Installation Wizard is started in unattended mode, however, the answer file allows the specification of the source domain controller. For the syntax for starting dcpromo with an answerfile, refer to Chapter 6, "Staging a Branch Office Domain Controller" in the Active Directory Branch Office Deployment and Operations Guide.

Connection Between Staging Site and Hub

The staging site needs a permanent network connection to the hub site for three reasons:

• Every time a new domain controller is installed, the domain controller that had been used as source domain controller creates new entries for the new domain controller. The new entries concern the computer account of the new domain controller, where the computer role is changed from a server to domain controller, as well as information in the configuration container needed for replication. These changes need to be replicated to the bridgehead servers in the hub site, before the new domain controller tries to replicate changes from a bridgehead server for the first time.

• After the installation of the directory service has finished, the new domain controller needs to request a RID pool from the RID pool owner. Therefore, the new domain controller needs to be able to communicate with the computer that currently holds the RID pool Operations Master role over the wide area network (WAN). If this fails, no security principal can be created on the new domain controller, and an event will be logged specifying that the domain controller cannot get a RID pool. The installation of the domain controller will succeed, in fact, the RID pool is requested after the domain controller has rebooted.

• The new domain controller needs to be able to update its DNS records stored in the _msdcs.<forest-root-domain> domain. Typically, only root domain controllers are primaries for this domain. There should not be a root domain controller in any staging sites in order to protect the Enterprise Admin account and the forest wide Operations Master roles.

The network connection does not have to be a high-speed connection. From a planning perspective, the same requirements as for a typical branch office suffice. If Active Directory is designed in such a way that a 64kilobit connection between any branch and the hub is sufficient, then the same applies to the staging site. However, the network connection must be permanent and the replication window must be open at all times. At least at times when new domain controllers are installed, the request for RID pools must work.

Domain Controllers Must Remain Online Until Shipped to Branches

The staging site must have the physical room to house all of the built domain controllers once the initial phase of the installation process is completed. In addition, to ensure that replication from the staging site domain controller continues right up to the time before shipping, the staging site must also have the network infrastructure that will allow all of the built computers to stay on the network. The problems that can occur if connectivity is not maintained are addressed in more detail in the next chapter.

Configuring the Replication Topology

For all large branch office deployments, the Inter-Site Topology Generator (ISTG), which automatically creates the replication topology between sites, is disabled in the staging site. In that respect, the staging site is not different from any other site. But this site is different with respect to the creation of a replication topology within the site.

The general rule is: "Never disable the ability of the Knowledge Consistency Checker (KCC) to generate the intra-site replication topology." Usually, little is gained by turning it off, while the risk of isolating computers from the rest of the deployment is very high. The staging site, however, is an unusual case where the topology should have a specific configuration, as opposed to the ring the KCC creates. Therefore, in the staging site it is necessary to disable the intra-site KCC.

When the KCC is used to create the intra-site replication topology, it always creates connection objects in such a way that the topology forms a bi-directional ring. The KCC on each domain controller is responsible for creating and maintaining the incoming connection objects. The ring is built as a result of the activities of the KCC on all domain controllers. In the case of a staging site, a ring would be a less than optimal topology: newly created domain controllers could create incoming connection objects from domain controllers about to be shipped. The initial period of operation for a new domain controller is crucial because the initial setup and configuration continues as a result of replication with its replication partner.

After a new domain controller is installed, it is necessary to keep the new server up and running for a period of time prior to shipment. This must be done to ensure that the RID pool gets delivered, replication performs a full pass in both directions, that File Replication Service (FRS) replication succeeds and SYSVOL is shared, and that the domain controller actually advertises itself as domain controller and a global catalog server, if so configured. During this period, by creating manual connection objects between each new domain controller and the staging site domain controller, you can ensure that this replication is success.

If the KCC had created the connection objects between the domain controllers, when each domain controller was prepared for shipment to the branch office, it would be easy to remove all connection objects from the computer and leave only the ones that would be needed in the branch office later. It is hard to determine, however, which other domain controllers have created connection objects to this computer. If the computer now comes online in the branch office, and the site move has not yet been replicated to all other domain controllers, active domain controllers from the staging site might try to create a connection object with the branch computer, not knowing that it is now in another site. This would lead to replication over the WAN, until the site move is replicated to all domain controllers.

To prevent these problems, the KCC should be disabled from creating the intra-site topology only in the staging site. Manual connection objects going in both directions, must be created between the staging site branch domain controller, which is used as the source for new branch domain controllers, and the each new domain controller.

Capacity Planning

There is only one domain controller in the staging site. If the plan is to install global catalog services on the branch office domain controllers, then the staging site domain controller should also be a global catalog server. If not, it can be a normal domain controller, installed in the same way as the branch office domain controllers (especially if the "Ignore GC failure" registry key is set, so that users in a native mode domain can be logged on, even if no global catalog server is reachable).

The performance of the staging domain controller depends on the number of domain controllers which are being installed at the same time. If the Active Directory Installation Wizard (dcpromo) runs on only one server at a time, the staging site domain controller can be a mid-class computer, (for example, a single processor XEON 600 with 512 megabytes (MB) of RAM). If the expectation is that more than one computer will use the staging site domain controller at the same time as its dcpromo source or there will be a large number of staged domain controllers running at any given time in the staging site, the hardware requirements are identical to those for bridgehead servers. The number of concurrent replication partners can be used to determine the hardware specifications. If 10 domain controllers are installed at a time, this maps to 10 concurrent replication partners as a bridgehead server, and that should be used as the hardware specification.

Software Installed on Domain Controllers

For every deployment, it is absolutely necessary to document the software version installed on new servers and domain controllers. This includes Service Pack (SP) releases as well as single Quick Fix Engineering (QFE) solution, as well as any other software or utilities installed.

If the decision is made during a mass roll-out to go to either a later Service Pack release or to add another QFE to the software to be installed on new domain controllers, three things must happen.

1. Before any changes are applied to a production computer, the installation of SPs and QFEs must be tested on a number of computers. For the purpose of testing, the staging site should always have one spare computer available. This computer should match the hardware standard used for branch office domain controllers exactly, meaning, it must be same type of computer, with the same configuration (number of CPUs, network cards, graphic adapter cards, etc.).

2. The new SP, QFE, or other software needs to be included in the software source used to install new servers and domain controllers.

3. The documentation has to reflect accurately which computers were installed with older releases, which computers have the newer software configuration, and what each configuration includes.

A safe way to ensure that all computers have the same software release is to clone new systems as stand-alone servers from one image, and then promote the servers to domain controllers. This computer can also be used as a spare computer, in case the staging site domain controller becomes unavailable.

In addition to the operating system, it is also necessary to install any software needed for ongoing monitoring and troubleshooting. If an image is used, add this software to the image. At a minimum, this includes the Support Tools (from the Microsoft Windows 2000 Server operating system installation disc) and the Windows 2000 Server Resource Kit. The scripts included with this guide, as well as any in-house developed scripts should also be included in the image. Again, the release version of these scripts is as important as that of the operating system. If the scripts are used to monitor the environment, make sure that up-to-date scripts will be installed on all systems. It must be part of a post-installation quality assurance test to check for the correct version numbers of in-house scripts.

The same applies if a monitoring solution, like NetIQ's Operations Manager is used. Installing monitoring agents as part of the domain controller staging process will help keep network traffic low between the hub site and the branch office sites since it will not have to be deployed over the WAN at a later date.

Included with the Active Directory Branch Office Deployment and Operations Guide are several checklists that can be used to document each step of the deployment process along with the installed software.

Monitoring

The most important aspect for monitoring the staging site is that the staging site needs to be able to replicate with the hub site. Tools like Repadmin or Replmon from the Support Tools and the Resource Kit should be used on a daily basis to guarantee that this is happening. See Chapter 9, "Post Deployment Monitoring of Domain Controllers" in the Active Directory Branch Office Deployment and Operations Guide for more information on Monitoring.

Planning and Configuring Third Party Monitoring Tools

In addition to the scripts included with this guide and the Microsoft Windows 2000 Resource Kit utilities, there are third party tools that can be used to monitor your Active Directory environment. This section provides information on using the NetIQ tools for monitoring your Active Directory environment. As with any tool, you should test this tool in your environment and evaluate the load it may place on your network while performing its data collection.

Monitoring with NetIQ

NetIQ Corporation offers several products that provide control and automation for monitoring enterprise performance, security, and service availability. These NetIQ products include AppManager, Operations Manager and Security Manager.

Operations Manager and Security Manager provide specialized security monitoring and operations management for specific applications and environments. AppManager provides advanced performance and availability monitoring with diagnostic and recovery task support.

Operations Manager and Security Manager are tightly integrated products that share monitoring infrastructure. AppManager uses a complementary infrastructure. Operations Manager and Security Manager can integrate with AppManager using the NetIQ Operations Connector, which enables two-way data sharing. Security Manager will not be discussed in this document.

Operations monitoring is crucial to maintaining stability and availability of a distributed system. Many such tools are available. We tested Operations Manager and AppManager, and as such, these will be the tools discussed.

Planning the Monitoring Infrastructure

The three most important considerations determining management system infrastructure design are

1. Number of servers to be monitored

2. Volume of auditing data to be collected

3. Topology/geography of monitored servers

If the total deployment will monitor fewer than 200 servers, a single server is usually adequate for any topology, unless extensive auditing is required. Operations Manager does complete event log management, including collecting and correlating security events. These events are the most numerous and a poorly configured server can generate millions of events per day. The following schedule can be used to determine the type of hardware recommended, assuming moderate security auditing.

For installations larger than 200 monitored servers, some functions should be broken out onto additional servers. If the budget allows, it is recommended to break the functions into multiple servers prior to the 50 server level for expandability and redundancy of central components. The servers listed below can be duplicated (i.e. buy two and set them up identically) to serve as load balancing and/or redundant servers. Also, multiple management servers can be used with a single database server. For instance, the 400-800 monitored-server case below assumes up to six management servers per database, resulting in several thousand servers feeding operational data to a single store. The total storage capacity of the database servers assumes moderate collection of long-term trending data. If you have a need to store performance data for more than three months, or security data for more than one month, consider a query server. With this, you can reduce the size of the management server database and keep less data. The query server is an additional, large reporting server that extracts data from the database on a regular basis and keeps it for long-term storage and reporting.

Refer to the Operations Manager User Guide for a complete discussion of the Operations Manager architecture, components, and Configuration groups.

Design Monitoring/Management Before Deploying

Think about monitoring and management of the infrastructure before completing design and deployment. It is far more costly to retrofit management into an existing deployment than it is to engineer it in at the beginning. There is a tendency to think that the designers can come back later and think about these issues. However, by that time, the network topology is in place and server allocations have been made and attempting to wedge some solution in at that point is complex and prone to failure. This results in added costs, randomization of technical experts, and, often, poor service while servers are deployed and running without monitoring.

Monitoring tools require connectivity between the managed server and the management server. For Operations Manager, this requires port 51515 over TCP/IP. In addition, for full function of the OM Agent Manager, RPC must be available. This document will explain how to install the agent as part of the server staging process, reducing much of the need for RPC. The bandwidth requirements are nominal, but should be considered before deploying an application that is going to take up already precious WAN bandwidth. Chariot from NetIQ allows "what if?" testing of network infrastructures prior to new service deployment. This kind of testing is worthwhile for both the management solution and the solution that it is managing (such as Active Directory).

AppManager requires ports 9998 and 9999 over TCP/IP. RPC is required for remote agent installation. This document will explain how to install agents as part of the server staging, so remote installation should not be an issue.

Operational Model and Management Servers

Like planning the management solution prior to deployment, it is important to consider the operational model of the IT center in designing the management solution. If there is central enterprise management, it is very likely that management servers and the database should be located at the central IT center. If there is local management, or a multi-tiered hub-and-spoke network design, smaller management servers should be deployed at the hubs and should be configured in a tiered structure for centralized management, monitoring, and audit data collection.

Individual targeted configuration steps are at various point in this guide. Below are the recommended agent installation steps for installing agents on servers before shipping those servers to their remote sites.

Summary

After reading this chapter, you should understand the physical and operational requirements for creating and operating a successful staging site. The next chapter addresses the planning required to ensure that the process of building domain controllers at the site is also successful.