Microsoft

A guide to Active Directory: Planning your upgrade

In the final installment of his four-part series on Active Directory, Richard Charrington leads you through the proper planning for your big upgrade.


In the final part of this four-part series, I will be touching on some of the things you’ll need to consider when you approach the upgrade to Windows 2000 and Active Directory. The main emphasis here is on planning. Do not upgrade with the idea that it is just like another Windows NT upgrade with a few extra benefits. Make sure you draw up a proper plan covering all aspects, from the changes you may need to make to the network to take advantage of the new operating system to the problems that may occur once you begin the first system upgrade. Do not go it alone. Talk about it with other administrators, managers, and even users. Brainstorm to ensure that no rock has been left unturned. Draw up a plan, including a timescale, and make it realistic. Consider replacing or rotating computers, especially servers that are more than two years old.
A guide to Active Directory: DNSA guide to Active Directory: Global CatalogA guide to Active Directory: Objects, classes, and attributes—Oh my
Pre-upgrade considerations
Although it is possible to run Windows 2000 on your network as it is, you’ll probably want to make a number of changes to the physical and the virtual network to get maximum benefit from the new operating system. In this Daily Drill Down, I’ll outline a few of the changes you may want to make, but this is by no means an exhaustive list.

In Windows 2000, clients rely on site information to identify the closest Active Directory server. Because sites correspond to IP subnets, you should place Active Directory servers on each subnet. You should also make sure that all systems on the same logical subnet are connected via LAN hardware. Some routing technologies, such as Proxy Address Resolution Protocol (ARP), can allow systems to be on the same logical subnet but different physical network segments. This setup will trick clients into thinking systems are closer than they really are, so it’s best to stick to standard routing techniques.

Consider creating a new Windows 2000 domain and then bringing in your existing domains once everything looks correct. Just make sure you do not switch the new Windows 2000 domain to Native mode until the last Windows NT backup domain controller (BDC) has been upgraded.

Make sure you have planned your Active Directory structure before you start migrating your network. You’ll be given the option of creating a new tree or joining an existing tree. Obviously, if you’re the first domain in the network to be migrated, you’ll want to create a new tree. If you’re merging multiple domains into a single Active Directory domain, however, you’ll want to join as a child of the existing tree.

Always migrate the Windows NT 3.51 or 4.0 Primary Domain Controller (PDC) to Windows 2000 Server Active Directory first so that users and groups from your current domain are automatically transferred into Active Directory. Before doing this, make sure you force synchronization between the PDC and all BDCs in the domain so the BDCs are completely updated with any recent changes.
If you want to ensure that you have a rollback should things go wrong, consider adding a new BDC to the domain and taking it offline before the upgrade.
Let the upgrade begin
When you begin the setup, the program will detect that a domain controller is being upgraded and will prompt you to install the Active Directory. This process will also give you the choice 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.

As part of the Active Directory installation process, the contents of the Windows NT account database and the SAM are copied into the Active Directory. These objects form the security principals (user accounts, local and global groups, and computer accounts).

Existing clients will interface with the new Windows 2000 domain controller exactly as if it were still a PDC. As long as you have both Active Directory servers and legacy BDCs in operation simultaneously, your domain will function as a mixed mode domain. Mixed mode domains can’t take full advantage of the new Active Directory features because Active Directory must ensure backward compatibility. For example, you can’t use nested groups in mixed mode domains. However, most of the functionality of Windows 2000 is now available:
  • The ex-PDC will appear as a Windows 2000 DC to other Windows 2000 systems and as a Windows NT PDC to older systems.
  • You’ll be able to use this system to create new security principals and to replicate these changes to Windows NT BDCs.
  • Windows 9x and NT clients can use this system as a potential logon server.
  • If this is the only Windows 2000 Server on the network and it goes offline for any reason, you’ll be able to promote a Windows NT BDC to PDC.

