Chapter 2: Domain Upgrade

Section 1:
Migration Concepts

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

On This Page

Introduction
Implications of Domain Upgrade

Introduction

Upgrading to Microsoft Windows 2000 Server is the easiest, least-risky migration route from Microsoft Windows NT 4.0 to Windows 2000 and Active Directory because it retains most of the system settings, preferences, and program installations.

Domain upgrade is the process of upgrading the software on the primary domain controller (PDC) of a domain, and upgrading some or all of the backup domain controllers (BDCs), from Windows NT to Windows 2000 Server.

Because Windows 2000 is designed to support mixed networks containing Windows 9x, Windows NT, and Windows 2000 with full interoperability, you do not need to upgrade all systems in the domain to take advantage of the features in Windows 2000. Even so, you should consider an upgrade of the PDC as only the first stage of the upgrade because you can obtain further incremental benefits by subsequently upgrading BDCs and then member servers.

Because this is an upgrade of an operating system rather than a fresh installation, it maintains the existing domain structure, users, or groups. In fact, the biggest distinction between an upgrade and a restructure is that upgrading maintains the existing domain structure. In the process, however, the upgrade will enable new Windows 2000 features.

After you complete the upgrade and have access to advanced Windows 2000 management tools and features, you might want to restructure the domains. Be aware that restructuring is not a trivial task and will require additional planning and implementation. (This is discussed in later chapters on restructuring.)

If structural change is one of your main goals for migration, you might consider restructuring during the migration.

Implications of Domain Upgrade

An upgrade is the easiest, least-risky migration. This section looks at the actual effects of the upgrade on domain controllers and security principals, and explains the importance of these in making your planning decisions.

The Active Directory Installation Wizard (dcpromo.exe)

It is good practice to sync all BDCs with the PDC before starting the upgrade.

After the installation of the core operating system on the PDC, the setup program detects the upgrade of a domain controller and prompts the administrator to install Active Directory on the server by automatically running the Active Directory Installation Wizard.

The Active Directory Installation Wizard gives the administrator the option of creating the first tree in a new forest, creating a new tree in an existing forest, creating a replica of an existing domain, or installing a child domain. The choice you make will depend on the outcome of the namespace planning process.

Note: This is not intended as a detailed description of the process. You also will need to consider activities such as backing up the domain in case you encounter serious problems and need to fall back. You might choose to add an additional BDC to the domain prior to the synchronization and upgrade, and then to take this BDC offline for the duration of the upgrade. See section 2 of the cookbook for a detailed walkthrough of a domain upgrade.

Windows NT PDC

The Active Directory installation process copies the contents of the Windows NT account database and the Security Accounts Manager (SAM) into Active Directory. These objects are the security principals (user accounts, local and global groups, and computer accounts).

As soon as the process upgrades the PDC and installs Active Directory, the domain is running in Windows 2000 mixed mode. (For a fuller description, see the section "Mixed Mode and Native Mode" below.) The former PDC now holds the role of the PDC operations master in the Active Directory domain.

From this point on, the Windows 2000 Server PDC operations master uses Active Directory to store objects. It is fully backward compatible because it exposes the data as a flat store to Windows NT BDCs during replication. This manifests itself in a number of ways:

  • The PDC operations master appears as a Windows 2000 domain controller to other computers running Windows 2000 and as a Windows NT PDC to computers that are not yet upgraded.

  • You can still use the PDC operations master to create new security principals and to replicate these changes to the Windows NT Server BDCs.

  • Windows NT and Windows 9x workstations can use the PDC operations master as a possible logon server.

  • If the Windows 2000 Server PDC operations master goes offline or otherwise becomes unavailable and no other Windows 2000 domain controllers exist in the domain, then you can promote a Windows NT BDC to PDC.

The Effect of Upgrade on Trusts

Bb727126.ckch0201(en-us,TechNet.10).gif

Figure 2.1: The HAYBUV.TLD domain example

In Windows NT, scaling security beyond one domain is done via the mechanism of trust. Interdomain trusts allow domains to authenticate users on behalf of domains that trust them. Prior to the availability of Windows 2000, trusts were explicit and one wayif Domain A trusts Domain B, which in turn trusts Domain C, there is no trust from Domain B to Domain A, or between Domain A and Domain C unless explicitly created.

Active Directory Installation Wizard installs the Kerberos software. Once this process is complete, it starts the authentication service and the ticket-granting service. If the administrator opted to join an existing tree, this establishes a two-way transitive Kerberos trust relationship to the parent domain. Any trust relationships created before the PDC upgrade will still exist, but these will take the form of explicit, one-way Windows NTstyle trusts.

Eventually, the domain controller from the parent domain copies all schema and configuration information to the new child domain. Once this information has been replicated, the upgraded domain is a fully functional member of the Active Directory domain tree, although it remains in mixed mode until the administrator decides to switch the domain into Windows 2000 native mode.

