October 1999

Windows 2000 is Almost Here--Are You Ready?

That long-awaited party guest, Windows 2000, looks like it's finally dressed for the ball. Microsoft's latest estimate puts a ship date for the product, depending on how you define the seasons, in late Fall/early Winter. The hype and anticipation in IT circles has been phenomenal--with everyone clamoring to know where they can get their very own copy of the latest beta release. Even if you don't have a copy of the software yet, there are quite a few things you can do now to plan and prepare your Windows NT network for a smooth upgrade once final software is released. We're going to take a look at those steps in this article. The steps don't have to be performed in any particular order, so tackle them as your time and energy allows.

Examine your current systems

You'll need to check all of your current systems for hardware compatibility. After you've verified that your hardware is supported, you'll need to verify that those same systems meet at least the minimum system requirements. You'll also find that the Windows 2000 Server setup program supports upgrades from Windows NT 3.51 or 4.0 systems.

Hardware compatibility

Many of the problems you'll experience with the Windows 2000 operating system occur because of incompatible hardware. It's important for you to be aware of any hardware in your system that hasn't been tested with Windows 2000 before you install. It makes troubleshooting any problems that occur easier if you know you're using supported hardware. To identify whether or not your system components meet Windows 2000 compliance, check the hardware compatibility list (HCL). Because Windows 2000 is still in beta, its hardware compatibility list isn't included in their main search engine at www.microsoft.com/hcl/. You can get a copy of the HCL in text file format from Microsoft's ftp server at ftp.microsoft.com/services/whql/win2000hcl.txt as shown in Figure A.

Figure A: Use the Windows 2000 Hardware Compatibility List to determine if your hardware is supported in Windows 2000.

Once Windows 2000 is shipped, use the main search engine to locate hardware compatibility information for Windows 2000, along with the other Microsoft products. It's important to note that all your hardware drivers must support only the 32-bit protected mode.

System requirements

After you've verified that your hardware is supported (or have resigned yourself to the fact that you'll attempt to upgrade untested hardware), you'll need to verify that those same systems meet at least the minimum, and hopefully the recommended, system requirements. For the plain-vanilla Windows 2000 Server product on an Intel-based computer, Microsoft is recommending at least a Pentium 166 MHz processor and 64 MB RAM (128 MB recommended). For a Digital-based system, Microsoft recommends at least an Alpha processor with 96 MB of RAM (128 MB recommended). For both platforms, you'll need a 2 GB hard drive with a minimum of 850 MB of free space, plus 2 MB of free space for each MB of RAM in your computer, and a VGA or higher display. In addition, make sure you have a network adapter card for network connectivity, a keyboard, a mouse or other pointing device (still listed as optional), a 12x CD-ROM for a local install, and a high-density 3.5-inch floppy disk drive if your CD-ROM drive isn't bootable. A PCI system bus is recommended.

For a more detailed analysis of hardware needs for various business situations, you can download the PC 99 System Design Guide (for general Windows 2000 systems and peripherals). This is available at www.microsoft.com/hwdev/desguid.htm

Upgrade support

The Windows 2000 Server setup program supports upgrades from Windows NT 3.51 or 4.0 systems, as shown in Figure B.

Figure B: This shows the Windows 2000 Server upgrade paths.

If you have existing Windows NT 3.51 or 4.0 Workstation or Server systems, you can upgrade these directly to Windows 2000 Server. If you have earlier versions of Windows NT that you want to upgrade to Windows 2000, you'll first need to perform an upgrade to Windows NT 3.51 or later.

Figure out what this Active Directory thing is

The Active Directory (AD), by the way, is the single most significant new feature of Windows 2000. It's the directory service provided with Windows 2000. A directory service, in general terms, is a database that stores information about objects of interest in a particular environment combined with a method for accessing that information. In your Windows 2000 domain environment, these objects of interest include users, groups, printers, shared folders, and so on. The AD enables access to all objects and resources in a Windows 2000 domain environment. In addition, the AD also provides a wide variety of other services, such as a single point of logon and authentication for users, a central point of management for administrators, domain security, and enforcing domain policies.

You use AD domains and container objects called Organizational Units (OUs) to organize resources in a manner that defines the logical structure of your business. For example, in the zdu.com domain, shown in Figure C, you could create OUs patterned after your business units of Sales, Marketing, and Publishing. Each OU would contain the resources (users, groups, shared folders, printers, and so on) that belong to that business unit.

Figure C: Use organizational units to mirror your company's organizational structure.

The AD will have an enormous impact on your organization and how you structure and use your enterprise's resources. Microsoft's Exploring Active Directory Web page, located at http://www.microsoft.com/WINDOWS2000/guide/server/features/activedirectory.asp

groups the AD information that's available through Microsoft's Web site to create Microsoft's one-stop source for information about the Windows 2000's AD service.

Here you can learn more about how the AD centrally manages network users, applications, and devices. It's the Microsoft-designated place to find AD technical and deployment resources, comparison information, and evaluation tools. So, check it out!

Learn DNS inside and out

