Shall We Dance? Learning the Moves for Windows Server 2003

A solid test environment normally leads to a smooth rollout of a new operating system. Our enterprise expert guides you through the elements you’ll need to consider for setting up your organization’s lab.

As Microsoft’s server products continue to evolve, you’re faced with more rigorous preplanning, project planning and implementation—and lab simulation and testing—than you were in prior releases. In terms of enterprise-class server software such as Windows Server 2003, administrators are technologically far ahead of where they would be in the Banyan Vines or Novell NetWare environments of yesterday or today. So rich (and complex) is the Windows server of the 21st century that you must tread carefully before launching a production installation.

An enterprise test lab is going to require some hardware in the form of servers, switches and routers that closely match production. (If you’re interested in testing Windows 2003’s 64-bit code, you’re also going to need hardware that’s compatible with the new operating system.) Additionally, you’ll want to be sure that you closely emulate the wiring environment; you can’t have a Cat-5 lab and a Cat-6 production environment—it’s not a fair test.

It’s important to try to get close to the kinds of servers you’re running in production so that you don’t run into BIOS or hardware snafus at deployment time. Suppose, for example, that you test Windows 2003 on a workstation-class single-processor computer and it works fine. However, when you get ready to install it on your server-class double-processor box, the setup just doesn’t run right. Where to start with the troubleshooting? You can doubtlessly see the complexity. And, sadly, you might get to the end of the troubleshooting road only to find that your friendly hardware manufacturer hasn’t yet come out with an updated BIOS that will handle the new OS.

Here’s where things get sticky: In these days of budget cuts and shortfalls, it may not be prudent for you to go to your boss and ask for $30,000 for additional servers for a test lab. On the other hand, if you don’t have a fair hardware representation, there are risks associated with a proposed upgrade. Somehow, you’ll have to find a way to balance these risks as best as you can. For those of you who already have a test lab, you’re in better shape.

Test Lab Parameters
I’m not talking here about setting up a little lab at home so you can study for a certification (though you’ll definitely need a minilab at certification study/testing time). When you begin to consider setting up an enterprise test lab that mimics your company’s production setup—first for the purpose of upgrading your network to Windows 2003 and then, after you’re finished, for testing out new networking scenarios—you need to consider the following issues:

Domain Controllers and Servers
You’ll want to closely match the domain controller setup currently running. This means that if you have several domains running in your production forests, you’ll want to get as close to the real thing as possible. Because Windows 2003 includes new cross-forest tools that allow forests to connect more easily with one another, it’ll be important to test these features in a mock environment before deploying them in any production multiforest settings.

All test servers (or some fair representation thereof) should be level-set with the same OS and service packs currently in production. Also, you’ll want to duplicate, as closely as possible, your production applications and services (more on this later). You’re performing an upgrade test, not a new installation.

Production cluster servers need to be emulated and tested. Windows 2003 has beefed up Microsoft Clustering Services (MSCS), so plan on making sure clusters will survive the upgrade.

User PCs
You’ll want some regular client PCs in your test lab that match the kinds of operating systems and applications users currently run in production. These are called reference PCs, and they illustrate where users may get into the weeds with a particular combination. For example, maybe you have an Enterprise Resource Planning (ERP) software deployment in the enterprise to which some user groups need to connect. Keep in mind, though, that setting up reference PCs that tie into large production systems such as ERP might prove an ominous task. You probably couldn’t emulate a PeopleSoft environment in your test lab (a workaround for this is listed below). Note, too, that you shouldn’t perform user testing with Administrative-level access: This doesn’t emulate the experience of the regular Joes and Janes of the user world.

You’ll need to closely copy the production TCP/IP infrastructure. It’s no good to test Windows 2003 on a flat 10-dot network in test when, in production, you have myriad class B networks subnetted on the third octet (/24).

You’ll also want to provide the same kind of production switching infrastructure to duplicate the vLAN, router protocol, spanning tree and subnetting options of your corporate world. Without this, you may deploy in production only to find a problem somewhere. TCP/IP and internetworking issues can be tremendously difficult to pinpoint in production environments, partly because usually some other team handles the internetwork, but also because you tend to suspect something other than the infrastructure.