Active Directory-aware clients such as workstations running Windows 2000 Professional or Windows 9x (running Active Directory client software) can now make use of Active Directory and perform actions such as querying global catalogs to locate resources and people. Clients also will be able to use the transitive trust relationships that exist within the forest to access resources throughout that forest. The way they achieve this will depend on whether the client is running Windows 2000 or earlier operating systems such as Windows NT or Windows 9x, and the upgrade state of the target domain.

Resources will be accessible across the forest via transitive trusts where the resources reside in any of the following:

  • Native mode domains

  • Mixed mode domains where all of the domain controllers have been upgraded

  • Mixed mode domains where the domain controller servicing the Kerberos or Windows NT LAN Manager (NTLM) authentication request has been upgraded

In all other cases, clients will have access only to those resources that are available through existing Windows NTstyle, one-way explicit trusts, which remain unchanged as a result of the upgrade.

Figure 2.1 (above) illustrates how NTLM and Kerberos authentication work.

Using NTLM Authentication

Imagine a user logging on to the domain haybuv-acct.haybuv.tld, which is a mixed mode domain, from the Windows NT Workstation ntws, which is in the same domain. The user then tries to make a network connection to a Windows NT Server computer, nts, in the domain haybuv-other.haybuv.tld, which is a native mode Windows 2000 domain. Because ntws is a Windows NT client, it will use the NTLM protocol.

Nts will receive credentials that specify the domain name haybuv-acct.haybuv.tld, and will determine that the domain name does not refer to its own account database. Then it will send the logon request to a domain controller in its own domain for authentication.

The domain controller checks the domain name, and because it doesn't match, the domain controller checks to see whether the domain is a trusted one. The domains haybuv-acct.haybuv.tld and haybuv-other.haybuv.tld are both children of the same root haybuv.tldso transitive trust exists between the two domains, and the domain controller passes the logon request through to a domain controller in the trusted domain.

That domain controller authenticates the username and password against its domain account database, and assuming the credentials match, passes the account-identification information back to the domain controller that contacted it, which in turn sends it back to the server.

Next, the server creates an impersonation token for the user, containing the user's security identifier (SID) and the SIDs of any domain groups the user is a member of. It then creates an impersonation thread in the user's security context, bearing the impersonation token, and attempts to access the resource on the user's behalf.

From this you can see that an earlier version client in a mixed mode domain can access an earlier version server in another domain in the tree using NTLM, as long as the domain controller in the target domain is running Windows 2000 and thus understands transitive trusts. Because all trees in the same forest are linked by transitive trusts, the same would be true even if the two domains were in different trees.

By extension, it follows that if you are trying to access a resource on the Windows NT Server computer nts in the mixed mode domain haybuv-res1.haybuv-other.haybuv.tld, the resource would be accessible via transitive trust across the forest as long as Windows 2000 is running on the domain controller to which the server passed the logon request.

Using Kerberos Authentication

Now imagine a user logging on to the domain haybuv-acct.haybuv.tld as before, but this time from the computer w2kpro in the same domain, which is running Windows 2000. The user wants to make a network connection to a Windows 2000 Server computer, w2ksrv, in the haybuv-other.haybuv.tld domain. Because w2kpro is a Windows 2000 client, it will attempt to use the Kerberos protocol.

Kerberos is a ticket-based protocol, where users are issued ticket granting tickets (TGTs) by the ticket-granting service on the Key Distribution Center (KDC) running on the Windows 2000 domain controller, at initial logon to the domain.

TGTs contain authentication information about the user encrypted with the domain master key, which then can be presented back to the domain controller as part of requests for additional session tickets to connect to other servers in the domain. Once the user has been granted a TGT, subsequent checks are quick and efficient, since the domain controller merely needs to decrypt the TGT to check the user's credentials. Session tickets are similar to TGTs, but are encrypted using a key shared between the server and the domain controller.

The Kerberos protocol, like NTLM, can operate across domain boundaries. A client in one domain can authenticate to a server in another if the two domains have established a trust relationship. When domains establish trust, they exchange interdomain keys. Each domain's authentication service uses its interdomain key to encrypt tickets to the other domain's ticket-granting service.

When a client wants access to a server in a remote domain, it asks the domain controller in its home domain for a referral ticket, a TGT that it can present to the ticket-granting service at the remote domain's domain controller. The local domain controller replies by sending the client a TGT encrypted with the remote domain controller's interdomain key.

The client presents the referral TGT to the remote domain controller's ticket-granting service, asking for a ticket to a server in its domain. The remote domain controller decrypts the client's TGT with its interdomain key. If decryption is successful, the remote domain controller can be certain that a trusted authority issued the TGT, and so it grants the client a ticket to the requested server.

In Figure 2.1, because haybuv-acct.haybuv.tld and haybuv-other.haybuv.tld are children of the same root, and transitive trust exists between the two domains, a trust path can be built between the domains. On receiving the referral TGT, the domain controller in the target domain will check to see if it has a shared key for the server in question, and if it does it will issue a session ticket to the client. Because the computer w2ksrv runs Windows 2000, a shared key will exist, so a ticket can be issued to w2kpro.

The important factors in this scenario are the existence of a domain controller in the target domain running the Kerberos ticket-granting service, and the existence of a shared key between the domain controller and the server. The Active Directory installation process installs the Kerberos service on Windows 2000 domain controllers, and adding a member server to a Windows 2000 domain involves the creation of a shared key. From this it follows that w2kpro would be able to access w2ksrv.haybuv-res1.haybuv-other.haybuv.tld using the Kerberos protocol as long as a Windows 2000 domain controller is available to issue the session ticket.

If w2kpro was attempting to access a resource on a computer running Windows NT such as nts.haybuv-res1.haybuv-other.haybuv.tld, Kerberos authentication would fail and the client would fall back to attempting NTLM authentication as described in the previous section.

Switching to Native Mode

The previous discussion shows that in some circumstances trust paths might be unpredictable where mixed mode domains are involved. Switching your domains to native mode removes this unpredictability.

Upgrade and Resource Domains

A resource domain is a special type of domain created to hold the accounts of resources such as servers and workstations. Resource domains were created in Windows NT typically to address two main situations:

  • SAM size limitation. In Windows NT, the maximum size recommended for the SAM account database is 40 megabytes (MBs). In an organization with many deployed workstations and servers and many security groups, this might equate to much less than the sometimes-quoted figure of 40,000 accounts. In order to scale an organization beyond this number, you should store user and machine accounts in separate domains, termed an account or master domain for the user account and a resource domain for the machine account.

    Resource domains normally would be created as second-tier domains, with one-way trustsa trusting relationshipto either a single account domain (this topology is called the master domain model), or a number of account domains (the multimaster domain model).

  • Local administrative capability. In a decentralized organization with geographically disparate facilities, it is often desirable to authorize local personnel to administer resources. In order to devolve this kind of responsibility in Windows NT, you can create resource domains with their own administrative structure. As in the above case, this would result in master or multimaster domain structures with one-way trusts to the account domains in the organization.

    The one-way nature of these trusts ensures that the resource domain administrators, by default, only have administrative scope over the resource domain.

When considering the effects of an upgrade on a resource domain, try to ascertain which of the previous two rationales was foremost in the designer's mind when the domain structure was determined. If the designer created the domain to address the latter situation, you will want to consider the implications of upgrading a resource domain on your administrative model because simply upgrading the resource domain and joining a forest will result in the creation of a two-way transitive trust between the child resource domain and the parent domain.

If the local administrators are less skilled, or you do not intend to grant them wider administrative rights in the Windows 2000 forest, you will want to consider the following options:

  • Upgrading the domain within the forest and using Windows 2000 delegation features. Check the administrative groups in the resource domain and remove those who are not administrators in the master domains. If you have only local resource domain administrators, add one or more of your master domain administrators. They will be able to administer the domain while it is being upgraded. As a further precaution you should ensure that the resource domain administrators do not have administrative access to the domain controllers through local computer accounts.

    Once you upgrade the PDC, you could organize the resources you want to administer locally into organizational units (OUs), and delegate administration of the OU to your former local administrators.

  • Upgrading the domain in a new forest. You could choose to upgrade your resource domain as a new tree in a new forest and maintain the link to the account domain by way of the preexisting explicit trust to the account domain, which like a Windows NT explicit trust is unidirectional and not transitive. This would effectively mirror the preupgrade structure.

    In general, you will want to minimize the number of forests you create, so you should consider this option only as a temporary measure, prior to a restructure, or as a last resort.

  • Restructuring into OUs. Another alternative might be to rethink your domain structure and consider merging your resource domains into the upgraded master domain as OUs at a later time. This would obviously influence your thinking on the order of domain upgrade.

Upgrade and Administration

Once you upgrade the PDC to Windows 2000 Server and install Active Directory, the administrator can start using the new tools that come with Windows 2000 Server to create new objects such as OUs that exist only in Active Directory.

If you create OUs, you can begin organizing your domain by placing objects into them. This structure is visible only to computers with Active Directory client software. Without it, the domain appears unchanged and the PDC still exposes objects as a flat store to earlier version clients.

An administrator working at a client without Active Directory can use only older administration tools.

Mixed Mode and Native Mode

Figure 2.2: Stages of Upgrade

Figure 2.2: Stages of Upgrade

Mixed Mode

From the moment you upgrade the PDC to the time the administrator decides to switch the domain into Windows 2000 native mode, the domain is in mixed mode. Mixed mode provides maximum backwards compatibility with earlier versions of the operating system.

Mixed mode relates only to the authentication infrastructure of a domainin other words, the domain controllers. Even when a domain has only Windows 2000 domain controllers and has been switched to native mode, clients and servers running earlier versions of Windows NT, and clients running Windows 9x, can exist within the domain. This environment is known as a mixed environment.

You can leave the domain operating in mixed mode indefinitely, even if you have upgraded all the BDCs in the domain as well as the PDC.

The table below summarizes the Windows 2000 features available in mixed mode and those available only by switching to native mode. If you are hesitant to switch to native mode, determine whether staying in mixed mode compromises your migration goals and whether there are acceptable trade-offs.

In general, the only reasons to remain in mixed mode are:

  • Inability to upgrade BDCs. In this scenario, you cannot upgrade or demote BDCs to member servers for some reason. This might be because the hardware is limited and certain BDCs are not physically capable of being upgraded or because you have applications that must run on a BDC that will not run on Windows 2000.

  • Inadequate physical security of BDCs. In any discussion of domain planning, security is an important consideration. A fundamental aspect of security is the physical security of the computer itself: Any computer that is physically easy to access is vulnerable to attack. A consideration here could be the difference between single-master updating of the SAM by the PDC alone, and Active Directory multimaster updating of the account database by all domain controllers.

    Because of the single-master nature of Windows NT directory updates, you might be comfortable with comparatively relaxed security on your BDCs. If this is the case, you need to reconsider this when upgrading them to Windows 2000 domain controllers. If you cannot upgrade security of your BDC appropriately, you might consider demoting the BDC to a member server during the upgrade, adding a new Windows 2000 domain controller in a different location, or possibly even reconsidering your proposed domain structure.

  • A need to fall back to Windows NT. One of the features of mixed mode is the degree of backward compatibility. Mixed mode has the benefit of allowing you to add new Windows NT BDCs to the domain if a problem arises. In this situation, once you add the BDC to the domain, you could force a resynchronization of the account database. Then, as long as no Windows 2000 domain controllers are in the domain, you could promote the BDC to PDC. You should plan for fallback or recovery, but at some point you will want to switch over completely to the new environment.

Native Mode

Once you upgrade all domain controllers, you can switch the domain from mixed mode to native mode. Several things happen during the switch:

  • The domain uses only Active Directory multimaster replication between domain controllers, so support for Netlogon replication ceases.

  • Because Netlogon replication is now switched off, you can no longer add new Windows NT BDCs to the domain.

  • Because multimaster replication is enabled, the former PDC is no longer the master of the domain, and all domain controllers can now perform directory updates. One point that sometimes causes confusion is the continued existence of the PDC emulator role. Despite the multimaster nature of Active Directory, Windows 2000 has a number of roles designated as operations masters, and PDC emulator is an operations master role. Usually, the former PDC will continue as PDC emulator operations master holder, which in a native mode environment means that other domain controllers replicate password changes to it preferentially.

  • Windows 2000 group types such as universal and domain local groups, and group nesting, are enabled.

Running Active Directory Installation Wizard does not automatically perform the switch to native mode; the administrator must initiate the change via the administrative interface.

Although you can get a great deal of benefit from upgrading your PDC and BDCs and remaining in mixed mode, you should make the switch to native mode as soon as possible. Here are some of the reasons:

  • Richer security group model. Universal groups, domain local groups, and group nesting are available only in native mode.

  • Predictable trust paths in the forest. In native mode, all domain controllers must be running Windows 2000 and are thus capable of understanding transitive trusts. See "The Effect of Upgrade on Trusts" (above) for more detail.

  • Removal of SAM size restrictions. Because all domain controllers must be running Windows 2000 in a native mode domain, you can safely allow your directory to grow above the size recommendations for Windows NT without the possibility of Windows NT BDCs being added to the domain.

Switching to Native Mode

Changing the domain mode from mixed to native mode is easy to do but impossible to undo, so you need to bear in mind all of the factors discussed above to determine when to make the change. Do not change domain mode if you have or will have any Windows NT domain controllers.

Figure 2.3: Change domain mode dialog

Figure 2.3: Change domain mode dialog

To change the domain mode, do the following:

  1. Open the Active Directory Domains and Trusts snap-in and right-click on the domain you want to administer in the left-hand tree view pane. A context menu will appear.

  2. Choose Properties to show a tabbed dialog box, as shown in Figure 2.3.

  3. On the General tab, click Change Mode.

Features Available in Mixed Mode

Availability of Windows 2000 Features in Mixed Mode

Goal

Feature

Available in mixed mode?

Better manageability

Kerberos transitive trusts

Yes, but see the section "The Effect of Upgrade on Trusts" (above).

 

