In-Depth
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.
- By Bill Heldman
- April 01, 2003
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.
Networking
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.]
AntiVirus
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).
Security
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
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.
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.