10 Steps to Prepare for NT 5.0 Now

Anxiously awaiting Windows NT 5.0? By now you're probably intrigued by the rich and impressive features this new version of NT promises: the Active Directory (AD), the incorporation of Windows-based Terminal Server (formerly code-named Hydra), 64-bit Very Large Memory (VLM), IntelliMirror, the Microsoft Management Console (MMC), Plug and Play, and Windows Driver Model (WDM) support, to name a few. Perhaps you're assuming that, as in the past, Microsoft will make the migration process easy and painless: You'll just buy the software, install it, and be on your way rejoicing. If that's your fantasy, think again.

Because the next version of NT promises to be as revolutionary as it is evolutionary, the new technologies will affect your network and your life as an administrator in several ways. To begin, you'll need to do more planning for NT 5.0 than for any previous upgrade. Fortunately, you can start today to prepare for your migration to 5.0. This article will discuss several NT 5.0 migration issues and recommend specific steps you can take to be ready for NT 5.0 when it arrives.

STEP 1
Prepare Your Domain Structure for AD
The most important aspect of the NT 5.0 rollout is the migration of your existing domain structure to NT 5.0's AD. The complexity of this process depends on your network's architecture. If you have a single-domain model (perhaps with local Backup Domain Controllers--BDCs--at remote sites for quicker logons and access to local network resources), the process of migrating to AD will be fairly straightforward, and AD will give you new options for further optimizing the administrative structure and network traffic of your existing domain model. But if you've implemented a complex multidomain model with decentralized administration, your planning process will be more involved.

Because of the limitations of NT 3.x and 4.0 domain architecture, many organizations have implemented multidomain models that use centralized administration (e.g., master domain or multiple master domain models) and centralized account domains with remote-resource domains. Such designs may fit an organization's administrative structure, particularly if IS staff are in one central location. But in other organizations, this design does not fit administrative structure. Those organizations implement multidomain models more to avoid complete-trust models (with their inherent multiple one-way trust relationships and resulting administrative burden) than to accommodate the needs of the organization.

NT 5.0 will change this complexity. An organization will be able to choose from a wide variety of multitiered network designs that it can fashion around any number of criteria, such as its organizational model, geographical layout, or a combination of the two. Furthermore, if you've had to create master or multimaster domain models to minimize the administrative hassles of placing user accounts into multiple domains, AD will let you move those accounts safely back to the domains in which they belong.

Granularity is the key. NT 5.0 enables these possibilities because of its granular design. NT 3.x and 4.0 group administrative entities (e.g., Administrators, Server Operators, and Backup Operators) into a limited number of global groups with a generic set of administrative rights, but AD will let you set administrative rights down to the individual permission level. This structure means you can easily assign user accounts in particular domains the amount of access they require to administer their local office, and you can do so without compromising the overall security or design of your network. You no longer have to choose between administering these resources remotely or assigning second-level administrators into a limited set of stock account groups.

AD's granularity has benefits that extend into other areas of administrative life. For example, you can use AD to assign particular user or group permissions to particular applications, as well as to traditional resources such as file and print shares. The ability to assign permissions to applications is leveraged by Zero Administration Kit (ZAK), a preview of Zero Administration for Windows (ZAW) that is available now. (For more information about ZAK and ZAW, see "Related Articles In Windows NT Magazine" on page 114.) By breaking permissions and rights down to a more detailed level, AD lets you tailor your directory to fit your organization's structure and administrative requirements.

Preparing for life in AD. What can you do now to prepare for life in AD? If you administer a multidomain environment, consider the advantages of flattening (i.e., consolidating and reducing) your multidomain structure before the arrival of NT 5.0. Flattening your structure will make room for a simplified AD design, and you can undo some of the kludges you may have been forced to introduce into your network design to accommodate your organization's administrative needs. I know what you're thinking: Won't that step mean reinstalling domain controllers? Believe it or not, it doesn't have to.