Active Directory

Yes

 

Active Directory organizational units (OUs)

Yes, but only visible using Windows 2000 administration tools. Cannot be administered from Windows NT BDCs or member servers

 

New Active Directory security groups

No, only global and local groups available

 

Windows installer through group policies

Yes

Greater scalability

64-bit memory architecture

Yes

 

Active Directory scalability

Yes, but only once all BDCs have been upgraded and are running the Active Directory. Be wary of taking advantage of this feature because you still can add new Windows NT BDCs while the domain is in mixed mode. This feature might be an important part of your fallback planning, so you should not compromise it.

 

Kerberos authentication

Yes, for computers running Windows 2000

 

Microsoft Management Console (MMC)

Yes

Improved security

Group policy

Yes, for domain controllers and other computers running Windows 2000 in the domain

 

Security Configuration Manager (SCM)

Yes

Improved availability

Active Directory multimaster replication

Yes, between PDC and BDCs that have been upgraded

Windows 2000 Groups

The previous section mentioned new and richer security group functionality in Windows 2000.

Windows 2000 supports four types of security groups:

  • Local

  • Domain local

  • Global

  • Universal

Local Groups

Local groups have always existed in Windows NT. They can have members from anywhere in the forest, other trusted forests, and trusted earlier version domains. In terms of resource permission, however, they have only computer-wide scope, in that you can only use them to grant permissions on the computer on which they exist.

A special case for local groups in earlier versions of Windows NT is related to the local groups created on a PDC, which by virtue of replication of the domain SAM amongst BDCs, resulted in the PDC and BDCs sharing these groups. In mixed mode, local groups behave in the same way on Windows NT and Windows 2000; in native mode, local groups on a domain controller become domain local groups (described next).

Typically, local groups are used to grant ad-hoc access to resources on a local computer.

Domain Local Groups

Domain local groups are a new feature of Windows 2000, though similar in concept and use to the local groups created on the PDC in a Windows NT domain (described above).

Domain local groups are available only in native mode domains. They can have members from anywhere in the forest, other trusted forests, and even trusted earlier version domains. Domain local groups have only domain-wide scope in terms of resource permission, so you can only use them to grant permissions within the domain in which they exist. They differ from local groups in that you can use them on any computer running Windows NT within the domain in which they were created.

Typically, domain local groups are used to gather security principals from across the forest to control access to resources in the domain.

Global Groups

Windows 2000 global groups are effectively the same as Windows NT global groups. In terms of membership, they have domain-wide scope, but can be granted permissions in any domain, even in other forests and earlier version domains as long as a trust relationship exists.

Universal Groups

Universal groups can contain members from any Windows 2000 domain in the forest, but cannot contain members from outside the forest.

You can grant universal groups permissions in any domain, even in other forests, as long as a trust relationship exists.

Although universal groups can have members from mixed mode domains in the same forest, the universal group will not be added to the access token of these members because universal groups are not available in mixed mode.

You can add users to a universal group, but it is recommended that you restrict universal group membership to global groups.

Universal groups are available only in native mode domains.

Use of Universal Groups

Universal groups have a number of important characteristics. You can use universal groups to build groups that perform a common function within an enterprise. One example might be virtual teams. The membership of such teams in a large company would probably be nationwide or even worldwide, and almost certainly forest-wide, with the team resources being similarly distributed. Universal groups could be used as a container in these circumstances to hold global groups from each subsidiary or department, with a single access control entry (ACE) for the universal group to protect the team resources.

In using universal groups, an important factor to consider is that while global and domain local groups are listed in the global catalog (GC), their members are not, whereas universal groups and their members are listed, a fact that has implications for GC replication traffic. Exercise care in the use of universal groups. As a guide, if your entire network has high-speed connectivity, you can simply use universal groups for all of your groups and benefit from not having to bother with managing global groups and domain local groups. If, however, your network spans wide area networks (WANs), you can improve performance in several ways by using global groups and domain local groups.

If you use global groups and domain local groups, you can also designate any widely used groups that are seldom changed as universal groups.

Universal Groups and Access Tokens

The previous discussion of universal group membership touched on the fact that universal groups can contain members from mixed mode domains, but that such members will not have the universal group's SID in their access token. This is a consequence of the way access tokens are created in Windows 2000.

When a user logs on to a Windows 2000 native mode domain and has been authenticated, the Local Security Authority (LSA) on the domain controller where the user was authenticated retrieves the user's global group memberships. The LSA then passes this information down to the workstation, where it is used to build the user's access token. At the same time, the LSA queries the GC for the user's universal group memberships, which it also passes to the workstation.

If a user is a member of a universal group, the SID of that group is included in the access token on the workstation, and is added to the authorization data in the TGT issued by the KDC.

