Step 7: Inventory, Schedule, and Budget
Most seasoned NT users won't be surprised to learn that the new technologies in Win2K are likely to add to system-resource requirements, and thus increase the price of Win2K systems. The base recommended memory configuration for Win2K is 64MB for workstations (it's more like 96MB for servers). If you're keeping score, this requirement is about three times the minimum recommended configuration for a comparable NT 4.0 system. Win2K's disk space requirements will probably see even greater increases, particularly if you implement IntelliMirror client-side caching features.
You aren't obliged to install Win2K on every workstation and server on your network. However, you'll probably want to migrate as many machines as possible to Win2K because you can't take advantage of many of Win2K's coolest features, such as multimaster replication, until you've migrated the last non-AD client. Therefore, begin the process of deciding when your organization will be financially, logistically, and politically ready to begin deploying Win2K, and don't forget to factor migration costs into the budget. Some companies plan rollouts on a percentage basis: X percent by this date, Y percent by this date, and so on until they've migrated 100 percent of the organization. Committing to a deployment time frame now is important because the migration process might be lengthy and involved, and creating a budget will be difficult without a migration schedule.
To begin budgeting, you'll need baseline hardware requirements (i.e., what each machine in your organization needs to set up a baseline Win2K configuration). This requirement means you need a current hardware inventory and a recommended minimum Win2K requirements list tailored for your organization's needs. To create the inventory and a requirements list, you can employ a network inventory package.
Although every network's minimum Win2K hardware requirements differ, you can keep in mind a few baseline figures when planning your Win2K migration. For Win2K Professional (Win2K Pro) workstations, you'll need at least a Pentium Pro or Pentium II-based system or better with a minimum of 64MB of RAM and a 4GB or larger hard disk. You won't need that much space to install Win2K, but 4GB is a realistic minimum figure for a hard disk that holds the OS, local profiles and application support files, and data that users store locally. However, a full installation of Win2K Pro and a local installation of Microsoft Office 2000 on a 4GB hard disk will feel crowded.
For servers, don't even think of installing Win2K on less than a Pentium II system with 128MB of RAM, and use a SCSI-based disk subsystem to minimize CPU utilization and maximize performance. Microsoft provides 128MB of RAM as a baseline figure for a very basic Win2K file server. For domain controllers, application servers, and services providing numerous networking services to users, 256MB is a more realistic starting figure. The correct amount of memory depends on the server's role and the various applications it will run.
These numbers are baseline figures rather than totals, so add the appropriate requirements for each application you plan to run. To assist you in assessing your hardware requirements, run the Win2K beta in a preproduction test environment as I mentioned previously.
Action Plan:
- Inventory your network to determine each system's current hardware and software.
- Assess your baseline Win2K workstation and server configurations based on Win2K's minimum recommended configurations and the specific needs of your users.
- Determine a deployment schedule, begin the process of budgeting for the migration and upgrade installations you'll require to deploy Win2K on your network.
Step 8: Start Using the Zero Administration Kit (ZAK) Now
Total cost of ownership (TCO) has become an important concept in the industry, and Microsoft has responded by developing the Zero Administration for Windows (ZAW) initiative, a set of core technologies to make the administration and control of user workstations simpler and more automatic. The first phase of ZAW is available now in ZAK for NT 4.0, Terminal Services, and Win9x. (For more information about ZAW, see Darren Mar-Elia, "Zero Administration Kit: The Answer to Your TCO Woes?" January 1998).
ZAK presents numerous important features that Microsoft will fully integrate into Win2K. You can use MMC snap-ins to manage these features in Win2K. However, you don't have to wait until Win2K ships to reap the benefits of these new features—you can download the NT 4.0 version of ZAK from Microsoft's Web site (http://www .microsoft.com/windows/zak).
Action Plan:
- Download ZAK for NT 4.0, and start learning about ZAK's features. You can also download a self-paced ZAK training kit.
Step 9: Obtain an Object Identifier (OID) for Your Organization
One of the most interesting features of Win2K's AD is its extensible schema. This feature means you are free to customize your AD structure by defining new object classes and attributes that you can store inside the directory. Although most organizations won't need this feature, it might be useful to developers and administrators who want to tailor their AD structure to their organizations' needs and extend the structure to incorporate new information and network services. However, schema modification can jeopardize the stability of your Win2K network. A special management snap-in for the MMC comes with Win2K to facilitate management of AD's schema.
One gotcha with schema extensions is that you must acquire a special number called an OID for each new attribute or class you define. An OID is an assigned number that identifies an object class or attribute within AD. Like IP addresses and DNS namespaces, issuing authorities within a country assign OIDs. In the United States, ANSI is the issuing authority for OIDs.
An OID is in the form of a dotted decimal string (e.g., 1.2.3.4). Organizations and individuals obtain a root OID from the issuing authority in their country, then divide the assigned OID into additional branch OIDs for use within their directories. For example, Microsoft has a root OID of 1.2.840. 113556, which the company has broken down into multiple branch OIDs for different uses (e.g., one to allocate OIDs for AD classes, another for AD attributes) within Microsoft's AD.
You can apply now for your organization's OID, which will save you time later, when you'll be busy migrating your entire network to Win2K. Visit ANSI's Web site (http://web.ansi.org/ public/services/reg_org.html), or send an email request to the OID contact person at mmaas@ansi.org.
Action Plan:
- Determine whether modifications to the AD schema will be necessary for your organization. You must never modify your AD schema unless absolutely necessary, because doing so can jeopardize the supportability and stability of your Win2K network.
- Obtain your organization's root OID from ANSI. You pay a one-time registration fee for the OID.
Step 10: Plan for a NetBIOS-free Universe
Believe it or not, Microsoft designed Win2K to free you from the bondage of NetBIOS. Because AD uses a DNS-based naming architecture rather than a NetBIOS-based one, Win2K theoretically can let you have zero NetBIOS traffic running on your network. For TCP/IP purists and those of us who detest the load NetBIOS traffic places on our networks, this concept is welcome. However, eliminating NetBIOS from your network won't be as easy as it sounds. Many, if not most, current Windows utilities and applications rely on a NetBIOS API layer to function (e.g., even simple commands, such as the NT Net commands, require NetBIOS).
To completely remove NetBIOS from your network, you must first eliminate all machines that use NetBIOS naming (which means they must join the Win2K network as AD participants) and all applications that require NetBIOS. Don't pull the plug on NetBIOS until you've used your existing applications to thoroughly explore the ramifications of doing so in a test environment. The good news is that you can continue to run NetBIOS on your Win2K network until you've upgraded all your clients to use AD and until you've eliminated all NetBIOS-based applications.
Action Plan:
- Begin removing NetBIOS-dependent applications from your network. Replace your legacy NetBIOS applications and utilities with AD-enabled ones as they become available. Although you don't have to remove NetBIOS to deploy Win2K, doing so will create a more efficient network environment, and one that leverages AD more effectively.
And Keep in Mind
If you follow the steps I've outlined, your company's migration to Win2K will be about as smooth as anyone can make it. Here are some additional pointers to help you move easily to Win2K. First, Microsoft recommends that you install or continue to run WINS throughout the Win2K migration process. According to Microsoft, running WINS during your migration will make it go much more smoothly. In addition, Win2K includes an improved version of WINS that addresses many of the problems that plague NT 4.0 WINS. As a result, managing your enterprise NetBIOS namespace under Win2K will be easier than it has been.
Second, do at least one complete dry-run migration before your live deployment of Win2K. A good way to do this dry run is to create a test environment that duplicates your network environment as closely as possible. For example, you can restore a backup of your domain controllers onto test machines and set up an array of test workstations to represent your user workstations. Then perform a sample migration and create your AD structure. If you're running in a WAN-based environment, obtain some figures on the total bandwidth utilization of your new network to compare it with your previous configuration (and to ensure that you haven't exceeded the capacity of your links). You can do this checking with Performance Monitor or a network monitoring utility such as the Network Monitor, which comes with Microsoft Systems Management Server (SMS). Although Win2K should create less traffic on WAN links than earlier versions of NT did, if you run a mixed Win2K and NT 4.0 domain environment you might increase the overall bandwidth utilization on your network—a situation you'll want to watch out for.
Finally, keep up-to-date with all the changes that occur during the development of Win2K. One lesson I've learned from previous Microsoft beta cycles is that new features or product revelations appear out of nowhere. Such is life in the brave new world of NT evolution.
EDITOR'S NOTE:
This article updates the version that appeared in the February 1998 issue of Windows NT Magazine.
Corrections to this Article:
- "10 Steps to Prepare for Windows 2000" states that you can't take advantage of many of Windows 2000's (Win2K's) coolest features, such as multimaster replication, until you've migrated the last non-Active Directory (AD) client. The correct statement is that you can't take advantage of many of Win2K's coolest features, such as Group Policy Objects (GPOs), with non-AD clients. We apologize for any inconvenience this error might have caused.