• upgrading a PDC to Windows 2000 has no immediate effect. Windows NT local groups become Windows 2000 local groups, and Windows NT global groups become Windows 2000 global groups.
• when switching the domain to native mode, local groups on the PDC become domain local groups

Domain Tree Modeling & Migration

• migration involves upgrade, while restructure is a complete structure redesign
• domain upgrade is the process of upgrading the PDC and the BDCs in a Windows NT domain from Windows NT Server to Windows 2000 Server. This is the easiest and lowest risk migration route as it retains most of your system settings, preferences, and program installations
• you do not have to upgrade all servers in a domain to take advantage of Windows 2000 features, as mixed mode allows W2K and non W2k platforms to run in the same network
• when planning an upgrade, you need to determine which upgrade paths are supported, examine the existing domain structure, develop a recovery plan, determine the order for upgrading domains and domain controllers, and finally, if you should switch to native mode
• possible upgrade paths for your existing OS:

• domain migration phases:

• design the forest
• migrate Windows NT domains to Windows 2000 native domains
• plan the domain restructuring

• migration-related goals are not driven by technical features of Windows 2000 Server, but are concerned with the migration process itself
• your migration goal determines what path you should take. In most cases, business-related goals such as greater scalability and administration flexibility drive the initial migration decision
• factors to consider before migration:

• application compatibility with W2K platforms
• interoperability with Windows legacy systems and non-Microsoft operating systems
• disk space requirements for Active Directory Objects. For example, User object consumes 3.6K bytes each, Organizational unit (OU) object consumes 1.1K, Public key certificate consumes 1.7K...etc
• physical security of PDC and BDC is very important
• security of BDC is often ignored. If you cannot upgrade the security of your BDC appropriately, demote the BDC to a member server during upgrade, or reconsider the proposed domain structure

• you must complete the design of the forest before planning the upgrade

• for remote sites under the same domain, replication takes place across slow WAN links, which is costly and resource intensive
• for remote sites under different domains, there is no replication traffic except for the tree metadata, which is replicated to all DSAs regardless of their domain membership. Result: fast, but prevents users from easily querying objects that belong to other domains
• for remote sites with all domain controllers of all domains being placed in every site location, client queries are always fast local operations, and administration has great flexibility as well, at the expense of high set up cost and high replication traffic across all sites
• for one domain per site plus global catalog servers, if a new object is created in one site, a partial replica of the object is transferred to all sites. If clients search for specific data, they can query the entire directory to locate the fully qualified name. If a client application requires properties of an object that is not included in the global catalog's database, fully qualified name can be used to learn the object's domain name and contact a domain controller in that domain. This setup is effective for reducing network traffic, and is ideal when all objects need to be accessible to all clients in all domains

• simplified administration
• easier to design
• organizational units' features--such as delegation of administration rights-- reduces the number of domains without sacrificing administrative flexibility
• fewer domains and a greater use of Ous

• distributed and scalable management architecture
• likely to transform their Windows NT 4.0 resource domains into full-featured domains and move user accounts from the former master domains to the domains where they really belong
• has more domains in the forest that enable local control

• when migrated, usually results in a single domain in the Active Directory. delegation of administrative rights through the use of OU hierarchy

• migration typically happens in a top-down manner
• master domain is the first domain to be migrated and the resource domains are migrated later
• centralized approach: migrate from several domains to a single domain and dissolve resource domains into OUs
• decentralized approach: retain the resource domains and move the user accounts to domains where they really belong

• single domain tree approach:

   

  • individual business units implemented as different domains on the next lower level of the tree
  • root domain offers global resources that need to be available for everyone

   

• multiple domain trees approach:

   

  • one domain tree for each master domain and its resource domains
  • domain trees are joined into one forest
  • business units implement their own subtrees using their own structure and security policy
  • all administration happens on the tree level
  • suitable for companies that treat business units independently

• either build one domain tree and dissolve all domains into Ous, or fully retain the decentralized structure and build a forest that consists of several trees
• the most extreme model is to migrate to separate forests, with 4.0-style trust relationships being established between selected domains to allow users from other domains some access to some domains in another forest

• within a domain, upgrade the PDC first. You can upgrade servers and clients at any time
• if you use LAN Manager Replication Service in the domain with the PDC hosting the export directory, change the export directory host before upgrading the PDC
• within groups of domains, it is better to upgrade your account domains prior to upgrading the resource domains
• to fully utilize W2K functions such as better directory scalability, universal and domain local groups, and group nesting, switch the domain to native mode once all of the domain controllers have been upgraded
• Routing and Remote Access RRAS Server:

• RRAS service runs as LocalSystem with NULL credentials
• by default, Active Directory does not accept querying of object attributes through NULL sessions
• in a mixed environment, a Windows NT RRAS server is able to retrieve user RRAS properties only if:

   

  • the domain is in mixed mode and the Windows NT RRAS server is also a BDC, so that RRAS has local access to the SAM
  • the domain is in mixed mode and the Windows NT RRAS server contacts a Windows NT BDC, which results in behavior identical to current Windows NT behavior
  • the domain is in mixed or native mode and Active Directory security has been relaxed to grant the built-in user "Everyone" permissions to read any property on any user object. This is not suggested due to potential conflicts with your security requirements
  • recommended practice: upgrade RRAS server early in the process of upgrading member servers

• a recovery plan is needed to prevent accidental data loss during upgrade. You should have this plan ready before performing the upgrade
• suggested practices:

• add a BDC to any Windows NT domain that contains only a single domain controller. If the PDC fails, you still have a backup
• fully synchronize all BDCs with the PDC, and take one BDC offline before you upgrade the PDC and the other BDCs to Windows 2000 Server.
• backup services such as file and print services or Dynamic Host Configuration Protocol (DHCP) to tape and make sure the backup tapes are working
• track all changes to the domain such as new accounts and password updates. If things go wrong with the Windows 2000 domain controllers, it will be necessary to roll back based on the tracked information. In any case, re-created accounts have a different security identifier (SID) which may prevent some users from accessing certain resources

• the obvious benefit of mixed mode is that it allows new BDCs to be added to the domain if a problem arises, thus providing opportunity for fallback. After the new BDC has joined the domain, you can resynchronize the account database. As long as there are no other Windows 2000 domains, you are able to promote the BDC to a PDC

Security Identifiers

• contain parts that identify the revision number, the authority that assigned the SID, the domain, and a variable number of sub-authority or Relative Identifier (RID) values that identify the security principal relative to the issuing authority uniquely
• security principals cannot be moved between domains without their SIDs changing if, during upgrade, SIDs identifying the security principals remain unchanged. i.e. resource access is unaffected by upgrade

Access Tokens

• form of user ID used by the system to determine whether the user needs to be granted access to system resources
• every process the user creates carries the user access token

Security Descriptor

• attached to resources such as files or printers
• contains access control list (ACL)
• system performs access check verification by comparing the SIDs in user’s access token against the SIDs in the ACL

1. Migrate the Master Domain

• migrate the master domain to Windows 2000
• install Active Directory on a PDC
• trust relationships to the resource domains remain unchanged at this stage

2. Create Organizational Units

• create the organization before moving resources
• use OUs to create a hierarchical namespace, and to create users and groups
• downlevel clients aren't aware of the existence of the organizational units yet
• resource domains do not notice any changes in the master domain yet

3. Migrate PDCs in the Resource Domains

• upgrade the PDCs in the second-tier domains to Windows 2000 and the Active Directory
• this step is mandatory if you plan to move either servers or security principals from the second-tier domains to the master domain
• Active Directory provides SID tracking mechanism which allows the right domain controller to be found even when the SID has been changed

4. Move Servers to the Master Domain

• the administration user interface provides a drag-and-drop tool that makes it very easy to move resources from the resource domains to organizational units in the master domain
• clients who use UNC names to connect to servers will continue to function correctly as UNC names are not aware of the domain membership of a server. Administrator can use both NetBIOS and Active Directory publishing to advertise the existence of a resource
• if downlevel clients still exist without the new directory access client software, NetBIOS advertisement should be used in addition to publishing the resources in the Active Directory
• this is not the right time to remove PDCs from second-tier domains yet

5. Check Access Control Lists

• you need the information about the organization of access rights on shared resources in order to migrate smoothly
• you do not need to make changes to the ACLs if:

• global groups from the master domain were used
• local groups on member servers were used

• you need to make changes to the ACLs if:

• local domain groups in the resource domains were used, and the domain controllers are eventually disappearing. In this case, you will need to move the local domain groups to the master domain

6. Move Workstations to the Master Domain

• for Windows 95 and Windows 98-based workstations, change the workgroup name in the network configuration section and install a service pack
• for Windows NT Workstation, remove from the old domain and add to the new domain. Windows NT 4.0 workstations must be upgraded to Windows 2000; if you use an automated setup script for the update, the domain change can be performed automatically

7. Turn off PDCs in Second-Tier Domains

