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
Estimated lesson time: 35 minutes
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.
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 failure | Resolution |
---|---|
Permanent |
|
Disk failure |
|
Other temporary failure |
|
Software or hardware errors during the installation of Active Directory directory services can present different problems. If failure occurs, perform the following:
NOTE
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.
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.
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.
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,
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.
Figure 11.1 Changing the Global Catalog setting
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 role | Consequences of server failure during migration |
---|---|
Schema master | Little consequence occurs unless you're planning on modifying the schema during upgrade. (For example, you're simultaneously deploying Microsoft Exchange Server 2000.) |
Domain naming master | Unable to add other domains to the forest. |
Infrastructure master | Changes to group memberships won't take effect across multiple domains. |
RID master | Problems will occur with creating objects in the domain. |
PDC emulator | Problems 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.
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
Now you'll attempt to transfer the role of RID Master.
To transfer the role of RID master
There might be short delays as the program tries to locate the unavailable TRAINKIT1 host.
Note that the RID Master is shown as being offline and that the role can't be transferred.
The message box shown in Figure 11.2 appears.
Figure 11.2 Unable to seize the RID master role
To transfer the RID master role using the Ntdsutil utility
The dialog box shown in Figure 11.3 will appear.
Figure 11.3 Seize the RID Master
You'll then be presented with the warning shown in Figure 11.4.
Figure 11.4 RID master warning
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.
Figure 11.5 RID master seizure
To verify that the RID master was successfully seized by MIGKIT1
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
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
Figure 11.7 Replicating NTDS settings between domain controllers
A message box should appear indicating that the replication was successful.
NOTE
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
The RID master role should transfer back to TRAINKIT1.
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.
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.
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.)
TIP
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.
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.