# Presentation: 951394

## Windows 2000 Active Directory PlanningJoanie RhineConsultant, MCSMicrosoft Corporation

## Agenda

**Domains defined**
**Planning**
**Number of domains (1 is better)**
**OU = Resource Domain**
**Examples**
**Optimize**
**Q&A**

## Domains

**Represent a boundary for Security**
**Define the scope of Replication **
**Must have a specific purpose and justification**

**Notes:**
Summary slide for a Domain in Active Directory

The Active Directory database can be partitioned into “domains”  This allows AD to be a “distributed” database.  Increased scalabilty.

## Domains

**Need to accommodate organizational changes without expensive domain changes**
**Domain design needs to evolve as organizational needs change**
**Plan that domain names will not change**
**One approach is to organize geographically as geographical names rarely change**

**Notes:**
Namespace is important here as organizational changes do occur frequently.  Consider naming that will withstand company changes.
Geography is one approach if the company has not changed over time.
Domain name changing is not available today.  Must move users to new domain using available tools and 3rd party utilities

## Planning your Domain

**Should always start with a single domain and only add domains if necessary**
**The fewer domains the better**
**Changes in domain architecture, such as collapses and re-creation, cause administrative overhead**

**Notes:**
Note that a single domain model is always the easiest and most flexible design.
Additional domains require more hardware (DC), administrators, and more complexity.
Additional domains could change over time.

## Planning (cont.)

**Key business objectives**
**Central administration**
**De-centralized**
**Replication traffic**
**Reduce the network traffic**
**Control information flow to specific locations.**
**Don’t use existing model as an example!**

**Notes:**
What model for administration does the business want?
Are there network bandwidth contraints?
Think about how the company wants to see their information.  Do not concede to the old architecture without justification.

## Instead of Multiple Domains

**Use organizational units (OUs) to reflect the detail of your company’s organization**
**User, groups, and computers can be placed in OUs**

**Notes:**
Use an OU for defining granular levels of administration.  Roll Resource domains into OU.  Assign directory ACL and Group Policy via an OU.

Account Policies	Configure password, account and kerberos policies (domain only)	
Local Policies	Configuring auditing, user rights and security options	
Event Log	Configure settings for application logs, system logs and security logs	
Restricted Groups	Confgiure group memberships for security sensitive groups	
System services	Configure security and startup settings for services running on a computer	
Regsitry	Configure security on registry keys	
File System	Configure security on specific file paths	
Public Key Policies	Configure encrypted data recovery agents, domain roots ad trusted certificate	
IP Security Policies	Configure IP security on a network	

## Reasons to Create OUs

**To delegate administration**
**To replace Windows NT 4.0 resource domains**
**To scope the application of policy**
**Policy precedence is Site, Domain, OU**
**You could create different OUs for full time and contract employees and then create different policies and easily apply the policies**

**Notes:**
Planning process:
Delegate administration
Hide objects
Group Policy

Important to follow the above order!  

## Reasons to Create OUs (cont.)

**To limit the total number of objects that will appear in an OU**
**To control administration of resources**
**Instead of setting permissions on multiple shares, you can set permissions on a single OU that contains the shares**
**To make administration of objects easier**

## Number of Domains		

**Single domain (best choice)**
**Justify additional domains**
**Additional costs (administrative)**
**Preserve existing NT domains (why)**
**Administrative partitioning (unique security policy)**
**Physical partitioning (optimize replication traffic)**

## Multiple Domains/Trees

**Sometimes it is necessary to have more than one domain**
**Multiple domains with a contiguous name space are referred to as trees**

**tailspintoys.com**

**europe.tailspintoys.com**

**marketing.europe.tailspintoys.com**

**Notes:**
Reasons:
Preserving existing Windows NT domains
Administrative partitioning
Physical partitioning

## Reasons to Have More Than One Domain

**If there are multiple business units that, for political reasons, have different names**
**To control where certain data is replicated**
**For example, create domains based on geographical regions **

**Notes:**
Again the recommendation is to have the fewest domains possible.  Reduce the number of trusts and consolidate Resource domains (local admins) into OU.
The political battle will be a challenge to overcome.  Remember that companies do change often in today’s market.  The domain name makes up the tree hierarchy.  This is not easily changed later.

## Reasons to Have More Than One Domain (cont)

