Branch Office Infrastructure

Solutions
Directory Services Guide

Version 3.0

Published: February 2008

Revised: September 2008
For the latest information, please see
microsoft.com/BranchOffice
Copyright © 2008 Microsoft Corporation. All rights reserved. Complying with the applicable copyright laws is
your responsibility. By using or providing feedback on this documentation, you agree to the license agreement
below.

If you are using this documentation solely for non-commercial purposes internally within YOUR company or
organization, then this documentation is licensed to you under the Creative Commons Attribution-
NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or
send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS".
Your use of the documentation cannot be understood as substituting for customized service and information
that might be developed by Microsoft Corporation for a particular user based upon that user’s particular
environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS
ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY
DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering
subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your
use of this document does not give you any license to these patents, trademarks or other intellectual property.

Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places and events depicted herein are fictitious.

Microsoft, Active Directory, Windows Server 2008, Windows Vista, and Windows XP are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.

You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to
the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft,
without charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You
also give to third parties, without charge, any patent rights needed for their products, technologies and services
to use or interface with any specific parts of a Microsoft software or service that includes the Feedback. You will
not give Feedback that is subject to a license that requires Microsoft to license its software or documentation to
third parties because we include your Feedback in them.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents

Solution Accelerators microsoft.com/technet/SolutionAccelerators