Also, you may have to consider the perimeter network and DMZ. It consists of a set of servers (or other hardware) that handles the firewalls, Web filtering, intrusion detection and Virtual Private Network (VPN) activity. You might, for example, have a Cisco PIX firewall, Microsoft Internet Security and Acceleration (ISA) Server for your VPN entry-point, Real-Secure for your intrusion detection and something else for your Web filtering component. In addition to your regular cadre of Internet servers (which might include IIS in its various flavors, AOLServer and Apache), you might also have servers and/or hardware appliances running on the DMZ for Web-caching (and possibly even a Google caching server for handling your users’ lunchtime shopping requests). It’s vital to test the new features of IIS 6.0, as they might operate in your current Internet implementation and test on a like-for-like basis with the current setup. [MCP Magazine reviewed IIS 6.0 in the February 2003 issue.—Ed.]

You’ll want to test your current anti-virus infrastructure against the new software. One of Windows 2003’s new features is an antivirus application program interface (API) to which vendors can write. But it will take a bit of time for Windows 2003 Active Directory-aware antivirus software to appear. Your vendor may be speedier than others at delivering new releases. Make sure your systems are protected fully before deploying the new server software.

Remote Connectivity
The communications infrastructure is also important. How do remote users get onto your private network today? VPN? RRAS? Wireless methodologies? Through what hardware or software interfaces? You’ve got to emulate this kind of interaction on the test network, to ensure how things will work in the new environment.

You should have some sort of connectivity to the public network so that any required “huge app” testing can happen on the production system. Here’s what I mean: Suppose you have a large ERP system such as Oracle Financials running on HP Unix big iron. You’d have a difficult time emulating that in a test environment. But you still need to test the client connectivity tools to make sure a user validated in the Windows 2003 environment can connect to and work in the ERP system. While there’s no reason to suspect they won’t work, you’d rather not find out on production-deployment day. In order to facilitate a test, you should have your subject-matter expert users test connecting to the real-life production ERP system. This will require some assistance from DBA types who’ll need to tweak files such as TNSNames.ORA and others like it. Optionally, your company might have set up an ERP test lab you could conceivably connect to, but there may be some logistical difficulties with this (maybe the ERP test lab is in Omaha and you’re in Toledo).

Your security infrastructure also needs to be checked. Windows 2003 still uses AD, with important updates, so you’re not likely to run into many showstoppers in terms of how users authenticate.

That being said, some of the most important updates to the new Windows server software is in the area of security. Goodies such as Software Restriction Policies, enhanced security for 802.11 wireless LANs, and the Credential Manager (among others) might be of huge interest to you. Standard security offerings such as Public Key Infrastructure (PKI) have been beefed up.

File System
Windows 2003 file system management provides enhancements to Dfs and the File Replication System (FRS), as well as new additions such as shadow copies for users (think file version history). All file system elements need to be tested—but only if you already have these things in place. Don’t tinker: Just test how current things will work with the upgrade in place. Included in file system testing should be any production Unix or Linux connectivity.

Printing improvements essentially revolve around making printers more visible, easier to control and the actual printing faster. You’ll want to have a fair representation of the printer farm in your test lab to validate support for updated drivers (which Microsoft says it’s improved). Also, it’s quite important to test mid-level multifunction devices (MFDs) from manufacturers such as Ricoh, Minolta, Xerox and Oce for connectivity. Because these devices (and others of their ilk) require third-party drivers, it’d be a shame to rush a deployment into production only to find that several hundred (or thousand) users can’t print because their MFDs won’t play with Windows 2003.

Name Resolution
Name services are the most vital element of a Windows server environment. If computers can’t resolve a name (NetBIOS or fully qualified domain name) to an IP address, there isn’t going to be any computing going on (not, at least, without some kludge workarounds that will bite you later). Therefore, it’s important to test name-resolution capabilities on the new network.

Lab Exercises
Check out "Lab Exercises for Windows Server 2003" to help get you on your way to using Windows Server 2003's new features.

What Not to Test
I’ve covered the crucial things to test, but there are also things that would be best not to test, as the purpose of an enterprise test lab is to determine how the new OS code will work in your production setup, not to try out new stuff.

