How to prepare for Windows 2000
(IDG) -- Just about the time most IT departments will be putting the dreaded Y2K issue behind them, they will encounter the second crisis of the new millennium: the arrival of Microsoft's Windows 2000.
Microsoft has promised to begin shipping the operating system as early as October, but analysts say the software may not be generally available until well into the first quarter of 2000.
Most medium to large shops say they won't implement the operating system until the first Service Pack is distributed. But some companies will begin to embrace it sooner than that for various business and technology reasons. The new Active Directory Service, for example, is attractive because it promises to simplify user account administration and reduce management costs.
For these users, we've prepared a crash course in Windows 2000 preparedness training. What follows is a list of things you can do now to help ease the pain of rolling out Windows 2000 when it arrives on your doorstep.
Top issues to be reckoned with include: Leveling the existing version of NT across your network for a simpler upgrade; ensuring you have the proper hardware; establishing a hierarchy for Active Directory; getting used to Domain Name System (DNS); and prepping for the new management services included with the operating system.
Getting the version right
Microsoft recommends moving from NT 4.0 to Windows 2000. That means if your servers are running NT 3.51 or any earlier version of NT, Microsoft says you'll get a cleaner migration if you move first to NT 4.0 and then on to Windows 2000. There are so many new features built around the NT 4.0 kernel that the transition to Windows 2000 would progress more smoothly from NT 4.0 than from any earlier version of the product, Microsoft says.
We think that you probably will be better off switching to NT 4.0 first, if only to avoid the potential hassles of dealing with Microsoft's technical support staff and its running cash meter should your migration go awry. Windows NT 3.1 and 3.51 users who attempt to move directly to Windows 2000 and run into problems may be forced by Microsoft's tech support to restore affected servers to NT 4.0 before migrating to Windows 2000. So you may not avoid the NT 4.0 step after all, even if you attempt an end run around it.
From a cost standpoint, as an NT 3.X user you may well get hit with a double upgrade fee because you'll have to install NT 4.0 and then Windows 2000. However, Microsoft said it would not comment on upgrading licensing fees until the product ships.
You'll also need to do some version checking when you're switching to Windows 2000 from NT 4.0. When you migrate from NT 4.0, make sure you first load the latest service pack -- Service Pack 5. This service pack changes the NT 4.0 Security Access Manager database, which holds all the information about user accounts and passwords and sets the database up to run under the new Windows 2000 Active Directory structure in tandem with the new Security Manager. This functionality is not available for NT 3.51, hence Microsoft's recommendation for an upgrade to NT 4.0 and the appropriate Service Pack prior to your Windows 2000 rollout.
Beefing up your boxes
While version leveling brings your NT Server software up to par for the Windows 2000 move, you still have to raise the bar for your hardware platforms.
If most of your company's servers are currently running NT 4.0, you might be able to make do with the hardware you have. But there are a few things to consider if you want to get the best performance out of Windows 2000.
The standard configuration for Windows 2000 is basically the same as an NT 4.0 host platform. Officially, NT 4.0 requires 32M bytes of memory, but most users deploy NT 4.0 on file servers with 64M bytes, with midrange servers having anywhere from 128M to 256M bytes. High-end database servers can use 1G byte or more of memory.
Windows 2000 is designed to run on a Pentium-class server with 64M bytes of memory. We recommend 128M bytes because memory is so inexpensive -- a 64M-byte DIMM module costs just $54.
Why pay for extra memory? To guard against "disk-thrashing," or excess disk swapping, for starters.
Engineers at The Tolly Group have launched the Windows 2000 Beta 3 along with Internet Explorer, Microsoft Word and Microsoft Outlook, all of which use a combined total of 94M bytes of memory. Windows 2000 is comprised of almost 40 million lines of code and itself takes up about 50M bytes of memory when it loads. If you unleash that behemoth on a server with only 64M bytes, you'll exhaust your server by just requiring it to swap data back and forth to disk.
Another factor to consider is the processor speed of the server. Pentium II-class servers should support the new operating system without a problem. But servers based on Intel's new Xeon-class processor -- which is available in Pentium II or Pentium III models -- offer an inherent advantage because the Layer 2 cache runs at the same speed as the processor. The Layer 2 cache in non-Xeon class Pentium II and Pentium III processors runs at half the speed of the processor. Moreover, the Pentium-class servers offer only 512K of Layer 2 cache, whereas the Xeon servers offer up to 2M bytes of cache.
While you don't need a bigger cache to run Windows 2000, you may need it for more advanced applications, such as SQL database applications that are designed specifically to take advantage of the larger caches. And if you're bolstering the hardware platform to support a Windows 2000 upgrade, you should consider upgrading the hardware to support your applications mix, as well.
Also, while servers with large caches may help you run advanced applications, servers that employ high-speed caches can reduce the time required for a server to transfer data from the cache to the processor core, which translates into faster processing and higher performance.
Prepping for Active Directory
Active Directory replaces NT 4.0's domain directory model and is the primary reason why many large shops will upgrade to the new operating system.
Microsoft has always maintained that NT 4.0 domains could be intricately woven together into a single hierarchical directory with the help of so-called "trust relationships" between domains. But all too often these trust relationships make for messy administration and confusing domain relationships.
Active Directory promises to erase that mess and confusion and let administrators literally see the forest for the trees. Inside Active Directory, trees are essentially domain structures that share a single namespace. Forests are a set of trees that do not share a contiguous namespace.
By using hierarchical design, and mapping resources in a network tree to DNS names, Active Directory should offer an improved directory structure.
Getting there, though, will be a task unto itself. To some extent, network planners may need to wipe the whiteboard clean and figure out just how to put existing domains into the Active Directory hierarchy, as well as determine how trust relationships of the past fit into the new Active Directory tree. For companies with many domains, figuring out the trust relationships between those domains and their resources can be quite a task, especially if you have user accounts in all of the domains.
This is entirely new ground for NT 4.0 users. Microsoft has issued a series of white papers to offer advice on rearchitecting domains. But these theories have yet to be widely tested in full-scale production environments. For many users with multiple domains, it boils down to a wait-and-see issue -- only when users begin to migrate to Active Directory will they begin to comprehend the magnitude of the changes that must take place.
Factoring in DNS
Any company intent on migrating to Active Directory will also have to embrace Domain Name System. DNS is the Internet service that associates IP addresses with domain names. While Windows 2000 does support the NT 4.0-based Windows Internet Name Service (WINS), Microsoft has tapped DNS as the primary name service. WINS has been downgraded to support legacy applications.
Any NT Server today can support DNS -- you just have to load the service and turn it on. The issue here, though, is how much risk does an organization wish to accept in running DNS?
If your organization isn't running DNS, are you going to wait until your new operating system requires it and face the daunting task of learning both DNS and the new operating system services at the same time? Or will you slowly migrate away from WINS, grow accustomed to DNS and have one less task to worry about six months from now? Shrewd network shops will make the jump to DNS now. If you don't, you're setting yourself up for a lot of pain later.
Let's talk about your options for starting the DNS learning curve.
You can run DNS and WINS in parallel, but you shouldn't let them perform the same function. If Windows is using both services to resolve a host name, you will have a hard time determining which service is being used at any given time.
But you can run the two in parallel if they are each playing to a different audience, so to speak.
Under this scheme, you would deploy DNS to provide domain-name services for all Internet users and to provide name resolution for Unix clients on the network. You would keep WINS in place to offer name resolution for NT clients and servers.
As another option, you can set up a proxy server to handle DNS entries. In effect, you install a default gateway that routes DNS queries to a DNS server located on your ISP's network. Under this scenario, Windows desktops don't interact with DNS at all. When the PC makes an Internet request, the PC performs a WINS lookup and, not finding a match, routes the request on to the proxy server. The proxy server then directs the DNS lookup to the ISP's server.
In this proxy server scenario, once your organization adds Windows 2000 functionality, you turn off the WINS service and utilize local DNS servers supported by Windows 2000.
Another interesting planning issue pertaining to Windows 2000 and DNS relates to Dynamic Host Configuration Protocol (DHCP) servers. If you are using a DHCP server, you may need to make some additional changes on the client side to support DNS. In those instances, you might have to reconfigure those devices by removing a WINS name, adding the DNS name and rebooting each machine.
If your client workstations are statically mapped, rather than set up to receive an IP address from the DHCP server, then you will need to schedule visits to all your client workstations to reconfigure the TCP/IP services.
Handling centralized control
Instead of having several interfaces for each of its NT-based management tools as Microsoft has in the past, with Windows 2000 the company will offer a single, unified interface across all management tools, called the Microsoft Management Console. MMC - which is available now in the NT 4.0 SP5 for administrators to examine - provides a consistent interface to several common tools and utilities.
The idea of a central management console for all server and desktop administration tools is a complete change for NT users and should give managers greater control over more NT resources. For example, instead of creating a user account, you now can create a user object that includes various attributes that help identify where the user account lives in the network hierarchy. This will let administrators centralize all their user data. Currently, in large NT 4.0 networks, user data is distributed across multiple domains. This setup tends to pose costly administrative problems as users move about.
Microsoft's MMC plug-ins - which are management applets that run inside the console - replace many of the old configuration and administration tools that currently ship with NT, such as the User Manager, Server Manager and Event Viewer. Third-party software developers can write their MMC plug-ins so that network administrators can manage these third-party products from inside the centralized console.
Initially, this may cause some confusion because administrators have been using the old interfaces since Windows NT 3.1 was first released in 1994. Instead of having to switch among different tools to do different management tasks, you now have this variety of plug-ins to do all the tasks with one common interface. But early beta builds of Windows 2000 show that the operating system is not completely integrated with some of the new management applications. For example, management of the Active Directory is distributed over three MMC tools.
So, network administrators will need some upfront training. Fortunately, that learning curve isn't as drastic as it might seem. Basically, once administrators launch a management plug-in from MMC, they will encounter many of the old tool-specific interfaces they know -- with just a bit more polish. Lack of luxury
Unlike large corporations that can experiment with Windows 2000 in network labs before rolling it into production networks, many small- to midsize companies don't enjoy that luxury.
Even if your organization can't get its hands on beta code today, there are steps you can take to prepare for Windows 2000. Some of these tasks, such as version leveling and hardware upgrades, are mundane but are nonetheless critical to the overall success of migrating to the new operating system.
Other issues, such as those surrounding Active Directory and DNS preparation, are more complex and require a good deal of education.
Addressing these issues now will put you in a position to smoothly handle the operating system upgrade whenever the Windows 2000 gold code becomes available.
Begin looking at these issues now, and let us know if you think there's more to preparing for Windows 2000 than meets the eye.
Windows 2000: An all-or-nothing proposition Proposition
RELATED IDG.net STORIES:
3 CIOs ponder the move to Windows 2000
|Back to the top||
© 2001 Cable News Network. All Rights Reserved.|
Terms under which this service is provided to you.
Read our privacy guidelines.