Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

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 1 - Overview of Planning 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.

This chapter presents the purpose and scope of this Active Directory Branch Office Planning Guide. The following chapters discuss the concepts and steps necessary to plan for a deployment of the Microsoft Windows 2000 operating system and Windows 2000 Active Directory service in a branch office environment.

On This Page

Introduction
Scope
Summary
For More Information

Introduction

Microsoft Windows 2000 is a relatively new operating system, capable of being deployed in both large and small corporate environments. While the Windows 2000 Resource Kit is the first resource for companies planning to deploy Windows 2000, in corporate branch environments, additional planning, configuring, and monitoring is necessary to ensure a smooth branch office deployment. The objective of this guide is to present a recommended method of planning the deployment of Windows 2000 Active Directory service in a branch office environment. Note that the Active Directory Deployment and Operations Guide is a companion to this guide. It uses the plan developed here and guides the reader, step by step, through the Windows 2000 branch office deployment, providing scripts to simplify and speed the process. Although this guide discusses branch office deployments, much of the information can be adapted to other environments, including the sections on staging domain controllers, monitoring domain controllers, and the associated scripts.

A branch office deployment, in terms of this guide, is one where there are numerous branch offices, with slow links to a corporate hub or data center. While this guide focuses on the planning for a simple hub and spoke deployment, the planning can be extended to a more complex, multilevel multi-hub and spoke deployment. For the more complex environment, breaking the corporate network design into smaller hub and spoke modules will allow you to use the guidelines and configuration presented here and in the Active Directory Deployment and Operations Guide.

Concepts

This guide is written for readers who have an understanding of Windows 2000, Active Directory, Domain Name System (DNS), and replication as can be found in the Windows 2000 Resource Kit, and other recommended White Papers (see More Information at the end of this chapter for a list of resources). We have, however, included a review of basic concepts and terms. This is not intended to replace the aforementioned resources; it is not possible to summarize all of the prerequisite knowledge assumed in the presentation of this paper. The objective of this guide is to build on information presented elsewhere, and to omit information that is available in other Microsoft sources.

Chapter Overview

This guide consists of six chapters, each dealing with a specific aspect of planning an Active Directory branch office deployment.

Chapter 2. Structural Planning for Branch Office Environments

This chapter will guide you through the process of planning the logical structure for your Active Directory branch office environment.

Topics covered include:

  • Structural Planning

  • Domain Controller and Global Catalog Placement

  • DNS Design Recommendations

  • Determining the Number of Sites

Chapter 3. Planning Replication for Branch Office Environments

This chapter will guide you through the process of planning your bridgehead servers and connection objects, based on Active Directory and File Replication Service (FRS) replication.

Topics covered include:

  • Replication Fundamentals

  • Components of the Replication Topology

  • Determining the Choice of Bridgehead Servers

  • Determining the Number of Bridgehead Servers

  • Configuring Replication Topology for Large Branch Office Deployments

  • Using KCC with a Small Number of Sites (<100)

Chapter 4. Planning the Hub Site for Branch Office Environments

This chapter will guide you through the process of planning your hub site, including building and maintaining your root and branch office domains.

Topics covered include:

  • Data Center Strategy

  • Building the Root Domain

  • Building the Branch Office Domain

  • Monitoring and Key Performance Indicators

  • Server Sizing

  • Disaster Recovery

  • Firewalls

Chapter 5. Planning the Staging Site for Branch Office Environments

This chapter will guide you through the process of planning your staging site.

Topics covered include:

  • Best Practices for Building a Staging Site

  • Configuring the Replication topology

  • Capacity Planning

  • Software Installed on Domain Controllers

  • Monitoring

Chapter 6. Building the Forest Root Domain and Central Hub Site

This chapter will guide you through the process of planning how to build, verify, and monitor branch office domain controllers. This includes everything from installation at the staging site through moving the domain controller to its branch office.

Topics covered include:

  • Design Considerations

  • Installing Software

  • Promoting the Server to a Domain Controller

  • Preparing the Computer for Transport

  • Alternative Configuration

  • Documentation

  • Post-Deployment

Scope

Branch Office

The characteristics of a branch office deployment as discussed in this guide include most, if not all, of the following:

  • A large number of locations with domain controllers.

  • A small number of users per location.

  • A large number of domain controllers.

  • A hub and spoke network topology.

  • Slow network connectivity to the branch office locations.

Large Number of Locations with Domain Controllers

The fact that a deployment has a large number of locations with domain controllers does not necessarily make it a branch office deployment in the context of this guide. In some large deployments the network may provide reliable, medium to high speed network connections which can be used to log on users over the wide area network (WAN). In this case, a small number of domain controllers could be installed in a data center or hub and there is no need for domain controllers in all remote locations. Since a centralized deployment model like this is less complex and easier to operate and monitor, it is preferred, but only if the network can be trusted to handle user logon operations at all times.

In the cases where the WAN cannot be trusted for logons 24 hours a day and 7 days a week, planning and deployment require more thought. In most cases, a domain controller has to be installed in the remote locations. Planning Chapter 2, "Structural Planning for Branch Office Environments," presents when to put domain controllers into a remote location.

Small Number of Users Per Location