FastLane Technologies has designed an impressive new product named Phoenix. This domain reconfiguration tool performs the feat of automating migration of user, group, and computer accounts from one domain into another. Automating migration lets you migrate a multiple-domain environment into a single- or multiple-master environment in either a piecemeal or wholesale fashion. Phoenix's six-stage migration process systematically copies the user account, global group, local group, access control lists (ACLs), user rights, and computer accounts from the source domain into a target domain. When the migration is complete, users can log on to the new domain without even knowing that their accounts were moved. If problems come up during the transition, however, users can log on to the source domain, because Phoenix has copied the information--it hasn't merely moved the information. (Screen 1 shows Phoenix's main display.)

Phoenix is impressive and could prove invaluable if you want to simplify your organization's domain structure before an NT 5.0 migration. For additional information on Phoenix, check out FastLane's Web site (http://www.fastlanetech.com).

To facilitate the flattening process, AD contains an important new feature, the Organizational Unit (OU), that makes categorizing your organization easy, even within a single domain. You can subdivide your organization into OUs in any way you want and later promote each OU to a full-blown domain within your organization's namespace--all with little or no effect on the users or resources within the OU. When you use the OU feature, you don't have to create multiple domains to divide your organization into separate, logical subdivisions.

Keep in mind that although domain flattening may be appropriate for some organizations, it isn't appropriate for all organizations. For example, if you want to separate your organization's divisions into separate domains under AD, you will want to retain your existing master or multiple-master domain structure until migration. Another reason for you to retain your existing domain structure as you migrate to NT 5.0 is that AD supports transitive trusts. In a transitive trust, the established trust (domain A trusts domain B and domain B trusts domain C) also means that domain A trusts domain C (see Figure 1 for an illustration of this trust arrangement). NT 3.x and 4.0 did not support transitive trusts; thus administrators were required to create additional trust relationships to establish a relationship between domains not related through established trusts. Obviously, you'll have fewer headaches creating multidomain security relationships under NT 5.0 than you're experiencing with NT 3.x and 4.0.

Finally, NT 5.0 can migrate any domain structure you have established, so flattening will not be necessary unless it will benefit your AD architecture. But remember that if you analyze your existing domain structure and compare it to what you might want to implement later under NT 5.0, you can start planning an effective and appropriate directory structure for your organization today. If you decide to modify your domain structure before your NT 5.0 migration and want to minimize the effects of a change in domain architecture on your users, consider implementing the modifications immediately before you introduce NT 5.0. Then you won't have to deal with a problem-filled interim period between the flattening process and the arrival of NT 5.0.

The forest for the trees. NT 5.0's AD design integrates the concepts of forests and trees (for details, see "Related Articles in Windows NT Magazine," page 114). A tree is a group of NT domains in AD that form a contiguous namespace and share a schema. For example, assume a domain named bigcorp.com exists in your AD structure. The two subdivisions of bigcorp.com are europe and us, and us has a subdivision called sales. Within AD, the names of these domains would be europe.bigcorp.com, us.bigcorp.com, and sales.us.bigcorp.com. This arrangement demonstrates the hierarchical structure of AD and its namespace: These domains are all part of one contiguous, related namespace in the directory; that is, they form one domain tree. The name of the tree is the root level of the tree: In this case, bigcorp.com. See Figure 2 for an illustration of this single-domain tree.

Let's take this concept to the next level. Assume that, within your AD, a parent organization oversees bigcorp, and this parent organization owns another subsidiary, called bigbiz, which is listed in AD with bigcorp. One subdivision, us.bigbiz.com, is beneath bigbiz in AD. Although your company wants both bigcorp and bigbiz defined in the same AD for administrative reasons, you don't want them to share a namespace. So, you define bigcorp and bigbiz as separate trees within the same forest (see Figure 3, page 111, for an illustration of this arrangement). All trees in a forest share a schema, configuration, and Global Catalog. Furthermore, all trees in a forest trust one another because of the transitive, hierarchical Kerberos trust relationships that AD is structured on.

To plan your organization's AD structure and namespace effectively, you can read two Microsoft white papers: "Migrating from Microsoft Windows NT Server 4.0 to Windows NT Server 5.0," and "Windows NT 5.0 Namespace Design." Both papers and others relating to NT 5.0 migration issues are available on Microsoft's Web site (http://www.microsoft.com/ntserver/guide/nt5_pdcwp.asp).

Action Plan:

• Learn about AD, and download the Microsoft NT 5.0 white papers.
• Start planning your AD structure.
• If appropriate, flatten and consolidate your domain structure.

STEP 2
Standardize Your Network on TCP/IP
TCP/IP is the future of networking, and it has become the network protocol of choice for NT 5.0 because it provides a uniform platform that supports many different operating systems. TCP/IP is the only protocol NT 5.0 installs by default during clean installations (legacy environments may still implement NetBEUI and IPX/SPX). This situation means that one of the best things you can do to prepare your organization for NT 5.0 is to standardize on TCP/IP as your primary (preferably sole) network protocol. Standardizing on TCP/IP as your primary network protocol will give you an additional benefit: Because TCP/IP is a highly efficient, routable protocol, you won't hit the types of bandwidth and usability ceilings that occur with NetBEUI (which is nonroutable) and IPX/SPX (which, although it's routable, has higher overhead than TCP/IP in WAN environments).

If you haven't already implemented TCP/IP on your network but will do so before your NT 5.0 migration, you must address NetBIOS-to-IP address-name-resolution issues. You can address these issues by deploying either Windows Internet Naming Service (WINS) or Domain Name System (DNS) servers (I'll discuss DNS servers in Step 3) or by using a centralized LMHOSTS file to resolve names. In addition, if your network is connected to the Internet, you must create an appropriate firewall to protect the network against intruders.

Get on the TCP/IP bandwagon now rather than later. TCP/IP can be slightly more difficult to administer than NetBEUI and IPX/SPX, so if you don't have much experience with TCP/IP, begin now to learn about TCP/IP administration. One helpful tool is Microsoft TCP/IP Training (Microsoft Press), a training kit published in July 1997. It's one of many TCP/IP training resources from Microsoft Press. You can find more information about these resources at the Microsoft Press Web site (http://mspress.microsoft.com).

Action Plan:

• Learn about TCP/IP routing and administration issues.
• If you use routable IP addresses, ob-tain an IP address pool from your Internet Service Provider (ISP). If you use nonroutable addresses (e.g., 10.x.x.x, 192.168.x.x, 172.16.x.x, 172.31.x.x), this step isn't necessary.
• Deploy TCP/IP as the primary file and print service protocol within your organization now. If possible, make TCP/IP your sole network protocol to minimize protocol overhead and administrative problems on the network.

STEP 3
Learn the Ways of DNS
Name resolution is central to TCP/IP standardization and deployment. Most current TCP/IP-based NT networks use WINS servers or LMHOSTS files to resolve NetBIOS names to IP addresses. But in NT 5.0, you query AD to resolve names. AD uses a dynamic form of traditional DNS that offers NT networks the best of both DNS and WINS.

In NT 5.0, Dynamic Host Configuration Protocol (DHCP) servers automatically register clients in AD's DNScompliant namespace and automatically unregister them when the DHCP lease expires or is released. As a result, you don't need to manually maintain dynamic DNS zone files, as you do with traditional DNS. Furthermore, dynamic DNS delivers a name-resolution method that is far more scalable and robust than WINS.

Another nicety of the dynamic DNS design is that it unifies the local and global namespaces of Internet-connected NT networks into a single uniform environment. With NT 5.0, you won't have to run two different name-resolution methods on your network, because everything's DNS. Finally, NT's dynamic DNS namespace is automatically stored within and therefore replicated throughout AD, and the consistency that this approach establishes means your DNS namespace will have a level of fault tolerance.

To facilitate your migration to NT 5.0's DNS environment, begin verifying that existing computer and network names within your organization are DNS-friendly. DNS stipulates that domain and host names contain only the following characters: A-Z, a-z, 0-9, and - (hyphen), with no spaces or underscoring. If a domain or a host is using names that don't follow the DNS convention, change the names so that they conform. In the case of workstations, this step probably won't be a big deal. However, in the case of domains or servers, illegal names will have an impact and will require a bit more planning on your part.

Work with the InterNIC (the Internet's name assignment authority) or an ISP to obtain a domain name for your organization if you don't have one (e.g., abc-corp.com, somegroup.org), whether you're connected to the Internet now or not (contact InterNIC at http://rs.internic.net). This task is important because when you migrate to NT 5.0, your AD structure will drive your DNS naming structure. If you have developed a naming structure for your organization that does not conform to DNS standards and you later connect to the Internet, you will have to observe Internet DNS standards and use a name that another organization hasn't already taken. Then you'll have to go through the hassle of renaming your entire organization and all of its domain trees. You can ensure that this hassle doesn't happen by registering DNS domain names for your organization now that will work later if you decide to connect to the Internet. And by acting now, you'll have a better chance of getting the domain name you want for your organization. If you wait, someone else might take the name you prefer.

   Previous  [1]  2  Next