**If security is administered at the domain level**
**For example, if there is a need for different security policies**
**Domain Administrators have more control than a delegated OU administrator**

**Notes:**
Physical Partitioning
Physical partitioning involves taking the domains you have in a forest and dividing them up into a greater number of smaller domains. Having a greater number of smaller domains allows you to optimize replication traffic by only replicating objects to places where they are most relevant. For example, in a forest containing a single domain, every object in the forest is replicated to every domain controller in the forest. This might lead to objects being replicated to places where they are rarely used, which is an inefficient use of bandwidth. For example, a user that always logs on at a headquarters location does not need their user account replicated to a branch office location. Replication traffic can be avoided by creating a separate domain for the headquarters location and not replicating that domain to the branch office.

Unique domain user security policy requirements
You might want to have a set of users on your network abide by a domain user security policy that is different from the security policy applied to the rest of the user community. For example, you might want your administrators to have a stronger password policy, such as a shorter password change interval, than the regular users on your network. To do this, you must place those users in a separate domain. 

## Examples of Domain Security Policies

**Password Policy**
**Account lockout**
**Kerberos ticket**
**Event Logs**
**IP Security**
**System Services**

**Notes:**

Examples:

Account Policies	Configure password, account and kerberos policies (domain only)	
Local Policies	Configuring auditing, user rights and security options	
Event Log	Configure settings for application logs, system logs and security logs	
Restricted Groups	Confgiure group memberships for security sensitive groups	
System services	Configure security and startup settings for services running on a computer	
Regsitry	Configure security on registry keys	
File System	Configure security on specific file paths	
Public Key Policies	Configure encrypted data recovery agents, domain roots ad trusted certificate	
IP Security Policies	Configure IP security on a network	

## Reasons Not to Create Multiple Domains

**To reflect your company’s organization of divisions and departments**
**Avoid naming domains for divisions, departments, buildings, floors, and groups**
**A good design will withstand company reorganizations without the need to restructure your domain hierarchy**

**Notes:**
More Domain Administrators 
Because domain administrators have full control over a domain, the membership of the domain administrators group for a domain must be closely monitored. Each added domain in a forest incurs this management overhead.

More Domain Controller Hardware
In Windows 2000, a domain controller can host only a single domain. Each new domain that you create will require at least one computer, and in most cases will require two computers to meet reliability and availability requirements. Because all Windows 2000 domain controllers can accept and originate changes, you must physically guard them more carefully than you did Windows NT 4.0 backup domain controllers (BDCs), which were read-only computers. Note that the administration delegation within Active Directory domains reduces the requirement for resource domains. Some remote locations that currently must host two domain controllers (a master user domain and a local resource domain) will now only require one domain controller if you choose to consolidate to fewer Active Directory domains.
More Trust Links
For a domain controller in one domain to authenticate a user from another domain, it must be able to contact a domain controller within the second domain. This communication represents an added possible point of failure if, for example, the network between the two domain controllers is malfunctioning at the time. The more users and resources located in a single domain, the less an individual domain controller must rely on being able to communicate with other domain controllers to maintain service.
Greater Chance of Having to Move a Security Principal Between Domains 
The more domains you have, the greater the chance you have to move security principals, such as users and groups, between two domains. For example, a business reorganization or a job change for a user can create the need to move a user between domains. To end users and administrators, moving a security principal between OUs inside a domain is a trivial and transparent operation. However, moving a security principal between domains is more involved and can impact the end user.
For more information about moving security principals between domains, see “Determining Domain Migration Strategies” in this book.
Group Policy and Access Control Do Not Flow Between Domains
Group Policy and access control applied within a domain do not flow automatically into other domains. If you have policies or delegated administration through access control that is uniform across many domains, they must be applied separately to each domain.

## Domain Examples

**Large, global company **
**Two possible designs:**

**tailspintoys.com**

**westernhemisphere. tailspintoys.com**

**easternhemisphere. tailspintoys.com**

## Domain Examples (cont.)

**Poor plan**

**tailspintoys.com**

**product2**

**product1**

## Forest

**Forest is a single or collection of active directory domains with the following characteristics:**
**Single Schema**
**Single Configuration Container**
**Complete, Transitive Trust**
**Single Global Catalog**
**Significant FSMO Roles**
**Schema exists as the defining context for all *****object classes***** and their attributes.  It is replicated to every DC in the forest.**