Once you’re sure that the mixed mode domain is functioning correctly, you can migrate your BDCs. When all domain controllers have been migrated, you can switch the domain to native mode, reboot the domain controllers, and take full advantage of the new features. Member servers and workstations running earlier versions of Windows will be completely supported and require no changes to interact with Active Directory servers. You’ll realize more benefits by upgrading the member servers as well, but always start by upgrading domain controllers.

Windows NT Workstation clients should be upgraded to Windows 2000 Professional to take advantage of the new features of Active Directory. Microsoft will offer a service pack that will make Windows 95 and Windows 98 clients Active Directory–aware and allow them to participate in Kerberos security.

When you’ve finished the upgrade and have access to advanced Windows 2000 management tools and features, you may want to restructure your domain(s). Needless to say, restructuring isn’t a trivial task and should not be approached lightly. It will require a great deal of planning.

Existing trusts
If this is the first tree, any trusts that existed before the PDC was upgraded will still exist but they will be limited to the explicit one-way Windows NT-style trusts.

If there are several trees/domains, transitive trusts will be enabled to any resource in any domain that is:
  • A native mode domain.
  • A mixed mode domain where all DCs have been upgraded.
  • A mixed mode domain where the domain controller servicing the Kerberos or NTLM authentication request has been upgraded.

Limit administrator access
Many companies have split domains into user domains and resource domains. The reason may be because of the SAM size limitation of 40 MB in Windows NT or because local administration on resources in the domain is desired. In the latter case, explicit one-way trusts to account domains in the organization would have been created to restrict administration to resource domain administrators. If such domains are simply upgraded, a two-way transitive trust will be created between the child resource domain and the parent domain, eventually resulting in all domains trusting all other domains, thus losing the restrictions originally put in place.

To overcome this limitation, consider upgrading using Windows 2000 delegation features. That way you can fine-tune the access rights of domain administrators to the relevant domains (or trees). Remember also to ensure that the domain administrators do not have administrator access to the domain controllers through local accounts.

BDCs cannot be upgraded
As stated earlier, the end result of your domain upgrade should be a Native mode domain. This may not be possible if, for some reason, a BDC cannot be upgraded. For example, you may have an application that must run on a BDC but doesn’t work under Windows 2000. You should be aware of any such problems before you begin the upgrade and take the necessary action. It may be that you can move the errant application to a member server; perhaps you can get the application upgraded to work under Windows 2000 or move the application on to a BDC in a different domain.

The point of no return
Once you’ve upgraded all your BDCs and switched to Native mode, you can’t get back to Windows NT. The switch to Native mode is easy to do, but it’s impossible to reverse because a number of things happen during the switchover:
  • Netlogon replication ceases as Active Directory multimaster replication between DCs comes into force.
  • No new Windows NT domain controllers can be added to the domain.
  • The former PDC is no longer the master of the domain because all domain controllers can perform directory updates.
  • Windows 2000 group types, such as universal and domain local groups and group nesting, are enabled.

Conclusion
In this four-part series, I’ve covered a number of aspects of Active Directory. The addition of Active Directory to Windows 2000 Server is the most significant reason to upgrade your servers. Active Directory combines Windows NT domains with Internet domains and makes them scalable from average company size to large enterprise capability. While the most significant benefit is the reduced cost of ownership, users will directly benefit from the advanced search capabilities of the Global Catalog.

Active Directory is both standards-based and flexible. It is based on the LDAP standard, which has already been adopted by Cisco for use on network hardware and UNIX systems. Any administrator who needs more functionality than is provided out of the box will appreciate the flexibility of Active Directory.

Microsoft wants it to be as easy as possible to migrate to Active Directory. To that end, it has provided wizards to transfer DNS responsibilities to Microsoft DNS dynamic update protocol servers. These wizards automatically import users and groups from legacy Windows NT domains. Finally, Microsoft has made every aspect of Active Directory setup intuitive and GUI-oriented, and Active Directory handles most complexities automatically.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks