Planning a Domain Upgrade

Upgrading a Windows NT domain to a Windows 2000 domain isn't quite the three-click process that you perform when upgrading a single Windows NT 4 workstation. In fact, considerable planning is necessary before you even start Windows 2000 Setup on the first computer. Some computers, such as the PDC and BDCs, must be upgraded in a specific order, with the PDC being upgraded first. Other computers, such as Windows NT member servers and stand-alone servers, as well as client computers, can be upgraded at any time before or after the actual domain is upgraded.

The following sections are essential for anyone planning a domain upgrade. They cover documenting an existing network, making a recovery plan, planning the Active Directory tree, and developing an upgrade strategy. Subsequent sections cover preparing for the upgrade, the actual upgrade process, and finally, switching an upgraded domain into native Windows 2000 mode.

An in-place domain upgrade is a domain upgrade that is performed while leaving the domain intact. Domains can also be upgraded by removing the PDC from the domain, leaving the BDCs to provide services. You upgrade the PDC to Windows 2000, test it, and then bring it back into the production domain.

Upgrading vs. Migrating to a New Domain

If your current domain structure is unsatisfying, it might be tempting to start from scratch, migrating accounts and resources into a fresh Active Directory domain. Resist this urge.

Migrating to a new domain is fraught with peril. A new domain name is required (a political nightmare in its own right), so all links need to be updated, and users need to adjust to logging onto a different domain. Also it's important to realize that everyone needs to sign off on a decision of this magnitude and that can be tough. The decision to migrate to a new domain structure is political, not technical.

With that said, it makes sense to look at migrating to a new domain or domain tree if doing so makes it possible to merge two or three separate domains or trees into a single domain or tree. Just remember to carefully weigh the pros and cons and get everyone's approval before opening up this can of worms.

Documenting the Existing Network

The first step in planning an in-place domain upgrade is to document the current network structure. To do so, take an inventory of the following network attributes:

  • The existing domain model and trusts
  • The number and location of the domain controllers
  • Account and resource domains
  • DNS namespaces currently in use
  • Application servers
  • Windows NT Routing and Remote Access Service (RRAS) servers
  • Whether LAN Manager Replication Service is in use
  • Windows NT 3.51 servers

The sections that follow describe how to document each of these features.

The Existing Domain Model

The type of domain structure, or model, that the existing Windows NT domains use determines how you implement the Windows 2000 Active Directory trees and forest. Table 7-2 summarizes the types of domain models that might be in use.

Table 7-2. Domain models available in Windows NT

Domain Model Description

Single-domain

A single Windows NT domain

Single-master

One account domain and multiple resource domains

Multiple-master

Multiple account domains with two-way trusts between them and multiple resource domains that trust all master domains

Complete trust

Every domain is a resource domain and an account domain, with each domain trusting every other domain

Existing Trust Relationships

Because trust relationships are preserved during the upgrade process, it's wise to check and document what trust relationships actually exist.

Location and Number of Domain Controllers

Determine where the PDCs and all BDCs are located. The PDC must be upgraded first. The BDCs can be upgraded after that and obviously cannot serve their intended function during the actual upgrade.

Our preferred way of upgrading a domain is to purchase a new server to use as the PDC to upgrade. This ensures that the computer is modern, compatible, and fast enough to adequately run Microsoft Windows 2000 Server. It also minimizes the amount of junk residing on the hard drive and in the registry, providing the "closest to clean installation" experience possible.

Account Domains and Resource Domains

Record the current number of account domains and resource domains. Also record how these domains are configured, and give some thought to whether you want to perform a domain restructure before or after you upgrade the network to Windows 2000.

DNS Namespaces

If the company has already deployed any DNS, you should carefully document the namespaces currently in use. Domains cannot be renamed after they've been created, and they must be unique on the network, so it's important to have domain names that aren't already in use in the organization.

Application Servers