Universal groups are not added to access tokens at any other timefor example, when impersonation tokens are created at member servers. As a consequence, if the universal group SID is not available when the user logs onfor example, where the user is logging on to a mixed mode domainit will not be added subsequently.

Nesting Groups

It is recommended that you do not create groups with more than 5,000 members. This guideline is based on the fact that updates to the Active Directory store have to be capable of being made in a single transaction. Because group memberships are stored in a single multivalue attribute, a change to the membership would result in the whole attributein other words, the whole membership listhaving to be updated in a single transaction. Microsoft has tested and supports group memberships of up to 5,000 members.

You can get around this limitation by nesting groups to increase the effective number of members. A further consequence is that you also reduce the replication traffic caused by replication of group membership changes.

Your nesting options depend on whether the domain is in native mode or mixed mode. The following list describes what can be contained in a group that exists in a native mode domain. These rules are determined by the scope of the group.

  • Universal groups can contain user accounts, computer accounts, other universal groups, and global groups from any domain.

  • Global groups can contain user accounts from the same domain and other global groups from the same domain.

  • Domain local groups can contain user accounts, universal groups, and global groups from any domain. They also can contain other domain local groups from within the same domain.

This list describes what security groups in a mixed mode domain can contain:

  • Local groups can contain global groups and user accounts from trusted domains.

  • Global groups can contain only user accounts.

Multimaster Replication and Group Administration

Because group memberships are stored in a single attribute, you should exercise special care when adding and removing members where you have a number of users with administrative rights in the domain. The reason for this relates to replication latency and conflict resolution in Active Directory.

If you have two administrators making changes to the same group on different directory replicas at the same time, you could have a situation where, for instance, administrator A makes changes to group A, removing user A and adding user B, while administrator B is making changes to the same group, this time adding user C. The outcome of these simultaneous operations would depend on Active Directory conflict resolution, which takes the last update as authoritative.

To avoid this situation, you should consider delegating administration of specific groups to specific administrators.

Effects of Upgrade on Groups

Upgrading a PDC to Windows 2000 has no immediate effect on groups. Windows NT local groups become Windows 2000 local groups and Windows NT global groups become Windows 2000 global groups. The real change occurs when the domain is switched to native mode, at which point local groups on the PDC become domain local groups.

As stated earlier, when a user has been authenticated, an access token is created for the user containing the user's primary SID, together with the SIDs of any groups the user belong to. Local groups on the PDC are a special case in Windows NT. This is reflected in the way the access token looks when it is created after interactive logon on the workstation of a user who is a member of such a group, or when it is created at a domain controller for the purpose of impersonating that user to grant access to resources. Because the PDC local groups have no scope beyond the domain's PDC and BDCs, the user's access token on the workstation does not contain the SID for that group. When the user attempts to access resources on a domain controller, however, the impersonation token created for the user at the domain controller does contain the SIDs of any of the PDC local groups to which the user belongs.

When the domain is switched to native mode, the SIDs of any domain local groups of which the user is a member are added to the user's access token, even when the user is logging on interactively at a workstation. This is because domain local groups have domain-wide scope.

Groups and Domain Mode

Group type

Membership

Scope

Available in mixed mode?

Local

Members from:
Same forest
Other trusted forests
Trusted earlier version domains

Machinewide

Yes

Global

Members from the local domain

Any trusted domain

Yes

Domain local

Members from:
Same forest
Other trusted forests
Trusted earlier version domains

The local domain

No

Universal

Members from the same forest

Any trusted native mode domain

No

NetBIOS and WINS in Windows 2000

Network basic input/output system (NetBIOS) is a high-level network-programming interface used in Microsoft networking components from the late 1980s onwards. Network resources are identified in the NetBIOS namespace by unique NetBIOS names. Windows Internet Name Service (WINS) is a service supplied as part of Windows NT Server to support registration of dynamic mappings of NetBIOS names to Internet Protocol (IP) addresses, and to provide NetBIOS name resolution.

With the release of Windows 2000, support for the NetBIOS naming interface is no longer required for networking computers. This, along with the tight coupling of the Active Directory and Domain Name System (DNS), will result in a decline in the use of NetBIOS over time. In the meantime, upgrading your domain to Windows 2000 does not dispense with the need for NetBIOS support on your network or affect the degree of support you currently have.

After upgrading, you can discontinue the use of NetBIOS and WINS if the following conditions are met:

  • No clients such as Windows for Workgroups, Windows 9x, or Windows NT 4.0, and no servers running Windows NT 4.0 use NetBIOS. NetBIOS names can still be required on your network to provide basic file and print services and support for many legacy applications used on client computers running under earlier versions of Windows operating systems.

  • You have assessed the impact of earlier applications and services in your testing plan.

  • You have a pure Windows 2000 network and are sure that all computers and applications on your network are able to function using another naming service such as DNS. Network naming is a vital service for locating computers and resources throughout your network, even where NetBIOS names are not required.

  • You only have a single Windows 2000 forest or you do not need trust between multiple forests. Trusts between multiple Windows 2000 forests can only be established as explicit LAN Manager trusts. This type of trust still requires NetBIOS.

