Lesson 1: Domain Upgrade Failures

If you followed the guidelines suggested in the previous chapters, hopefully your migration went as smoothly as can be expected. However, you might experience anything from minor teething problems to major headaches if there are any migration failures. This lesson examines some of the possible causes of a failed domain upgrade.

After this lesson, you will be able to

  • Understand how to resolve hardware failures.
  • Understand how to resolve third-party tool issues.
  • Resolve issues associated with rights necessary for an upgrade.
  • Resolve domain name issues.

Estimated lesson time: 35 minutes

Hardware Failures

Knowing what to do in the event of a hardware failure is important during any migration. Depending on the role of the server in your organization, you might need to do more than just recover the server. In the following sections, you'll learn what to do if the PDC fails during upgrade, what to do if a server holding an FSMO role fails, and what to do if the servers holding other critical roles fail.

Failure of a PDC During Upgrade

If you've decided to create your Windows 2000 forest by upgrading from Windows NT 4.0, the upgrade of the PDC is the step where your Windows 2000 domain is first created. It is, therefore, a critical step. It's extremely important that you synchronize a BDC with the PDC in each domain and take the BDC offline before upgrading the PDC. Synchronization will give you an up-to-date version of the SAM database as it is before the upgrade so that you'll be able to roll back to the previous environment if the upgrade fails.

Exactly what you should do if a PDC upgrade fails depends on when the failure occurred. Table 11.1 shows what to do if a PDC upgrade fails during setup.

Table 11.1 Resolving Failure of a PDC During Upgrade to Windows 2000

Type of failureResolution
  1. Bring BDC back online
  2. Promote BDC to PDC
  3. Synchronize another BDC
  4. Take that BDC offline
  5. Upgrade new PDC to Windows 2000
Disk failure
  1. Replace faulty disk
  2. Recover machine from backup
  3. Restart Windows 2000 Setup
Other temporary failure
  1. Resolve hardware problem
  2. Restart machine
  3. Setup should continue

Software or hardware errors during the installation of Active Directory directory services can present different problems. If failure occurs, perform the following:

  • Look to see whether there are entries for Active Directory in DNS.
  • Remove any entries specific to Active Directory.
  • Recover the server.
  • Run the Active Directory installation wizard again.


If a server has experienced a temporary hardware failure and you try to restart the Active Directory installation wizard, you might not be able to recover. The only solution might be to revert to your Windows NT 4.0 environment and begin setup again.

Failure of BDCs During Upgrade

Windows 2000 doesn't depend on the successful upgrade of your BDCs. Therefore, it's critical to successfully upgrade BDCs only if they are themselves running critical services. If a BDC fails permanently during upgrade, consider moving the services that were running on it to a domain controller (or server) running Windows 2000; or, if necessary, recover the BDC to another machine with working hardware using the BDC backup and then upgrade this BDC.

Failure of Domain Controllers in the Root Domain During Migration

If all the domain controllers in the root domain fail, enterprise functionality is lost. Therefore, even if you're planning on having a placeholder root domain, be sure that you have at least two domain controllers present in the root domain before creating child domains. If you do lose all the domain controllers in the root domain, you'll either have to recover them from backup or recreate your Active Directory forest.

Failure of DNS Servers During Migration

One of the most critical servers that can fail during a migration is the DNS server. Therefore, you should have multiple DNS servers available. Each DNS client should have a primary and secondary DNS server specified. The easiest way to ensure continued service from DNS is to use Active Directory–Integrated DNS. If Active Directory–Integrated DNS isn't used,

  • The primary DNS represents a single point of failure and will need to be recovered to restore DNS propagation.
  • Automatic updates of DNS records won't be possible; therefore, as extra domain controllers are added to the domain, they won't appear in DNS.

To minimize problems with primary DNS servers, either ensure that you have an Active Directory–Integrated DNS or always have secondary DNS servers. In addition to being able to resolve queries if the primary DNS server fails, a secondary DNS server can be converted to a primary DNS server if necessary.

Failure of a global catalog server will not affect the migration directly. Recall that any server can be made a global catalog server at any stage by accessing the Active Directory Sites And Services administrative tool and selecting the check box in the NTDS settings of the server, as shown in Figure 11.1.

click to view at full size.

Figure 11.1 Changing the Global Catalog setting

Failure of FSMO Servers During Migration