## Forest Root Domain

**First domain in the Forest**
**Must be very fault tolerant**
**Can be a dedicated domain**
**Placeholder (large company)**
**Separate Domain Admins from Forest –wide Admins**
**Easily replicated because of size**
**Never obsoletes (namespace issue)**

**Notes:**
The forest root domain is the first domain that you create in a forest. The two forest-wide groups, enterprise administrators and schema administrators, will reside in this domain.

There is no way to reinstall the forest root domain of a forest.

Using a Dedicated Domain
Creating an additional, dedicated domain to serve solely as the forest root carries all the costs of an extra domain, but it has certain benefits that might apply to your organization, such as:
	The domain administrator in the forest root domain will be able to manipulate the membership of the enterprise administrators and schema administrators groups. You might have administrators who require domain administrator privilege for some part of their duties, but you do not want them to manipulate the forest-wide administrators groups. By creating a separate domain, you avoid having to place these administrators into the domain administrators group of the forest root domain.
	Because the domain is small, it can be easily replicated anywhere on your network to provide protection against geographically-centered catastrophes.
	Because the only role the domain has is to serve as the forest root, it never risks becoming obsolete. In the case where you select a domain from your planned list of domains to be the forest root, there is always a chance that particular domain will become obsolete, perhaps due to a change in your organization. However, you will never be able to fully retire such a domain, because it must play the role of forest root.

## Forest Root (cont.)

**Enterprise Admin**
**By default, the Enterprise Admins group is granted Full Control over all objects in a *****forest*****.**
**Schema Admin**
**The Active Directory schema defines the *****object classes***** and the attributes of object classes that can be created in the directory. The schema administrators security group has Full Control over the *****schema.***

**Notes:**
Enterprise Admin role:
The Active Directory Configuration container is a naming context that is replicated to every domain controller in the forest. Directory-aware applications store information in the Configuration container that applies forest wide. For example, Active Directory stores information about the physical network in the Configuration container and uses it to guide the creation of replication connections between domain controllers. 

The enterprise administrators security group has full control over the Configuration container.

Schema admin role:
The Active Directory schema defines the object classes and the attributes of object classes that can be created in the directory. Object classes define the types of objects that can be created in the directory. The schema exists as a naming context that is replicated to every domain controller in the forest. The schema administrators security group has full control over the schema.

## Domains in a Forest	

**Configuration Container stores and replicates data that is required forest-wide.  (i.e., subnet/topology)**
**Complete and Transitive Trusts are configured automatically.**
**The Global Catalog contains a copy of every object, but only a selected (configurable) set of attributes.**
**The global catalog provides a full index for searching.**

## Definitions

**The global catalog provides a full index for searching. **
**Consider one GC per site to reduce WAN traffic**
**GC is required for network logon in multiple domain environment**
**Floating Single Master Operator (FSMO) **
**Schema Master*******
**Domain Naming Master*******
**Relative Identifier Master****†**
**PDC Emulator****†**
**Infrastructure Master****†**

*** ****Held by only one machine in the forest at any given time.**** **
**† ****Held by one machine per domain for each domain in the forest**** main-wide Role**

**Notes:**
RID - The RID master allocates Relative Identifiers, which are combined with the domain Security Identifier (domain SID) and used to create Security Identifiers for new objects. 
Infrastructure Master – Responsible for updated the group-to-user reference whenever the members of groups are renamed or changed.

## Forest Planning Process

**Step by Step**
**Determine the number of forests required.**
**Forest FSMO Roles**
**Create/Implement change control.**
**Who to involve**
**Domain Administrators**
**Network Security Team**

**Notes:**
Determine number of forest roles required based on security requirements or politics.  Reasons to choose multiple forests are:  

Distrust for enterprise admins
Two way transitive trusts not desireable
Political motivations

Determine which DCs in the forest will hold the forest wide FSMO roles.  By default, this will be the first DC online in the forest, which will hold all roles.  Consider placing the schema and domain naming master on the same machine as they will be infrequently accessed.??   It states that the two roles are seldom used, and are often ones that youwant to watch and secure. Placing them on the same DC would allow you tosecure that single system rather than trying to secure two separate systems.Simplicity leads to security and to manageability.

Create and implement change control—changes to forest and forest root should be infrequent, planning apprpriately should mitigate hassles of forest changes—remember cannot merge forests currently.

## Number of Forests

***Always start with a single forest!***
**The Single Forest Architecture**
**Why?**
**Easy to maintain and setup**
**Single Directory view through the GC**
**Who?**
**Companies with Enterprise Vision**
**Influential CIO/VP Technology**
**Central or Cooperative IT Group(s)**
**Companies looking for domain consolidation**
**Companies interested in single sign-on**
**Companies interested in leveraging the Active Directory for applications across the enterprise**

## Number of Forests

***Always start with a single forest!***
**The Single Forest Architecture**
**What is needed?**
**At a minimum – Single Domain Controller**
**2 recommended for redundancy and Master Operator stand-by.**

**Notes:**
If you lose the forest root, you loser AD, so DO NOT create a forest with only one domain controller....

## Number of Forests

***Always start with a single forest!***
**Multiple Forest Architecture**
**Why?**
**No or Limited Trusts Between Domains**
**Possible Extranet Architecture**
**Irreconcilable differences Between IT Groups**
**Who?**
**Regulated Industries**
**ISV’s That Host Multiple Organizations**
**Highly Political/Distributed Organizations**
**  **

**Notes:**
Multiple and separate organizations....

## Number of Forests

**Incremental Cost for Additional Forest**
**At least one Domain per Forest = At least 2 DCs**
**Multiple Forest-wide components (FSMO Roles)**
**Manual Trusts**
**Limited Scope of Influence/Knowledge**
**Must clone users to move them between forest**
** **

## Forest Change Control

**Schema Change Control**
**List Team Members that will have schema administration rights...create a group**
**Guidelines and Process for requesting and evaluating schema changes**
**Technical and Architectural Review**
**Testing Requirements**
**Training**

## Forest Change Control

**Configuration Change Policy**
**Enterprise Administrators**
**Starting Membership**
**Guidelines and Process and creating new domains and modifying forest-wide site topology**

## Forest Change Control

**Currently:**
**Forests cannot be merged**
**Domains cannot be moved between forests**
**Best to have a single forest unless absolutely necessary**

## Forest/Domain Optimization

**Issue:  Slow logon or resource access**
**Multiple domains (user needs access to resource in different domain)**
**DC from each Domain must communicate.  (parent-child okay)**
**If not parent child, then:**
**Slower login times**
**Authentication traffic across WAN**

**Notes:**
When a user requests access to a network resource, a domain controller from the user’s domain must communicate with a domain controller from the resource’s domain. If the two domains are not in a parent-child relationship, the user’s domain controller must also communicate with a domain controller from each domain in the trust tree between the user’s domain and the resource’s domain. Depending on the network location of the domain controllers for each domain, each extra authentication hop between the two domains can increase the chance of a possible failure, or increase the likelihood of authentication traffic having to cross a slow link. To reduce the amount of communication necessary for such interactions, you can connect any two domains with a shortcut trust relationship.

## Optimization	(cont.)

**Create Shortcut Trust Relationships**

**Notes:**
For example, if you have multiple trees in a forest, you might want to connect the group of tree roots in a complete mesh of trust. Remember that in the default arrangement, all tree roots are considered children of the forest root from a trust perspective. That means authentication traffic between any two domains in different trees must pass through the forest root. Creating a complete mesh of trust allows any two tree root domains to communicate with each other directly.
This slide shows a complete mesh of trust created between four tree root domains.

## Optimization	(cont.)

**Consider domain controller and global catalog placement**
**Place domain controllers in sites where users logging on**
**Consider placing domain controllers for frequently accessed domains in the same site**
**Implementing one global catalog per site will decrease query traffic and logon traffic**

**Notes:**
For example, if you have multiple trees in a forest, you might want to connect the group of tree roots in a complete mesh of trust. Remember that in the default arrangement, all tree roots are considered children of the forest root from a trust perspective. That means authentication traffic between any two domains in different trees must pass through the forest root. Creating a complete mesh of trust allows any two tree root domains to communicate with each other directly.
This slide shows a complete mesh of trust created between four tree root domains.

## Impact of change

**Difficult to restructure**
**Organization changes**
**Organization based partitioning **
**Geographic based partitioning **
**Adding and removing domains**
**Tree root domain is top level!**