The Domain Name System (DNS) is a system of name resolution that's used on the Internet. The AD uses DNS as its method for naming and locating all AD objects. This means that all AD domains and the objects they contain must conform to DNS naming rules. (Examples of typical AD DNS domain names include microsoft.com, ziff-davis.com, and zdeducation.com.) In an AD domain, the domain controllers (DCs) are Lightweight Directory Access Protocol (LDAP) servers. DNS and LDAP work hand-in-hand; DNS enables clients to find the servers that host the AD (an LDAP directory), and then the AD (LDAP) server enables clients to find objects within the directory. Because LDAP communicates via the TCP protocol, networks that support AD domains must use the TCP/IP network protocol.

In order to install the Active Directory service and create a Windows 2000 domain, you must have a DNS server set up on your network. Conveniently, Microsoft has included DNS server software with the Windows 2000 Server product. While your DNS server doesn't have to be Microsoft's, it does need to support RFC 2052. Microsoft also strongly recommends that it support dynamic updates as described in RFC 2136.

Microsoft's DNS server is RFC 2052-compliant and supports Dynamic DNS (DDNS). One of the things that RFC 2052-compliant servers support is the SRV record. SRV records are needed to identify the AD DCs (and servers hosting other types of services) within the DNS database.

Dynamic DNS means that DNS clients can register their own resource records with the DNS server; in other words, you no longer need to manually create and administer every individual record in a DNS database! This is critical in the AD environment because of the enormous complexity of creating all the SRV records and related A records (host records) required to properly identify AD DCs and their domains. In addition, all AD client computers in your network must be DNS clients.

If you don't have DNS running already, you can set it up on your Windows NT network. You must apply to the Internet Network Information Center (InterNIC) for a domain name for your organization. Getting DNS implemented on your NT network will help you learn the ins and outs of DNS before your network and critical processes are relying on it.

Implement the TCP/IP protocol

TCP/IP, also called the Internet Protocol, is the native protocol in Windows 2000. It's the required protocol for Active Directory communication. Windows NT includes the TCP/IP protocol as an optional protocol. If you haven't got it running on your NT network, implement it now. You'll need to apply to the American Registry for Internet Numbers (ARIN) to obtain a valid Internet network address from the Internet Assigned Numbers Authority (IANA). You'll also need to decide if you'll assign addresses to each and every one of your computers statically, or assign them dynamically with Dynamic Host Configuration Protocol (DHCP).

ARIN can be reached at http://www.arin.net/.

If you don't know much about implementing TCP/IP and TCP/IP services such as DHCP, WINS, and DNS, now is the time to sign up for a course on it.

Ziff-Davis' online learning center, ZDU, offers courses on implementing TCP/IP in a Windows NT 4.0 network. You can reach their site at http://www.zdu.com/.

There are also many books on the subject available at your local or online bookstore, or through MS Press. Trust us, it will be well worth your time to have TCP/IP running successfully on your network prior to upgrading to Windows 2000.

Plan your AD structure

Much of your migration strategy to Windows 2000 will depend on the domain model and network topology you currently have implemented. In Windows NT 3.51 and 4.0, your network structure is based upon one of four domain models: single domain, master domain, multimaster domain, and complete trust. These domain models are explained in detail in "NT Domains: which model is right for your network?" found in the February 1999 issue of this journal. Windows 2000, however, bases your network structure around the Active Directory. When planning your Windows 2000 AD structure, give careful thought to planning the following three components: sites, DNS namespace, and domain trees.

Plan your site structure

You use Active Directory site information to define the physical structure of your network. In the AD, a site is defined as a collection of one or more well-connected IP subnets. The purpose of sites is to optimize replication traffic over slow network links and to assist clients in finding domain controllers that are closest to them. With this in mind, it's important to combine only IP subnets that share inexpensive, reliable connections of more than 512 KB/sec when planning your Active Directory sites. For example, as shown in Figure D, combine direct physical connections within a single building or floor, rather than subnets that are separated by distance and connected by slower or less reliable WAN links.

Figure D: When planning your site structure, place separate physical sites into separate AD sites.

To start planning your site structure now, gather a map of your IP subnets and the links between them. Use the map to determine how many sites you'll need to optimize AD replication, and identify which subnets will be in each site. If you don't have a map of your IP subnets or one that shows the links between your subnets, start drawing!

Plan your DNS namespace

One of the first decisions you'll need to make about your DNS namespace is whether to extend the external DNS domain name you currently have from InterNIC or to create a new domain name for internal use only. Some of the benefits of extending your external domain name are:

• Consistent resource names for internal and external networks
• Users can access both internal and external resources with one user account
• No extra cost for registering and maintaining a second domain name
• Can make internal resources available externally through the Internet

• Clear distinction between internal and external resources
• Resource management for internal and external resources is separate
• Simplified configuration for proxy and browser clients

If you're going to extend your external domain name to create a single Windows 2000 domain, in many cases the simplest way to accomplish this is to use the existing Windows NT 3.5x or 4.0 NetBIOS computer and resource names and append them to your DNS domain name. This creates a fully qualified domain name (FQDN) for the computer or resource, as shown in Figure E.

