Deploying Active Directory for Branch Office Environments
| 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 1 - Overview of Deploying and Operating Active Directory for Branch Office Environments
Operating System
Deployment and Operations Guide
Abstract
This chapter provides an overview of the process necessary to deploy and maintain Active Directory™ directory service in a large branch office environment. For the purposes of this guide, a large branch office environment is considered to be 100 or more branch offices. This chapter gives you a high-level overview of the deployment process and explains the steps that you need to take to complete a successful branch office deployment.
Introduction
Deploying Active Directory™ directory service in a large branch office environment, in which each branch will have a domain controller locally and branches may be connected to the corporate data center through low-speed links, can be a complicated procedure. This guide intends to simplify this process by providing you with a series of easily understandable steps that will help you achieve your goal of implementing Active Directory in a branch office environment of 100 or more branches.
This guide is aimed at network managers, system integrators, and consultants involved in Active Directory branch office implementations, either in their own organizations or for client companies. By implementing the procedures in this document, you should be able to deploy and maintain Active Directory in a large branch office environment.
Topology Overview
This guide will walk you through the process of building the following branch office architecture:
.gif)
This architecture consists of the following four components:
The root domain, corp.hay-buv.com, with three root domain controllers in the hub site.
The branch office domain, branches.corp.hay-buv.com, with four domain controllers in the hub site. One of the domain controllers is the operations master roles holder and the bridgehead server for the staging site. The other domain controllers are the bridgehead servers for the branch offices.
The staging site with a domain controller that is the source domain controller for the staging process.
The branch office sites.
The example architecture includes three bridgehead servers for the branch offices. Based on the decisions you made in the Planning guide, you will need to create the number of bridgehead servers that you determined are necessary for your environment.
This guide will walk you through the configuration of this scenario by giving you instructions for every phase of the deployment. By repeating the domain controller staging process in Chapter 6, "Staging a Branch Office Domain Controller," you can scale out the number of branch offices to meet your organization's requirements. Information will be included on using and configuring appropriate management and monitoring tools.
The chapters in this guide use the domain names and Internet Protocol (IP) addresses shown in the previous diagram whenever an example is appropriate. Therefore, you will want to have a copy of this diagram available as you go through the chapters and substitute the information in the diagram with your domain name and IP addresses.
Chapter Overview
This guide consists of 11 chapters, each dealing with a specific aspect of implementing an Active Directory branch office deployment.
Chapter 2 Building the Forest Root Domain and Central Hub Site
In this chapter, you build the forest root domain and the central hub site. This provides the foundation for your Active Directory branch office deployment.
Topics covered include:
Installing Microsoft Windows 2000 and Service Packs
Configuring Transmission Control Protocol/Internet Protocol (TCP/IP)
Creating Domain Name System (DNS) Zones
Creating the Forest Root Domain
Configuring DNS Forwarders
Extending the Forest Schema
Renaming the Default First Site
Verifying the Root Domain Configuration
Automating Quality Assurance (QA) of the Root Configuration
Chapter 3 Building the Branch Office Domain and Bridgehead Servers
After the root domain is in place, you can build the branch office domain and the bridgehead servers that will support the branch office domain controllers. In the Active Directory Branch Office Planning Guide, you will have already determined the number of bridgehead servers that your environment will require.
Topics covered include:
Configuring and Verifying DNS on the Branch Office Bridgehead Servers
Promoting and Verifying the Bridgehead Servers
Transferring Operations Master Roles.
Chapter 4 Pre-Staging Configuration at the Hub
After configuring the bridgehead servers in the hub site, it is necessary to perform some configuration before creating the staging site and beginning the process of staging branch office domain controllers. This chapter outlines the steps to perform the necessary configuration at the hub site.
Topics covered include:
Disabling Automatic Site-Link Bridging
Creating the Branch Office Sites
Disabling the Intersite Topology Generator (ISTG)
Creating Your Hub and Spoke Topology
Disabling the Intrasite Knowledge Consistency Checker (KCC) for the Staging Site
Configuring the Branch Domain Controller Installation Scripts
Chapter 5 Creating and Configuring the Staging Domain Controller
After the hub site is configured, you can configure the staging site domain controller, which will be the source domain controller for all staged branch office domain controllers.
Topic covered include:
Installing the Staging Site Source Domain Controller
Configuring and Verifying DNS
Promoting and Configuring the Domain Controller
Creating Connection Objects
Quality Assurance and Monitoring of the Staging Site Domain Controller
Chapter 6 Staging a Branch Office Domain Controller
After the staging site domain controller is in place and its configuration has been verified, you will be ready to stage a branch office domain controller. Several scripts are provided with this guide and are used in this chapter to simplify the staging process.
Topics covered include:
Installing a Staged Domain Controller
Verifying DNS
Promoting and Configuring the Branch Office Domain Controller
Post Dcpromo Quality Assurance of the Branch Office Domain Controller
Chapter 7 Pre-shipment Configuration of the Branch Office Domain Controller
Following successful quality assurance verification of the branch office domain controller, you will need to perform several pre-shipment tasks. The procedures in this chapter should be performed only immediately prior to shipment of the domain controller to the branch office.
Topics covered include:
Verifying the Site and Moving the Domain Controller to its Destination Site
Verifying the ISTG is Disabled on the Staged Domain Controller
Creating the Branch Office Domain Controller's Connection Objects
Configuring TCP/IP for the Branch Office
Configure File Replication Service (FRS) and DNS for Shipment to the Branch Office
Chapter 8 Quality Assurance of the Domain Controller at the Branch Office
After a staged domain controller arrives at its branch office, it requires additional quality assurance and some final configuration to ensure that it is working properly. This chapter provides the procedures for the necessary quality assurance and configuration.
This chapter covers:
Final Configuration of the Branch Office Domain Controller
Quality Assurance of the Branch Office Domain Controller
Chapter 9 Ensuring Active Directory Health in Branch Office Environments
After completing your deployment of Active Directory in a branch office environment, it is necessary to continually monitor the environment. This will ensure that Active Directory is functioning properly in all of your branch offices and indicate any branches that may be having problems so that they can be resolved.
This chapter covers:
General Domain Controller Monitoring
Redundant Connection Objects
Monitoring Active Directory Replication
Monitoring FRS Replication
Chapter 10 Disaster Recovery for Branch Office Environments
If you encounter problems in your environment, the disaster recovery procedures in this chapter can help you to recover.
This chapter covers the following areas:
Backup and Restore
Repairing the Active Directory Database
Using Windows 2000 Terminal Services to Remotely Backup and Restore Active Directory
Staging Replacement Domain Controllers
Chapter 11 Troubleshooting Guidelines for Branch Office Environments
Chapter 11 provides procedures that can be used to troubleshoot issues with an Active Directory branch office deployment. If you encounter issues during the staging process, the procedures in this chapter can assist you in resolving the issues.
This chapter covers troubleshooting:
TCP/IP AND DNS Configuration
Active Directory Replication Troubleshooting
Troubleshooting Replication Errors
Fallback Plans
Troubleshooting FRS
Non-authoritative FRS Restore
Resource Requirements
As with any large technology project, having the right resources for planning and deployment is essential. Your specific resource requirements will depend on a number of trade-off factors including project scope, solution features, implementation schedule, and budget. In addition, the skill level and makeup of your existing Active Directory services team will impact your needs for team training and external resources. The resources that you will require for an Active Directory branch office deployment fall into five categories.
Hardware
Software
Personnel
Time
Space
Hardware
The specific hardware requirements for Active Directory will depend on the expected service level and load that is defined in the Vision Scope and other planning documents. For example, the number of branches that will be serviced by each bridgehead server and the expected replication load during each replication connection will impact the processor and memory requirements for the bridgehead servers. In addition, the load generated by client and server DNS queries and the number and frequency of directory look-ups from directory-enabled applications will impact hardware requirements in terms of configuration and quantity.
The following table shows the minimum requirements to install Windows 2000. The recommended configuration is based on a number of existing branch office deployments. Your specific hardware requirements may be different depending on the specific parameters of your deployment.
Item |
Minimum |
Recommended |
|---|---|---|
Processor |
Pentium-compatible 133 megahertz (MHz) processor or higher |
Dual/quad Pentium III or Xeon recommended for bridgehead servers and servers supporting large numbers of users. |
Memory |
128 megabytes (MB) |
Minimum of 512 MB |
Disk space |
1 gigabyte (GB) of free disk space on the disk drive where you install the Windows 2000 operating system. |
Configure the operating system and logs on separate drives that are mirrored. Configure directory database on Redundant Array of Independent Disks (RAID) 5 or RAID 0+1. |
Compact disc read-only memory (CD-ROM) drive |
Fitted |
|
Monitor |
VGA |
SVGA |
Software
The following table lists the required software for deploying Active Directory in a branch office environment.
Item |
Comments |
|---|---|
Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Data Center Server |
The version of Windows 2000 you require will depend on the size of your organization, the number of clients you wish to support, and the features that you want to use, such as support for clustering. |
Windows 2000 Service Pack 2 |
Available for order or download at https://www.microsoft.com/windows2000/downloads/servicepacks/default.asp. |
Microsoft Windows 2000 Resource Kit |
This includes in the seven-volume set Microsoft Windows 2000 Resource Kit. |
ZIP file containing the Active Directory Branch Office Installation files. |
This ZIP file will be installed on the first server and used as a share point for all other servers. Chapter 2, "Building the Forest Root Domain and Central Hub Site," contains details about how to install it. |
Personnel
Active Directory impacts your entire organization, so it should not be surprising that the personnel involved in its deployment will cross all boundaries in a company. The team makeup described in this document is based on the Microsoft Solutions Framework (MSF) "Team of Peers" approach. MSF has been extremely successful when used with projects such as this in which many groups and aspects of the organization will be required to participate. It is recommended that the following roles be established early in the process of planning and deploying Active Directory services.
Permanent Roles (in order of probable involvement)
Network Administrator
User Education/Training/Communication
Desktop Administrator
Infrastructure Administrator
Intranet/Internet Administrator
Logistics Management
Project Roles
Project Manager
Deployment Administrator
Testing/Quality Assurance Team
In addition, the following individuals will play a role in the project planning or deployment:
Chief Executive Officer/Managing Director
As the owner of the vision statement, the CEO will participate in making critical trade-off decisions. The CEO will want to be informed about the progress of the deployment and may participate in the project planning in terms of defining key milestone dates.
Chief Information Officer/IT Director
In most organizations, the CIO (or equivalent) will not be the hands-on architect of the deployment. However, the CIO will usually be the management sponsor for the Active Directory project and should be willing to provide the support for implementation at the board level. This includes the coordination of cross-team dependencies. The CIO will also participate in the development of the vision statement, risk assessment, and the planning of key milestones.
Departmental Heads
Departmental heads are usually involved insofar as the project cuts across departmental boundaries. Normally, the CIO will brief the departmental heads and ensure cooperation, such as when requesting volunteers for the pilot program.
Network Manager/System Administrator
Normally the person who ends up doing most of the planning and day-to-day work on the deployment is the network manager, which makes the network manager the project manager by default. It is assumed that in most cases this will be the reader.
Consultants/System Integrators
Some organizations will outsource the project management aspect of deployment, whereas others may bring in technical assistance. The organization may choose to do both. In addition, a third party may be used for the staging and deployment of new domain controllers to branch office sites. The logistics manager and quality assurance team will play a critical role in ensuring that staging processes are followed and domain controllers are operational before and after deployment to the branch office.
Technicians/Server Operators
Technicians or server operators can help with building servers, installing the client software onto users' machines, setting up labs, and carrying out various jobs in the pre-pilot and pilot phases. These individuals will ensure that build processes have the necessary steps for implementing enterprise-monitoring tools.
Help Desk/Operations
The help desk and operations staff should be involved early in the planning and testing. Early involvement will allow them to receive the proper training and they can participate with integrating Active Directory monitoring into existing processes, procedures, and change control.
Pre-Pilot and Pilot Users
A pilot deployment helps identify issues early in the process and provides a structured environment for resolving these issues.
Space
During an Active Directory deployment, you must have space for the following activities:
Planning (somewhere quiet)
Lab testing
Pre-pilot and pilot program
User and technical training
Server installation
Active Directory Implementation Plan
Project Management - Microsoft Solutions Framework (MSF)
Statistics show that a significant number of large information technology (IT) projects fail. There are many reasons for failure: constantly changing requirements, volatile or incomplete specifications, poor quality coding, a scope that is too big, inadequate staffing, poor process, unclear goals, and so forth. MSF addresses these issues through its Team and Process Models.
MSF is a proven project management framework that has been used in thousands of Microsoft Consulting Services (MCS) engagements. This framework is used internally at Microsoft and encompasses best practices for project management. MSF matches up well with the project management requirements for a large Active Directory deployment for a branch office environment. MSF provides tools and best practices for bringing together a large number of diverse groups that will be required to interact throughout the life cycle of the project.
MSF Team Model
The MSF Team Model can be applied to infrastructure deployment projects, in addition to software development. In this case, the role of development may consist of technical evaluation, monitoring, setup, and configuration of the product or service.
The MSF Team Model is defined as a team of peers working in interdependent and cooperating roles. Each team member has a well-defined role on the project and is focused on a specific mission. This approach encourages ownership and ultimately results in a better product. The leaders of each team are responsible for management, guidance, and coordination, and the team members focus on carrying out their missions.
Depending on the project size, each role may be assigned to a single individual or to a team of people with a team lead. Alternatively, one person may take responsibility for more than one role.
Each team member estimates their own workload. These estimates are rolled into the project plan for their respective role on the team. The project plan for each team role becomes a part of the master project plan.
In a successful team, every member feels responsible for the quality of the product. Responsibility for quality cannot be delegated from one team member to another team member or function. Similarly, every team member must be a customer advocate.
The MSF Team Model key themes are as follows:
Each member has a defined role and specific mission.
Leaders are responsible for management, guidance, and coordination.
Everyone focuses on execution.
Communication is unrestricted.
Every member is responsible for the quality of the delivered product.
MSF Process Model
The process model for infrastructure deployment consists of the following four phases, each culminating in an externally visible milestone:
The envisioning phase is the period during which the team and the customer define the business requirements and the overall goals of the project. The mission starts with determining what the customer wants to accomplish and then committing to it. The envisioning phase culminates in the vision/scope-approved milestone, which indicates team and customer agreement on project direction. In addition, the preliminary risk assessment is completed.
The planning phase is the period during which the team and the customer define what will be built and deployed, in addition to how and when it will be built and deployed. The planning phase culminates in the project plan approved milestone, which indicates the project team, customer, and key project stakeholders agree on what will be delivered and when.
The detailed architecture, including the number of forests, domains, sites, and so forth, is developed in this phase. Capacity planning for bridgehead servers and logistics planning is started in this phase. The communication plan is developed and executed during the pilot and production deployment.
The communication plan must include mechanisms for the various teams, including deployment staff, support teams, design engineers, and executive sponsors, to maintain frequent and open communication regarding project status. Having an effective communication plan will greatly improve the likelihood of project success.
The developing phase is the period during which the team builds and tests the solution. It is especially important to test assumptions and processes to ensure the deployment goes smoothly. The lab should be available throughout the life cycle of the project.
After testing, the team pilots the technology and stabilizes it in preparation for release. See the Pilot section below for more recommendations about this phase of the project.
The developing phase culminates in the release milestone, which indicates that the solution is ready to be deployed in production.
The deploying phase is the period during which the team deploys the solution to all sites and ensures that it is stable and usable. The root Active Directory domain and base Windows 2000 infrastructure is deployed and monitored. Monitoring and quality assurance processes are used during this phase to ensure that the released solution meets customer expectations and the requirements specified in the Vision Scope document.
The deploying phase culminates in the deployment complete milestone, at which point responsibility for the solution shifts to the operations and support teams.
Risk Management
"At virtually every stage of even the most successful projects, there are large numbers of very important things that are unknown." Jim McCarthy, Dynamics of Software Development
Risk is the possibility, not the certainty, of suffering a loss. The loss could be anything from diminished quality of a solution to increased cost, missed deadlines, or project failure. Risk is a fundamental ingredient of opportunity and therefore is not inherently bad, but it is a factor in every project. Successful teams deal with risk by recognizing and minimizing uncertainty.
During the envisioning phase, the team completes a preliminary risk assessment. Keep the following recommendations in mind when managing project risks:
Assess risks continuously throughout the project life cycle.
Use risk-based decision making.
Use a consistent process to establish some level of formality.
Cover all key persons and processes, including business and technology areas.
Treat risk identification as a positive.
Pilot Planning
Early phases of any technology integration project encompass mainly high-level, theoretical views of potential solutions and their impact on the business. Although the development of a functional specification may necessitate proof-of-concept initiatives, these activities are normally constrained to the controlled environment of the testing lab.
By contrast, the purpose of the technology pilot is to begin introducing new applications of technology into the mainstream of the business. Furthermore, the successful pilot facilitates this introduction while minimizing potential risk to existing systems and processes. The pilot also provides a wealth of critical information about the true ability of the proposed solution to fulfill its objectives. The pilot is much more than a prototype. It is a truly scaled model of the actual environment in which the production system will operate. In essence, the pilot is simply a limited deployment that offers the advantage of early course correction.
In the case of a branch office scenario, conducting a pilot is crucial to ensuring a successful Active Directory deployment. Keep the following recommendations in mind when planning your pilot:
Ensure key personnel are trained in advance.
Test procedures in a lab environment prior to pilot.
Document pilot activities in advance.
Document clear pilot objectives and timelines.
Establish change control procedures for the pilot.
If the deployment of domain controllers is outsourced, include third parties early in the process of developing and testing procedures. They will be more likely to understand and follow the process.
Communicate and set expectations early with pilot users. Have a pilot champion.
Provide support channels for pilot personnel and users.
Provide feedback channels for pilot users and deployment personnel.
Involve operations support early in the process and test monitoring and Quality Assurance processes.
Monitor pilot activities closely to secure critical feedback.
Evaluate pilot results and make adjustments. Track changes and re-pilot adjustments.
Conduct a post-pilot review with key personnel.
Risk management and pilot planning are just a few of the many items to consider when planning a Windows 2000 deployment. For more information about planning and managing a Windows 2000 deployment, see the Microsoft Web site at:
https://www.microsoft.com/windows2000/library/resources/reskit/dpg/default.asp
Post Implementation Review Phase
After you have completed a successful deployment, you can review the entire implementation. The main purpose of this review is to document the state of the network in its new configuration.
More Information
For more information on MSF and how to apply it to this project, see the MSF resources on the Microsoft Web Site at:
https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise&AnnMenu=solutions
1200