Microsoft Confidential Windows 2000 活动目录设计 与部署: 最佳实践 微软产品技术顾问 微软中国有限公司 Microsoft Confidential Agenda Active Directory™ Strategy And Roadmap Active Directory Design: Best Practice Active Directory Deployment: Best Practices
Download ReportTranscript Microsoft Confidential Windows 2000 活动目录设计 与部署: 最佳实践 微软产品技术顾问 微软中国有限公司 Microsoft Confidential Agenda Active Directory™ Strategy And Roadmap Active Directory Design: Best Practice Active Directory Deployment: Best Practices
Microsoft Confidential Windows 2000 活动目录设计 与部署: 最佳实践 微软产品技术顾问 微软中国有限公司 Microsoft Confidential Agenda Active Directory™ Strategy And Roadmap Active Directory Design: Best Practice Active Directory Deployment: Best Practices Microsoft Confidential Today’s Directory Roles Application-specific E-Mail address book/White pages Information ‘joined’ from multiple directories NOS directory Name and e-mail address information Enterprise directory Coupled tightly to an application Typically a database Users, computers, devices, applications,… Outward-facing directory Users and profiles Typically an LDAP directory Microsoft Confidential Before Active Directory… For each Windows NT® 4.0 domain: Domain Controllers (PDC, BDC) The Computer Browser WINS (in many domains) Exchange directory (in many domains) Each system Has unique object, admin, monitoring, backup/restore, and security models Maintains replicated objects May have scalability issues Microsoft Confidential The NOS Directory Motivation Store of objects, used by variety of applications, distributed where needed on the network Example: Single Sign-On The idea isn’t new Banyan Vines DS (1984) Directory service for PC email and security Novell NDS (1993) Netware 4.0 introduced NDS to overcome limitations of Netware 3.x "bindery" Microsoft Confidential Design Choices LDAP access and data model DNS-based object naming and server discovery Enables globally unique namespace Based on de-facto Internet locator service Security Protocol was becoming industry standard Object hierarchy permits subtree-scoped queries Schema defines attributes and object classes Multiple authentication paths (NTLM, Kerberos, other), one authorization model Attribute-level access control - required for data sharing between applications In-place or side-by-side upgrade Learned from Novell: offer upgrade flexibility! Microsoft Confidential Replication Design Choices Multi-master Attribute-level granularity When attribute changes, replicate entire new value Reduces network traffic and lost updates versus object-level granularity State-based Needed for local password update Approximately “last writer wins” Eventual convergence Send current state not a log Predictable storage overhead, needed anyway for full sync Tombstones for deletes Transitive (“store and forward”) Communicate update to somebody not everybody Big win with mixed link speed - once per slow link Automated topology generation (“KCC”) ® Microsoft Confidential Windows 2000 and Active Directory Kerberos and NTLM authentication service Public Key Infrastructure Store information about applying policies DFS and FRS Printer information is published in AD Group Policy Locate certificates & perform service location Print service location Store user and password information Store configuration data DNS, DHCP, IPSec, IAS (RADIUS), QoS Store configuration data (i.e. RAS policy) Microsoft Confidential ® Case Study: Microsoft ITG 13 Master User Domains (MUDS) 2-Way Trusts Africa Central Europe Far East 1-Way Trusts Middle East MSLI Corp MSForest North Northern South Southern MSNBCI Redmond America Europe America Europe SYSWINNT AppsWGA Resource Domains (approx 420) Windows NT 4.0 Domain Model Approximately 5000 trusts (!) South Pacific VMUDVendor Microsoft Confidential Case Study: Microsoft ITG Norway Finland Poland Russia DenmarkSweden Ireland Holland Czech Rep Germany England Belgium Austria France Switzerland Spain Hungary Italy Portugal Turkey Greece Israel Morocco Data Center Korea Japan China Taiwan Hong New Delhi KongPhilippines Bombay Thailand Bangalore Kuala Lumpur Singapore Data Center Redmond Data Center Bismarck Boston Oregon Tucson Charlotte Dallas Smyrna Puerto Rico Mexico BogotaVenezuela Medellin Ecuador Egypt Ivory Coast Brazil Chile Uruguay Argentina With the Windows 2000 domain model Kenya Peru Indonesia Australia New Zealand UAE Single forest for ‘corporate’ A root domain with 13 child domains 1.1 million objects, 19GB DIT for Global Catalog South Africa Microsoft Confidential Key Benefits 14 domain databases versus 433 13 essential trusts versus 5000 Far fewer domain controllers Was 2 (minimum) per resource domain Simpler DNS management No trust “rot” Integrated DNS managed as part of Active Directory New capabilities Group Policy makes hundreds of applications easy to install “Find printers” solves a universal headache Simplified corporate application development Microsoft Confidential What We Learned Norway Finland Poland Russia DenmarkSweden Ireland Holland Czech Rep Germany England Belgium Austria France Switzerland Spain Hungary Italy Portugal Turkey Greece Israel Morocco Data Center Korea Japan China Taiwan Hong New Delhi KongPhilippines Bombay Thailand Bangalore Kuala Lumpur Singapore Data Center Redmond Data Center Bismarck Boston Oregon Tucson Charlotte Dallas Smyrna Puerto Rico Mexico BogotaVenezuela Medellin Ecuador Peru Indonesia Australia New Zealand Active Directory works as intended… Ivory Coast UAE Kenya Brazil Chile Uruguay Argentina Egypt Replicates efficiently across WANs Supports very large numbers of replicas Stores very large numbers of objects Is secure down to the attribute level South Africa Microsoft Confidential What Else We Learned Technical Potential group replication collisions Replica and GC creation can take a long time Migration tools need to be more complete Monitoring requires scripting and 3rd-party tools Deploying multiple forests should be simpler Non-technical Windows NT Windows 2000 = paradigm shift Cross-group planning requirements and irreversible decisions lengthen planning cycles DNS configuration should be simpler Need “prescriptive” versus “descriptive” content What We’re Doing In Windows .NET Microsoft Confidential To ease deployment No-GC logon for branch office deployments Create replica from media Replication improvements Per-value replication for group membership * Eliminate limitation in number of sites through improved topology generation algorithm * No full sync when extending the GC partial attribute set Eliminate 5000 member group membership limitation * Updated Active Directory Migration Tool (ADMT) Password migration * Requires Windows .NET forest functionality level What We’re Doing In Windows .NET Microsoft Confidential To improve manageability Domain rename * and domain controller rename Cross-forest trust * DNS improvements Built-in diagnostics in DCPROMO Stub zones and conditional forwarding Control client settings through Group Policy Improved admin tools Drag and drop Multi-select and edit users Command line administration tools * Requires Windows .NET forest functionality level What We’re Doing In Windows .NET Microsoft Confidential Things to keep in mind Windows 2000 and Windows .NET Active Directory are fully interoperable Some features are not enabled until all domain controllers in a forest are upgraded to WIndows .NET None of the features in Windows .NET require you to stop or redesign your current deployment Microsoft Confidential The Enterprise Directory Enterprise directory characteristics Needs to “join” data from many sources Repository of consolidated information from many sources, usually about people Used for centralized management and provisioning Intended for reuse by many applications NOS, ERP, databases, PBXs, more… Key technology: metadirectory Pioneered by Kim Cameron at Zoomit Corp. Microsoft Confidential The Enterprise Directory Active Directory design choices Scriptable access via ADSI Low-level access via LDAP C API Extensible schema Microsoft acquired Zoomit in July 1999 Position Active Directory as an Enterprise directory Make it easier to integrate Active Directory with other directories Provide platform for directory-centric “provisioning” Simplify multi-forest operation Microsoft Confidential Customer Example: ICL-only information All computers across the enterprise Microsoft NT >50,000 accounts TRACS Exchange 5.5 26,000 users NT Domains X.500 Employees/contractors 18,000 records (in SQL) Human Resources Metaverse Active Directory >10,000 Users Active Directory Exchange 5.5 MMS Self-Service Web Application > 50,000 users and more than 80 connected directories under management by MMS Active Directory is provisioned for users automatically Microsoft Confidential Active Directory And Exchange Active Directory replaces Exchange directory Integrates Windows and Exchange concepts Mailboxes Users Custom recipients Users and Contacts Distribution lists Groups Repository for Exchange configuration Security authority for Exchange data and applications Shared topology using Active Directory sites Microsoft Confidential What We Learned Customers consolidating NOS and Enterprise Applications piggyback on NOS infrastructure Exchange 2000 Public Key Infrastructure MMS works as intended… Supports connectivity to wide range of directories, applications, databases and ‘other’ Able to build and maintain ‘joined’ namespace ‘Converges’ even after connected directory failures MMS 2.2 solutions available via 30+ partners Microsoft, Compaq, DeLoitte, ePresence, Lucent, more… Microsoft Confidential What Else We Learned Technical Broad scale-out of NOS directory puts constraints on applications: no big data, no volatile data MMS connector development and configuration not as easy as we would like MMS programmability, scalability could be better Non-technical Consolidation easier in small companies, but may be more difficult in larger companies Messaging group has new dependency on NOS group Multiple NOS forests common for autonomy, isolation; MMS is crucial in these situations Many “Application directories”: independent directories tied to an instance of an application What We’re Doing In Windows .NET Improved standards support Aux classes Virtual List View Improved flexibility for developers Schema deactivate Application partitions Microsoft Confidential Container with arbitrary replication scope Suitable for large and/or volatile data DSML 2.0: mapping of LDAP to http/XML “Resource forest” as application directory Microsoft Confidential Summary “Over the long term, Active Directory will accelerate the directory’s progress toward commodity status which will put it on part with TCP/IP as an essential component of the baseline network services infrastructure” -- The Burton Group Active Directory is: Engineered to meet your needs now and for a long time to come Ready to deploy now We’re delivering on that vision now and it gets better in Windows .NET Microsoft Confidential Best Practice Active Directory Design For Managing Windows Networks Microsoft Confidential What Is Active Directory Design? Creating structure around objects Microsoft Confidential Design Process 1. 2. Determine number of forests Forest design Domain design DNS design Organizational unit design Site topology Microsoft Confidential What Is A Forest? An instance of Active Directory A collection of partitions called domains Sharing centrally-controlled schema Sharing centrally-controlled configuration Global catalog for easy searching Complete trust Security and administrative boundary Microsoft Confidential Best Practices Forest Model Model #1: Centralized Division 1 Division 2 Division 3 Single centralized DS infrastructure Microsoft Confidential Best Practices Forest Model Model #2: Subscription Division 1 Division 2 Division 3 Opt-in/out of centralized infrastructure Microsoft Confidential Best Practices Forest Model Model #3: Distributed Division 1 Division 2 Division 3 Separate DS infrastructures for each autonomous division Microsoft Confidential Forest Design Each forest owner proceeds with independent forest design Domain design DNS design Organizational Unit design Site topology Microsoft Confidential Domain Design What is a Domain? A domain is a partition of a forest Replication boundary Administrative boundary Enable directory to scale out Over slow or congested networks Limit where data is replicated Microsoft Confidential Best Practices Domain Model Dedicated Root Domain corp.ellipsis.dot New branch of DNS: <prefix>.<existing_name> Admin users only One Level of Child Domains noam ds eur Single, or Geographic Microsoft Confidential Best Practices Domain Model Dedicated root One level of domains Enables easy transfer of forest ownership Isolate forest admins from ordinary admins No strong need for multiple trees or disjoint namespace No strong need for grandchild or deeper nesting Geographic partitioning Map well to network/WAN layout Map well to organization of global IT group Stable - geography is relatively unchanging Microsoft Confidential Best Practices Model Say No to Organizational Domains Autonomous org may want own domain Unlikely that forest owner trusts org domain owner - forest owner accountable for service delivery in whole forest Unlikely that org domain owner trusts other org domain owners – after all, wanted domain in order to stay autonomous! Autonomy can ONLY be achieved by creating a separate forest Microsoft Confidential Domain Design Process 1. 2. 3. 4. 5. Design forest root domain Select single or regional domain model If regional model, define regions Define origin and name of each domain Map remaining Windows NT domains to Active Directory domains for consolidation Microsoft Confidential Sizing Guidelines Single Global Domain Minimum bandwidth on global network (kbps) 9.6 14.4 19.2 28.8 38.4 56 (or higher) Create single global domain no larger than (# of users) 20,000 30,000 40,000 50,000 75,000 100,000 * Assumes 10% of channel available for replication (see Appendix) * Approximation only, not a substitute for lab testing * Applies to forests up to 100,000 users - larger forests are possible Microsoft Confidential Domain Design Example MUD MUD MUD 60,000 users slowest link = 28.8 kbps MUD RD RD RD RD MUD RD RD RD RD Microsoft Confidential Replication Sizing Assumptions Net 10% of channel used for replication All DCs are GCs Incoming new user rate 20% per year Outgoing user rate 15% per year Dominant factor in replication traffic is group membership changes 1:1 ratio users to computers DS-integrated DNS in use DNS scavenging in use Microsoft Confidential DNS Design How does Windows 2000 use DNS? Windows 2000 uses DNS as a domain locator and name-to-IP translator Domain controllers are registered in DNS Clients query DNS to locate DCs Analogous to Internet mail (the MX record) Better-scaling long-term replacement for NetBIOS Name Services (aka WINS) Microsoft Confidential DNS In A Nutshell zone ‘.’ (root) forwarding dot iteration client Q: What is the IP address of www.ellipsis.dot? authoritative for ellipsis.dot delegation ellipsis Microsoft Confidential DNS Design Elements of a DNS Design DNS server configuration Server placement Zone placement and type Method of recursive name resolution DNS client configuration Computer naming Resolver configuration Microsoft Confidential Best Practices DNS Model Server Configuration Server placement: Run Windows 2000 DNS on all DCs Method for recursion: Use same method as current DNS servers corp.ellipsis.dot corp noam _msdcs noam _msdcs ellipsis.dot Zone placement: Each domain hosts DS-integrated zone of name of domain, secure update, scavenging enabled Forest root also hosts _msdcs.<fr> zone Child domain hosts secondary copy of _msdcs.<fr> zone through incremental zone transfer Microsoft Confidential Best Practices DNS Model Resolver Configuration Windows 2000 clients must be provided with the IP address of a DNS server Can be any pre-existing DNS server Does not have to be Windows 2000 server Clients will automatically locate correct DNS server when sending dynamic update Microsoft Confidential Organizational Unit Design What is an Organizational Unit? Hierarchical structure within a domain Group objects for management Delegation of administration Scope of policy Microsoft Confidential Best Practices OU Model Overview Service owner <domain> Account owner Resource owner Users Computers Domain Controllers <acct> …<acct> <res> Users Service Accounts Computers Groups Admins <res> …<res> …<res> Microsoft Confidential Best Practices Model Overview Default containers/OUs Account OUs Well-known and built-in users and groups Used to manage identity and policy Analogous to Master User Domains Resource OUs Used to manage access to resources Analogous to Resource Domains Microsoft Confidential Site Topology Design What is a Site? A site is an area of good connectivity Defined as a set of IP subnets Clients prefer servers in their site Intra-site replication optimized to reduce update latency Inter-site replication optimized to reduce bandwidth usage Sites connected by Site Links Microsoft Confidential Site Design Process 1. 2. 3. 4. Create location map Place DCs into locations Map locations to sites Connect sites with site links Microsoft Confidential 1. Create Location Map Hub Hub Hub Hub Microsoft Confidential 2. Place Domain Controllers Place forest root DCs Place regional domain DCs Into relevant hub locations Into sites that require autonomous logon Place each domain’s PDC Into each hub location Into locations with DCs from >1 domain Into well-connected location With large number of users from domain Remember physical security requirements! Microsoft Confidential 2. Place Domain Controllers eur (p) noam (p) root root noam eur root noam soam soam root soam (p) eur Microsoft Confidential 3. Map Locations To Sites eur (p) noam (p) root root noam eur root noam soam soam root soam (p) eur Microsoft Confidential 4. Connect Sites With Site Links Connect sites according to WAN links Name site links: <site1>-<site2> If any site is connected to >20 sites, stop – consult Branch Office whitepaper Set site link parameters Cost: understand failover behavior Schedule: keep open when possible, understand impact on replication latency Interval: based on latency requirements Microsoft Confidential Capacity Planning Deploy enough DCs to satisfy user demand at a reasonable cost Too few: poor service Too many: high cost to deploy, operate Parameters Number and speed of CPUs Memory size Disk size and configuration Microsoft Confidential Impact On Performance FACTOR CPU User Logon Workstation logon LDAP search Replication <10 partners Replication >10 partners KCC <200 sites KCC >200 sites High Medium Variable Low-Medium High Low-Medium High PDC role High GC role Variable Microsoft Confidential Best Practices First scale up, then scale out Scale up: small number of powerful DCs Scale out: add more DCs to distribute load Long-term admin cost savings for smaller number of DCs outweighs short-term higher purchase cost of powerful DCs Aim for average CPU utilization <60% Microsoft Confidential CPU And Memory Guidelines USERS IN SITE DCs IN SITE GCs IN SITE DED* <100 No 100 – 500 500 – 1,000 One uniprocessor PIII One 500 Mhz 512 MB One uniprocessor PIII One 500 Mhz 512 MB One dual processor One PIII 500 Mhz 1 GB 1,000 – 10,000 Two quad processor PIII Xeon 2 GB Two Yes >10,000 One quad PIII Xeon 2 GB, per 5,000 users One GC per two Yes DCs, min of two Yes Yes Microsoft Confidential CPU And Memory Exceptions For forests with 100-200 sites, use multiple processors on all DCs in forest For sites connected to >10 sites, use multiple processors on all DCs in site Single global domain: make all DCs GCs Use Dedicated PDC configuration for domains >50,000 users Lowering priority of DC in locator will keep “ordinary” requests away Use same h/w as >10,000 user site Microsoft Confidential Disk Guidelines DC: 0.4 GB per 1,000 users GC: (DC) + (Sum of store other domains)/2 USERS IN SITE <10,000 >10,000 COMPONENT Operating system Log files Database and SYSVOL Operating system Log files Database and SYSVOL DISK Single RAID 1 disk RAID 1 RAID 1 RAID 1 (good) or RAID 0+1 (better) Microsoft Confidential Using Guidelines Use guidelines as an approximation More precise results with the ADSizer Use sizer if you know input parameters http://www.microsoft.com/windows2000/do wnloads/deployment/sizer/default.asp Verify design with lab testing Microsoft Confidential Summary Forest design is politically driven Domains are geographically-based Delegate DNS to Active Directory Use Account OUs and Resource OUs Site topology reflects network topology Capacity planning: scale up before out Microsoft Confidential Best Practices For Active Directory™ Deployment Microsoft Confidential Active Directory Deployment Phases Microsoft Confidential Best Practices For Building Domain Controllers - Installation Install server as member server Install Terminal Service Install Service Pack 2 plus additional hot-fixes Install DNS with operating system Always use fixed IP addresses Install Support Tools and Resource Kit Tools Install monitoring solution Microsoft Confidential Best Practices For Building Domain Controllers - Promotion Move machine to it’s final location Promote DC Run quality assurance tools Check event log Dcdiag Netdiag Repadmin Consider DC pre-staging if large number of domain controllers has to be build More information in “Branch Office Deployment” session Microsoft Confidential DNS Integration DNS client (resolver) On forest root domain controller: preferred and alternate DNS server points to a different computer (should be in the same site or close site) On non-forest root domain controller: preferred DNS server should be local computer DNS server Create delegation entry for new domain controller Delegation entry consists of two parts, NS record and A record In <forest-root> DNS zone for regional domains For domain controllers in the forest root domain DNS for Active Directory owner in the forest root domain will do this for you If DNS already exists, contact DNS owner to create delegation entry in parent DNS domain Do this for every forest root DC If no DNS already exists, dcpromo will automatically create DNS root domain Zones will be configured after Active Directory is installed on the domain controller / DNS server For zone configuration, see “Best Practices for Active Directory Design” Microsoft Confidential Installing The Root Domain Root domain is a special domain Houses schema and configuration Center of Kerberos referrals DNS zone in root domain holds forest wide resource records Replication GCs Considerations Operations master and capacity planning Securing the root domain Domain controller placement Microsoft Confidential Excursion Backup and Operations Masters Backup / restore recommendations Operations masters Special considerations for restoring operations masters Microsoft Confidential Domain Controller Backup Backup sufficient number of domain controllers Minimum: 2 domain controllers per domain Ideally: all domain controllers Reality: trade-off of cost vs. easy restore All DCs on a rotating schedule is good compromise At least one per site Branch Offices: cost of replication might be higher than cost for restore Microsoft Confidential Domain Controller Restore Best Practices to bring DC online again NEVER restore a DC on a private network, if this DC is the only DC on the private network Best practice Move DC to private network Restore DC (do not reboot) Move second DC to same private network Second DC should be direct replication partner Make sure that this DC is up-to-date Reboot restored DC Replicate between DCs (force if necessary) Move both DCs to production network again If DC is restored on production network, force replication immediately after restore Especially if restored DC is only online DC in a site Use site-services snap-in (or any other tool) to enforce replication Verify that replication has succeeded Microsoft Confidential Forest Operations Master Schema master Used for schema extensions (Exchange 2000, application schema extensions) Domain Naming Master Needed when new domain is added to forest Microsoft Confidential Domain Operations Master PDC operations master Used for replication to downlevel domain controllers Used by downlevel clients for write operations in the directory Used for password forwarding when users change passwords All client operating systems versions, not for clients Preferred server for group policy changes Changes for Domain DFS Subnet master browser Time service RID pool owner User password changes, workstation password changes Assigns RID pools to all other domain controllers Needed for bulk security principal additions Must be online for Intra-forest migrations Infrastructure master Updates references to objects that moved between domains Microsoft Confidential Operations Masters Dependencies Forest wide operations master roles Schema master: low performance impact Domain naming master: low performance impact, must be GC Domain wide operations master roles PDC operations master: low performance impact (root domain only) RID pool operations master: low performance impact Infrastructure master: low performance impact, must not be a GC Microsoft Confidential Best Practices For Operations Masters First DC in forest root domain is a GC and has all operation master roles by default Leave GC service and forest wide operation master roles on first DC Do not add GC service to second DC in forest root domain and move all domain wide operations master roles to second DC Monitor these two DCs very closely For each operations master Have “stand-by” operations master in same site Create manual connection object between operations master and stand-by Forest root domain Forest operations master can be stand-by for domain operations master and vice versa Microsoft Confidential Operations Master Offline Scenarios If you don’t need the operations master online, do nothing Having the Schema, Domain Naming master and Infrastructure master off-line for a short time does not affect the DS RID pool owner should be brought back within hours, but bulk-operations (migrations) might need it earlier PDC emulator must be online If operations master down-time is planned and either very long, or master is needed, transfer operations master role If operations master down-time is unplanned and master is needed, seize operations master role to stand-by operations master Microsoft Confidential How to Bring Operations Master Back Online This is mandatory in the following cases Restore of the operations master Bringing the operations master back after role was seized If you cannot follow these instructions, do not bring operations master online again Checklist Move old operations master to private network Restore old operations master if necessary (do not reboot) Move stand-by operations master (which now has the roles) to private network Reboot restored DC (=old operations master) Replicate between DCs (force if necessary) Make sure that this DC is up-to-date This will update the operations master with live data (RID pool) Transfer all operations master roles to original operations master again Move both DCs to production network again Microsoft Confidential Securing The Root Domain At least two domain controllers Back-up of both DCs Best in different locations One can have corrupted data, which could end up on a back-up tape Corrupted data never replicates out Domain controller availability Depends on deployment Root DCs are used for Kerberos referrals, make sure that some root DCs are always online If _msdcs.<forest-root> is not delegated, make sure that enough root DCs are on-line for DNS name resolution of forest wide resource entries For forest operations, the operations master must be on-line. No frequent operation Microsoft Confidential Root Domain – Best Practices On the first root DC On second root DC Promote DC, let dcpromo configure DNS Manually create _msdcs.<forest-root> DNS domain Restart Netlogon service to re-register entries Add DNS delegation entries Get monitoring and back-up in place Promote DC Transfer all domain wide operations master roles Get monitoring and back-up in place Do not add GC service On all additional root DCs Promote DC Get monitoring in place Do not add GC service Reduces number of replication connections to DCs in other domains Deploy forest root DCs to all hubs Configure DNS clients to point to other DCs as preferred and alternate DNS servers Microsoft Confidential Creating Regional Domains Selecting initial source for directory data Considerations Operations masters Capacity planning for DCs / GCs Should DCs be GCs? Preparing OUs for data owners Creating OU structure Delegating rights Microsoft Confidential Operations Masters In Regional Domains PDC Emulator Provides some CPU intensive operations User password changes are forwarded to PDC Emulator immediately When user types wrong password at logon, request is forwarded to PDC Emulator Replicates to down-level DCs in mixed mode domains Only place where down-level clients can change passwords In domains >50,000 users, machine should be dedicated to role Lower priority in SRV records HKEY_LOCAL_MACHINE\System\CCS\Services\Netlogon\ Parameters LdapSrvPriority: 0 = highest = default setting Set to higher value, like 10 Microsoft Confidential Operations Masters In Regional Domains RID pool owner Distributes RID pools to other DCs Low performance impact Infra-structure master Updates links to objects after domain move operations Low performance impact Must not be a GC Microsoft Confidential Operations Masters – Best Practice Leave all operations master roles on first domain controller Never put GC on this domain controller Monitor closely Microsoft Confidential Should DCs Be GCs? Domain controller placement and Global Catalog placement are part of AD design Consider additional GCs DCs that are most likely inter-site replication sources (minimizes number of connection objects) Microsoft Confidential Creating New Regional Domain Create DNS delegation from root domain Install first domain controller Configure client to point to itself as primary DNS server and any other DNS server as alternate DNS server Install additional domain controllers Microsoft Confidential Domain Upgrade Order of Upgrade Start with all NT 4.0 environment Upgrade domain controllers first Workstation and server deployment independent from Active Directory deployment No worries Upgrade NT4 clients to W2K first W2K clients in NT 4 domain only authenticated by PDC SP2 Q272348 Upgrade clients in mixed mode mixed version domain Special care must be taken (piling on scenario) Considerations RAS servers first LMRepl export server last Microsoft Confidential Upgrade Considerations Stages of Upgrade Upgrade MUD MUD MUD PDC and none of BDCs upgraded PDC and BDCs upgraded, switch to native mode not made MUD PDC and BDCs upgraded, switch to native mode made Migration Pre-migration Environment Windows 2000 Native Mode Microsoft Confidential Upgrade Considerations Stages of Upgrade - PDC First Now in mixed-mode Objects copied from SAM to AD Windows 2000 DC PDC Emulator Still replicates to Windows NT BDCs Windows NT BDCs can still be added Fallback: If all Windows 2000 DCs offline, one Windows NT 4 BDC can be promoted to PDC – domain is now Windows NT 4 domain again No effect on SIDs If PDC cannot be upgraded (hardware) Install new BDC Promote BDC to PDC Upgrade Microsoft Confidential PDC Overload Scenarios Different components put load on PDC role master Domain DFS and NT4 SP6 clients PDC registration in WINS Sort order of domain 1C entries returned by WINS Some object picker versions go to PDC only Pass-through authentication to PDC Win2000 clients only authenticated by PDC in NT4 domain Kerberos logon goes to Windows 2000 DCs only In small domains, this is not an issue Microsoft Confidential Upgrade Considerations Stages of Upgrade - BDCs Next Moving or demoting BDCs new in Windows 2000 Upgrade to Windows 2000 If resource domain should remain Windows NT 4 domain, but BDCs have to be moved Take BDC offline Promote to PDC Upgrade Demote to standalone / member server Move to new domain Microsoft Confidential Best Practice Recommendations Monitor your Active Directory Replication and replication latency Important domain controllers Performance Replication sources in data centers (hub sites) PDC and RID pool operations master Poor performance is an indicator that something is wrong Avoid panic trouble-shooting Increasing replication schedule to troubleshoot issues Deleting objects in the DS in the hope that they get somehow re-generated (Windows NT 4 practice) Microsoft Confidential Best Practice Recommendations Test, test, test Not only the product, test your procedures Use scripts for common tasks and to document operations (delegation) Spending time and money on testing pays off during the deployment and the operation of AD Do not under-engineer hardware Plan for future growth If machines become increasingly under stress, operations might fail and retries might add to more stress Microsoft Confidential For More Information Best Practices Online Best Practice Active Directory Deployment for Network Operating System Environments http://www.microsoft.com/windows2000/ technologies/directory/default.asp Look in the Planning & Deployment section Microsoft Confidential Microsoft Confidential © 2002 Microsoft Corporation. All rights reserved.