**Notes:**
Can add  new domains but the move process is lengthy.  SID dependencies.

Consider organization change vs. geographic change history of the company.  Choose the most static of the two.

Tree root can’t be changed!!!!

## Impact of change (cont)

**Domain can only be removed if it has no child domains**
**No tools to split domains currently**
**Can create new and move objects**
**Domain can’t be renamed**
**Consider namespace that will not change**
**Can create new and move objects**

**Notes:**
3rd party tools from:
Mission Critical
Fastlane
Entevo
Clone Principal

## Order for AD Planning

**Read Deployment Guide!**
**Forest Plan**
**Domain Plan**
**OU Plan**
**Site Topology**
**Read Deployment Guide!**

## Summary Points

**Single Domain/Single Forest  is the best**
**Forest Root domain is critical**
**Build domains based on longevity of the namespace. **
**Use OU for:**
**Resource Domains**
**Group Policy based administration**
**Directory objects**

## Windows 2000 Active Directory Planning:Case Study by BanyanJoe BiggsConsultantBanyan Corporation

## Agenda

**Banyan’s Changing Business Environment**
**Planning and Implementation Approach**
**Lessons Learned**

## A Tale of Transformation

**Banyan’s is a unique story of transformation from a “pure-play” product company to a “pure-play” services company**
**Past infrastructure was designed to support a product-focused business and as a result “non-homogenous”**
**Lacked consistent application integration**
**Our needs are simple, but critical:**
**Consolidation and standardization**
**Environment management and control**
**Decreased cost of ownership and administration**
**Increased business flexibility and nimbleness**

## Role of Windows 2000 and Active Directory

**Establish a consistent operating system and directory foundation that is representative of the business**
**Create a hub for role/policy-based computing to enable relationships between people, information and process**
**Create a client showcase for directory-powered e-business**
**Maintain a pragmatic, consulting perspective**
**Optimize our technology and cost base**
**Facilitate rapid response to business needs, such as organizational change or acquisitions**
**Allow multi-vendor flexibility, thereby planned heterogeneity**

## Our W2K Migration

**Windows 2000 Professional deployed worldwide**
**27 Windows 2000 servers globally – consolidated from 172 Windows NT, VINES, and StreetTalk for NT servers!**
**Active Directory is fully deployed**
**Desktops are being controlled via role-based policies**
**Terminal Services are being use with key legacy applications**
**User support is being provided via NetMeeting Remote Desktop Sharing**

## Where we will go tomorrow

**Widespread use of IntelliMirror**
**Expanded policy usage**
**Implement Exchange 2000**
**Implement new enterprise business applications**
**Integrate existing corporate applications with Active Directory**
**Integrate acquired companies **

## Where we will go tomorrow

**Build our internal environment as a showcase **
**Build as the basis of the business internet**
**Wireless**
**ASP oriented (international only)**
**Portal and Dashboard **
**Knowledge Management and collaboration**
**Leverage the Windows 2000 investment!**

## Our Microsoft Connection

**Banyan Worldwide is a Microsoft Enterprise Partner**
**Only 15 in the world**
**Committed to train 500 new MCSEs in 3 years**
**Windows 2000 Rapid Deployment Partner (RDP)**
**Exchange 2000 Alliance Partner Readiness Program**
**Microsoft Certified Solutions Provider Partner (MCSP)**
**Premier Support Services (PSS)**

## Banyan’s Windows 2000 Planning & Deployment Approach

**Build Teams**
**Train & Learn**
**Planning**
**Assessment/Discovery**
**Design & Architecture**
**Development & Planning**
**Prototype**
**Pilot**
**Implementation**

## Build Teams

**Build Teams**

**Active Directory Architecture **
**Servers (file, print, other)**
**Desktops**
**Corporate Applications**
**Training**
**Project Management**

**Teams designated for major areas:**

## Train & Learn

**Train & Learn**

- In-depth architecture and design courses (partners only)
- Generally available training (Microsoft Official Curriculum)
- Banyan’s Windows 2000 “Special Forces” Training
- Development Lab/Microsoft Solutions Center
- Guided self-study/hands-on
- Banyan’s Windows 2000 Knowledge Base

## Planning Assessment and Discovery

**Identify information about**
**Organization**
**Locations**
**Enterprise Computing Environment**
**Network**
**Internet**
**Desktop**
**WAN/Remote Communications**

## Planning Design & ArchitectureDirectory Infrastructure

**DNS Design**
**Active Directory Design**
**Forest(s)**
**Domain(s)**
**Organizational Units**
**Group Policy**
**Delegation of Administration**
**Sites & Services/Server Placement**

***Windows 2000 Strategic Directions Workshop***
***(1 - 2 Days) ***

## DNS Design Considerations

**Internal DNS records should not be exposed to the Internet**
**Internal DNS servers should never directly query the Internet**
**All Windows 2000 client logons must access a DNS service**

***No DNS - NO network logon***

**Notes:**
Slide Objective:  Identify some design guidelines for selecting a DNS design

No Internet user should ever be able to query the DNS record for your PC on the internal network (and discover why types of resources you’re using, discover IP addresses for directed attacks, etc).
No internal DNS server (supporting the Windows 2000 network) should ever query a DNS server on the Internet.  This opens a hole through the firewall that skilled hackers can exploit.
A W2k client needs a DNS server to get logged on – it uses DNS (after getting an IP address/configuration from DHCP) to locate its closest Domain Controller (DC) and then get logged in.

## Active Directory Design Example

**Active Directory Design Example**

- Building Blocks of Active Directory
**Forest(s)**
**Domains**
**Organizational Units**

***Forest***

**Notes:**
Slide Objective:  To show that there’s more than one right answer

We could’ve just as easily deployed a single domain for our entire worldwide organization, as depicted here.  We basically decided on the other design to gain experience in working with multiple domain organizations and to allow our overseas divisions (emea and apj) to exercise greater control over their portions of the network.

## Banyan’s Active Directory Design- Americas/HQ

**Banyan’s Active Directory Design- Americas/HQ**

**Single domain for Americas and Corporate Headquarters**
**Organizational Unit (ou) for each level of:**
**Delegated administrative control**
**Application of group policy**

**Notes:**
Slide Objective:  To show the next step in the design process – identifying structure within the domain – organizational units.

The structural model shown here is geo-political.  You can also go with just geographical, just political or some other logical representation of the organization.  Note that we still have NOT include physical network layout at this point.  We’re still designing the logical directory design first.

## User Naming - bnyn.org

**User Naming - bnyn.org**

**Apply a User Principal Name (UPN) of “banyan.com” to all Windows 2000 domains**
**Use W2k logon (b) to logon and as email address**
**User is insulated from domain/ou hierarchy**

**Joe Smith**
**username:****	****    jsmith**
**down-level logon:  bnyn/jsmith**
**W2k logon (a):****	****    jsmith@bnyn.org**
**W2k logon (b): ****	****    jsmith@banyan.com**
**email addr:****	****    jsmith@banyan.com**

**Notes:**
Slide Objective – Show the impact of the design decisions on a user.

Let’s take a look at how a user is affected by the choices we’ve made – for instance, Joe Smith.  Using  a standard of first initial and last name, we come up with a user name of jsmith.  So far so good.

With W2k’s built in down-level support (meaning support for NT4, Win95 and Win98 clients), the domain and user name is banyanww/jsmith.  Note how it uses the first part of the W2k domain as the down-level domain name.

So now, we see that the user has a W2k login of jsmith@banyanww.org.   However, they have an Internet email address of jsmith@banyan.com.  We’ve now created two different names for them to remember – not a good idea (we want to minimize logins/usernames, not add to them).

Well, with a feature within Windows 2000 called User Principal Naming (UPN), we can apply a “mask” or template of all the users within a domain tree.  In our case, we chose “banyan.com” .  This means the user can use this in place of their real W2k domain and the system will accept it.  Now we have a user name and email name that are the same!  Excellent...

## 3 Sites
Each site=collection of high speed connected networks
Domains can cross site boundaries
Services
Domain Controller (DC)
Global Catalog (GC)
Domain Name System (DNS)
Dynamic Host Control Protocol (DHCP)
Clients seek services in own site first

**Each site=collection of high speed connected networks**
**Domains can cross site boundaries**
**Services**
**Domain Controller (DC)**
**Global Catalog (GC)**
**Domain Name System (DNS)**
**Dynamic Host Control Protocol (DHCP)**
**Clients seek services in own site first**