If you've documented your migration sensibly, you'll be aware of which servers hold each of the five Windows 2000 FSMO roles. By default, the first server in your forest will hold all five FSMO roles (in other words, there is one schema master and one domain naming master per forest, and there are one each of the PDC emulator, RID master, and infrastructure master per domain). The first server in each domain will be a PDC emulator, RID master, and infrastructure master. Depending on the stage you're at in the migration, this might still be the case; therefore, failure of a single server could result in multiple (or all) FSMO roles failing. Table 11.2 shows the consequences of each FSMO role failing.

Table 11.2 Hardware Failure of FSMO Servers During Upgrade

Server roleConsequences of server failure during migration
Schema masterLittle consequence occurs unless you're planning on modifying the schema during upgrade. (For example, you're simultaneously deploying Microsoft Exchange Server 2000.)
Domain naming masterUnable to add other domains to the forest.
Infrastructure masterChanges to group memberships won't take effect across multiple domains.
RID masterProblems will occur with creating objects in the domain.
PDC emulatorProblems will occur with updating passwords in a mixed-mode domain.
No synchronizing with Windows NT 4.0 BDCs.
No time synchronization across the domain (or enterprise if this is the PDC emulator in the forest root).
Problems with account lockout.

Whichever FSMO server fails, you'll need to recover the role. If it's a temporary failure, simply recovering the server will be enough. If the failure recurs, you should transfer the FSMO role to another server. If the server is permanently down, the role will need to be seized.

Practice: Seizing the Role of a RID Master

In this scenario, you're unable to create new objects within your domain. You suspect that the RID Master is down. If it's down permanently, you might need to seize the role.

First you'll simulate the RID Master being down.

To simulate the RID master being down

  1. Shut down Trainkit1. (Turn it off.)

    Now you'll attempt to transfer the role of RID Master.

To transfer the role of RID master

  1. Log on to MIGKIT1 (PC2) as Administrator with the password secret.
  2. Open Active Directory Users And Computers.

    There might be short delays as the program tries to locate the unavailable TRAINKIT1 host.

  3. Right-click trainkit.microsoft.com and wait for the shortcut menu to appear.
  4. Click Operations Masters.

    Note that the RID Master is shown as being offline and that the role can't be transferred.

  5. Click the Change button. Then click Yes in the dialog box that appears.

    The message box shown in Figure 11.2 appears.

    click to view at full size.

    Figure 11.2 Unable to seize the RID master role

  6. Click OK to close the message box.
  7. Click OK again to close the Operations Master dialog box.

To transfer the RID master role using the Ntdsutil utility

  1. Close Active Directory Users And Computers and open a command prompt.
  2. Type ntdsutil.
  3. At the prompt, type roles and press Enter.
  4. At the Fsmo Maintenance prompt, type connections and press Enter.
  5. At the server connections prompt, type connect to server migkit1 and press Enter.
  6. At the server connections prompt, type quit.
  7. At the Fsmo Maintenance prompt, type seize rid master.

    The dialog box shown in Figure 11.3 will appear.

    click to view at full size.

    Figure 11.3 Seize the RID Master

  8. Click Yes in the dialog box.

    You'll then be presented with the warning shown in Figure 11.4.

    click to view at full size.

    Figure 11.4 RID master warning

  9. Click Yes again.

    The RID master role transfer role will fail, so it will then be seized. You should see the readings shown in the command prompt window in Figure 11.5.

    click to view at full size.

    Figure 11.5 RID master seizure

  10. Type quit at the next two prompts and then close the command prompt window.

To verify that the RID master was successfully seized by MIGKIT1

  1. Open Active Directory Users And Computers.
  2. Right-click trainkit.microsoft.com and select Operations Masters from the shortcut menu.

    Note that this time, migkit1.trainkit.microsoft.com is the RID master as shown in Figure 11.6.

    Figure 11.6 Operations Master dialog box showing migkit1.trainkit.microsoft.com is the RID master

  3. Click OK to close the Operations Master dialog box. Close all open command prompts and applications running on MIGKIT1.

    Now you'll transfer the RID master role back to TRAINKIT1. Before you can do this, you'll need to force replication across the network to ensure that the correct information is shown in the Operations Masters role.

To force replication across the network

  1. Start up TRAINKIT1 and log on as Administrator with the password secret.
  2. Open Active Directory Sites And Services from the Administrative Tools folder.
  3. Expand the tree hierarchy by opening Sites, First-Site-Name, Servers, and then expand TRAINKIT1.
  4. Click NTDS Settings for TRAINKIT1. Then right-click MIGKIT1 in the right pane to open the shortcut menu, as shown in Figure 11.7.

    click to view at full size.

    Figure 11.7 Replicating NTDS settings between domain controllers

  5. Select Replicate Now from the menu.

    A message box should appear indicating that the replication was successful.


    If your system refuses to replicate because of RPC failures, ensure that all programs on MIGKIT1 have been closed down. If replication still fails, restart MIGKIT1.

