If you keep up with the latest developments in the Windows NT 5.0 infrastructure, your head is swimming with a myriad of new terms. You've heard about forests, trees, sites, Kerberos trusts, and Active Directory (AD). But, how familiar are you with NT 5.0 networking? NT 5.0 brings so many new concepts to Microsoft networking that seeing how all the new operating system's (OS's) pieces fit together can be challenging. Of all the questions people ask me about NT 5.0, I hear most often, "What will the new OS mean for my network?" A look at a fictitious midsized network's upgrade from NT 4.0 to NT 5.0 can help answer this question.
Meet BigCorporation
BigCorporation, my fictitious firm, has an NT 4.0 network that includes 19
servers and serves 500 users in three offices. Of the company's 500 users, 250 work at BigCorporation's headquarters in Maryland, 95 work in a branch office in Ohio, and 155 work in a branch office in New York. BigCorporation's network comprises four NT domains in a single master domain model.
The company's administrators manage all user accounts from an accounts domain called BIGCORP (the master domain), and each of the company's offices has a resource domain. The resource domains are MARYLAND, OHIO, and NEWYORK. Each resource domain has a one-way trust relationship with the accounts domain, and each office houses a Backup Domain Controller (BDC) in the BIGCORP domain that handles local authentication requests. Figure 1 depicts BigCorporation's domain structure. Table 1 lists each BigCorporation server's NetBIOS name and explains the server's function.
BigCorporation decision makers chose the single master domain model for their NT 4.0 network because this domain configuration keeps administrative costs down. The configuration keeps centralized control over the accounts database within the company's IS group, because giving each site's administrators account operator permissions in the BIGCORP domain would give them rights over all the company's accounts. But, the configuration's resource domain structure lets administrators at each site perform routine tasks such as backing up servers, starting and stopping services, and rebooting servers. Local administration of the resource domains is more cost-effective than remote administration.
BigCorporation's network uses TCP/IP as the primary protocol. Each office has a Dynamic Host Configuration Protocol (DHCP) and Windows Internet Naming Service (WINS) server, and each office uses two adjacent, private class-C address blocks for servers and workstations. Table 2 lists these subnets. Each resource domain's DHCP and WINS server gives its address to clients in its domain for use as a primary WINS server and gives clients the address of an enterprisewide WINS server in the BIGCORP domain for use as a secondary WINS server. The resource domains' WINS servers are push/pull replication partners with the BIGCORP domain's WINS server. (For information about WINS push/pull replication, see Mark Minasi, "Advanced WINS Features," September 1997.)
Because BigCorporation delegates administration tasks, it decided to upgrade to NT 5.0. AD will let BigCorporation reduce its number of domains from four to one, provide local administrators with administrative rights for user accounts and resources at each site, and reduce the number of servers the network requires. (For more information about AD, see Mark Minasi, Inside Out, November 1997 through February 1998.) BigCorporation uses an eight-step approach to upgrade from NT 4.0 to NT 5.0.
Step 1
Designing the New Infrastructure
NT 5.0 introduces the concept of Organizational Units. OUs are
administrative boundaries in AD that organize user and resource objects. Think of an OU as a directory in a file system and think of the OU's users and resources as files within the directory. You can assign a user administrative rights for one OU's accounts and resources but exclude the same user from administrative rights for other OUs' accounts and resources within the same domain. This flexible account and resource organization contrasts with NT 4.0 organization, in which domain boundaries are the administrative boundaries. BigCorporation collapses its four-domain infrastructure into one domain and organizes the domain's accounts and resources into OUs. Delegating administration becomes straightforward when you can grant separate administrative rights for each OU.
BigCorporation administrators design an NT 5.0 network that consists of three OUs: OU-MARYLAND, OU-OHIO, and OU-NEWYORK. Each OU contains all the user accounts and resources for its office. BigCorporation's IS department defines access control lists (ACLs) for the OUs so that each office's local administrators have permission to reset passwords, reboot servers, start and stop services, and perform backup operations on their OU's objects but not on the other OUs' objects.
"But wait," you say. "Won't rolling the four domains into one domain increase traffic over the WAN?" Microsoft anticipated the possibility of an increase in traffic and borrowed the concept of sites from Exchange and Systems Management Server (SMS) for controlling traffic over slower links. Microsoft defines a site as a collection of computers with a local affinity. A more common definition of site is one or more well-connected subnets. This definition leaves unclear how to determine which subnets are well-connected, but one Microsoft document targets 512 kilobits per second (Kbps--about one-third the speed of a T1 circuit and four times the speed of a full ISDN Basic Rate Interface--BRI--connection) as an appropriate amount of bandwidth for devices within the same site. Microsoft doesn't recommend using links slower than 512Kbps or high-speed links that are too saturated to produce at least 512Kbps of bandwidth to connect machines within an NT 5.0 site. NT 5.0's 512Kbps minimum connection speed for machines within a site is substantially higher than Exchange's current minimum speed (128Kbps) for intrasite connections, but the difference isn't surprising. AD's multimaster replication creates a lot of work within NT 5.0 sites. (For more information about multimaster replication, see Mark Minasi, "NT 5.0 Gets Better and Better--Mostly," December 1997.)
BigCorporation uses the TCP/IP subnets Table 2 lists to create three sites: SITE-MARYLAND, SITE-OHIO, and SITE-NEWYORK. BigCorporation defines each site with a /23 addressing scheme, which translates into a subnet mask of 255.255.254.0. By defining each site's IP address range, BigCorporation ensures that every NT system in the domain can differentiate between other machines in its site and systems outside its site (i.e., systems it has slow connections to). NT 5.0 adjusts replication according to site boundaries to minimize traffic over BigCorporation's WAN links.
NT 5.0 contains a Dynamic Domain Name System (DDNS) implementation that complies with Request for Comments (RFC) 2136. An organization no longer needs NetBIOS names after all its machines have migrated to NT 5.0, so before migrating any systems to NT 5.0, BigCorporation makes sure all its machines have DNS-compliant names. DNS names consist of only the letters A through Z, the numbers 0 through 9, and the hyphen character. (SQL Server systems have a problem with names that contain hyphen characters.) Because BigCorporation's servers will eventually rely solely on DNS for name resolution on the network, the company adds the DNS service to each WINS server before upgrading any machines.
After BigCorporation completes the WINS-to-DNS transition, the company is ready to migrate its network to NT 5.0. Figure 2, page 138, shows the company's NT 5.0 network design.
Step 2
Migrating the Accounts Domain
Because BigCorporation wants to roll all its systems into the BIGCORP
domain, the company starts the NT 5.0 migration in that domain. The first step
in migrating a domain to NT 5.0 is upgrading the domain's Primary Domain
Controller (PDC) to NT 5.0. This upgrade lets you use NT 5.0 administrative
tools to create AD objects for the new infrastructure. To the domain's BDCs, the
new NT 5.0 domain controller still looks like an NT 4.0 PDC
After BigCorporation administrators migrate the BIGCORP PDC, they migrate the domain's four BDCs and the BIGCORP WINS server. The domain name changes from the NetBIOS name BIGCORP to the DNS name bigcorporation.com, and the BDCs become domain controllers.
Step 3
Defining OUs and Sites
After step 2, BigCorporation has a functional AD that consists of the
bigcorporation.com domain. NT 5.0 domain controllers emulate NT 4.0 PDCs and
BDCs, so the company's resource domains continue to function as usual. To begin the resource domain migration, BigCorporation administrators define in AD the OUs and sites they designed in step 1. As administrators migrate the resource domains' servers to NT 5.0, they place users and resources into the OUs and sites they create in this step. After creating the OUs and sites, BigCorporation administrators move the servers that were the three offices' BIGCORP BDCs to the offices' OUs.
Step 4
Migrating Local Domain Groups
Before migrating resource domain machines, BigCorporation administrators
carefully examine how the NT 4.0 network grants access to resources (such as
files and printers) to ensure the network doesn't lose security configurations during the migration. NT 4.0 uses security IDs (SIDs) to identify access control entries (ACEs). As BigCorporation migrates to NT 5.0, it loses the SIDs that define the resource domains' security. If administrators defined security in NT 4.0 using global groups in the master accounts domain or local groups directly on the member servers, NT 5.0 automatically inherits the company's NT 4.0 security structure. But, if BigCorporation administrators used local domain groups in the resource domains to define security in NT 4.0, they need to re-create their NT 4.0 security groups as global groups in the NT 5.0 master domain. They need to test their NT 5.0 security configuration to make sure that the global groups' security works correctly before proceeding to step 5.
Step 5
Migrating Resource Domain PDCs
After configuring OU security, BigCorporation upgrades its resource domains'
PDCs to NT 5.0 and inserts the new domain controllers into AD. This step enables AD's SID tracking mechanism to follow the servers' movement from the NT 4.0 resource domains to big corporation.com. When BigCorporation migrates the resource domains' PDCs to NT 5.0, the BDCs remain NT 4.0 systems, and the resource domains continue to function.
Step 6
Moving Member Servers, Workstations, and Users to OUs
After migrating the resource domain PDCs to AD, BigCorporation moves the
resource domains' member servers and workstations to OUs in
Bigcorporation.com. At the same time, the company transfers user accounts into the appropriate OUs. BigCorporation administrators take this step slowly so they can detect and resolve any security or configuration problems they previously overlooked. When they have moved all the network's resources and user accounts to the new OUs, BigCorporation administrators are almost finished with the migration.
Step 7
Testing Security
Security is an important concern during an NT 4.0-to-NT 5.0 migration. To
make sure the network is working properly, BigCorporation thoroughly tests
network security before turning off the NT 4.0 resource domains' PDCs and BDCs.
Step 8
Shutting Down the NT 4.0 Network
Finally, BigCorporation shuts down all the NT 4.0 resource domains' PDCs and
BDCs. Administrators take this step slowly and keep an eye on the network to
make sure the new network is functioning properly. If everything works fine
after the PDCs and BDCs disappear from the network, administrators need to
switch the network from a mixed-domain environment to a purely AD environment. This switch tells NT 5.0 to rely completely on the multimaster replication protocol and prevents administrators from adding NT 4.0 PDCs or BDCs to the network in the future. Because this operation is irreversible, NT 5.0 requires an administrator to manually initiate the switch.
Prepare for Your Network's Migration
This migration scenario works for BigCorporation's simple, textbook-case
network, but it's not an ideal migration plan for every business. This
eight-step approach isn't the only migration plan open to BigCorporation; it's one of many possible approaches for moving a network to NT 5.0. I've based BigCorporation's migration plan on Microsoft documents and white papers about NT 5.0 beta 1.
Take this migration plan with a grain of salt. Most modern networks are much more complex than BigCorporation's, and Microsoft needs to iron out many details of the NT upgrade. Nevertheless, this simple example will help you think about the basic steps you'll need to take to upgrade your network. You can use this plan to create a framework for your network's migration, then fill in the framework with details when those details become available.