**Westboro**
**site**

**Melbourne**
**site**

**UK**
**site**

**128k**

**128k**

**1.54Mbs**

**I**

**Active Directory Site Design & Server Placement**

**Notes:**
Slide Objective:  To show that the physical network doesn’t impact design until we get to site design.

Now that we have our optimal directory design, we can design our sites.  Sites allow us to group high-speed networks (LANs or campus networks, for example) for providing services.  Thus, when a client needs services, they will first go to servers in their own site before searching elsewhere.

A domain and/or an organizational unit can span sites.  It just so happens that our directory design breaks up evenly with our site design.  If we had chosen the single domain model (with the two OUs for the international regions), we could still use this site design.

With this site design, we can then decide where to place our network services – such as Domain Controllers (DCs), Global Catalogs (GCs), DNS servers and DHCP servers.

## Capacity Planning & Resource Sizing

**Size of Active Directory – estimate size of NTDS.DIT file**
**Watch size of SAM (for down-level compatibility) when mixing Windows 2000 PDC Emulator with Windows NT 4 BDCs**
**Replication Traffic**
**Domain Naming Context (NC)**
**Schema/Configuration NC**
**Global Catalog**

## Planning – Development & Planning

**Prototype**
**Lab environment**
**Methods and procedures **_**testing**_
**Applications testing**
**Test ALL applications thoroughly**
**Client/Server and Desktop**
**Test ALL functionality (including print)**
**Pilot**
**Live/production users**
**Methods and procedures **_**verification**_

## Migration Options

**In-place upgrades (avoid – don’t carry forward legacy clutter)**
**Synchronize Exchange 5.5 directory with the Active Directory Connector**
**Use Clone Principal & SIDHistory to replicate SIDs**
**3****rd**** Party Tools**
**Mission Critical/NetIQ**
**FastLane**
**BindView/Entevo**
**Others**

## Implementation

**Staged/incremental deployment**
**Continuous improvement process – build in review periods**
**Use a formal change management process**
**Establish measures of success**

## Learnings

**Strategy and planning are critical from both business and technical perspectives**
**Defined methodology drives efficiency and effectiveness**
**Management support is imperative**
**Change management processes must be employed**
**Upfront user community involvement is key**
**Organizations should exploit the opportunity to standardize, consolidate, gain control and clean-up**
**Be aggressive “slaying sacred cows”**

## Learnings (continued)

**Be focused!  Otherwise breadth and depth of the products will lead to endless scope creep**
**Time-box deliverables and focus deployment team on specific areas of the products**
**Put testing in the hands of the accountable users**
**Revisit business drivers and objectives regularly to ensure focus**
**Train deployment and operations staff upfront**

## Learnings (continued)

**Do a comprehensive, exhaustive H/W and S/W inventory**
**Complete application testing, all features**
**Group Policies can be powerful – with power comes responsibility**
**Terminal Services/NetMeeting Remote Desktop Sharing**
**Image control**
**NT4 Service Accounts**

## Summary

**Windows 2000/Active Directory and Exchange 2000 vital to our success**
**Comprehensive planning and testing keys to the success**
**The breadth and depth of Windows 2000 is unprecedented**
**Determine and establish manageable scope**
**Prioritize and implement features in manageable sizes**

## Breakout Sessions

| Best for Digital Business | Easier to Manage and Use | Reliability |
| --- | --- | --- |
| 101: Developing Scalable E-Commerce Windows DNA Applications on Windows 2000  | 201: The Power of Pro  | 301: Namespace Planning for Windows 2000 Active Directory  |
| 102: Windows 2000 Reliability, Scalability and Availability  | 202: Planning a Migration from Windows 9x/NTW 4.0 to Windows 2000 Pro  | 302: Windows 2000 Active Directory Planning  |
| 103: Upgrading an E-Commerce Company to Windows 2000  | 203: Strategies for Rapid Deployment of Windows 2000 Professional  | 303: Windows 2000 Active Directory Organizational Unit and Group Policy Planning  |
| 104: Thin Client Solutions using Windows 2000 Server Family  | 204: Managing the Desktop with Windows 2000 Active Directory and Group Policy  | 304: Cluster in a Box with Windows 2000 Advanced Server  |

## Where

**do**

**you**

**want**

**to**

**go**

**today?**