Operating System Upgrades
Don’t test cool additions or upgrades to the OS unless they represent something currently running in production. For example, if you don’t currently have Dfs running in production, don’t test it now. Save it for later when you decide you want to get into Dfs. Testing nonproduction features introduces complexities that may skew the results. One exception could be testing 64-bit code on a server you know is currently running 32-bit code, but which you’ve validated can run and would benefit from running the 64-bit stuff. Plan to extend your testing time by a third to compensate for this enhancement.

Application Upgrades
Don’t test upgrades to Microsoft applications now. In other words, don’t decide simultaneously to perform a Windows 2003 upgrade and an upgrade from SQL Server 7.0 to SQL Server 2000. Save Microsoft applications upgrades for later. This caveat also applies to non-Microsoft applications (though you certainly need to test the current production copies of these applications to make sure they’ll mesh with the upgrade).

Consider saving security augmentation capabilities until after you’ve deployed into production and have some time to test the enhanced features. You might be inclined to say, “Cool! We can use that right away!” But exercise caution; no matter how closely you think you’ve mirrored the production environment, something will crop up you haven’t taken into consideration.

Operating Paradigms
Don’t change an operating paradigm while in upgrade mode. Maybe you have a small shop and decide you want to bag your ancient Cisco router for a Windows 2003 software router instead. Now isn’t the time to implement such a change, because you’re introducing too many unknowns.

Process Changes
Upgrade time is the wrong time to introduce process improvements. If you’ve wrestled with a multiple-domain installation since upgrading to Windows 2000 and always hated it, it’s not advisable to consolidate some of your domains at upgrade time.

In general, anything that isn’t germane to the actual upgrade itself and represents an enhancement or paradigm shift probably shouldn’t be considered part of your rollout. The fewer unknowns and complexities you introduce, the smoother the rollout is going to be.

Building the Testing Dream Team
The enterprise-class capabilities of Win2K and Windows 2003 (and associated AD-aware applications) call for project management techniques to make sure deployments cover all the bases. Here are some things to think about when considering how to manage this project:

Get buy-in from the managers who can authorize the resources needed to get the lab going. Managers need to understand that you: a) are considering the upgrade and b) need their approval and empowerment to get it done right. Help sell this by painting a picture of the future benefits of upgrade and app testing. Remember that, generally, they’re thinking bucks while you’re thinking tech.

Formulate a project team consisting of:

 A project leader

 Subject-matter experts who understand the business processes underlying your enterprise

 At least one internetworking expert who can help grapple with infrastructure nuances

 At least one DBA who understands how clients connect to enterprise databases and can help with connectivity issues.

 Application admins who understand the enterprise applications that need to work in this new environment. If you’re not an Exchange expert, you’re going to need one.

 Testers able to assist in the testing of various rollout elements. These may be the subject-matter experts mentioned before or others. This element—user-acceptance testing—is vital to successful implementation. Users need to have confidence in what you’re doing and where the project is going.

 Non-Windows OS gurus who understand Unix, Linux, mainframe and Apple installations in the enterprise. Nothing is more uncomfortable than snapping in
a new upgrade only to find that another OS representation on the network has now snapped out!

Get the Most From Your Lab
Create a project plan that succinctly, but completely, encapsulates the steps you need to take to fully test the upgrade in your lab. Understand the “critical path” of the project (i.e., those steps that have to happen one after the other in order to facilitate completion, vs. steps that can happen simultaneously). Properly managing steps can dramatically decrease the time from test to production.

 Routinely update all individuals who need to know. In project-management parlance, anyone who has something to gain or lose in the project is a “stakeholder.” Robust stakeholder communications are vital to the health of an enterprise-class project like a Windows 2003 upgrade.

 Mitigate risks. Identify risks before lab implementation and testing to help with the “risk mitigation process.” It’s important to spend some time with your team to figure out what might go wrong, then come up with ways to fix them.

 Plan for failure. Good project plans also include a backout set of steps to restore the previous network in case of a failure. Even in an enterprise-class test lab, you’ll want to have backout steps worked out so you can go back to the drawing board in case something didn’t go right.

A well-detailed project plan will assure that you’ve identified the right items to test, thereby shortening the duration between test and production. Those who willy-nilly set up a lab without a plan will suffer from Homer Simpson moments in which they realize they forgot some crucial element. Don’t be a Homer.


comments powered by Disqus

Subscribe on YouTube