Windows 2000 and the Enterprise

7 tips to achieve optimal Win2K performance in an enterprise environment

Industry experts have been discussing what action Microsoft needs to take for Windows 2000 (Win2K) and Windows NT to succeed in an enterprise environment and have focused much of this discussion on how to market Win2K and NT to the enterprise customer. Although my UNIX friends point out that no one questions UNIX's suitability as an enterprise server, they also grudgingly admit that 30 years of aggressive development and use might have something to do with UNIX's acceptance. NT encroached upon the server market incredibly quickly, and both NT's acceptance and Microsoft's high profile led to the press' emphasis on NT's problems instead of its benefits. Negative publicity draws far more attention than positive publicity, so the announcement of a bug that costs a user data receives better press coverage than the announcement of a bug fix.

Microsoft has fixed several technical problems in Win2K that plagued NT 4.0. Memory leaks and forced reboots put a crimp in the acceptance of NT 4.0 in mission-critical, 24 x 7 enterprises. These companies are only a small part of the total OS installed base, but they're high-profile, high-margin, and important to all the vendors in the value chain.

Yet, getting a Win2K or NT system to perform well in an enterprise environment isn't rocket science. I'm not suggesting that a thorough understanding of the technical problems isn't necessary, but rather that a large dollop of common sense will make a Win2K or NT Server enterprise implementation much easier. That said, here are my top seven tips to make Win2K perform at its best in an enterprise environment.

1. Check the Hardware Compatibility List (HCL). The HCL is a crucial component of any enterprise implementation. Remember that every time you add or change a component in your server, the system's dynamics change. In most cases, NT 4.0 works well regardless of hardware, but Win2K will be more selective about the hardware it runs on. You can expect Win2K Datacenter Server (Datacenter) to support only specific combinations of vendor hardware. Although your configuration might meet the installation requirements and work initially, it might not perform well under load. For information about the status of hardware compatibility, see the Microsoft Windows Hardware Quality Labs' Web site at http://www.microsoft.com/hwtest/ default.asp.

2. Don't run legacy drivers. Quite a few available device drivers only sort of work properly. Win2K will work with some NT 4.0 drivers, but if you want to build for reliability, you don't want non-Win2K drivers and artifacts on your system.

3. Don't perform an OS upgrade. You need to perform a clean installation of Win2K, rather than upgrade from NT. Although you might be tempted to take a running system and upgrade it to Win2K, and even though Microsoft fully supports this action, it isn't a great idea.

You can perform the following test that demonstrates why I think an upgrade is a bad idea. Take two identical computers running NT Workstation 4.0 or NT Server 4.0. (You can ghost a system to set up this test.) These systems can even have clean installations of NT 4.0 without applications and user modifications. Now, take a quick baseline survey of the first system by looking at the system's directories and what the directories contain. (An easy way to assess the directories is to redirect a directory scan to a file—dir /s>filename.txt—then save that file somewhere safe.) Next, upgrade this NT 4.0 system to Win2K.

On the second system, wipe out the NT 4.0 installation (or start with a clean disk) and install Win2K from scratch. Now, look at the directory structures of both machines and compare the contents of the winnt and winntsystem32 directories. You can see that these directories aren't the same. The upgraded system contains artifacts of the NT 4.0 installation.

The differences will be even more pronounced on systems with multiple application installations— even if you remove the applications. These leftover pieces from the previous installation can have an unpredictable effect on Win2K and installed applications.

4. Perform a fresh installation of your required applications. Make sure that you run Win2K-compliant applications on a Win2K system. Microsoft has the Win2K logo program in place, so expecting vendors to certify applications isn't unreasonable. Remember that Win2K compatible isn't the same as Win2K ready; Win2K-compatible applications merely support Win2K, and Win2K-ready applications take advantage of Win2K's functionality and features.

5. Supply the appropriate hardware. After you decide which applications you plan to run, you need to size the proper hardware. Attempting to support 100 active Microsoft Exchange Server users on a server that carries the Win2K logo but has too little CPU speed, memory, or hard disk space is an exercise in futility.

6. Use one server per application. In almost all cases, you need to give each server application a separate server to run on. This is true unless the application requires that other server-side applications be installed on the same hardware. Although remote management of many applications (and in some cases, OS management) requires the presence of a local Web server, Microsoft Internet Information Server (IIS) 5.0 in Win2K will support the installation of HTTP services without the addition of Microsoft Transaction Server (MTS) and Microsoft Message Queue Server (MSMQ).

Keep the OS installation as clean and simple as possible. If you expect a significant load on a server, don't install multiple Microsoft BackOffice applications. Although Microsoft sells the BackOffice suite with one server license, putting a bunch of server applications on the same box isn't a good idea unless your level of use is moderate. The client restrictions for Microsoft Small Business Server (SBS) are good rules of thumb for the proper use and recommended client load for one server with multiple applications.

7. Don't mix domain controllers and user applications. Feel free to put your DHCP servers, DNS servers, and management tools on your domain controllers, but don't install applications such as Microsoft SQL Server or Exchange Server on your domain controllers. When you consolidate multiple servers into fewer and more powerful servers, don't mix the applications on those servers. Moving the users of 15 Exchange servers onto 5 Exchange servers is a good idea. Trying to combine Exchange Server with heavily used Web servers isn't.

These tips—based on a few-dozen installation experiences and the feedback from hundreds of readers over the past few years—are just my opinion. My advice boils down to one statement: Keep it simple. Regardless of how technically complex your installation needs to be, reducing the number of potential variables is the only way to end up with a reliable and manageable solution.