The Windows 2000 WINS client caches resolved names locally. It uses a component called the Caching Resolver to look in this cache before submitting a query to DNS. The host file is cached as soon as the client starts and any updates to the host file are reflected in the cache immediately. The name resolution sequence is as follows:

  1. Attempt name resolution from the client cache.

  2. If resolution from the client cache fails, the client attempts name resolution through DNS.

  3. If DNS name resolution fails, the client attempts resolution through WINS.

As a result, assuming that you have implemented sufficient change control over your new clients as you have upgraded them, and once all earlier conditions have been removed, the switch away from NetBIOS and WINS should be seamless.

Availability of LAN Manager Replication Service

Windows NT Server provided a replication facility known as LAN Manager Replication (LMRepl). LMRepl often is used to replicate logon scripts from an exporting domain controller to a number of importing domain controllers in the domain. The File Replication service (FRS) replaces this service in Windows 2000 Server.

Windows 2000 Server does not support LMRepl in mixed or native mode, so if you have been using LMRepl, you will need to include in your upgrade plan a strategy for using FRS to provide the same functionality.

The LMRepl Process

LMRepl uses the concept of import directories and export directories. An administrator can configure LMRepl by selecting a server on which to host an export directory and a number of servers to host import directories. The servers hosting the directories do not need to be domain controllers; they can be ordinary member servers.

Figure 2.4: The LMRepl process

Figure 2.4: The LMRepl process

The FRS Process

FRS in Windows 2000 Server is automatically configured so that every domain controller has a replicated System Volume (SYSVOL). Any change you make to a logon script stored in the SYSVOL of any domain controller is replicated in multimaster fashion to other domain controllers. Unlike LMRepl and the hosting of import and export directories, in FRS only domain controllers can host the SYSVOL.

Figure 2.5: The FRS process

Figure 2.5: The FRS process

Maintaining LMRepl Services in a Mixed Environment

As you now have learned, during an upgrade you can have a mixed environment of Windows NT 4.0 BDCs and servers operating with Windows 2000 domain controllers. Because Windows 2000 Server does not support LMRepl, maintaining LMRepl services in a mixed environment could be an issue. To provide this support, you will need to create a bridge between LMRepl and FRS so both services can operate. You could do this by selecting a Windows 2000 domain controller whose SYSVOL would be used to populate the export directory of the Windows NT BDC hosting LMRepl. A sample script, which you can regularly schedule to perform the necessary file copying, is available from Microsoft.

LMRepl and Upgrade

In order to maintain availability of LMRepl during an upgrade, you should ensure that the server hosting the export directory is upgraded only after all the other servers hosting import directories have been upgraded. If the server hosting the export directory is the PDC, you should select a new export server and reconfigure LMRepl.

Using Remote Access Service in a Mixed Environment

If you are using Remote Access Service (RAS) to provide your users with remote access to the corporate network, you might want to consider upgrading your RAS server early on in the process of upgrading member servers. This is because Windows NT checks RAS properties such as availability of RAS access or dial-back for a user.

RAS is an example of a Windows NT service. A service is a type of background process, designed to run continuously with no user interface, usually fulfilling some kind of server function such as a Web server or a File Transfer Protocol (FTP) server. Because the service must run even when no users are logged on to the system, it runs in the security context of a special service account, usually the system account, also known as LocalSystem.

The system account is a special account known only to the local machine, and is granted all privileges available on the operating system. When a service logs on as LocalSystem, it logs on with NULL credentials. In other words, it does not provide a username or password. This means that this account cannot be used to access network resources relying on NTLM authentication unless the remote machine allows access with NULL credentials (often referred to as a NULL session). In Windows NT, RAS uses the LocalSystem account.

By default, Active Directory will not accept querying of object attributes via NULL sessions, so in a mixed environment a Windows NT RAS server will not be able to retrieve a user's RAS properties unless the following conditions are met:

  • The domain is in mixed mode and the Windows NT RAS server is also a BDC. In this case, RAS will have local access to the SAM.

  • The domain is in mixed mode and the Windows NT RAS server contacts a Windows NT BDC, which would result in behavior identical to current Windows NT behavior. This might lead to some inconsistencies.

  • The domain is in mixed mode or native mode and the Active Directory security has been loosened to grant the built-in personality Everyone permissions to read any property on any user object. The Active Directory Installation Wizard (dcpromo) allows the user to select this configuration by means of a weaken the permissions option on certain Active Directory objects.