Figure E: Create FQDNs by appending the NetBIOS name to a DNS domain name.

For example, a computer in your organization with a NetBIOS name of judik appended to your DNS domain name of zdu.com would be identified in the AD as judik.zdu.com. This approach requires that your NetBIOS names be DNS compatible. DNS names can contain the letters A-Z, numbers 0-9, and the hyphen (-) character. DNS names aren't case-sensitive. An alternative to appending your existing NetBIOS names to your DNS domain name would be to create a whole new naming scheme for hosts. If you do create a new namespace, try to follow these guidelines:

• Limit the number of domain levels to no more than three or four levels. For example, judik.sales.us.zdu.com.
• Use standard DNS characters.
• Use unique names. Each object's fully qualified name (FQN) must be unique throughout your entire DNS namespace.
• Avoid lengthy domain names. By using up your 255-character limit with long domain names; it limits your ability to add subdomains at a later time if you need them.

Plan your domain tree

In Windows 2000 Server, the AD is scalable--meaning that it can accommodate many more objects (users and resources) than in previous versions of Windows NT. This is great news for system administrators! Gone are the days when you had to set up intricate domain models containing master and resource domains with complex one-way trust relationships to accommodate a large number of users and resources. In Windows 2000 networks, you can join multiple Windows 2000 domains together into forests and trees all linked by transitive Kerberos trusts. A domain tree is any group of Windows 2000 domains that share a contiguous namespace, a common schema (the entity that defines all the possible objects, attributes, and values that can exist in the AD database), site configuration, and Global Catalog (an index of the most-used objects and attributes in the AD). An example of a domain tree is shown in Figure F.

Figure F: Here's an example of a domain tree.

A forest is a group of AD domain trees that share a common schema, site configuration, and Global Catalog. The domains in a forest don't have to share a contiguous namespace. An example of a forest is shown in Figure G.

Figure G: This is an example of a forest containing multiple domain trees.

The AD's flexible structure enables you to implement any of the following structures:

• A single domain with organizational units representing various areas of your business
• Multiple domains representing various areas of your business in a single domain tree
• Multiple domain trees with non-contiguous DNS namespaces joined together in a forest

Centralized model

A centralized model consisting of a single domain that contains OUs is one of the simplest Windows 2000 domain models to administer. This model creates a minimal amount of domains, while enabling administrative control to be assigned to the individual OUs. Resources are assigned to each OU and control over these resources can be maintained at the domain level or given to administrators at the OU level.

You should consider implementing a single domain model with OUs in Windows 2000 if you prefer to keep all company resources within a single domain, yet want the flexibility to organize resources around your company's business structure. You should also choose this model if you want to keep centralized control over domain resources, while enabling some administrative control to be delegated to the individual business areas, or if you predict that your organizational structure will evolve over time. Because OUs are logical containers in the AD, they're more easily re-organized than domains in a domain tree.

Distributed model

You have two choices for a distributed administration AD model. One option of a distributed domain model consists of a single domain tree containing multiple domains that represent geographic locations. This option may be preferable to you if your company has geographically diverse locations. This distributed domain model enables you to move your Windows NT 3.5x or 4.0 master and resource domains to domains that represent geographical locations. You should consider implementing a single domain tree model with individual domains in Windows 2000 if you have a decentralized organization with different administrative groups for each area; have an organization that includes several countries and want each country's resources administered in its native language; or have slow WAN links between office locations where AD replication traffic would put too great a burden on your network.

The second option for a distributed administration AD model consists of several domain trees combined into a forest. This model, which is typically organizationally structured compared to the geographically structured option described previously, allows companies that have separate and distinct business units or subsidiaries to maintain separate DNS namespaces, yet take advantage of the Kerberos trust relationship between domain trees in a forest. You should consider implementing a forest model with individual domains in Windows 2000 if you have separate business units with different existing DNS namespaces; have business units or subsidiaries that you might want to sell; or acquire another company that has an existing DNS namespace already in place.

Examine your current Windows NT domain model

Take the time now to examine your current Windows NT domain model and administrative model. Determine whether you'll migrate your existing model to a centralized AD model using OUs, or a decentralized model with multiple domains in a domain tree or multiple trees in a forest. Remember, this is the perfect opportunity to restructure your network to match your business needs! You could even go so far as to create a draft sketch of your new Windows 2000 AD structure. Include your AD domains, any OUs, and your DNS names. Overlay your sites onto the AD domain structure. Indicate where the objects from your current Windows NT domain will migrate to in your new Windows 2000 AD structure.

Conclusion: a stitch in time saves nine!

Taking the time to implement and become familiar with some of the Windows 2000 components that are available in Windows NT and performing the extensive planning steps outlined in this article could make the difference between a successful and productive AD structure for your business and a failed one. It's also better to learn and experiment now before your mission critical systems are relying on your Windows 2000 expertise!

Copyright © 1999, ZD Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD Inc. Reproduction in whole or in part in any form or medium without express written permission of ZD Inc. is prohibited. All other product names and logos are trademarks or registered trademarks of their respective owners.