Windows 2000:

Designing and Deploying Active Directory Service for the Microsoft Internal Corpnet

White Paper

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the data of publication. Due to ongoing development efforts and because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft can not guarantee the accuracy of any information presented after the date of publication. This information is provided for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. 1999 Microsoft Corporation. All rights reserved. Companies, names, and/or other data used in screens and sample output are fictitious, unless otherwise noted.

EXECUTIVE SUMMARY CONTENTS

Microsoft, Active Directory, IntelliMirror, Outlook, JScript, Visual Basic, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other company and product names mentioned herein may be the trademarks of their respective owners.

Windows 2000:

1 1

EXECUTIVE SUMMARY........................................................................2 INTRODUCTION THE ACTIVE DIRECTORY SERVICE.......................4 Directory Service Architecture 5 ITG ENVIRONMENT..............................................................................7 ITG Organizational Structure 7 Unique Considerations 8 NAMESPACE DESIGN ENVIRONMENT.................................................10 Windows 2000 Team Structure 10 Deployment Timeline 10 Namespace Design Goals 12 Namespace Design Process 13 NAMESPACE DESIGN...........................................................................14 Forest Structure 14 Domain Structure 15 Organizational Units Structure 21 Site Topology 24 CONCLUSION.......................................................................................30 Future Steps 31 FOR MORE INFORMATION...................................................................32 APPENDIX............................................................................................33 The Sizer Tool 33 The health of an organizations information infrastructure determines its adaptability to rapidly changing global business conditions. The Information Technology Group at Microsoft (ITG) conceives of an information infrastructure that enables a company to perceive and react to its environment, to sense competitive challenges and customer needs, and to respond to those challenges and needs promptly. A key function of an organizations information infrastructure is representing and maintaining information about people, including all of the attributes that represent their digital identity: descriptors such as title, role, location, rights and privileges to company resources, as well as personnel information such as salary, benefits, and tenure. The Active Directory service of the Microsoft Windows 2000 Advanced Server operating system was created to meet the challenge of unifying and bringing order to diverse directory server hierarchies, or namespaces. In the context of this paper the term

namespace is defined as the logical naming of domains and their trust relationships, including supporting infrastructure. Active Directory is an enterprise-class directory service that is scalable to Internet size and fully integrated with the operating system, consolidating all user information into a single hierarchical structure that is easy to back up and manage. It uses the namespace concept similar to the Internet to provide a single point of administration and replication, a hierarchical view of the directory, extensibility, scalability, distributed security, and multimaster replication. Today information about people, applications, and other network resources is usually distributed in multiple systems throughout an organization. As companies continually increase the number of applications and platforms they use and support, the number of different repositories increases as well. This forces companies to manage information in many different places--even when they contain duplicated and related information. For example, in ITG user logon and e-mail accounts and passwords, access rights to applications, data shares, and printers and fax servers can be managed by dozens, if not hundreds of people in different locations. Due to the highly distributed nature of its infrastructure and defined management model, data backups of this crucial information for disaster recovery must also be done locally where the information is changed or stored. Besides facilitating ITG management of corporate directories and information resources today, Active Directory lays the foundation for future directory-enabled applications (such as Microsoft Exchange 2000) and devices. These include new and improved applications and services such as application distribution, licensing control, document management and workflow, enterprise wide workstation and server backups, and network management. The security features in the Active Directory service set the stage for use of the Internet as a primary base for wide area connectivity. For users, Active Directory provides what they need most - a robust directory that delivers a single network logon and a single point of administration and replication, allowing them to easily find the information they need anywhere in the organization. For administrators, Active Directory simplifies network resource management through delegated authority and centralization of diverse directory information. Theres a vast logical difference, however, between the old NT domain system and the Windows 2000 Active Directory service. For example, in the past ITG created separate user domains to delegate administration of certain groups of users in the organization. In the Windows 2000-based design ITG can delegate fine-grained administrative authority at the organizational unit (OU) level. Also, in the Windows NT 4.0 operating system, domains with a large number of objects (roughly more than 40,000) had to subdivide into smaller domains to accommodate the scalability limitations of the domain accounts database. This restriction is removed in Windows 2000 Active Directory; single domains can hold millions of objects. Administrators must understand these differences and plan their Active Directory-based structure accordingly for successful migration from Windows NT 4.0 to Windows 2000. This paper describes the crucial namespace design and deployment activities associated with the successful upgrade to Windows 2000 of the Microsoft enterprise network, including some of the unique ITG business drivers, as well as a historical view of the people and processes involved in the context of the overall internal deployment of Windows 2000. This namespace design also defines the infrastructure for Microsoft to realize the competitive advantages offered by new Active Directory aware applications, such as Exchange 2000, which rely on Windows 2000 for directory services, transport

INTRODUCTION THE ACTIVE DIRECTORY SERVICE

and name resolution. The infrastructure elements detailed in this paper include the Windows 2000 Active Directory and Domain Name System (DNS) namespaces, forests, domains, administrative structure and organizational units, sites, domain controller placement and specifications. Note that the names provided are for illustration only and do not necessarily reflect actual names used for security reasons. The Microsoft enterprise network comprises both an inward-facing network (known as Corpnet) and a customer-facing network (Internet properties). This paper focuses primarily on the Corpnet upgrade to Windows 2000. This document is based on initial design efforts begun by ITG before the release of Windows 2000. It is important to note this namespace design has undergone frequent change and will continue to be refined prior to and following the release of Windows 2000. This paper is intended for IT architecture, engineering and operations staff and consultants at the enterprise level. It is not intended to serve as a procedural guide. Each enterprise environment is comprised of unique circumstances and, therefore, each organization should adapt the plans and lessons learned described in this paper to meet their specific needs.

Directory services function like the white pages of a telephone book. Using specific input (for example, a persons name), a user can receive specific output (a persons address and telephone number). Directory services also provide the functionality of yellow pages. Using general input (e.g., where are the printers?), a user can receive a listing of printer resources. From a logical perspective Active Directory is the unit of scope and administration for a collection of resources (such as users, computers, printers and groups) on a network. The network and its objects are organized by constructs such as forests, domains, trust relationships, organizational units, and sites. In addition to handling the traditional administrative directory services, ITG uses the Windows 2000 Active Directory service to satisfy a wide variety of naming, query, administrative, registration, and name resolution needs in the Microsoft production environment. Figure 1 shows its overall function in the system.

x c h a M a i l
Recipient Lookup

n S
M

gu be m
a i l

it

i l

l i e

Loa d/S tore

t t p / h t t p s S e r v e rUser Authen Q L S

Zon eD B
tication

e Rr v e e g r i s t e r

e r v i c e

i r e c t o r y e r v i c e

c u

r Crtedential M i y

anagement

Ad dre ss Bo o

D S

y n a m i c e r v i c e s

r y / R

f e

r r a

Figure 1: The Active Directory Service

Directory Service Architecture

Active Directory provides a data repository that is logically centralized but physically distributed. Because all domains store forest-wide configuration and schema information, each domain can reference objects stored in any other domain if the information requested is not stored locally. The Active Directory service provides a hierarchical namespace of objects, in which: The distinguished name (DN) of each directory object uniquely identifies it in the database. The object's DN is composed of its relative distinguished name (RDN) and the chain of successive parent objects. The database stores the RDN for each object, as well as a reference to the parent object. The database layer follows these parent references and concatenates the successive RDNs to form the DN of the object.

Active Directory functionality is shown in figure 2 as a layered architecture representing the server processes that provide directory services to client applications, and the protocols used for interface.

L O u

A t l o

R e P / A D S T r o k C l ( R P

p l i c aW t i io n n d o W w si n d o w I / O a n s p No T t 4 N 0 T r . 4 . 0 B i e n t s C C , S N M e T t P A RPI P eI s ) p l i c a t

s u t l o D C l i e n i o n

o k t s

i r e

c t o D a n

r y t a b l e

S a

y s t e s e S t o L

m a r a

A y e g e

g r E