You should use this last workaround only after careful study of its impact on the security of Active Directory. If you think it conflicts with your security requirements, you should adopt the recommended approach, which is to upgrade the Windows NT RAS server to Windows 2000 and make it a member of a Windows 2000 mixed or native domain. This would also have the benefit of avoiding inconsistent behavior while the domain is in mixed mode, as described in the second condition.

Your upgrade plan should take these factors into consideration. One implication is that you should consider upgrading your RAS server first in the server upgrade process.

Supported Upgrade Paths

An important consideration in planning your upgrade to Windows 2000 will be the operating systems you already have deployed in your enterprise, and whether you can upgrade them directly to Windows 2000.

The table below contains a list of supported upgrade paths at Windows 2000 beta 3. In the cases where an upgrade is required but a direct upgrade is not supported, you will upgrade via another operating system such as Windows 9x, Windows NT 3.51/4.0 for workstations, or Windows NT 3.51/4.0 for servers. You will need to reflect this in your upgrade plan.

Supported Upgrade Paths

Platform

Upgrade to Windows 2000 Professional

Upgrade to Windows 2000 Server

Windows 3.x

No

No

Windows NT 3.1

No

No

Windows NT 3.1 Advanced Server

No

No

Windows NT 3.51 Workstation

Yes

No

Windows NT 3.51 Server

No

Yes

Windows 9x

Yes

No

Windows NT 4.0 Workstation

Yes

No

Windows NT 4.0 Server

No

Yes

Order for Upgrading Domains

So far, this chapter has covered the order of upgrade for domain controllers in a domain. There is little room for variation on this point: You must upgrade the PDC first, and then the BDCs. The question of which domain to upgrade first is more problematic, and the answer may vary depending on your circumstances. For example, if you are planning to restructure certain domains out of existence, there might be little point in upgrading them first.

Although your situation may change this, in general you should consider the following order for upgrading your domains:

  1. Account domains

  2. Resource domains

Upgrading Account Domains

As a general rule, you will get the most benefit from upgrading your account domains earliest because in most cases there will be more users to administer than computers. By upgrading your account domains to Windows 2000, you will benefit from:

  • Improved scalability of Active Directory. Many organizations are pushing the upper bounds of the recommended SAM size with their existing numbers of users and groups.

  • Delegated administration. The ability to delegate administrative capability at very fine granularity, without the necessity to grant absolute power.

Order of Account Domains

If you have more than one account domain, the following guidelines should help you choose in which order to upgrade them:

  • Maintain control. Although you will have tested your upgrade strategy in a lab, or via a pilot, the first live migration will be the riskiest. To mitigate risk, you should upgrade domains where you have easiest access to the domain controllers.

  • Mitigate risk and disruption. If there is more than one domain to choose from in any situation, upgrade the smallest first so that you minimize disruption to the greatest number of possible users, particularly while you are gaining experience at the process.

  • Get the job done. Once you have gained experience and confidence in the process, move onto the bigger account domains.

  • Look for targets of account domain restructure. If you are planning to restructure your domains, you should look to upgrade the likely targets of restructure early in the process. You cannot consolidate domains into a target that does not exist.

Order of Resource Domains

If you have more than one resource domain, the following guidelines should help you choose in which order to upgrade them:

  • Provide the features that applications need. First you should upgrade domains where you are deploying applications that demand Windows 2000 infrastructure or features, such as the Active Directory required by Microsoft Exchange 2000 (the next major release of Microsoft Exchange).

  • Choose domains with many workstations. Next you should upgrade domains with many workstations, so that you can take advantage of Windows 2000 infrastructure such as Microsoft IntelliMirror.

  • Look for targets of resource domain restructure. Just as with account domains, if you are planning a restructure of your domains, you should look to upgrade the likely targets of restructure early on.

Upgrading Workstations and Servers

Although the focus of this chapter is domain upgrade and consolidation, do not assume that you should postpone deployment of Windows 2000 workstations and member servers until you upgrade the domain infrastructure. Using Windows 2000 workstations and servers in an existing Windows NT environment will still have a number of benefits. The following table lists some of the benefits achieved by simply upgrading workstations and servers to Windows 2000.

Benefits of Simple Workstation or Server Upgrade

Benefit

Features

Manageability

Plug and Play
Hardware wizard with device manager
Support for universal serial bus
Microsoft Management Console (MMC)
New backup utility

File system support

NTFS 5.0 file system enhancements, including support for disk quotas, the ability to defragment directory structures, and compressed network input/output
File allocation table (FAT) 32

Application services

Microsoft Win32 driver model
Microsoft DirectX 5.0
Windows Script Host

Information sharing and publishing

Microsoft distributed file system (Dfs) for Windows NT Server, a network server component that makes it easier for users to find and manage data on the network.
Integrated Internet shell

Scalability and availability

Improved symmetric multiprocessor support