iv Guide Title (for single guide/doc accelerator or accelerator title (for multi-guide/doc accelerator)

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Active Directory Domain Services
For many years, designing IT infrastructures that are capable of supporting branch sites
has been a challenging task. The complexities introduced by the limitations in available
network bandwidth, performance issues, and geographic separation, have a significant
impact on an organization’s ability to implement an appropriate single IT solution for all of
its sites. As wide area network (WAN) bandwidth and performance grows, client and
server technologies are also introduced (or enhanced) so that they support branch
operations better. However, although the situation will improve, there will always be a
fundamental difference between the design for a geographically distributed IT
infrastructure and the design for a single site. The addition of branch sites introduces a
number of significant constraints that modify the options that are available to solution
designers.
This guide updates the design that was described in the Directory Services section of
Chapter 3 of the “Branch Office Infrastructure Solution for Microsoft Windows Server
2003 Release 2” guide and specifically deals with the changes that are introduced by the
Windows Server® 2008 operating system. Although many of the fundamental design
principles in this guide remain the same, there are some important implementation details
that have changed, especially with the introduction of Read-Only Domain Controllers
(RODCs) which are designed specifically with branch officer scenarios in mind. This
guide provides the necessary updates to ensure your branch infrastructure designs take
advantage of the latest Active Directory® Domain Services (AD DS) design approaches.

Goals and Objectives

This guide introduces a method of designing AD DS for a service-based branch
infrastructure. The branch environment is typically part of a larger network that supports
an organization's main sites and data centers. However, the addition of branch sites
introduces a number of significant constraints that modify the options that are available to
solution designers. This guide describes how to look at the specific requirements of
branch AD DS in the larger context of an organization's IT services.

Audience
The primary audience for this guide is the experienced Infrastructure Architect or IT
professional who is responsible for designing the AD DS for a branch site infrastructure.
The AD DS is a fundamental part of the Windows Server platform and as such can
impact other services within the branch infrastructure. Therefore IT professionals
responsible for other services within the IT infrastructure will also benefit from this
guidance.

AD DS
Organizations that are currently using AD DS to manage authentication and authorization
for branch sites should already have a defined architecture for those branch sites, as well
as the organization as a whole. However, the task of effectively redefining and
streamlining the physical structure and organization of IT components for branch sites
requires that you assess how your existing forest and domain architecture can meet both
current and emerging branch site requirements because the most effective architecture
might not be that which is currently in place.
Guidance on designing a complete forest and domain architecture is out-of-scope for this
guide. However, there are several unique issues to consider for defining an architecture
that is specific to branch sites. The starting point for this effort is to define the logical

Solution Accelerators microsoft.com/technet/SolutionAccelerators

2 BOIS Directory Services Guide

structure for the forests and domains to which branch sites will belong. The design of the
logical structure for branch sites must take into account both the functional characteristics
of the available technologies and the individual requirements of branch sites. The
underlying goal for the design of the logical structure is always a single, centrally
managed forest and a single domain (unless specific requirements make this impossible).
Determining an appropriate logical structure requires an assessment of the following
factors:
• The most appropriate forest design for the solution
• The most appropriate domain design for the solution
• Appropriate replication traffic configuration for the network infrastructure
• Other forest and domain design considerations for the logical structure
Note This guide covers only general design considerations that are specific to branch sites. It
does not cover all of the processes and decisions that are required to define and design a
complete AD DS infrastructure or the details of deploying AD DS in a branch site, both of which
are covered in depth in other Microsoft documentation.
In addition to these factors Windows Server 2008 introduces a number of new
enhancements to AD DS including:
• Read-Only Domain Controller. A domain controller with a read-only version of
the Active Directory database can be deployed in branch environments where the
security of the domain controller cannot be guaranteed. The use of Read-Only
Domain Controllers (RODCs) prevents changes made at branch locations from
potentially polluting or corrupting your AD forest via replication. RODCs also
eliminate the need to use a staging site for branch office domain controllers, or to
send installation media and a domain administrator to the branch location.
• Fine-Grained Passwords. Password policies can be configured for distinct
groups within the domain. No longer does every account have to use the same
password policy within the domain.
• Restartable AD DS. The AD DS can be stopped and maintained if required.
Rebooting the domain controller and restarting it in Directory Services Restore
Mode is no longer required for most maintenance functions. Other services on
the domain controller can continue functioning while the directory service is
offline.
• Database Mounting Tool. A snapshot of the Active Directory database can be
mounted using this tool. This allows a domain administrator to view the objects
within the snapshot to determine the restore requirements when necessary.
Of these enhancements the single most significant in a branch infrastructure is the
introduction of the RODCs. The use of RODCs provides several benefits to branch
environments:
• RODCs prevent changes made at branch locations from potentially polluting or
corrupting your AD forest via replication.
• RODCs eliminate the need to use a staging site for branch office domain
controllers, or to send installation media and a domain administrator to the
branch location.
• Deploying an RODC in a branch allows users at that site to authenticate locally
instead of relying on authentication across a wide area network link.
To learn more, please visit the Active Directory page at:
http://www.microsoft.com/windowsserver2008/en/us/active-directory.aspx

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 3

Figure 1 provides a reference for the stages that are required for the AD DS design for a
branch infrastructure environment.

Figure 1. AD DS design reference

Most organizations already have a domain structure in place that is either servicing
branch sites or will have to be modified to support these environments. For more
information about how the logical structure of the domain model should be changed to
support the branch sites, see the “Designing the Logical Structure for Windows Server
2008 AD DS” at http://go.microsoft.com/fwlink/?LinkId=89024 or, for details of each step
in the design, see “Mapping Your Design and Deployment Tasks to an AD DS
Deployment Strategy” at
http://technet2.microsoft.com/windowsserver2008/en/library/5ed8b9ca-e88a-4e06-a203-
83d37b54d9bb1033.mspx?mfr=true.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

4 BOIS Directory Services Guide

The domain model used for the Branch Office Infrastructure Implementation Solution
(BOIS) example is a single forest design that has three domains that are arranged as
shown in Figure 2.

Figure 2. BOIS Active Directory domain model

This model is in line with the recommendations of the “Windows Server 2003 Active
Directory Branch Office Guide”, located at http://go.microsoft.com/fwlink/?LinkId=28523
because it provides a separate domain specifically for a branch site, which is a child to a
dedicated forest root. The following considerations may require you to modify this model
for your own business environment.

AD DS Forest Design
The first design option to consider is whether your organization requires a single forest or
a multi-forest design. The BOIS design model features a single forest design. Consider
the following issues when making this decision:
• Administrative overhead. A single forest model provides less administrative
overhead than the BOIS model; this can reduce your organization's support costs.
• Isolation requirements. If administrators are not trusted universally, you may need
to create additional forests to provide a security boundary between the different hub
and branch sites.
• Scalability. If your organization has more than 5,000 branch sites or more than
100,000 users, you may need to consider multiple forests.
The following primary forest design options are each associated with a number of
considerations:
• Place branch sites in the same forest as the hub site. This option represents the
preferred forest design for branch sites. When feasible, the optimum solution is to
have a single forest for the entire organization, which supports full integration. This
option provides the following benefits:
• Enables efficient directory service management, even with multiple domains,
because of the shared schema and configuration of a forest.
• Enables a single messaging infrastructure that is provided when an organization
uses a single messaging platform, like Microsoft Exchange.
• Does not require trust relationships to provide communication between branch
sites and the hub site.
• Facilitates secure management of trust relationships between domains, because
one enterprise administrator has authority to manage trusts within the forest.
This option requires:
• Centralized ownership of the critical high privilege accounts (enterprise
administrator and schema administrator) to facilitate change control and maintain
the integrity of the forest.
• Careful design of the administrative security delegation model to maintain
appropriate levels of control that result in granting the least possible privileges.
For more information, see “Best Practices for Delegating Active Directory
Administration”, at http://go.microsoft.com/fwlink/?LinkId=46677.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 5

• Stringent password protection policies for maintenance of cross-forest trusts.

This option can provide strong identity for one or more branch sites by
creation of a separate domain tree in the hub-site forest. (This is highly
recommended as opposed to creating a new forest.)
• Create a separate forest for multiple branch sites. This option should be used
only if it is not possible to place branch sites in the same forest as the hub site. This
option provides complete separation and security isolation, which can be appropriate
for branch sites that require the following:
• Distinct identity branding (separate from the corporate identity), where the forest
must reflect a unique identity (and a separate domain tree is not acceptable for
political or other reasons).
• Total and exclusive administrative control of services (isolation of service
management), where the branch site infrastructure is managed by a separate IT
organization or is outsourced.
• Total and exclusive administrative control of data (autonomous management of
information), such as might be required to provide maximum security for a branch
site with sensitive data.
Other considerations are that this option:
• Enables the schema to be different for the branch site infrastructure.
• Increases complexity in deployment and management of the directory service
because of the need to manage an additional directory service infrastructure.
This design also may complicate collaboration amongst users in the individual
forests because not all applications work well in this scenario or might require
meta-directory services to work. Finally, this option requires setting up of cross-
forest trusts.
• Requires thorough testing of all applications to ensure that they can provide the
required cross-forest functionality.
• Requires establishment of stringent password protection policies since cross-
forest trusts are needed.
• Create a separate forest for each branch site. This is the least preferred forest
design option and should only be considered if other options are not feasible. This
option provides complete separation and security isolation, which can be appropriate
for branch sites that require containment of each branch site. In the past, this would
be required if each office represented a significant security risk to other offices or to
the hub site. However, with the introduction of RODCs, the primary consideration
tends to be when regulatory requirements require a distinct separation of
authentication sources between sites. This option:
• Minimizes replication because the scope of the forest is limited.
• Eliminates problems associated with replication to a branch site that has
extremely limited network availability; the branch site can be disconnected from
the network for a long period of time.
• Can limit the security impact of standing up or recovering forests that are
deployed in field operations and are not connected to the general network.
• Enables the schema to be different for each branch site.
• Significantly increases complexity in deployment and management of the
directory service because each branch site is managed as a separate
infrastructure. This also significantly complicates collaboration between users in
the individual forests, because not all applications work well in this scenario, or
might require meta-directory services to work. Finally, it requires setting up cross-
forest trusts.
• Can facilitate mergers, acquisitions, and divestitures.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

6 BOIS Directory Services Guide

Microsoft strongly recommends that you not place branch sites in a separate forest. If it is
absolutely necessary to have a separate forest for one or more branch sites, you should
use the minimum possible number of forests.

AD DS Domain Design
The first option that you have for the domain design is to decide whether a single domain
will support the requirements of your organization. The following design considerations
may affect your choice:
• Administrative overhead. A single domain model provides less administrative
overhead than the BOIS model, so this may reduce your organization's support
costs.
• Number of users per domain relative to WAN link speeds. If your organization is
likely to have more than 100,000 users in the branch site domain, and you have low
bandwidth (in the order of 19.2 kilobits per second, with one percent of that
bandwidth dedicated to replication traffic), you may need to consider additional
branch domains.
• Number of domain controllers relative to the Microsoft File Replication service
(FRS) replication. Because of the way that FRS works with SYSVOL replication, if
you have more than 1,200 domain controllers in the domain, you should consider
creating additional domains. In Windows Server 2008 domains it is possible to
migrate from FRS to DFSR for SYSVOL replication which makes this limit outdated
due to improved performance.
For branch sites that share a forest, the primary domain design options are similar to
those for the forest. The following three primary domain design options are each
associated with a number of considerations:
• Put branch sites in the same, single domain as the hub site. This option
represents the preferred domain design for branch sites and is consistent with the
best practice of having only a single forest and a single domain. This means that the
optimum solution is to have a single domain for the entire organization. If your
organization already has multiple regional domains, you should consider integrating
branch sites from the region into the regional hub domain, which provides the
following benefits:
• Minimizes the number of domains in the organization, so it represents the
simplest domain structure to create, secure, and manage.
• Facilitates centralized management of branch sites.
However, this option does not provide the distinct identity branding that is possible
with the separate domain tree structure.
Note that larger distributed domains cause more replication on the WAN.
• Create a separate domain for multiple branch sites. This option should be used
only if it is not possible to place branch sites in the same domain as the hub site. It is
a best practice to use the fewest domains possible. The domain for branch sites can
be set up either as a child domain or as a peer of the regional hub domain.
This option has the following benefits:
• Decreases replication traffic because of the limited scope of the domain.
• Can meet the requirements of specific branch sites for a distinct domain
password policy.
• Can satisfy a perceived need for autonomy in a branch site because the domain
name can provide a unique identity, especially if the domain is a separate domain
tree.
However, this option increases complexity in deployment and management of
directory services for branch sites.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 7

• Create a separate domain for each branch site. This option represents the least
desirable domain design and should only be considered if the other options are not
feasible. In addition to all of the considerations discussed previously in this guide for
putting multiple branch sites in a domain of their own, this design can significantly
increase deployment and management costs because this option:
• May require a considerably larger number of domain controllers to provide
redundancy.
• Complicates disaster recovery for the forest.
Although this option generally minimizes domain-related WAN traffic, by
using a large number of domains global catalog traffic can become a
significant challenge, if it exceeds domain replication traffic.

Organizational Unit Design

The last part of the logical design is the creation of the organizational units (OUs) that will
be used to organize the objects within the directory. The model used in BOIS is shown in
Figure 3.

Figure 3. BOIS OU model

By using a model like this as the starting point, you can review the following
considerations and modify the structure to suit your designs needs:
• Administrative delegation requirements. OUs can be created to enable
administration to be delegated to subsets of the objects in the directory. If your
organization wants to delegate control in this manner, your model may need to be
modified to reflect these requirements. For information about the administrative
delegation, see the Understanding Delegation of Administration section in the "Best
Practices for Delegating Active Directory Administration" white paper, at
http://go.microsoft.com/fwlink/?LinkId=46678 and the Designing Organizational Units
for Delegation of Administration section of the “Designing and Deploying Directory
and Security Services” guide, at http://go.microsoft.com/fwlink/?LinkId=47118.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

8 BOIS Directory Services Guide

• Group Policy assignments. OUs can also be used to group objects together that
inherit a common group of settings, by using Group Policy objects (GPOs). If this is
the case, you many need to create additional OUs to contain these objects so that
the common settings can be applied.
• Optimization of resource access. An OU can also be used to contain commonly
accessed resources, like those physically located at a branch site. Additional OUs
can be created in the model to reflect your requirements.
• Complexity. It is important to try and keep the design as simple as possible. An
overly complex OU structure is harder to use and manage, and is therefore more
expensive to support and more prone to errors.
• Application restrictions. OU structures that are deeper than 10 levels can lead to
problems if you have applications that have restrictions on the number of characters
used in the distinguished name (the full Lightweight Directory Access Protocol, or
LDAP, path to the object in the directory), or on the OU depth within the hierarchy.
• Legal and compliance requirements. If your organization crosses international
boundaries, complex laws may affect the structure of your OU design. Similarly,
depending on your organization's sector, compliance regulations may affect areas of
the OU design.
Other historical and political elements that are outside the scope of this document can
also affect the OU design. For other recommendations and more information about OU
planning, see the “Designing the Logical Structure for Active Directory Domain Services”
page at http://go.microsoft.com/fwlink/?LinkId=89024.

Domain Controller Placement and

Specification
The placement and specification of domain controllers is a major design consideration
that involves determining which type of domain controller to place where and how to
implement that domain controller, based on whether it is a stand-alone physical server, a
virtual server, or collocated on an existing server with other applications or services. With
the introduction of RODCs in Windows Server 2008, domain controllers can be placed at
branch sites that were otherwise too insecure or difficult to manage, which improves
flexibility for domain controller placement.
The decisions that you make about domain controllers for branch sites are integral to the
forest and domain design. Refinement of the design might therefore be required to
accommodate appropriate placement of domain controllers. In BOIS, the wireless local
area network (WLAN) links provide enough bandwidth and reliability to enable the
domain controller roles to stay at the hub site. This enables the branch site server to be
optimized to provide local servers to the users at the branch site. Consider the following
issues if you must modify this approach to meet the needs of your organization:
• Administrative overhead. Moving domain controllers out to the branch site adds
additional administrative workload to the domain administrators. This, in turn,
increases the overall support costs. However, the use of RODCs can mitigate the
management overhead by reducing the need for branch site administrative staff.
Another option that can reduce administrative overhead includes the use of Server
Core implementations for stand-alone domain controller implementations. Windows
Server 2008 Server Core options are designed to only include the binaries that are
required for the role that is assigned to that server, so the administrative overhead
associated with software updates and configuration tasks is minimized to only what is
required for the Server Core operating system and its specified role.
• Branch site security. While security at branch sites is typically more difficult to
control, the new RODC capabilities of Windows Server 2008 makes this
consideration less a matter of where domain controllers can be positioned, and more
a matter of what type of domain controller is best suited for a given site. Windows

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 9

Server 2008 Server Core instances can further improve security by limiting the
vulnerability profile of the domain controller.
• Hardware costs. The cost of upgrading a local server or placing an additional server
at the branch site to provide the domain controller role can be high. It is important to
also consider the less obvious costs such as additional software, monitoring, and
management agents.
• Administrator access. When a server is promoted to a domain controller, the local
account database is effectively removed and replaced by the domain database, so
the local administrator account and the Local Administrators group are removed. A
member of the Domain Administrators group must then perform management of
services that are running on the domain controller. For most organizations, granting
domain administrator privileges to a branch administrator who does not require this
level of authority poses an unacceptable risk to the integrity and security of the
domain database. However, RODCs mitigate these risks by using unilateral
replication so that changes cannot be made on the domain controller at the branch
location, but only at a centralized location. Also, RODCs allow administrators to
delegate specific administrative tasks to domain users via Administrative Role
Separation. For more information about Administrative Role Separation and other
RODC features, please see the “Read Only Domain Controller Step By Step Guide”
at http://go.microsoft.com/fwlink/?LinkID=92728.
• WAN availability. The availability of the directory service is dependent on the
availability of the WAN link. If the WAN link is down, users may be unable to log on
and access resources (depending on the information that has been cached locally).
This even includes resources located in the branch site, because it might not be
possible to obtain the necessary Kerberos session ticket that is required for
authorization. Even though RODCs do not maintain authentication information locally
by default, they can be configured to cache credentials for select users, computers,
and resources in the branch in order to permit authentication and resource access
even when the WAN is down.
• WAN traffic. Depending on the number of users, network traffic can be significant,
especially during peak periods. If the available link bandwidth is insufficient to support
branch access to domain controllers in the hub site, local domain controllers are likely
to be required. However, it should be noted that even though administrators can
control when directory replication is scheduled to occur by placing a DC at a branch
site, RODCs will still generate unscheduled traffic when it is necessary to forward any
write requests to the hub. For more information about WAN traffic considerations, see
“Assessing Network Bandwidth Availability and Requirements”, at
http://go.microsoft.com/fwlink/?LinkId=47125.
• Application performance. Applications that make frequent use of domain data can
be significantly affected or not function at all, if the domain controller is not available
at typical LAN speeds. Also, applications that make frequent writes to Active Directory
may be affected when an RODC is used at a branch location since directory write
activity will have to traverse the WAN in order to access DCs at a hub location.
• Logon times. Large logon scripts, or logon scripts that use executables on the logon
share, may take a significant amount of time to complete when there are no local
DCs or RODCs, which negatively affects the user experience. It is possible to provide
a better user experience by using the fast user logon feature that is available in the
Microsoft Windows XP® operating system to optimize performance during logon if
you are not using Windows Vista. For more information about fast user logon, see
Microsoft Knowledge Base article 305293, “Description of the Windows XP
Professional Fast Logon Optimization feature” at
http://go.microsoft.com/fwlink/?LinkId=47117.
• Group Policy application. With previous versions of Windows clients and servers,
using Group Policy to manage clients across WAN links could cause saturation
problems, depending on the timing of policy changes and the policy distribution
method. However, new changes in Windows Server 2008 and Windows Vista makes
Group Policy replication tasks more network aware and efficient.
Solution Accelerators microsoft.com/technet/SolutionAccelerators
10 BOIS Directory Services Guide

• Global catalog placement. When placing domain controllers, you must consider the
computer's access to the information that is stored in the global catalog server role.
For more information about this placement of global catalog servers, see the
“Windows Server 2008 Branch Office Planning Guide” at
http://go.microsoft.com/fwlink/?LinkId=100207.
• Universal group caching. If you want to place domain controllers in branch sites, by
configuring the universal group caching option on these servers you can ensure that
a branch site user's universal group membership information is available when the
user tries to log on, even if a centralized global catalog server is not available at the
branch site at the time.
It is likely that no single option is appropriate for all branch sites. The decision to place a
domain controller in branch sites must made by balancing the considerations for your
organization's business and security requirements, with thorough testing and piloting of
the solution (by using well defined and realistic performance and usability criteria).
For general information about domain controller design, see “Planning An Active
Directory Domain Services Deployment” at
http://go.microsoft.com/fwlink/?LinkId=100493.
The demands that a particular domain controller role places on the hardware of the
server is an important part of the design. This is particularly true in environments where
additional services are being considered on the same hardware.
For most organizations, an existing preferred server specification is already in place for
the domain controller role. For more information about how to plan for the hardware
specification of a domain controller, see “Planning Domain Controller Capacity” at
http://go.microsoft.com/fwlink/?LinkId=89027.
If you need a domain controller role in the branch site, you should consider the following
options, each of which directly affects the hardware specifications that the branch site
requires:
• Add the domain controller role to the branch site server. This option has security
isolation implications unless read-only domain controllers are used because service
roles that share the same standard domain controller server may require Domain
Administrator privileges to administer the local service on the branch site server.
• Run the domain controller on a separate computer in the branch site. This
option provides physical isolation, but requires the highest hardware cost, which
might not be justifiable for scaling to large numbers of branch sites. If a server is
designated as a stand-alone domain controller, Windows Server 2008 Server Core
Active Directory® Domain Services (AD DS) role installation may be the ideal
solution and reduce hardware requirements, administrative overhead, and the
vulnerability profile of that server.
• Run the domain controller on a virtual machine on the branch server. This
option provides logical isolation without requiring separate hardware. However,
virtualization may require more robust server hardware than a single physical
instance would. Additional testing may be required to ensure that the required levels
of service can be maintained by using virtual server instances on the hardware
platform. Using a Windows Server 2008 Server Core virtualized instance may reduce
the hardware requirements, but you should still test to ensure proper performance is
achieved.
Also, when considering the use of virtualized domain controllers at branch sites, it is
recommended that RODCs are used instead of writable DCs as this avoids a number
of issues that could potentially cause forest-wide outages. For more information
about virtualized domain controllers, please refer to “Running Domain Controllers In
Virtual Server 2005” at
http://www.microsoft.com/downloads/details.aspx?FamilyId=64DB845D-F7A3-4209-
8ED2-E261A117FC6B&displaylang=en and “Considerations When Hosting AD DCs
In Virtual Hosting Environments” at http://support.microsoft.com/kb/888794/en-us.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 11

• Run the domain controller on the host operating system, and run other
services on virtual machines on the branch server. This option also requires
Virtual Server and the same hardware issues as the previous option. It also requires
that the Virtual Server administrator have Domain Administrator privileges, because
all administrators on a domain controller are essentially Domain Administrators. It is
also possible that some of the required services on the server do not support
virtualization or have performance issues in this environment. Finally, because of
potentially complex licensing issues this option is generally not recommended.
Note: Attempting to install the Directory Services role on a virtual server hosted by a server
running directory services is not supported and will result in a Stop error message 7b on the host
server.
Any of these options could still pose a potential security risk to cross-site domain
information unless you use an RODC. Another consideration for RODC placement is
which directory services capabilities continue to work when access to a writeable domain
controller is severed. Generally, RODCs can supply authentication and logon services, so
long as the user’s credentials have already been cached due to previous activity, and any
server administration performed by a delegated RODC server administrator will succeed.
However, branch RODCs will forward write requests to writable hub DCs for operations
such as password changes, domain joining requests, computer renaming requests,
Group Policy updates that use the gpupdate /force command, and authentication
attempts from accounts that have not been cached.
For more information about running the domain controller in a virtual machine, see
“Hyper-V Release Notes”, at http://go.microsoft.com/fwlink/?LinkID=98821.

Directory Site Design

It is common to establish an AD DS site for each branch site that has a domain controller.
If a branch site does not have a domain controller, you may benefit from establishing an
AD DS site for the branch site, because other services can use the site design of AD DS.
Figure 4 shows the site model that is used in BOIS.

Figure 4. BOIS AD DS site model

A site was created for the hub (NYC) and each of the branch site locations (DAL, WSG),
and the main hub site contains the domain controllers for the branch site domain
(Americas-Branch.corp.woodgrovebank.com).
By using a site structure like this as the starting point, you can review the following
considerations and modify the structure to suit the requirements of your design:
• Complexity. The main goal of a site is to communicate to Active Directory a grouping
of computers that are connected through high-speed network links. Although it is
possible to create highly granular site structures down to individual subnets,
managing the replication connections in a complex configuration can increase the
ongoing management costs, so a design should be kept as simple as possible.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

12 BOIS Directory Services Guide

• Network connectivity speeds. The site and site link configuration directly affects the
replication topology of Active Directory. It is therefore important to ensure that the
physical network connections, together with their bandwidth and other relevant
characteristics, are represented in the site configuration. You can achieve this by
using site links together with the associated replication schedule and cost.
• Staging requirements. If you are using a server staging area for your branch site
server deployment, you should consider creating a site specifically for this staging
area.
• Number of branch offices. Typically, each branch site requires the configuration of
its own Active Directory site.
• TCP/IP topography. The Active Directory site structure uses the underlying TCP/IP
network subnets as its method of application. It is therefore important to understand
both the current and the planned TCP/IP topography when you plan the site design.
• Replication topology. After you have identified the number of sites and the number
and placement of domain controllers, you need to determine whether you want to
control the replication topology manually or whether you can allow Active Directory to
configure it automatically. For most scenarios, automatic configuration provides the
required level of service; however, manual configuration, such as custom replication
schedules, can be introduced if required.
• Domain controller failover. In the event that a client domain controller is
unavailable, the SRV records that are stored in the Domain Name System are used
to determine which other domain controllers to use. The records registered in the
local site are tried first, and then the records registered in the non site-specific
location.
For more information about site structure, see the Designing the Site Topology section in
the “Designing and Deploying Directory and Security Services” guide, at
http://go.microsoft.com/fwlink/?LinkId=48395.

Summary
This guide deals with AD DS design for branch infrastructures; including the essential
design elements that determine how best to approach the design of the individual AD DS
in your implementation.
The information provided in this guide is designed to be the starting point for a solution
design. The more experienced the designer or the more complex the design, the more
the AD DS design reference models will need to be customized. The example model
provided in this guide is designed to illustrate various stages in the AD DS design
process; it does not represent a "one size fits all" design. (Branch environments are too
varied for that.) Where possible, best practice recommendations have been added to
help determine the best place to start. But the best designs will be determined by
following the design reference stages and customizing the design model to fit the
particular requirements of the organization.
The information provided in this guide is only intended to be the starting point for your
Windows Server 2008-based branch infrastructure solution design.

Additional Resources
The following resources can be used to learn more about Active Directory Domain
Services in Windows Server 2008 environments:
For more information about Active Directory planning and design, see the TechNet Active
Directory Domain Services Library at
http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorydoma
inservices.mspx

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Directory Services Guide 13

For more information about Active Directory in the branch office, see the Windows 2003
Active Directory Branch Office Guide at http://go.microsoft.com/fwlink/?LinkId=28523
For more information about server roles, see the Windows Server 2008 Roles page at
http://www.microsoft.com/windowsserver2008/editions/roles.mspx
For more information about Windows Server 2008 AD DS services, see the Windows
Server 2008 TechCenter: Active Directory Domain Services page at
http://go.microsoft.com/fwlink/?LinkId=48547
For more information about server core installations, see the Server Core Installation
Option for Windows Server 2008 Step-by-Step Guide at
http://technet2.microsoft.com/windowsserver2008/en/library/edc9ae73-8df6-4bb5-a863-
45fdcb5496cb1033.mspx?mfr=true
For more information about server virtualization in Windows Server 2008, see the
Windows Server 2008 Hyper-V TechCenter at
http://go.microsoft.com/fwlink/?LinkId=101268

Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.

Solution Accelerators microsoft.com/technet/SolutionAccelerators