A crucial and sometimes forgotten step in documenting a network is to make an inventory of the application servers. This includes all DNS, DHCP, and Windows Internet Name Service (WINS) servers, as well as application servers such as Microsoft Exchange servers, SQL servers, proxy servers, and so on. DNS is a required service on a Windows 2000 native domain, so some thought should go into determining whether you want to use existing DNS servers for this purpose, deploy new DNS servers, or use the domain controllers as DNS servers—which is what Microsoft suggests.

Also examine any NetWare servers in the environment and determine whether you want to synchronize Active Directory with Novell Directory Services (NDS). You should also check the release notes included on the Windows 2000 Server CD-ROM for any compatibility issues with the version of NetWare. Chapter 21 discusses interoperating with NetWare.

Samba servers might require access to a real Windows NT 4 domain controller (instead of a Windows 2000 Server running the PDC emulator). Record the location and capabilities of any Samba servers on the network, and make a special note of whether they require access to Windows NT domain controllers (if so, you'll need to postpone switching the network to a native mode until this issue is cleared up).

Application servers such as earlier versions of Exchange, SQL, or media servers should also be evaluated for compatibility with the new Active Directory domains. Most servers will have no problems, but this is a good opportunity to double-check, as well as to reevaluate these servers' roles and their effectiveness on the network.

Windows NT RRAS Servers

Windows NT 4 Routing and Remote Access (RRAS) servers need access to a real BDC for user information, and thus cease to work properly after the last BDC is upgraded. For this reason, upgrade any Windows NT 4 RRAS servers before you promote the last BDC. Alternatively, you can loosen the security settings for Active Directory such that Windows NT 4 RRAS servers can still work properly (this is one of the first questions in the Active Directory Setup Wizard), although this isn't optimal. Windows 2000 Server provides much more powerful and reliable RRAS services, so we recommend that you bite the bullet and upgrade or replace any old RRAS servers.

LAN Manager Replication Services

The LAN Manager Replication Service feature of Windows NT isn't supported on Windows 2000 Server-based networks and needs to be disabled or replaced before a network upgrade. This service is used to replicate files (usually logon scripts) on servers using Import and Export directories.

It is replaced in Windows 2000 Server by the file replication service (FRS), which makes use of the system volume (SYSVOL) on domain controllers to replicate files to other domain controllers in a multiple-master fashion. It is automatically installed on domain controllers.

It is possible to maintain LAN Manager Replication Service on an Active Directory network if you really must, although we don't recommend it. For information on setting this up, see the Microsoft Windows 2000 Server Resource Kit.

Windows NT 3.51 Servers

If there are still Windows NT 3.51 servers and/or clients on the network, it's time to upgrade or get rid of them. Windows NT 3.51 computers exhibit problems in an Active Directory domain that make them generally unsuitable for use. The problems include Windows NT 3.51 computers either denying access to user or group logons, or incorrectly granting access to users or groups that have been denied access (not a good thing). These difficulties occur because of the way in which Windows NT 3.51 generates access tokens when a user logs on to the server.

If you absolutely can't part with your Windows NT 3.51 (or earlier) computers, create or leave an existing domain running under Windows NT 4 and create the appropriate trust relationship between this domain and your Active Directory structure. Just keep them off Active Directory domains.

Making a Recovery Plan

Upgrading a domain involves a fair amount of risk. If the PDC fails the upgrade and there aren't any BDCs available, the entire domain can be brought down. To protect your network from this unhappy possibility (and others), you need a recovery plan.

The following sections provide specific recommendations to follow to safeguard a network from disasters—just in case.

Make Sure All Domains Have at Least One BDC

Be sure that all domains you plan to upgrade have at least one BDC in addition to the PDC. This prevents the domain from being orphaned (or lost entirely) if the PDC fails the upgrade. Having a working and recently synchronized BDC also allows the network to function (almost) normally while you upgrade the PDC (some programs or services such as WINS don't like it when the PDC is gone).

Back Up Each Computer Before Upgrading

It's just common sense to back up the systems before upgrading them. This is perhaps overly cautious on some Windows NT desktop systems, but it really is important on servers, especially domain controllers. Also, make sure that you test the backups; there's nothing more useless than a corrupt backup tape.

Synchronize All BDCs with the PDC

We've already said this, but it's worth repeating: synchronize the PDC with all of its replication partners before upgrading it. If the PDC fails the domain upgrade, you can promote a BDC to the PDC and the domain won't lose any changes.

Take a BDC Offline for Backup

Having freshly synchronized BDCs and new tape backups of the PDC will protect you from most disasters. However, it's good insurance to take a freshly synchronized BDC offline before upgrading the PDC. This provides you with a quickly available, working backup of the domain as it existed before you started the upgrade process. If the upgraded PDC replicates bad domain information to the BDCs or the domain becomes damaged in some other way, having an offline backup allows you to go back and start over.

To prepare a BDC to act as an offline domain backup, synchronize the BDC with the PDC domain, back up the BDC, and then disconnect the network cable to the BDC. If a major disaster occurs after upgrading the PDC and it's necessary to restore the domain to its pre-Active Directory state, use the following steps:

  1. Demote any Windows 2000 or later domain controllers on the network back to member server status.
  2. Reconnect the offline BDC to the network.
  3. Promote the formerly offline BDC to a PDC.
  4. Synchronize the new PDC with the other BDCs on the network. This returns the domain to the state it was in immediately before you took the BDC offline.

    All changes to your domain performed after taking the backup BDC offline will be lost if you bring the BDC back online and promote it to a PDC. Because of this, we recommend keeping a record of any changes you make (such as creating or deleting accounts, changing group memberships or trust relationships), so that in the event of a disaster you can manually re-create the lost changes.

Relax

Don't let all of these warnings put you off. If you take precautions and the upgrade goes faultlessly, you won't have to resort to restoring backups or using other recovery mechanisms. That's good news. Just remember that no one ever lost a job because of being too prepared.

Plan the Active Directory Tree

There are several steps you should take in planning the Active Directory tree, including defining the DNS namespace and creating the initial tree structure. This section briefly covers these steps. More detailed information on planning the namespace and the domain structure can be found in Chapter 3.

Define the Namespace When deciding how to implement a DNS namespace, you usually need to decide whether to use an existing DNS namespace and create the root domain with an existing domain name or create a new root domain and associated DNS namespace. The decision is crucial because the root domain can't be easily deleted or renamed; you're pretty much stuck with it. (You can change or delete the root domain if you really must, but it involves taking down the entire domain—not a whole lot of fun.) Domain names are also highly political in nature, so if you're fond of your job, don't create the domain structure and namespace without first getting the approval of the powers that be.

With that said, the following list summarizes the tasks necessary to define and implement the namespace. (The specifics of some of these tasks are given in the sections that follow.)

  • Decide either that you can use an existing domain name for the root domain or that a new one is necessary.
  • If you are going to use a new domain name, determine what constraints you have in the name selection process and go through the proper channels to pick the domain name.
  • Set up the root domain to form the top level of the namespace, with a couple of domain controllers for redundancy.
  • Set up one or more DNS servers for the root domain tree. The DNS server needs to support the service resource record (the DNS resource record for specifying the location of services) and should ideally support dynamic updates as well. Microsoft recommends installing DNS on each domain controller and storing the zone data in Active Directory—not a bad idea.
  • Add the other domains as child domains under the root domain. This is an excellent time to perform a domain restructure or to at least consolidate some of the resource domains into OUs.

Create the Initial Tree Structure After you've decided on the DNS namespace, you're ready to plan the Active Directory tree in detail. For this chapter, we are going to assume that you have a single-tree forest, with all domains sharing a contiguous namespace. In practice, many companies will need to use a forest with multiple trees, each having its own namespace. However, the process is no different; each tree is constructed and then added to the forest in the same way.

The first domain that you upgrade to Windows 2000 (or create if you're using a multiple-master domain model that doesn't lend itself to consolidation under one of the current domains) needs to be the root domain. The root domain stores the configuration and schema for the entire Active Directory forest and cannot be renamed or deleted.

Adapt to Specific Domain Models

Four domain models are available in Windows NT: the single-domain model, the single-master-domain model, the multiple-master-domain model, and the complete trust model (see Table 7-2 for a summary).

Single-Domain Model The Windows NT single-domain model consists of a single domain, with all accounts and resources stored together.

The single-domain model is easy to upgrade: the single domain under Windows NT becomes the root domain in Active Directory under Windows 2000. You can then use OUs to organize the accounts and resources and delegate some of the administrative burden.

Single-Master-Domain Model The Windows NT single-master-domain model consists of one master domain that contains all user accounts, and one or more resource domains that trust the master domain and only contain computer accounts and other resources.

If you have a single-master-domain model, make the former master domain the root of the tree and add the resource domains as child domains of the root. If the company has a centralized network structure, you might want to consider restructuring the domains into a single domain after you've upgraded the domains to Active Directory. You can use OUs either to mimic the resource domains or to organize them more logically, with the accounts and resources grouped and organized according to the company's structure.

Merging the resource domains back into a single domain offers a number of advantages. Because there are fewer domains to manage, the administrative burden is less. You can use OUs to create a detailed network structure without dealing with trusts. In addition, you can delegate administrative authority to the OUs, giving you the flexibility to handle the administrative tasks the way you want. Active Directory queries are also performed faster and more efficiently in a single domain. Finally, because OUs don't require domain controllers, there is the potential to free up some underused computing resources for other tasks. Figure 72 shows a single-master Windows NT domain converted to a Windows 2000 Active Directory tree.

Figure 7-2. A single-master Windows NT domain converted to a Windows 2000 Active Directory tree, with a resource domain converted to an OU after switching to native mode.

A company with a more decentralized organization, or one with different business units, might want to stick with multiple domains but convert its resource domains into full-fledged domains, with both resources and user accounts. (With Active Directory, there is no reason to keep distinct resource domains.) This arrangement allows users to be in the same domain as the resources that they use, reducing traffic and making it easier for users to find and access the resources they need. You should wait, however, until all relevant domains have been upgraded before moving the accounts because transitive trusts make moving accounts between domains much easier, and this type of trust is available only between Active Directory domains. Alternately, you can establish a two-way trust between the resource domains and the parent domain, but it usually makes more sense to wait until all domains are running in native mode.

Third-party solutions can provide much of this organizational flexibility in Windows NT 4, with the intent of permitting companies to restructure their domains in a way that works well with Active Directory before they upgrade. For example, Fastlane Technologies sells a product called Fastlane Migrator (formerly DM Manager), which allows companies to upgrade Windows NT 4 domains into a multimaster structure that is very similar to that provided by Active Directory. Using this product allows a company to restructure its domains into a hierarchical domain structure that can be very easily upgraded to an Active Directory-based network once the company is ready, while benefiting from many of Active Directory's features in the meantime.

Multiple-Master-Domain Model The multiple-master-domain model in Windows NT consists of a network with two or more master domains that contain all the user accounts, and multiple resource domains that trust each master domain and contain all of the computer accounts and other resources. Very large networks use this model to circumvent the Windows NT limit of 40,000 objects per domain.

Because of the flexibility and advantages the single-domain model has to offer, many companies with a multiple-master-domain model choose to consolidate their domains into a single Windows 2000 domain, using OUs to hierarchically structure their network. If you choose to consolidate the domains, you should first perform the domain upgrade just as if you were going to preserve the existing domain structure, and then perform the domain consolidation. After the domains are upgraded, all accounts can be moved into the single domain without the need to reassign permissions on the objects.

If you want to create a single-domain tree (with a contiguous namespace) during the domain upgrade, you can use one of the existing domains for the root of the tree, or create a new root domain and add the other master domains as its children, as shown in Figure 7-3. You might want to consider using a structural domain for this root domain. (See the Real World sidebar "Using Structural Domains," later in this chapter.) Upgrade or create the root domain first. After this domain is up and running with a couple of domain controllers, upgrade the rest of the domains and add them to the tree.

Figure 7-3. A multiple-master Windows NT domain converted to a Windows 2000 Active Directory tree, with two resource domains converted to OUs after switching to native mode.

If you want to keep each master domain in an authoritative role, you can create a multiple-tree forest, with each master domain seeded as the root for a new tree in the forest. In this case, it doesn't matter which master domain you upgrade first, but you must upgrade the master domain for each tree before you upgrade the resource domains you plan to add to the tree.

Real World

Multiple-Master Domains and the Case for Domain Consolidation

The Windows NT multiple-master-domain model is widely used in larger organizations for a couple of reasons. First, it allows the network to grow beyond the limitations of the single Security Accounts Manager (SAM) that single domains and single-master domains use. The SAM in Windows NT is stored in the system registry, and once it grows past 40 MB, performance degradation is noticeable. This means that the practical limit for a domain is 40,000 objects, with a maximum of 20,000 user accounts. To have more user accounts or objects than this, Microsoft recommends moving to a multiple-master-domain model.

The second reason that companies use multiple-master domains under Windows NT is to allow for physically different network sites that don't possess wide area network (WAN) connections that are fast and reliable enough to allow domain controller replication to take place without consuming an inappropriate amount of the WAN bandwidth. Using a master domain in each site gets around this lack of adequate connectivity, because no replication takes place between master account domains and all of the WAN bandwidth is available for other uses.

The third reason to use a multiple-master Windows NT domain structure is to reflect the company's organization in cases where different parts of the company need to control their own resources and users. Each master account domain can have its own administrator or the administration can be centralized, depending on the desires of the company.

Active Directory deals with these issues effectively, permitting many companies to move to a single-domain model (or at least to reduce the number of domains) and gain the advantages that model has to offer. Active Directory stores all domain information in its database (which is external to the registry and free to grow in size), with each domain storing its part of the entire directory instead of one server storing the entire network schema, allowing you to scale the domain to approximately a million objects. No other domain is necessary; all organization can be done with OUs. You can also create multiple physical sites, with a single domain spanning all sites and intersite replication set up to make the best use of slow WAN links.

Complete Trust Model The Windows NT complete trust model involves multiple domains that all trust each other.

The Windows NT complete trust model is used most often by very decentralized companies or by companies that implemented domains in a piecemeal fashion and gradually connected them. The model provides a lot of autonomy and flexibility for each master domain, but it also entails a large administrative burden.

As with the multiple-master-domain model, many companies, when upgrading a domain that uses the complete trust model to Windows 2000, try to consolidate their domains into a single tree or even a single domain. However, if you want to maintain the autonomy of the current domain structure of the complete trust model, you can set up each current master domain as a new tree or (if necessary) as a new forest. When you create the Active Directory structure like this, you automatically reduce the amount of administration necessary, as all trusts between domains in an Active Directory tree or forest are automatically transitive.

When you upgrade the domain, create the root domain first, either by creating a new domain (structural or normal) or by upgrading an existing domain and seeding it as the root of the Active Directory tree. Once you have the root up and running with a couple of domain controllers, you can move on to upgrading the other domains and adding them as children of the root domain or as roots in new trees or forests. If necessary, after upgrading all domains and switching to native-mode operation, you can replace any transitive trusts with Windows NT-style one-way trusts to limit access within a forest or to provide external domains access to specific domains in the tree or forest.

A one-way trust can also be set up to permit a legacy Windows 3.51 or Windows NT 4 domain or a child domain of another forest (such as one belonging to a business partner) to access a specific domain in the tree or forest. When you set up an explicit one-way trust in Windows 2000, it works identically to trusts in Windows NT—that is, the trust is not transitive. If you grant a domain access to a single domain in the tree or forest, the trusted domain cannot access any other domain in the tree, even though the tree is linked with transitive trusts.

Planning the Site Topology

Sites, an important new feature in Windows 2000, define the boundaries of LAN connectivity, making WAN links more efficient. When you set up sites that mark the sections of the network that have high-speed connectivity, Active Directory tunes the way it uses the WAN links by reducing the frequency of replication between sites and by directing clients' service requests (such as logons or directory searches) to domain controllers that are available locally.

Sites are independent of domains. Whereas domains typically mirror a company's logical organizational structure, sites mirror the physical network structure of a company. A single site might consist of one or more domains, trees, or even forests, and a single domain can span multiple sites. A site can consist of a single IP subnet (often the case because subnets frequently mark physical network boundaries) or multiple IP subnets, but all subnets must share reliable, high-speed connectivity to be a part of a single site.

In these days of Asynchronous Transfer Mode (ATM) WAN links, it is becoming increasingly common for a company's WAN link to be as fast (or sometimes faster) than an internal LAN. However, the WAN link charge might be based on usage, or a company might use the link heavily for real-time, bandwidth-intensive tasks such as video, reducing the available bandwidth. In such cases, you might still want to set up a site structure for the Active Directory forest to avoid burdening the WAN link with excessive replication and service requests.

When planning to upgrade a Windows NT domain to Windows 2000, it is important to plan the site topology so that you can set up the site structure promptly after upgrading. Ask yourself the following questions and make a record of your answers:

  • What sites will you need to create in the Active Directory forest?
  • What links are available between these sites, and how fast and expensive are they? Are they already heavily utilized, or is an abundance of bandwidth available?
  • Are there any planned links between the sites?
  • Are there any domains that will span physical sites, and if so, are the links between the sites fast enough to support this?

Two types of connections are available for intersite replication: point-to-point synchronous low-speed RPC and Simple Mail Transfer Protocol (SMTP). Any domains that span multiple sites must have at least a point-to-point synchronous low-speed RPC connection between the sites within the domain. This connection is required because you can't use SMTP for intersite replication between domain controllers in the same domain; you can use SMTP links only for schema, configuration, and Global Catalog (GC) information replication. Therefore, if you have multisite domains, double-check the link between the sites to make sure that you have adequate connectivity for this setup.

It's a good idea for there to be a Global Catalog server on each site to allow a local domain controller to service requests for any resource in the forest without having to use the WAN link. However, the Global Catalog server shouldn't be the same server as the infrastructure master unless there are no other domain controllers in the domain, as this configuration breaks the infrastructure master's ability to update other domain controllers in the domain (see Chapter 12 for information about the infrastructure master role).

We also recommend placing at least one DNS server in each site, and having a minimum of two domain controllers per site for redundancy (this isn't as important for remote sites with a small number of clients).

Sites are easy to reconfigure, and should be tuned as your network links change.

Real World

Using Structural Domains

Companies that use the multiple-master-domain or complete trust model under Windows NT usually choose an existing domain to use as the root for their Active Directory tree. However, some organizations choose to use a structural domain as the root of their tree, with the former master domains as child domains.

A structural domain is simply a domain without user accounts or resources—it exists purely to form the structure of the domain (hence the name) as well as to aid in easy and efficient interdomain replication. Structural domains can be used to provide a domain structure that is well suited to further restructuring in the future. By placing one or more levels of structural domains in the Active Directory tree, you provide an unchanging anchor in the domain tree, under which you can move child domains without altering the higher level domain structure. At the same time, the structural root domain acts as a shield to the world so that changes in complexity are hidden behind it.

Structural domains are also useful for replication between sites, especially when accessing or replicating the Global Catalog (GC), which is the master catalog for all objects in the host domain's portion of Active Directory and a partial catalog of objects stored in other domains. If you have more than one site, you might choose to create a structural domain at the root that spans all sites and maintains a copy of the GC at each site. (You could also store a copy of the GC in the top-level local domain at each site and just use the structural domain as a link between the sites.) Having an on-site GC permits the local domains at all sites to concentrate on intrasite data processing and replication, with all intersite replication performed by the structural domain.

Using structural domains for replication also makes setting up and maintaining replication links easier. Child domains simply replicate upward to the parent domain, obviating the need to know the name of each domain you need to replicate with.

More Info

For more information about structural domains, see Microsoft Windows 2000 Distributed Systems Guide.

Developing an Upgrade Strategy

After documenting the existing network infrastructure, making a recovery plan, and designing the Active Directory trees and sites, you're ready to put it all together and create an actual upgrade plan. This section presents some general guidelines that apply to all domain upgrades, as well as some tips for specific domain models.

Make Sure the PDC Is Sufficiently Powerful

Start the domain upgrade by carefully examining the current PDC. Although Windows 2000 uses peer-based, multiple-master domain controllers, the first domain controller retains extra services that in some cases cannot easily be moved to other domain controllers. These services include the Global Catalog server, the Operations Master, and the PDC emulator. (The PDC emulator provides services for Windows NT and Windows 95/98 clients and also performs some tasks in a pure Windows 2000 environment.) In other words, all domain controllers are equal, but the first Windows 2000 domain controller is a little more equal than the others, so you want that machine to be especially fast and powerful.

Our preferred method of dealing with this is by going out and buying a brand new, powerful computer, putting Windows NT 4 Server on it as a BDC with Service Pack 6a and the latest hot fixes. Promote the server to your PDC, let it sit for a little while, and then take it offline and perform the upgrade to Windows 2000 Server. This ensures that your first domain controller is on the most powerful and up-to-date hardware you have available, and also provides the closest to clean-install experience possible from an upgrade.

Create the New Root Domain Before Upgrading the PDC

If you're moving from a multiple-master-domain or complete trust model and want to create a new domain to serve as the root of the domain tree, you need to do this before you upgrade the PDC. By the way, creating this new root domain, whether it's a structural domain or not, involves a brand new system (or at least a clean install) with Windows 2000. After you have created the new domain and have it running with a couple of domain controllers (as well as any new systems or clean installs), you can upgrade the PDC and join it to this new tree as a child domain.

Upgrade or Retire Any Incompatible Clients and Servers

If you have any Windows NT 4 RRAS servers or computers running Windows NT 3.51 or earlier, upgrade or retire these systems as discussed earlier in this chapter.

Servers using the LAN Manager Replication Service should disable this service, because it's incompatible with Active Directory networks. The file replication service (FRS) feature of Windows 2000 Server domain controllers replaces it.

Upgrade the PDC First

The first server to be upgraded must be the Windows NT PDC in the account domain you want to use as the root of the new Active Directory tree. This is true whether the tree you're creating is the first in the forest or the twentieth in the third forest—you always need to upgrade the PDC first if you want to upgrade the Windows NT domain instead of creating a new domain.

Upgrade the BDCs

Upgrade the BDCs as soon as the first Windows 2000 Server domain controller is up and running properly. Upgrade BDCs one at a time, but pause before upgrading the last BDC. Verify that you've dealt with all incompatible clients and servers, and to be extra safe, take the last BDC offline for a while before upgrading it. If nothing erupts in flames, go ahead and upgrade it.

Make sure that the first domain controller is visible on the network when upgrading a BDC. When you upgrade a BDC, it only replicates with the PDC emulator. If the former PDC isn't available, the BDC tries to configure itself as the first domain controller in the domain, creating serious problems when the first domain controller comes back online.

Upgrade Member Servers and Clients Independently

Upgrade member servers and workstations whenever you want—either before or after you upgrade the domain. Windows 2000 and Windows XP clients and member servers work perfectly well with Windows NT domains; however, the benefits of Active Directory aren't available to them until the domain is upgraded.

Schedule the Domain Upgrade Appropriately

Schedule the domain upgrade at a time that will have the lowest impact on the user population. Although it's probably a forlorn hope, it's best to avoid upgrades during major projects and at the busiest times of year. Even perfect upgrades produce some impact on the users, especially if you perform any domain restructuring or consolidation.



Microsoft Windows 2000 Server Administrator's Companion
Microsoft Windows 2000 Server Administrators Companion
ISBN: 0735617856
EAN: 2147483647
Year: 2003
Pages: 320

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net