• eliminate the second-tier domains by turning off all domain controllers in the second-tier domains, or move the domain controllers to the master domain

Mixed Mode

• a domain is in mixed mode if the PDC has been upgraded but not all BDCs have been upgraded, or the PDC and all BDCs have all been upgraded but the native mode switch has not been enabled

Native mode

• the final operational state of a Windows 2000 domain
• offers the full range of Windows 2000 features
• enabled by first upgrading all domain controllers to Windows 2000, and then setting a switch on the user interface
• during the switch to native mode, the following occurs:

   

  • Netlogon synchronization is off, and you can not add BDCs into the domain
  • domain uses only Active Directory multiple-master replication between domain controllers, thus the former PDC is no longer the master of the domain, and all domain controllers can now perform directory updates (although Windows 2000 still designates the role of PDC emulator to the former PDC, which means that (in native mode) password changes are replicated to the former PDC preferentially by other domain controllers )

   

• PDC Emulator - all pre-Windows 2000 clients use the PDC emulator to locate the PDC and perform password changes. Also, Windows NT resource domains use the PDC location information to establish trusts
• the switch to Native mode cannot be undone

Domain Restructure

• restructure is a complete structure redesign
• may provide Greater Scalability
• may allow further Delegation of Administration
• may provide Finer Granularity of Administration

• upgrade first and restructure later if you can solve your migration requirements by doing a two-phase migration (migrate and then restructure)
• restructure first if you want to redesign your directory services infrastructure to take advantage of the enhanced capabilities of Active Directory. This will impact your production environment, however
• recommended practice – restructure after upgrade, but before using features such as application deployment or the new group policy

ClonePrincipal

• allows incremental migration of users to a Windows 2000 environment without impacting your existing Windows NT production environment by creating clones of the Windows NT users and groups in the Windows 2000 environment
• consists of the COM object DSUtils.ClonePrincipal that supports three methods:

• AddSidHistory - copies the SID of a source principal to the SIDhistory of an existing destination principal. It requires you to provide Domain Administrator credentials in the source and destination domains. Its events can be audited to ensure that both source and destination domain administrators can detect when this function has been run. Note that ClonePrincipal sample scripts call the underlying AddSidHistory method; therefore the other ClonePrincipal utilities are subject to the same security sensitivity and constraints as AddSidHistory
• CopyDownlevelUserProperties - copies the Windows NT properties of the source principal to the destination principal
• Connect - establishes authenticated connections to the source and destination domain controllers

Netdom

• allows you to manage Windows 2000 domains and trust relationships from the command line to join a Windows 2000 computer to a Windows NT or Windows 2000 domain, with options to specify the OU for the computer account; generate a random computer password for the initial join; manage computer accounts for domain member clients and member servers; specify the OU for the computer account; and move existing computer account for a member client from one domain to another, while maintaining the security descriptor on the computer account
• in addition, you can establish and manipulate trust relationships between domains

• migrate users incrementally to a pristine Windows 2000 environment without impacting the Windows NT production environment, thus protecting the current production environment from migration changes and allowing you to revert back to the old production environment if the need arises
• to decommission the old account domain and reassign the domain controllers, you perform the following steps:

• create the pristine Windows 2000 forest that reflects the requirements and structure identified in the namespace planning activities of the organization. Domains in the new forest will be native mode Windows 2000 domains
• use Netdom to query what trusts currently exist from any resource domains to the Windows NT source domain, compare the output from Netdom with the list of trusts that are required to allow resource access to users and groups in the target domain, and finally use Netdom to establish any trusts that do not already exist in order to maintain resource access
• clone all source global groups in the target domain using ClonePrincipal
• identify and clone sets of users
• decommission the source domain after all users and groups have been moved permanently to the destination forest by powering off the source domain BDCs, and then the source domain PDC. However, store the PDC for disaster recovery purposes

• consolidate a resource domain into an OU within a native mode Windows 2000 domain to reduce the costs of administering complex trusts:

• establish any trusts required from the target domain to account domains outside the forest using Netdom
• clone all shared local groups using ClonePrincipal
• demote application servers to member servers after you have cloned all of the shared local groups
• upgrade the PDC of the resource domain to Windows 2000 and run the domain in mixed mode during the transition period, then upgrade each BDC to be demoted using Active Directory Installation Wizard
• move member servers (including former BDCs) and clients
• decommission the source domain after you have permanently moved all groups and computers to the destination forest by powering off and removing the source domain BDCs, and then the source domain PDC