To transfer the RID master role back to TRAINKIT1

  1. Continue working from TRAINKIT1 and open Active Directory Users And Computers.
  2. Right-click trainkit.microsoft.com.
  3. Select Operations Masters from the shortcut menu.
  4. The Operations Master dialog box appears, displaying migkit1.trainkit.microsoft.com as the RID master.
  5. Click the Change button.
  6. When asked whether you're sure you want to transfer the role, click Yes.

    The RID master role should transfer back to TRAINKIT1.

  7. Click OK to return to the Operations Master dialog box.
  8. Click OK to return to Active Directory Users And Computers.
  9. Close all applications on TRAINKIT1.

Third-Party Tool Issues

Third-party tools each have their own way of facilitating the migration from Windows NT 4.0 to Windows 2000, but ultimately, they all rely on a form of automated domain restructure. Before deploying any third-party tool to migrate from Windows NT 4.0 to Windows 2000, you're advised to examine the migration on a test network. In most cases, by extracting the Windows NT 4.0 SAM database, it should be possible to simulate the entire migration and therefore minimize the potential problems of doing the first upgrade on a live network. Ensure that you can roll back from any restructure to your original state.

Rights Necessary for Upgrade

To upgrade the PDC in Windows NT 4.0 to Windows 2000, you need the necessary rights over the Windows NT 4.0 system. However, once Active Directory has been created, you'll need to be part of the Enterprise Administrators group to add domain controllers to Active Directory. Either ensure that the administrators global group is in the Enterprise Administrators universal group, or create a separate global group and place your designated Enterprise Administrators group in the global group and then put this global group in the Enterprise Administrators universal group.

Domain Naming Issues

As mentioned in previous chapters, whether you're upgrading from Windows NT 4.0 domains or performing domain restructures, domain naming can provide you with one of the worst problems during migration.

Windows NT 4.0 domains are referred to by their NetBIOS names, whereas Windows 2000 domains are referred to by their FQDN as seen in DNS. So, for a domain called trainkit.microsoft.com in Windows 2000, the NetBIOS domain name is TRAINKIT.

When running the Active Directory installation wizard, you need to specify both the Windows 2000 FQDN and the NetBIOS domain name. It's possible to make these entirely different, which allows the migration of a Windows NT 4.0 domain to a Windows 2000 domain with a completely different domain name. The implication of having different names means that Windows NT 4.0 servers and workstations will see the domain by a completely different name than will Windows 2000 clients and servers during the upgrade. To avoid confusion, you might want to consider changing the name of the domain in Windows NT 4.0 prior to the upgrade. For example, if you were planning to upgrade the Windows NT TRAINKIT domain to a Windows 2000 domain named ukaccounts.microsoft.co.uk, you might want to rename the Windows NT domain to UKACCOUNTS before starting the upgrade. (Of course, in your own company, you wouldn't be using microsoft.co.uk but some form of your company's name or organizational structure.)


If your NetBIOS domain name is totally different from your Windows 2000 domain name, it's not only your legacy operating systems that will use the old name. If you're running NetBIOS-based applications, they will also use the NetBIOS name to identify the domain. This problem will require some thought if you're using an inter-forest or intra-forest migration because the domain name of your pristine environment will need to be different from the existing Windows NT domain. One solution would be to migrate the applications to the Windows 2000 domain first so that they will register the name change. If you're performing an upgrade, it's easier to change the domain name and register or install the applications again with the new domain name prior to upgrade.

If you plan your Windows 2000 environment to have an Internet presence, remember that you'll need to ensure that any domain names with IP addresses that are accessible outside the enterprise have a duly registered domain name on the Internet and that you're running the domains on their proper IP addresses.

Lesson Summary

In this lesson, you learned about several problems that might occur if hardware fails during a migration and how to deal with them, what to look for in third-party tools for a migration, the rights required to perform the upgrade, and issues you'll encounter as you name your Windows 2000 domains.

MCSE Training Kit (Exam 70-222. Migrating from Microsoft Windows NT 4. 0 to Microsoft Windows 2000)
MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)
ISBN: 0735612390
EAN: 2147483647
Year: 2001
Pages: 126

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