( D

x t e

s i b

i n

( E S E T F S

Figure 2: Active Directory Service Layers and Interface Agents ITG designed its Active Directory service to provide substantial enterprise benefits, including: Information Replication. Active Directory uses multimaster replication, which allows the directory to be updated at any domain controller (DC). If one DC within a domain slows, stops, or fails, other DCs within the same domain can provide necessary directory access, because they contain the same directory data. This offers high availability of both query and update operations. Information security. Management of user and computer authentication and access control are key security features that are both fully integrated with Active Directory. Active Directory centralizes authentication using Kerberos authentication, which allows clients to verify the identity of a server before transferring sensitive data. Access control can be defined not only on each object in the directory, but also on each property of each object. In addition, Active Directory provides both the store and the scope of application for security policies. Fine-grained delegation of authority at the organizational unit level allows ITG to improve both security and operational efficiency, especially in managing rapid and frequent organizational change. Interoperability. Because Active Directory is based on standard directory access protocols, such as Lightweight Directory Access Protocol (LDAP), it can interoperate with other directory services employing these protocols. Several application programming interfaces (APIs) such as Active Directory Service Interfaces (ADSI) give developers access to these protocols. Integration with DNS. Active Directory uses DNS as its name location service. DNS is an Internet standard service that translates human-readable computer names (such as mycomputer.microsoft.com) to computer-readable numeric Internet Protocol (IP) addresses, allowing clients and servers in TCP/IP networks to identify and connect to one another. ITG uses the Dynamic DNS service included in Windows 2000 Advanced Server to reduce network administrative complexity and redundant DNS infrastructure. Policy-based administration. Group Policies are configuration settings applied to computers or users. All Group Policy settings are contained in Group Policy Objects

ITG ENVIRONMENT

(GPOs), which are applied to sites, domains, or organizational units. ITG uses GPO settings to determine access to domain resources (such as applications) that are available to users, and how these domain resources are configured for use. Scalability. Active Directory can include one or more domains, each with multiple DCs, enabling ITG to scale the directory to meet any network requirements. Multiple domains can be combined into a domain tree and multiple domain trees can be combined into a forest. The database for Active Directory has been tested internally at Microsoft to over 85 million objects. Performance tests showed logon performance for a single LDAP client to be equally as good with 10,000 objects, 100, 000 objects and 1.1 million objects. The directory service did not slow measurably when the size of the database increased. Extensibility. The Active Directory schema is extensible, allowing administrators and new applications to add new classes of objects to the schema and add new attributes to existing classes of objects. The schema contains a definition of each object class, and each object classs attributes, that can be stored in the directory. For example, ITG can add a Purchase Authority attribute to the User object and then each user's purchase authority limit can be openly available as part of the user attribute set.

ITG Organizational Structure

The primary business of Microsoft is software design. As such, ITG has business drivers that are unique among global enterprises. For example, in addition to running the enterprise IT utility, ITG plays the strategic role as one of Microsofts early adopters, testing and deploying Microsoft software before customer release. As of this writing, ITG comprises roughly 2,500 people worldwide, including full-time employees, contractors and interns, who are responsible for managing roughly 50,000 users, 100,000 desktops, and thousands of servers that span 450 sites in 62 countries. The internal network (Corpnet) physical topology is comprised of: More than 200 Wide Area Network (WAN) circuits. Over 1,000 routers. More than 140 Asynchronous Transfer Mode (ATM) switches. Over 900 Local Area Network (LAN) switches (100 Mbps to servers, 10 Mbps to desktops). In excess of 2,500 IP Subnets. More than 100,000 LAN ports.

Like other global enterprises, ITG is organized into functional groups, including those that run the IT utility, as well as those responsible for HR, finance, legal, and other business processes. Five main IT groups have been involved in the Windows 2000 domain namespace design and deployment as part of the overall internal Windows 2000 deployment, including: 1. Global Networking and Systems (GNS) provides corporate computing and communication infrastructure services. GNS is responsible for designing, implementing and supporting IT solutions to meet enterprise requirements of Microsofts data communications around the globe. This includes Microsofts corporate Intranet (Corpnet) and Internet presence. For example, GNS personnel determine the sizing and placement of Windows 2000 Advanced Server DCs and global catalogs. 2. IT Security (ITSEC) provides both physical and computer network security services. The Domain Security Management group, for example, is responsible

3. 4.

5.

for the creation and management of domains, Windows NT permissions, and disk management support. ITSEC personnel manage the delegation of authority using organizational units. Operations IT (OPSIT) manages the corporate data centers as well as teaming with Microsoft business units in applications design, development and support. End-User Services/Application Platform Services (EUS/APS) manages the global helpdesk, corporate desktops, user accounts and messaging operations. Enterprise Applications and Services (EAS) manages enterprise data services, such as HR applications and finance. Product Group IT (PGIT) provides knowledge management leadership across Microsoft and coordinates product group-ITG interaction.

In addition, the deployment team for Windows 2000 includes members from other areas of the company, such as the Windows 2000 product development group and Product Support Services (PSS). End-User Documentation groups were also involved as observers in various stages of the deployment, because ITG usually deploys so early in the product cycle that product documentation is not yet complete. Internal reorganizations are a fact of life in most IT enterprises. During the course of the Windows 2000-based Corpnet deployment ITG underwent several reorganizations. For example, late in 1998, two separate ITG groups the Worldwide Infrastructure Operations group and the Global Networking group merged and became the GNS group. GNS then became responsible for: Data Networking: responsible for global data networking from architecture through engineering, implementation and operation. Computer Systems: responsible for all global data center systems from architecture through engineering, implementation, and operations. Telecom: responsible for converging global voice, video, and broadband services.

Unique Considerations
Dogfood. Eating our own dogfood is a colorful phrase used within ITG to describe the internal deployment of Microsoft products. Microsoft deploys technologies internally early in the product life cycle in order to improve the product before it releases to customers. Running the Microsoft global enterprise on Microsoft products is one of ITG's key responsibilities. ITG is involved as a partner in product development from the beginning alpha stage, in which ITG experts provide input on feature specification, through to release to manufacturing (RTM). In the beta and release candidate stages ITG provides bug logging, detection and regression testing in close cooperation and communication with the product groups. ITG internal testing in real-world scenarios uncovered hundreds of bugs in Windows 2000 that were fixed before release. "Dogfooding", as it is called, is not without its challenges for ITG. For example, the requirement to test beta product code in a global production environment can impact reliability and availability measurements. Part of the process of deploying new products involves several iterations and different test cases in order to fully test different features of the product. Tearing down and rebuilding machines, domains and even networks, while necessary for thorough testing, results in lower than normal availability metrics. The product development groups for Windows 2000 and Exchange 2000 host dogfood environments that require regular server infrastructure changes and re-configurations, and the product development process requires frequent changes to the schema design

of the Active Directory service. Because schema changes affect the entire forest, the development teams require their own isolated forests for maximum flexibility and to isolate frequent schema changes from the production environment. Multiple forests present unique management challenges. ITG is responsible for managing the trust model, managing schema between forests to make sure the data being queried is available in each forest, and checking for duplicate data/objects and appropriate security settings. Another challenge specific to the ITG deployment of Windows 2000 was that in the early stages not all the tools were complete. Likewise, some aspects of the deployment were driven by the fact that monitoring, management, and maintenance tools were not complete in the early stages, so new temporary process automation procedures had to be created. Prior to deploying Windows 2000 Advanced Server into the production environment, ITG began its preliminary design work on the Windows 2000 namespace. The namespace design effort was driven through each of its several iterations by ITG goals for overall Windows 2000 deployment prior to RTM, which included: 100% client base (approximately 50,000 desktops) upgraded to Windows 2000 Professional. Deployment of IntelliMirror management technologies and MyDocs Redirection services in production. 100% of ITG infrastructure services hosted on Windows 2000 Advanced Server. A minimum of 20% of the rest of Microsofts global IT services hosted on Windows 2000. 150 Windows NT 4.0 resource domains consolidated into OUs in Windows 2000 domains. All mission critical and business critical line of business (LOB) applications tested, 26 LOB applications hosted.

Employee needs guide which feature is the focus of different deployment phases, and Microsoft employees have been very responsive to ITG's deployment efforts. Microsoft employees are typically technical people, or people who like to take advantage of new technologies to improve their productivity. When ITG sends an e-mail asking employees to install a new product, roughly seventy percent will install the product immediately on their own, and eighty to ninety percent troubleshoot their own desktop PC configurations. ITGs deployment of Windows 2000 enjoyed high-level executive support, and employees received e-mails containing upgrade instructions directly from very high-level company executives, making deployment efforts that much more effective. Highly dynamic environment. ITG undertook a global network infrastructure upgrade roughly simultaneously with the initial design of the Windows 2000 operating system. Maximum throughput under the old design had been limited by the gigaswitch serving as the corporate hub (3.2 gigabits/sec). To break this bottleneck and to accommodate future growth a very high speed (170 gigabits/sec) ATM backbone was installed, bringing 100 Mbps first to 60 buildings in the Puget Sound campus in five months, and then to Europe and the rest of North America. The next phase of the upgrade encompasses Asia, the South Pacific region, Southeast Asia, India, and Latin America. The final phase of the upgrade calls for using the Internet as primary transport, with more than 7,000 external partners moving from Corpnet to Internet virtual private

NAMESPACE DESIGN ENVIRONMENT

network (VPN) connections. Hardware standards also changed during this timeframe, and new standards were established for all servers and clients. Standardizing the hardware platform and deploying it into sites to facilitate a smooth transition to Windows 2000 allowed ITG to reduce the number of servers and maximize the return on team time they only had to visit the field offices once to take care of multiple needs. Servers were sized aggressively so as to serve the forecasted needs for the next 18-36 months.

Windows 2000 Team Structure

ITG formed a Windows 2000 project team to coordinate and communicate time-sensitive tasks as effectively and efficiently as possible. This group is responsible for controlling, coordinating, and synchronizing the delivery of deployment tasks so that project goals and milestones are achieved in a timely fashion. This team consists of experts representing product development, product support, and several ITG areas of focus, including: Infrastructure and Server Deployment Information Security and Accounts Administration Messaging IntelliMirror management technologies Data Networking Telecommunications Management and Tools Line of Business (LOB) Application Compatibility Desktop Deployment Active Directory Design and Integration

The Active Directory service must be in place before deploying other features and products that depend upon it, such as Intellimirror desktop management services, telephony integration, and so on. Consequently, the first order of business for the team was the design and deployment of the Windows 2000 domain and account validation infrastructure components.

Deployment Timeline
ITGs namespace planning effort was constrained by the overall deployment schedule for Windows 2000 Advanced Server, which is divided into phases that align with the product development cycle, as shown in figure 3. This deployment strategy is roughly followed for each of the many beta products ITG simultaneously deploys before release to manufacturing (RTM). The Windows 2000 deployment received special, very highlevel executive support from the beginning. At the time of this writing ITG is completing the fourth phase of the deployment.

i n 2 0 P r o C y

d o w s 0 0 C o n d u c t c l e

c e p t B

e t a ( n

( n

T M

I n

u t / P S

l a e

i n

g r / S e c u r i t y P i l o t D o m a i n > P

r v e

N
D I T G e p l o y m e n t

t w

r k i n

i l o

i n

>

r o

r k s t a

t i o

i l o

>

r o

i s t r a

t i v e

l s

i l o

>

r o

x c h

i l o t

>

Figure 3: Deployment Timeline for Windows 2000 Pilot Testing During pilot testing of Windows 2000 Advanced Server, ITG built its own Windows 2000 Active Directory-based environment to learn with. 1,000 users from ITG business units, ITG, and product groups were moved into the pilot environment to authenticate against Windows 2000. This pilot environment continues throughout the production deployment to provide a test environment for other new products and services. New features are tested and new procedures developed and documented in this environment before production deployment. For example, application publication procedures were piloted in this environment before production. ITG upgraded five percent of all corporate production infrastructure servers such as Print, Proxy, PPTP, Dynamic Host Configuration Protocol (DHCP), and Windows Internet Naming Service (WINS) to Windows 2000 Advanced Server in this timeframe Production Domains In this phase of the deployment ITG first upgraded Microsofts largest Windows NTbased Master User Domain (MUD) to Windows 2000, providing authentication services to roughly 27,000 users. MUDs contain user accounts and security groups. Workstation and server machine accounts are contained in second tier resource domains. 239 of 417 Windows NT Server 4.0 resource domains were consolidated into twelve Windows 2000-based Corporate MUD's and six Development MUDs in this timeframe. ITG used the WAN between Redmond, Africa, and South America as a replication test bed during this phase to demonstrate reliable Global Catalog traffic over some of the slowest Corpnet WAN links. New services such as IntelliMirror, and new management of groups and policy objects within Active Directory were piloted in this phase. Global Rollout and Viability The goal of this phase was to have 42,000 users authenticating against Windows 2000

Advanced Server and to upgrade seventy percent of corporate infrastructure servers in Redmond, as well as an additional twenty infrastructure servers outside of Redmond. Seventy-five resource domains were consolidated into twenty OUs within Active Directory in this timeframe. Microsofts Redmond, Far East, South America, and South Pacific MUDS were converted to Windows 2000 native mode during this phase. ITG also began piloting new Windows 2000 Advanced Server services such as Quality of Service and IP Security during this phase. Reliability Testing Core infrastructure services, such as RAS, PPTP, DHCP, WINS, print and proxy services will be hosted exclusively on Windows 2000 Advanced Server when this phase is complete. ITG will consolidate over two hundred of its Windows NT Server 4.0 resource domains into the Windows 2000 Active Directory services during this phase, and six production domains will upgrade to native mode. Three Windows NT Server 4.0 MUDS in Europe will be consolidated into one Windows 2000 native mode domain. Full Global Deployment In order to transition to the fifth and final phase, ITG will have demonstrated that the reliability of Windows 2000 Advanced Server exceeds that of Windows NT Server 4.0 in the Microsoft production environment by at least fifty percent. During this phase ITG will also collapse all remaining Windows NT Server 4.0 resource domains into OUs, and use Windows 2000 domains to house more than 60,000 Windows 2000-based machine accounts. They will also demonstrate that new services such as IP Security and Quality of Service (QoS) work in the environment.

Namespace Design Goals

The ITG plan for Active Directory had to be general enough and flexible enough to accommodate ITGs dual mission running the utility and dogfooding. Some of the overall objectives driving the design during this timeline included: Rapid Deployment. The deployment of the design must be achievable in less than 18 months. The design must facilitate periodic revisions in order to incorporate new features in the product as they are developed, and must be fully deployed before RTM. Services continuance. Existing IT services and user functionality must be maintained. Support Microsoft LOB applications, extranet applications and Microsoft product development. The design must isolate production environments from lab environments via separate forests. For example, product groups require the flexibility to update systems software independent of ITG. These self-host environments must be separated from Microsoft production resources, yet in some cases have secure access to corporate resources. Support evolutionary migration path. Existing Windows NT 4.0 MUDs must be preserved in the design where necessary for business or administrative reasons. The design must also facilitate domain consolidation of existing Windows NT 4.0 resource domains into OUs in geographically based Windows 2000 child domains.

Take advantage of new security granularity of Active Directory to provide delegated resource control. The design must allow for greater administrative flexibility than was provided by the Windows NT 4.0 environment, using a combination of OUs and group policies within each domain to streamline resource management. Streamline the authentication model. The design must reduce authentication complexity through Kerberos authentication and the consolidation of resource domains. Reduce the quantity of infrastructure hardware required to support the Windows 2000 environment compared to Windows NT 4.0. The deployment must eliminate dedicated primary and backup domain controllers of the 400+ Windows NT 4.0 resource domains, consistent with the simultaneous infrastructure hardware upgrades underway. Map to the DNS namespace. Windows 2000 domains rely on DNS for resource naming. The design must incorporate a majority of the domains into the existing Microsoft corporate root DNS namespace. No new registration of top-level DNS names should be required. Reduce the impact of business unit reorganizations on the namespace. Domain names are based on geographical regions or geographical data center boundaries, which are not prone to change. Lay the groundwork for future technologies. Exchange 2000 is slated to be the first Microsoft product incorporating and relying on Active Directory. The namespace design must accommodate the schema extensions of Active Directory in Exchange 2000, as well as handle the additional attributes and replication traffic resulting from incorporation of the Exchange 5.5 Global Address List into Active Directory. In addition, the security infrastructure for allowing the use of the Internet as the corporate backbone and new services, such as smartcard authentication, must be enabled.

Namespace Design Process

With these goals in mind, the team in place, and the timeline for overall Windows 2000 deployment established, ITG devised a four-step plan for Active Directory deployment in this timeline, starting with the namespace design: 1. Create a Forest Plan a. Determine the number of forests b. Create a change control policy for each forest Create a Domain Plan for each forest a. Determine the number of domains b. Choose a forest root domain c. Assign a DNS name to each domain d. Plan DNS server deployment e. Optimize authentication with shortcut trusts Create an OU plan for each forest a. Create OUs to delegate administration b. Create OUs to hide objects c. Create OUs for Group Policy Create a Site Topology/server placement plan for each forest a. Define sites and site links

2.

3.

4.

NAMESPACE DESIGN

b.

Size/Place servers into sites

This sequence of steps was later refined, expanded, and documented in the Windows 2000 Resource Kit Deployment Planning Guide. The next section of this paper examines each of these high-level steps in more detail.

Forest Structure
From the logical view a forest is a collection of domains and domain trees that defines the replication and security boundaries of Windows 2000 the directory cannot be larger than the forest itself. From the physical view the forest is a distributed database, where domains define the partitions of the database. Windows 2000 domains in the forest are automatically connected by bi-directional transitive trust relationships. However, one-way only, non-transitive Windows NT 4.0style trusts can be established between domains in different forests. Therefore, when access between domains must be isolated, each domain must reside in a separate forest. For example, Microsoft product groups, such as the Windows 2000 and Exchange 2000 groups, have self-host environments that require regular server infrastructure changes and re-configurations. These dynamic environments are required to support the product development process and dogfood activities. The development process requires frequent changes to the schema design of the Active Directory service. Because schema changes affect the entire forest, the development teams require their own isolated forests for maximum flexibility and to isolate frequent schema changes from the production environment. ITG administers the high-level forest configuration, user accounts and system access. Because inter-forest trusts are not transitive, explicit trusts are required between domains in separate forests. ITG defines and manages these trusts. The corpnet.ms.com forest is the primary container of ITG-controlled corporate domain user accounts, groups and corporate resources. The root of the forest is the corpnet.ms.com domain. This domain is a top-level placeholder that contains a limited number of corporate-wide resources and administrative accounts only. Domains within the corpnet.ms.com forest have multiple external trusts to child domains in development forests. The prefix (DC=corpnet) is added to microsoft.com in order to differentiate the Corpnet from the Internet namespace (microsoft.com). Because all domains in a forest share a common schema and configuration information, domains within each forest form the administrative, security and replication boundaries for a collection of objects, such as users, groups and computers that are relevant to a specific group of users. User account password policy, account lockout policy, and Kerberos ticket policy are set on a per-domain basis. The critical decision point in this design is that two forests cannot be merged easily in the initial release of Active Directory. Multiple forests in this design isolate the production environment from schema changes that are necessary in the development environments, yet allows central management of the development forest users and groups and other network resources. Figure 4 shows a high-level view of the Microsoft enterprise Windows 2000-based forest structure.

i n d o w o n e - w

s N T 4 . 0 a y t r u s t

- s t y l e

c o

r p

t . m

s . c o

W o

i n n

d o w e - w

s N T 4 . 0 a y t r u s t

- s t y l e

c h i l d d o m a i n s a u t o m c o n n e c t e d b y b i - d i r e t r a n s i t i v e t r u s t s W o n i n d o w s N T 4 . 0 - s t y l e e - w a y t r u s t s t o c o r p n e c h i l d d o m a i n s W t o

a t i c a l l y c t i o n a l

i n d o w s N T 4 . 0 n e - w a y t r u s t s t o c h i l d d o m a i n s

- s t y l e c o r p n e

t . d e m s . c o m

v .

c h i l d o m a

i n

x c h a n d e v . m s . c o m

Figure 4: High-level Forest Structure

Domain Structure
The domain is the core unit of logical structure in an Active Directory service. Domains represent a logical partition within Active Directory for both security and directory replication. Each domain requires at least one domain controller. Each DC in a given forest shares the common schema and forest configuration attributes of the forest it resides in. A single domain can span multiple physical locations or sites. Unlike the single-master model used by Windows NT 3.x and 4.0, with its primary domain controllers (PDCs) and backup domain controllers (BDCs), Active Directory uses a multimaster peer-controller model. Thus, all of the DCs that are authoritative for a domain can receive changes directly and propagate those changes, allowing inter-site replication to occur within a domain (even if any single DC is down). Microsofts Windows NT 4.0 logical domain model consisted of 12 MUDs that each trusted the other MUDs, and roughly 400 resource domains, which, in turn, trusted each of the 12 MUDS, as shown in figure 5. In this environment, resource domains served as units of delegated administration. User domains were used as a partitioning mechanism to scope replication and because of the security accounts manager (SAM) domain object limit. Every Windows NT 4.0 domain consisted of a single PDC and at least one BDC (some domains contained as many as 200 BDCs). This environment was complex to manage, as it created a web of more than 5,000 trust relationships managed by ITG.

1 s t 1 1 1 4

M a s t e r U T i e r D o m

s e r D o m a i n ( M U D ) a i n s w i t h B i - D i r e c t i o n a l

T r u s t s

2 - W i - W i n - W i n 0 0 + 2

n d o w s N T 4 . 0 M U D s w / 2 d o w s N T 4 . 0 M U D w / 1 - w d o w s N T 4 . 0 M U D I s o la t e n d t ie r D o m a i n s w i t h 1 - w

w a y t r u s t s a y t r u s t d ( n o t r u s t s a y t r u s t s t o

e a c h

e d m

o n

N o r t h S o d m e r i c aA m

u t h S o u t h e r Nn o r t h e r nC e r i c aE u r o p e E u r o p e E

e n t r a l M i d d l e u r o p e E a s t

F a r E a s t

S o u t h P a c i f i c

f r i c a

P O

S S u t s o u

V r c eV

M U D e n d o

r s

T r u s t e d t i e r d o m t r u s t s t o

b a C

y i n

s e l e c t e d 2 n d s , b u t h a v e n o o r p o r a t e M U D s 2 n d 4 0 0 + t i e r d o r e s o u r c e d m a i n s w i t h o m o n a i n e - w s . a y t r u s t s t o

E M

x t r a n U D

- X

X SX Y

- X

XW

- X

I T

- X

X O

- X

XL C

- X

- c i t yI R

L - c it y

- c i t y

D W o

e v e l o p e r S e r v e r s / r k s t a t i o n s R e s o u r c e D o m a i n s

D W

e p a r t m e n t a l S e r v e r s / o r k s t a t i o n s R e s o u r c e D o m a i n s

R W

e g i o n a l S i t e o r k s t a t i o n s D o m a i n s

S R

e r v e r s / e s o u r c e

Figure 5: Windows NT 4.0 Domain Structure Each domain was limited by the roughly 40,000-object limit of its domains SAM database, which was replicated (using single-master replication) at per-object granularity from each PDC to each BDC. For example, each time a users password was changed or account renamed the entire user object was replicated from the PDC to each BDC. For users, locating resources in this flat structure was difficult. A user had to know the location of a particular resource, such as a printer or file share, in order to find and use it. Name resolution service in this environment was primarily through WINS. Since WINS is non-hierarchal, the more than 30 WINS servers for Corpnet were heavily accessed any time a resource location was not already known. Replication traffic for WINS service was heavy, as a change in one WINS database had to be replicated worldwide. The new domain hierarchy allows users to search multiple domains with one query to the Active Directory global catalog service. Consequently, finding a resource in Active Directory is much easier; a user effectively queries against all domains at once and need not know the location of the resource. Active Directory knows about all resources in all domains and their logical locations. Theoretically, if an organizational network is linked by permanent connections with ample bandwidth, there is very little architectural need for more than one domain. However, adding additional domains can help to solve both architectural and political issues. Since logon authentication and access is primarily controlled at the domain level, adding additional domains effectively decentralizes the control of the network. In this design, the old Windows NT 4.0 geographical MUDs become child domains of corpnet.ms.com in the Windows 2000 forest. Three European domains (Northern Europe, Southern Europe and Central Europe) are consolidated into one, as shown in figure 6.

P N

. M

.C

e d m

o n d

F a r E a s t

id le E

a s t

u r o p e

N A m

o r t h e r ic a

S o u t h P a c if ic

S A m

o u t h e r ic a

S E

o u t h e r n o r t h e r nC N u r o p e E u r o p e E

e n t r a l u r o p e

x i s t i n g W w i l l c o n W i n d o w s

i n d o w s N T 4 . 0 M U D s o l i d a t e i n t o 2 0 0 0 C h i l d D o m a i n

Figure 6: Windows 2000 Domain Structure The new domain design eliminates resource domains, collapsing them into OUs. Only 12 domain directory databases need to replicate instead of more than 400. Trust management is simplified because Windows 2000 automatically establishes trust relationships between domains. Trust between domains in the same forest is transitive and hierarchical, so if domain A trusts domain B and domain B trusts domain C, domain A also trusts domain C. Thus the vast majority of the trust relationships ITG had to manage manually are eliminated, network traffic is reduced, and fewer domain controllers are needed. For example, in the European child domain MUD consolidation process: More than 300 departmental global groups will be eliminated. More than 20 local groups will be eliminated. More than 700 resource domain trusts that must be managed by ITG will be eliminated. Fail-over authentication across the WAN will be improved. Centralized OU management will be enabled. Group Policy Object creation and management will be enabled. The number of domain controllers needed will be reduced by 10. The new design enables finer control of delegated authority by moving a great number of objects into OUs instead of resource domains. DNS Structure DNS is a hierarchal, distributed database consisting of resource records containing a DNS name, record type, and data values associated with that record type. The Active Directory service can use any IETF standard-based DNS server that supports the dynamic update protocol and the SRV resource record type, including the DNS server provided with Windows 2000 Advanced Server. WINS name resolution is

still supported, primarily for down-level clients. Windows 2000 Domain Names are DNS names. This greatly decreases cross-WAN traffic for DNS queries for resources that can be found within the given domain and allows Corpnet users to find resources with the same simple naming convention in Active Directory that is on the Internet. For example, the fictional JamesSmith@microsoft.com is both an Internet e-mail address and a user name in the redmond.corpnet.ms.com domain. ITGs implementation of DNS in Windows 2000 can use the Active Directory service instead of the standard DNS structure as its data storage and replication engine. This approach provides the following benefits: DNS replication is performed by the Active Directory service, so there is no need to support a separate replication topology for DNS servers. Only the changes to the zone transfers database need to be replicated instead of the entire database. Active Directory service replication is secure. A primary DNS server is eliminated as a single point of failure. Standard DNS replication was single-master, relying on a primary DNS server to update all the secondary servers. Active Directory service replication is multi-master; an update can be made to any domain controller, and the change is propagated to other domain controllers. When DNS is integrated into Active Directory service, the replication engine always synchronizes the DNS zone information. As ITG deploys Windows 2000 Advanced Server throughout the enterprise, each new domain controller handles its DNS registration and updates without administrative intervention.

The goals for ITGs DNS design were: Minimize administrative overhead by making use of Active Directory for replication between name servers. Implement the Corpnet namespace (corpnet.ms.com) internally to differentiate between Corpnet resources and Internet resources (microsoft.com). Ease the transition from friendly names used with WINS to the Fully Qualified Domain Names (FQDN) used by DNS. Make effective use of the network bandwidth to provide accurate and timely name resolution responses to the clients. Minimize administrative overhead by utilizing DNS where appropriate and placing all legacy systems in the legacy zone (dns.microsoft.com).

Pre-deployment network infrastructure traffic analysis showed about thirty percent of Corpnet traffic for NetBIOS name resolution. The delta for Windows 2000 logon traffic was also calculated, and found to be minimal. Note that these tests were conducted at an early stage and post-release results will likely vary. The representative test DNS server had dual Pentium II 400 Mhz processors, 256 MB of RAM and a 4 GB hard drive, running DNS service exclusively.

The working benchmark at that early stage established that approximately 4 MB of RAM were used when the DNS server was started without any zones. For each addition of zones or resource records to the server, an average of approximately 100 bytes of server memory were used. Roughly 900 queries per second, and 100 dynamic updates per second, at thirty percent processor utilization were recorded. This preliminary testing showed that ITG could easily make full use of the integration of DNS in Windows 2000 Advanced Server and design each DC to provide DNS services as well. DNS on the corporate network is configured to run in DS integrated mode for all zones. As each new DC is introduced into the namespace, DNS registration is automatic. Windows NT 4.0 and previous versions of the operating system use a NetBIOS name to identify a particular machine or domain on the network. NetBIOS names are restricted to 15 bytes, whereas a Host name can be up to 63 bytes long (DNS names are encoded in UTF-8 and are not necessarily one byte per character). A Windows 2000-based machine can be identified by a NetBIOS name (for down-level interoperability), and by a full DNS computer name, which is a concatenation of Host name and primary DNS suffix. By default the primary DNS suffix of a computer is set to the DNS domain name of the Active Directory service to which it is joined. ITG used the NetBIOS name of each upgraded domain as the leftmost label in the DNS name of the domain, as shown in table 1, to minimize confusion among users and administrators as they transitioned from legacy tools to Windows 2000-based tools. Note that child domains are appended with the name of the parent domain. For example, the full name of the Africa domain is africa.corpnet.ms.com.
DNS Name 1 NetBIOS name 2 Windows NT 4.0 Domain

Corpnet.ms.com africa.corpnet.ms.com redmond.corpnet.ms.com europe.corpnet.ms.com

CORP AFRICA REDMOND EUROPE <new domain>

<new> AFRICA REDMOND NORTHERNEUROPE, CENTRALEUROPE, SOUTHERNEUROPE domains combined3. MIDDLEEAST NORTHAMERICA FAREAST SOUTHAMERICA SOUTHPACIFIC

middleeast.corpnet.ms.com northamerica.corpnet.ms.com fareast.corpnet.ms.com southamerica.corpnet.ms.com southpacific.corpnet.ms.com

MIDDLEEAST NORTHAMERICA FAREAST SOUTHAMERICA SOUTHPACIFIC

Table 1: NetBIOS-DNS Namespace Mapping Administrative Structure In the Windows NT 4.0 environment ITG centrally managed global groups and Windows NT account creation, modification, deletion at the domain level, in the primary MUDs.
1 2

Windows 2000-based clients see this DNS name. All down level Windows 9X-, Windows NT 4.0-based clients see this NetBIOS name for backward compatibility. 3 Note that as of this writing, the European MUD consolidation process is not complete.

The administrative model in the Windows NT 4.0 environment is shown in figure 7.

M aster U ser D ains om

(1st Tier Dom ains)

M UD-1

M -2 UD

M -3 UD

M -4 UD

M UD-5

M UD-6

M UD-7

M UD-8

D -1 EV

D -2 EV

D -3 EV

DEP T-1

DEP T-2

D T-3 EP

SITE-1

SITE-2

SITE-3

D eveloper Servers Dom ains

(2nd Tier Dom ains)

Departm ental Servers Dom ains

(2nd Tier Dom ains)

Site Servers D ains om

(2nd Tier Dom ains)

= Trust R elationship

= D ain om

= Local Adm in

= ITG Adm in

Figure 7: Windows NT 4.0 domain administration model ITGs Windows 2000-based design makes use of Group Policy associated with containers (domains, OUs, and sites) to manage resources. Group Policy in Windows 2000 really has no equivalent in the Windows NT 4.0 environment. While Group Policies can control most environment settings, they are strictly administrative in nature and maintained only within the realm of the Active Directory service. Group Policy is administered through the use of Group Policy Objects (GPOs), which are data structures attached in a specific hierarchy to selected objects, sites, domains, or OUs. These GPOs, once created, are applied in a standard order: LSDOU, which stands for (1) Local, (2) Site, (3) Domain, (4) OU, with the later policies further refining the earlier applied policies. Group Policies define the various components of the users environment that ITG administrators need to manage, including security and software settings, application deployment options, scripts, user settings and document options. By default, Group Policy affects all computers and users in a selected container (site, domain or OU). However, GPO effects can be filtered based on user or computer membership in Windows 2000 Security Groups. In this design ITG will take advantage of new group features, such as Universal Groups, for fine-grained delegation of administration of objects to users, and management of permissions by adding Groups to access control lists (ACLs). Some of these new features are: Groups can be nested. Groups can be managed similarly to Exchange 2000 distribution lists. Groups can contain non-security members (this is important when the group is used for both security and distribution list purposes). Security usage of groups can be disabled (this is important when the group is solely used as a distribution list).

A Universal group is the most flexible type of group. Universal groups can appear in

ACLs anywhere in the forest, and can contain other Universal groups, Global groups, and users from any trusted domain. For example, Universal groups can be used for virtual teams, whose membership includes members from domains across the globe, but with similar access requirements to team resources. A Universal group can hold Global groups from each domain, subsidiary, or department, and then team resources can have a single access control entry (ACE) that grants access to the members of the universal group. A Global group can appear in ACLs on any member computer of a trusting domain and can contain users and other Global groups from its own domain. A Domain Local group can be used in ACLs only on member computers of its own domain, and only on domain controllers if the domain is in mixed-mode. A Domain Local group can contain users and Global groups and Universal groups from any trusted domain, and other Domain Local groups in its own domain. These three group types provide ITG rich and flexible access control while reducing GC replication caused by group membership changes. The membership of a Universal group appears in the GC, but in ITGs plan these Universal groups include primarily global groups from domains in the forest. Membership changes in Global groups and Domain Local groups are not replicated outside of the domain where they are defined. Therefore, changes to membership in the Universal groups have the most impact on replication throughout the forest, unlike the other group typeswhich are confined to domain boundaries. In order to minimize GC updates, ITG minimizes changes to Universal group membership. Because group membership is stored in Active Directory as a single multivalue attribute, a change to the membership list requires the entire membership list to be replicated. Group membership is limited to 5,000 members per group, so that the store can be updated in a single transaction during replication. Specific desktop configurations for particular groups of users and computers can be created using the Group Policy Microsoft Management Console (MMC) snap-in. This MMC snap-in extends the functionality of the System Policy Editor and provides built-in features for setting Group Policy, including options for registry-based policies, security settings, software installation, scripts, and folder redirection. The Group Policy settings are contained in a GPO that is in turn associated with selected Active Directory system containers: sites, domains, and OUs.

Organizational Units Structure

OUs are the containers used to organize objects within a domain. They form the logical administrative units that are used to delegate administration within a domain. Examples of OUs are geographic locations, projects, cost centers, and business units or divisions. Specifically, OUs can contain, but are not limited to, the following objects: Users Computers Groups Printers File shares Other OUs

An OU cannot contain objects from another domain. In Windows NT 4.0 delegation of administration was achieved at the domain level, and limited to the use of built-in local groups, such as the Account Operators group, or by the creation of separate domains called resource domains. Resource domains were expensive, requiring additional management and hardware. In the Windows 2000-based design resource domains can be consolidated into a hierarchy of OUs. Delegated authority is achieved through combinations of OUs, per-attribute access control, and access control inheritance. OUs are used as administrative constructs for grouping objects within the AD directory service without the overhead of assigning corresponding security identifiers (SIDs) to the objects. SIDs are domain-unique values, assigned when a user, computer, or group is created. Moving security objects between domains assigns new SIDs to the objects, whereas moving objects between OUs does not. OUs are not themselves security constructs, though they provide a means of aggregation that can be used by Active Directory service security mechanisms. The OU hierarchy within a particular domain can be independent of the OU hierarchy in any other Domain. Each domain can implement its own OU hierarchy. ITGs hierarchy design for OUs reflects two primary goals: 1. Application of group policy. For example, controlling policy application so that it applies to a distinct group of users, such as permanent employees or temporary contractors. Distribution of resource management. For example, grouping objects with identical permissions together, and assigning permissions once for the OU rather than multiple times for each resource.

2.

Although OU structures can be unique to each domain, in this design first-level OUs are standardized throughout corpnet.ms.com domains, regardless of whether a particular location requires them, and they primarily contain servers. These OUs house the servers over which each of the Microsoft business units has administrative control. Examples of common first-level OUs include: services, legal, sales, and marketing. For example, the sales operations group has administrative control over the SQL servers in the sales OU. This provides consistency for enterprise support and administration at no additional cost. An OU structure can have many levels. However, LDAP searches are slightly degraded when there are large numbers of OU levels and a simpler environment, where possible, is desirable. ITG arbitrarily limits OU nesting to three levels, which provides a clear, and simple logical structure that is easily understood yet still supports its delegation needs. Users are left in the Users container, and workstations are typically left in the Computers container, unless there is a special need to place them in a separate OU. Figure 8 shows the top-level logical OU namespace common to all domains in this design, with example nested OUs:

N N e s t e d O U s

s t e

S O B a c k u p s R P A O S O U O U
O U

a l e s U p p s U O W f f i c e o r d

r o d u c t s

c o r p n e t . m s . c o m ( c h i l d d o m a i n )
O U O U

L e g a l O U

A O

I T R

S e r v i c e s o o t O U

N R

o n I T G e s o u r c e

I T G O s e r & R o o t

w G O

O n N e de s t e d r o u p s S y s t e m U
O U

I T

I E

Figure 8: Top-level OU Structure In Windows NT 4.0, the system policy editor could be used to define user and computer configurations at the domain level. In Windows 2000, ITG uses Group Policies, which can be applied at the OU level. For example, by using Group Policy in combination with containers, ITG is able to enforce essential settings at the container level, such as: Computer & User Settings. These include policies that specify operating system behavior, desktop appearance, application settings, assigned and published applications, file deployment options, security settings, and computer startup and shutdown scripts. Computer-related Group Policies are applied when the operating system initializes. User-related Group Policies (including user logon and logoff scripts) are applied when users log on to the computer. Software Policies. Software Policies settings mandate registry settings on the desktop. These include Group Policies for the Windows 2000 operating system, components, and applications. User documents and settings. User Documents and Settings extensions are used to add files, shortcuts, or folders to special folders (such as My Documents, Start menu, Desktop, and Favorites) that represent the users desktop. Scripts. Assign scripts to run when the computer starts or shuts down, or when users log on or off their computers using Windows Scripting Host to include both the Visual Basic development system, Scripting Edition (VBScript), and the JScript development software. Security settings. These include: o Account Policies. Computer security settings for password policy, lockout policy, and Kerberos ticket policy in Windows NT domains.

Local Policies. Audit policy, user rights assignment, and security options. Local policy is used to configure who has local or network access to the computer and whether or how local events are audited. Event Log. Controls security settings for the Application, Security, and System event logs.

System Services. Control configuration settings and security options (ACLs) for system services such as network services, file and print services, telephone and fax services, Internet/intranet services, and so on.

Using delegated authority, a group of helpdesk technicians within a given domain can be given the right to reset passwords for a specific group of users, but not the right to create users or modify any other user attribute. Other administrators can be granted the ability to modify a users address book attributes, but not the ability to modify passwords. ITG user account creation is provided by an internally developed tool, which creates unique user accounts in the user container from the data in the HR system. Another internally developed tool centralizes machine account creation in the Computers container. Further detailed information on the creation and management of Group Policy and delegation of administration can be found in the For More Information section of this paper.

Site Topology
Sites, site links, and subnets are objects that represent physical connectivity. They are stored in the configuration container, which is replicated to every DC in the forest. A site is both a physical and logical area of the network containing servers running Active Directory, where network connectivity among machines is assumed to be very good (10 Mbits/s or better). In logical terms sites are used as a unit of scope to control replication traffic. Active Directory automatically creates more replication connections between DCs in the same site than between DCs in different sites. Replication traffic is not compressed within a site, but is compressed between sites. In the Windows 2000-based design ITG optimizes network bandwidth for replication traffic by placing sites on each side of slow WAN links and ensuring that all IP subnets in a site have permanent, high-speed connectivity. In physical terms, Windows 2000 defines a site as one or more well-connected TCP/IP subnets. This is based on the assumption that computers with the same subnet address are connected to the same network segment, typically a LAN or other high-bandwidth environment such as Frame Relay, ATM, or others. Defining a site as a set of subnets lets administrators quickly and easily configure Active Directory access and replication topology to take advantage of the physical network. When a user logs on, the Active Directory-based client finds Active Directory-based servers in the same site as the user. In physical terms, sites are not part of the Active Directory namespace (a logical construct). Domains may span multiple sites as shown in figure 9, and sites may span multiple domains.

s o

D t h

O p a

A I N : c if i c . c o

r p

t . m

s . c o

S R e

i t e 1 d m o

S A
D C D C

i t e 2 u s t r a

S S i n

l i a
D C

i t e 3 g a p

r e

D D C D C D C D C

C D C

Figure 9: Site Topology Site boundaries are delimited by the speed of the network connections, with a minimum link speed of 256 KBs recommended by ITG to accommodate both non-Active Directory traffic and Active Directory replication traffic. Because machines in the same site are close to each other in network terms, communication between machines is fast, reliable and efficient. For users this is useful for quick logon authentication, for example, or for locating a resource by physical proximity. For ITG administrators replication traffic is much easier to manage because only the attribute of the object that has changed needs to be replicated. For example, renaming a user object results in only the name field being replicated, instead of the entire user object (as in Windows NT 4.0). IP Subnets are the foundation of Active Directory location services and new features such as printer location. IP subnets define the physical location of Corpnet resources such as printers, distributed file system (DFS) shares, database locations, file server locations, and so on. Test and lab environments are also partitioned and managed by ITG through subnets. However, most users are unaware of which subnet they are on. When a user workstation connects to the network, it receives a TCP/IP address from a DHCP server, which also identifies the subnet to which the workstation is attached. Workstations that have statically configured IP addresses also have statically configured subnet information. In either case, the DC locator will attempt to locate an AD server located in the same site as the user, based on the subnet information known to the

workstation. Subsequent resource requests, such as finding the nearest color laser printer, are resolved in a similar manner. This is accomplished easily, because the user's workstation already knows what TCP/IP subnet it is on, and subnets translate directly to Active Directory-based sites. Sites are connected using site links. Active Directory site links are used to define connectivity between sites, and together they represent the physical network. A site link represents a set of sites that can communicate with one another at the same cost using the same schedule. For example, two sites that are connected with a point-to-point T1 might be represented by a single site link. A set of buildings (each in their own site) that are connected to each other over an ATM backbone might also be represented by a site link that contains all of those buildings (i.e. sites). A full mesh Frame Relay network might be represented with a single site link, assuming each of the sites had equal cost connectivity to every other site. Site links are used to manage replication traffic between two or more sites using the logical cost and replication interval assigned to them. Both inter-site and intra-site replication traffic is automatically managed by the knowledge consistency checker (KCC) built into Active Directory. Within a site, the KCC automatically generates a bi-directional ring topology for all DCs in the same domain, and all replication traffic occurs using Remote Procedure Calls. The KCC also attempts to ensure that there are no more than three hops from any DC in a site to any other DC in a site by adding additional replication partners where necessary. Between sites, the KCC automatically generates a least-cost spanning tree replication topology, and replication occurs using RPC over TCP/IP. For inter-site replication topology, the KCC takes into account whether a DC has been identified as a Bridgehead Sever, as well as the cost of each site link. It is extremely easy to change site topologyit is just a matter of changing the association of given subnets with given sites. Generally, all Microsoft remote offices have WAN-speed connectivity back to the corporate ATM mesh. Consequently, all remote offices that have a DC/GC are individual sites in the Windows 2000-based design. If a remote office is too small (roughly under 25 people) to cost-justify having its own DC/GC, then their subnet is set to be part of the site which is closest to them on the network (where "closest" implies good WAN speed and low latency). This allows clients from that office to authenticate against the next closest DC/GC. ITGs Windows 2000-based design calls for each site that housed an Windows NT 4.0 DC to house a Windows 2000 domain controller that also serves as a global catalog and DNS service provider, placing the most used services (authentication, directory lookup, DNS, DHCP) physically and logically closest to the end user. Domain Controller/Global Catalog ITG was conducting a worldwide infrastructure upgrade at the same time as the overall Windows 2000 deployment. The placement and specifications of Corpnet DC/GCs were determined taking many factors into consideration.

Windows NT 4.0 resource domain DCs were often housed in the field on the same LAN as the client workstation community they served. At least one additional DC for each resource domain was housed in the corporate data center in Redmond to provide redundancy, fault-tolerance and live backup capabilities. In Windows NT 3.51 and 4.0, there are two kinds of domain controllersPDCs and BDCs. PDCs hold a read/write copy while BDCs hold a read-only copy. In Windows 2000, all DCs hold a writeable copy of the directory. There is no distinction between primary and backup; all DCs are equal. Windows 2000 DCs may also contain a partial replica of all objects of all of the domains in the forest in the form of a Global Catalog (GC). A GC contains a super-set of the objects in the other domains in the forest. ITG refers to domain controllers that also contain a GC as DC/GCs. GCs are implemented on a forest-wide basis. ITG determined hardware requirements and placement of DC/GCs based primarily on end user, application and administrative requirements. ITG conducted tests simulating a wide variety of Corpnet conditions and latencies to determine client response requirements for authentication, LDAP queries and pass-through authentication. For example, site traffic analysis showed that infrastructure network traffic at that time was approximately: 50% browser traffic 30% directory service 5% trust relationships 5% directory replication 10% WINS

Hardware requirements are partially determined by the number of users in a site. The greater the number of users, the greater the hardware requirement for processor/memory, and network interface throughput. Note that ITG found that the disk capacity requirement is the same regardless of the site size, because the data being stored is approximately the same for all DC/GC servers of the same domain. Larger sites have more users accessing the server, so there will be a greater processor and memory requirement. However, the amount of data for Active Directory, SYSVOL, and the DHCP database is very similar in each server. For example, disk space requirements for objects and their attributes were calculated as shown in table 2.
Object Disk Space Required (bytes)

User object Organizational Unit (OU) object (Object) Attribute

4.4K 2.0K 85bytes

Table 2: Benchmark object size These benchmark tests were performed on a Compaq server with two Pentium II 400 Xeon processors and 256 MB of RAM, serving as a DC for the redmond.corpnet.ms.com domain (mixed-mode Windows 2000 domain). In addition, this test server acted as a GC server for the corpnet.ms.com forest; a DNS server for the redmond.corpnet.ms.com domain; and a DHCP server for two scopes consisting of approximately 700 client machines and 32,632 users (including some

groups). The Active Directory database (NTDS.dit) size for this test machine was approximately 310 MB, with typical CPU usage fluctuating between 5% and 10%, with spikes observed up to 80%. Note that these tests were conducted with an early release; final production release figures may vary. However, additional testing on various pre-release object attribute sizes was also conducted to forecast the effects of applications adding information to the store. For example, a public key certificate was found to add roughly 1.7K. Hard-disk storage requirements were also generously forecast, because logging activity can consume hard-disk space, and disk storage is one of the least expensive system components (depending on RAID configuration). These baseline performance figures allowed ITG engineers to begin to forecast the effects of replication and user authentication traffic, and to size and place the new standard infrastructure DC/GC servers to serve those needs both now and in the future with Exchange 2000. Client needs, including downlevel clients, were also forecast, taking into account future software deployments and population growth. For example: All clients must be able to access a MUD DC in order to authenticate to the domain. DCs from native-mode MUDs must be able to access a GC during login because Universal Groups are stored in the GC. Clients accessing Exchange 2000 require a GC to resolve mailbox attribute information and distribution lists, which are stored in the GC as Universal Groups.

Finally, application-publishing needs were considered. Microsoft employees require quick and easy access to software in order to do their jobs. When a Microsoft employee starts a new job, or transfers to a new responsibility, there are standard software applications the employee must have access to, such as the Office productivity suite, as well as specialized applications required for the employees particular job function. In the old domain structure, dedicated product distribution servers, called data distribution servers (DDS) met these software needs. However, most users were unaware of the location of the nearest DDS, and so would install software from a DDS that was known to them, but located across a slow WAN link. Service Publication in Active Directory enables applications to publish the names and locations of services they provide, as well as their installation points, so clients can locate and use services dynamically. Because physical location information for both the clients and DFS shares is in Active Directory requests to DDS resources can be seamlessly rerouted to the nearest available DDS, minimizing network traffic and maximizing user response time for this often-used procedure. Based on this unique environment, and user needs, ITG developed the following guidelines for Corpnet DC/GC placement: At least one DC/GC per site of 1,000 users or more. For larger sites, additional DC/GCs will be placed according to the needs determined for acceptable user response time. A DC/GC in existing Regional Data Centers (RDC) or Site Data Rooms (SR) where there is at least one Exchange server. A DC/GC in each RDC or SDR where there is at least one DDS. A DC/GC replaces each of the existing Windows NT 4.0 PDCs.

At least one DC/GC in the Redmond Datacenter for each production domain so that centralized administrative changes can be mastered locally and the changes replicated automatically by multi-master replication.

The new standard DC/GC hardware platform became known as the Consolidated Services Platform (CSP) that is designed as a domain controller (authentication), global catalog server (resource location), DNS server (name resolution), and DHCP server (address allocation). In some locations the CSP also provides file and/or print services. Corporate Domain Controller/Global Catalog (DC/GC) Configuration Hardware Hardware needs were forecast well in advance of the release of Windows 2000, even though capacity planning tools were not yet complete. ITG also wanted to adequately address future hardware needs. Consequently planners erred on the conservative side and chose a very powerful platform. The standard server platform is sized to support a varying number of users. Example specifications for the 2,000 to 5,000 user platform is based on the Compaq Proliant 5500R, with four Pentium II 450 Xeon processors, a total of 1 GB of RAM, two 9 GB hard drives (RAID 1) and three 18 GB hard drives (RAID 5). Hard Drive Configuration The following is a summary of hard drive configuration ITG applied to all DC/GC servers, regardless of the number of users they support: Physical Disk 0 - Two 9 GB hard drives configured as RAID1 to provide one physical drive, divided into two logical drives (C: and F:) formatted as Windows NT File System (NTFS), each over 4 GB in size, containing: Drive C: (System, DHCP and DNS services) o o The system files - C:\WINNT Pagefile

Drive F: (DS and DHCP Logging) o The log files of Active Directory - F:\NTDS.log

Physical Disk 1 Three 18 GB hard drives configured as RAID5 to provide one physical drive (P:) formatted NTFS containing: The database of Active Directory - P:\NTDS The System Volume files - P:\SYSVOL

Note that drive letters are for illustration purposes only and do not necessarily reflect drive letters used by ITG. Standard Infrastructure Services/Settings All DC/GCs also provide additional services, such as DHCP, and DNS. Some standard servers are further modified to provide file storage and/or applications services. Standard services and settings include: DHCP - The database and its support files are placed in a DHCP directory on the D$ drive, with a subdirectory named BACKUP, where database backup files are kept.

CONCLUSION

Conflict detection is off by default unless scopes are being migrated or used as backup scopes while another DHCP server is down. Lease times are set to eight days unless dictated by special circumstances (such as a high degree of client mobility). Logging is off by default, due to the impact on server performance. If logging is needed for problem diagnosis, it is turned on until the issue is resolved.

DNS - All DC/GC servers have DNS configured so that the DNS zone is an Active Directory Integrated Primary. The dynamic update option is set to Allow only secure updates. Some DC/GCs at sites that have WINS requirements for NetBIOS name resolution are configured with the dns.corpnet.ms.com zone configured to forward lookup WINS queries to the nearest WINS server. Terminal Services - for remote administrative use only. Restricted to two domain admin account connections. File Replication Service (FRS) used to replicate the contents of the SYSVOL container, which contains domain-wide policy settings and user login scripts. Key Distribution Center (KDC) generates session keys and grants service tickets to Kerberos clients. Netlogon provides pass-through authentication of logon events for domain computers. The Netlogon service can be stopped and restarted independently of the directory service. Stopping Netlogon on a DC prevents it from authenticating clients, but does not stop other services. SAM stores security information for Windows NT 4.0 local user accounts. Used only by administrators in DS Repair mode and by the Command Recovery Console.

In the early stages of Windows 2000 namespace planning ITG confronted some barriers in the Windows NT 4.0 Corpnet environment that had to be addressed before moving forward with the deployment of Windows 2000 Active Directory service. ITG is sharing these "lessons learned" in hopes that, when applicable, customers can benefit from ITGs experiences. As Microsoft continues to deploy Windows 2000 Advanced Server and Windows 2000 Professional, ITG will continue to share its experiences with customers. The first lesson that ITG learned was that early planning is extremely important to a successful deployment with minimum end user disruption. The Windows 2000 namespace is fundamentally different than that of Windows NT 4.0, and many of the initial Windows NT 4.0 domain design and deployment considerations were reexamined. This was especially true for the Windows 2000 name space, group policy, and organizational unit strategy. Additional lessons learned include: Optimal namespace design should include several iterations. First, follow the design process based on the ideal desired environment, without regard to dependencies, existing environment, and timeline. Next, set this design aside and follow the process again, this time based on dependencies, existing environment, and timeline. Compare the two and reconcile the differences to determine the best design.

Detailed information on the current environment will be required in order to plan the deployment path from present to future. The number of employees in each location; the speed of local network links; TCP/IP subnets by location; and anticipated growth rates are some of the building blocks from which the namespace design is constructed and deployed. Much of this information may have already been gathered in Y2K projects. The Active Directory Sizer tool (see appendix) can be used to estimate hardware requirements. International considerations regarding the information contained in Active Directory should be reviewed carefully. For example, it may be useful to include an employees home phone number in the Active Directory service; however, Europe for example has specific legal issues in this area that must be followed. The namespace design should take international naming concerns into account. Computer, site, and domain names that have a benign or useful meaning in one language can sometimes be derogatory or offensive in another language. Windows 2000 uses DNS for location services and name resolution, so remember that Windows 2000 domain names are DNS names. Using only Internet-standard characters in domain and computer names will ensure that computers with multiple localized versions of Windows will be able to communicate with each other. The close communication and coordination between ITG, executive sponsors, the product development teams, PSS and end users was critical to success. ITGs Windows 2000 deployment received very high-level executive support from the beginning. Determining what information Active Directory is to hold, and from what source the data will come (for example the HR system), is the key deciding factor for the design. These factors drive the planning of necessary network bandwidth, organization and security requirements. Configure DC/GC system, database and log files on three different hard drives to improve system performance. Use RAID 5 for fault tolerance for the database, since 90% of the operations are read operations. Use RAID 1 or RAID 10 for log files. Deploy from the top down. With tight integration of DNS, and a consolidated infrastructure service platform, installation and configuration of each succeeding DC/GC is to a great degree automatic. The steps ITG used to creating a OU structure plan for a domain were: o o o Create OUs to delegate administration. Create OUs to hide objects. Create OUs for Group Policy.

ITG found it was important to follow the steps in the order presented, because an OU structure designed purely for delegation of administration is shaped differently than an OU structure designed purely for Group Policy.

Future Steps
ITG requires a data population and logging tool for Active Directory to provide data population and logging for such things as sites, subnets, printers, DFS shares and interforest synchronization of Active Directory services. In 1999, Microsoft acquired ZOOMIT, and is developing connection agreements to Active Directory that interface

FOR MORE INFORMATION

with the Microsoft (ZOOMIT) VIA metadirectory4 application to provide some of these enterprise identity management functions for ITGs Active Directory deployment. With the addition of Zoomit technologies, Active Directory will have the ability to detect changes to identity information in various directories and execute business rules to change group policy and user privileges. For example, a transfer of an employee from the finance department to the sales force could be easily accomplished by moving a user object from the finance organizational unit (OU) folder to the sales OU folder. As a result, the group policies assigned to the sales OU would be automatically applied to the user identity, resulting in new privileges to network resources such as creation of a remote access account and distribution of the sales force automation application to that user without additional system administrator or user action.

ITGs initial plans for design and deployment of the Active Directory service at Microsoft were intimately connected with the overall deployment plans for Windows 2000. Initially ITG focused on getting the Active Directory service up and running as a foundation for many other services. Although deploying Microsoft products into production while in beta code can sometimes be at odds with the goal of running the IT utility, the combination of Windows 2000 Advanced Server on the backend and Windows 2000 Professional on the desktop has already yielded bottom-line benefits to Microsoft by simplifying and centralizing network administration and consolidating server hardware. The Active Directory service is already in use for application publication, printer location publication, and delegation of administration. In addition, the ITG deployment of the Corpnet Windows 2000 namespace sets the stage for future technologies, such as Microsoft Exchange 2000, which will use the Active Directory service in place of the Global Address List. Apart from facilitating domain and server hardware consolidation today, network security and transport improvements such as RSVP and QoS set the stage for using the Internet as a primary network pathway in the future, connecting Microsoft, external partners and Internet properties.

To view additional IT Showcase material please visit http://www.microsoft.com/technet/showcase Windows 2000 Active Directory Technical Resources http://www.microsoft.com/windows/server/Technical/default.asp Windows 2000 DNS http://www.microsoft.com/windows/server/Technical/networking/w2kdns.asp Windows 2000 Resource Kit: Online Books: Deployment Planning Guide Active Directory Infrastructure Windows 2000 Upgrade and Installation Windows 2000 Resource Kit: Online Books
4

A metadirectory enables integration of any number of disparate identity repositories in virtually any format, enabling lower administrative costs, elimination of duplication, reduction of discrepancies, and wide distribution of the identity information.

APPENDIX

Distributed Systems Guide Windows 2000 Group Policy Whitepaper http://technet.microsoft.com/cdonline/Content/Complete/windows/win2000/win2ksrv/tech note/nt5polcy.htm Secure Networking Using Windows 2000 Distributed Security Services Whitepaper http://technet.microsoft.com/cdonline/Content/Complete/windows/win2000/win2ksrv/tech note/disesewp For any questions, comments or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send email to showcase@microsoft.com

The Sizer Tool

ITGs experience in planning the size and placement of DC/GCs in Active Directory has been incorporated into a useful capacity-planning tool called the Active Directory Sizer. The Sizer is available to customers through the Web site for the Windows 2000 resource kit at http://windows.microsoft.com/windows2000/reskit/. The Sizer allows customers to estimate the hardware required for deploying Active Directory in the organization based on the organization's profile, domain information and site topology. The Sizer takes a number of user inputs and using internal formulas estimates: Number of Domain Controllers per domain per site Number of Global Catalogs per domain per site Number of CPUs per machine and type of CPU Number of disks needed for Active Directory store Memory required Network bandwidth utilization Estimated Domain Database Size Estimated Global Catalog Database Size Estimated Inter site replication bandwidth required

The list of information to be gathered per domain to accurately size the DC/GCs includes: Total number of users in the domain. o Total number of concurrent users Total number of attributes per user. Active Directory automatically assigns each user a number of attributes. Additional attributes (based on the business uses of the Active Directory service) should be included in the estimate.

Average number of groups a user belongs to. The number of groups a user belongs to can affect the time to process a logon request. The logon request evaluates user access by looking at the access granted to each group the user belongs to. Average logon rate per second during peak hours (Interactive, Batch and Network). Interactive logon type is intended for users who will be interactively using the machine, such as a user being logged on by a terminal server, remote shell, or similar process. Batch logon type is intended for batch servers, where processes may be executing on behalf of a user without their direct intervention; or for higher performance servers that process many clear-text authentication attempts at a time, such as mail or web servers. Network logon type is intended for high performance servers to authenticate clear text passwords. This type is used to access other network resources, such as remote servers or printers. Password expiration rate (in days). Additional Access Control Entries (ACEs) per user. Active Directory automatically adds a set of ACEs to user objects or attributes to control access. For example, an ACE can specify read permission for everyone on the telephone number attribute, but restrict modify permission to the account owner. As the number of ACEs increases all Active Directory operations that check permissions require additional processing. Additional ACEs (either direct or inherited) should be entered. Number of Windows 2000-based computers in the domain. Number of other computers in this domain. Number of other objects published in this domain. Other objects are any objects other than users and computers that will be included in Active Directory. For example, user groups, organizational units, contacts, printers or shares would be consider other objects. Desired average CPU utilization limit for each Domain Controller. Preferred CPU type for Domain Controllers. o Number of processors required of the CPU type specified above. Churn. This section allows an administrator to specify the administrator-generated workload for object addition, deletion or modification to Active Directory. The planned average number of objects added, deleted, or modified on a daily, weekly, or yearly interval should be entered. Microsoft Exchange 2000 issues. Exchange 2000 uses Active Directory for directory services, transport and name resolution. If installation is planned, then the average number of messages per user/per day and the average number of recipients for each message should be entered. DNS related issues. Other Active Directory-enabled application issues. This section covers other Active Directory-enabled applications that are not specifically known by the Sizer. Changes introduced by Active Directory Connector (ADC) or other directory synchronization programs (such as DirSynch) should be estimated in operations per second for searching, adding, deleting and modifying objects.

or by duplicating existing domains. The company topology could then be created by adding sites and site links and users could be distributed among existing sites. On completing these tasks the Sizer estimates hardware requirements for each domain controller (and GC) at each site and estimates the inter-site replication bandwidth.