Another feature of the branch office deployment discussed in this guide is that there are a small number of users in each branch location. Examples of companies that meet these conditions are insurance companies and banks. Insurance companies frequently have a large number of subsidiaries and branches, each with a small number of employees. Again, small in the context of this guide means between 10 and 50 users of computers and network services.

Large Number of Domain Controllers

A large number of domain controllers implies that there may be a need for a staging site, which may or may not be contracted out, and that the number of branches to which domain controllers are being deployed is more than 100.

Hub-Spoke Topology

Usually in branch environments the topology is comprised of one or more hub locations, and spokes that extend from the hub or hubs, as indicated in the following figure.

Cc749943.adplc101(en-us,TechNet.10).gif

The simple hub and spoke topology shown above is used for all discussions in this guide, that is, a single hub with slow links to the branches, acting as spokes. This Active Directory Planning Guide steps you through the process of planning the above environment. The accompanying Active Directory Deployment and Operations Guide then steps you through the process of building the above environment.

There is little explicit discussion of planning for a complex topology as shown in the following diagram.

Cc749943.adplc102(en-us,TechNet.10).gif

Figure 2: Complex Hub and Spoke Topology

For the complex hub and spoke case, you can use the planning presented here for each hub and its spokes, as well as the deployment procedures presented in the Active Directory Deployment and Operations Guide. Each set of hub and spokes can then be combined in a larger hub and spokes design, in a nested or layered fashion.

Slow Network Connectivity to Branch Locations

A common scenario in a branch office environment is that locations are often linked to the corporate data-center or hub by slow WAN links. For our scenario a slow link is defined as a link with a line speed between 19.2 kilobits and 64 kilobits. Such a link could be either a dial-up link or a leased line. To plan the right topology when working over slow links, you should know the following:

  • The real available bandwidth over 24 hours

  • The stability of the link

  • What other services are going to use the link (such as Exchange, Backup, Systems Network Architecture (SNA), Microsoft SQL Server, or Internet access)

Management Models for Handling Branch Office Scenarios

There are basically two different management models to consider in a Windows 2000 deployment scenario: centralized and decentralized. According to the centralized management model, changes are made at a corporate level and replicated to the branches. With the decentralized approach, changes are mostly made at the branches and are replicated through a hub to the rest of the domain and the forest. Management of users and groups, as well as Group Policy management should be considered in light of these two models, since each will have significant effects on replication traffic, and therefore on the load on domain controllers.

Managing Users and Groups

When managing users and groups, there are pros and cons to each model.

There are advantages and disadvantages to a centralized management modelwhere all objects in the organization are managed by one central IT organization:

Advantages

Disadvantages

Good security control and policy enforcement

Success varies directly with the availability and speed of the local area network (LAN) or WAN.

Easy automation of common management tasks from a single source point

Propagation changes are time-consuming, depending on the replication infrastructure and the replication schedules.

Problems can be fixed quickly

Time to react and to fix issues might be longer.

In contrast, in the decentralized management model the IT organization is divided into smaller divisions based on geographical, political, or organizational needs, and management of users and groups is distributed. The tradeoffs in this situation are as follows:

Advantages

Disadvantages

IT organization tends to be closer to the "customer"

Automation of tasks needs to be coordinated

Less replication traffic inbound-from hub to the branches

More replication traffic inbound-from branches to the hubs

Managing Group Policies in a Distributed Environment

As with user and group management, Group Policy management can be centralized or decentralized.

In the centralized approach, all Group Policies are created by administration staff in the data centers (or hubs) and flow from the data centers to the branch offices. Changes will never occur at the branch level. Typically, there is no local personnel with complete administrator rights available in the branch.

In a decentralized environment, the regional IT organizations will have the knowledge and ability to add to the group policies and be able to override certain settings. Just as with decentralized user and group creation, this will cause more replication to originate at the branches, causing more inbound replication traffic at the hub site.

Warning: The biggest problem with decentralized group policy management is that the changes are focused on the Primary Domain Controller (PDC) Emulator for the domain, which is located at the hub. We recommend, therefore, that you centralize the creation of Group Policies.

For the purposes of the planning discussions in this guide, assume a centralized model. Realize, however, that where your organization's administration model differs, you must consider the effect this has on your replication traffic patterns. The purpose of this guide is to present the basic building blocks of the planning process, which will enable you to complete a plan that suits your organization, and its administrative and network structure.

Summary

While this guide is focused on the planning for a branch office deployment within the parameters defined in this chapter (a large number of locations with domain controllers, where each location has a small number of users and has slow WAN connectivity) the issues and concepts discussed here are frequently relevant in other scenarios. The following chapters discuss the structural planning considerations, the planning needed for replication, and the planning that should take place to have a successful hub site and staging site. Quality assurance steps are presented, including monitoring. While the specifics of this guide relate to large branch office deployments, the general concepts and issues are helpful in many other scenarios.

For More Information

Resource Centers on the Web

For more information, refer to the following external resources on the Internet at microsoft.com.

Windows 2000 Technical Resources:

http://www.microsoft.com/windows2000/library/

Windows 2000 Developer Support Center

http://msdn.microsoft.com/windows2000/

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.