In-Depth
Systems Engineering: Test Lab 2000
Setting up a Windows 2000 test lab involves planning, presenting, and documenting. This game plan can help ensure your success.
- By Kevin Kocis
- September 01, 1999
As the final release of Windows 2000 draws near, and
betas populate the eager hands of administrators, the
anxiety to ascend from the mediocrity of Windows NT4 environments
grows rapidly. While the release of Windows 2000 is scheduled
for October 6, implementation planning should begin now.
Windows 2000 is a significant upgrade deserving careful
domain planning; so don’t neglect its impact on your user
community. A testing lab is a critical step in ensuring
your organization’s positive upgrade to Windows 2000.
At first glance, the reason for a test lab is obvious.
Testing, right? No problem. (Dr. Frankenstein thought
it was no problem, either…) But seriously, there are several
reasons for setting up a test lab. First, a test lab provides
non-production impact, the opportunity to test hardware
and software without wreaking havoc on your user community.
This is very important, particularly if you discover your
hardware or software doesn’t function optimally under
Windows 2000. You wouldn’t want to upgrade your manager’s
computer only to find that half of her hardware is inoperable.
Not a great first impression of Windows 2000.
Another reason for configuring a test lab is documentation
verification. Different companies use different software,
hardware, and networking equipment. Under your current
environment, you should have documentation outlining your
setups and configurations. Well, those procedures may
have changed under Windows 2000. You’ll want to verify
whether or not the same instructions apply under a new
operating system. As a direct result, you’ll be able to
standardize configurations and create new documentation.
A Plan of Action
Planning is the biggest key to creating a successful
test lab. Without a plan, controlling and directing your
test lab will prove difficult. The first step is to do
your homework: Research the various aspects of Windows
2000. You can download a significant amount of information
from the Microsoft Web site—everything from the new features
of Windows 2000 to walkthroughs and deployment planning.
Also, research some of the resources available from Microsoft
Press. A multitude of newsgroups focusing on Windows 2000
may identify some of the issues raised by other administrators,
as well as offer some solutions.
The second step in planning is training. Members being
considered for your test team should receive necessary
training at a Certified Technical Education Center (CTEC).
TechNet is another great training resource with features
on Windows 2000. You can find that online or obtain a
CD subscription for a fee. Another option is to subscribe
to various online and local training for Windows 2000.
Just make sure the vendor/provider is Microsoft certified.
The next step is establishing goals. This provides additional
challenge because you need to address your organization’s
goals in addition to your IT goals. Your company’s management
will be eager to hear how your testing lab will relieve
budget pains, lower the total cost of ownership, and increase
availability, reliability, and scalability of the servers
and workstations. Make sure you work with management to
address concerns about your current infrastructure and
devise tests accordingly. Lab goals should coincide with
company goals. Focus on documentation (such as work instructions)
and standardizing protocols and user configurations. In
standardizing user configurations, consider the goal of
creating a standard disk image for your organization (if
you haven’t already) including system policies, user rights,
and administrative access.
After setting your lab goals, develop procedures for
your lab. First, establish a test team including a lead
person who’ll maintain contact with management and present
status updates. Next, create a test plan that includes
methodology, schedule, resources, and pass/fail criteria.
The test plan should include considerations such as lab
location and accessibility, scheduling for inventory and
testing priorities, hardware and software to be used in
the lab environment (don’t forget networking equipment),
and individual assignments. Pass/fail criteria may include
event viewer log information in addition to functionality.
It’s important that all team members understand the procedures
for the test lab. As with all teams, make sure you get
feedback from members regarding lab procedures and have
them help with the test plan documentation.
Next, develop a tracking system for your lab. I suggest
a lab log in the form of a spreadsheet where you can keep
track of your testing progress. You may want to set up
a log at each testing station, describing the current
status of the computer/hardware/software. This way, if
other members of your test team get interrupted, you have
a snapshot of their progress. There are many ways to devise
a tracking system. Make sure you design a system that’s
beneficial to your team.
Establishing a project schedule may be a bit tricky.
Since you really don’t know what kind of roadblocks you’ll
encounter on your lab journey, setting a schedule could
be a bit complicated. Start by prioritizing your lab goals.
Identify which ones are business critical, and begin with
those. Determining if your computer systems are Windows
2000-compliant should also be at the top of your list.
You may need to work with management when prioritizing
(if you haven’t already). When estimating timeframes for
testing, be conservative. Add at least 25 percent to your
approximate timeframes to allow for unforeseen dilemmas.
And don’t be anxious to condense timeframes if you later
find you’re ahead of schedule. You may need the time later
in your testing.
When finalizing your project schedule, build in some
checkpoints and metrics. It’s important to monitor your
progress and be able to present some concrete information
to management. Checkpoints will help you step back and
analyze timeframes and pass/fail rates, as well as logs
and other documentation; they provide a means for creating
metrics from your documentation. If you see, for example,
that half of your hardware or software doesn’t meet the
Windows 2000 criteria, those metrics need to be conveyed
to management as soon as possible. This may affect how
soon your company will be able to upgrade. It’s a good
idea to call a meeting and create a presentation for management
explaining your metrics.
Counting Up Resources
Your current environment will determine hardware resources
for your lab. If you’re part of a WAN configuration, you’ll
obviously need more hardware than a single site configuration
would. Let’s start by looking at some basics. You should
consider the following hardware for a full-blown lab for
a WAN configuration:
- Domain controllers (two)
- Standalone server
- WAN simulator/router
- All clients (Windows 95/98/NT, as well as Macintosh
and Unix)
- Laptops (for mobile and PCMCIA testing)
- Peripherals (printers/tape drives/removable media,
etc.)
Remember, your test lab is representative of your current
environment. Configure your units exactly as they exist
in your user community. Set up a primary and backup domain
controller and a file/print server or Web server and configure
your clients. You may have to subnet your LAN to isolate
your test lab or set up on a private LAN. Give strong
consideration to imaging an existing backup domain controller
and testing an upgrade to Windows 2000.
For testing purposes, inventory all your hardware and
software. This may be quite a task, particularly if you’re
part of a large organization or you’ve never completed
an audit. You may discover, for example, that your company
uses every modem model on the market. If this is the case,
standardization is important to ease administration. Depending
on the outcome of your testing, you may want to consider
standardizing PCMCIA cards, modems, NICs, and video and
multimedia cards. In terms of software, include all applications
currently used in your environment. This includes custom
and proprietary software, which may give you more trouble
in the upgrade than other third-party software. Focus
on business-critical applications, such as email, remote
access, and Internet software.
Budgetary Considerations
Budgeting for a test lab can be a challenging process.
Many managers outside IT/MIS departments may consider
lab environments for research and development purposes,
not for IT purposes. As a result, funding for such a lab
may be limited. Of course, you’ve already presented all
the good news about Windows 2000 to management: lower
TCO, non-production impact on future testing (in addition
to Windows 2000 testing), and the like. You can help with
budget concerns by being creative in your approach to
getting test lab equipment.
One option is purchasing identical hardware through auctions.
A variety of Web sites now feature auctions of a wide
range of hardware, software, and networking equipment.
While this may be an economical option, finding comparable
hardware to your current environment may be an issue.
There may also be the question of quality or history of
the machine.
Another budget option is leasing. This has become increasingly
popular, particularly short-term leasing, focusing on
the lifecycle of computers. If you can cycle some of the
computers into production following your testing, this
is a practical option; I’d suggest, however, that you
retain several in your test environment. Leasing also
appeals to managers who aren’t looking to spend capital
on testing equipment. Spreading out the cost can be beneficial.
A final option is renting. Rentals tend to be fairly
pricey, however, since companies offering this service
need to keep the computers in circulation. Unlike the
leasing option, the renting company will “eat” the cost
if they can’t rent out the units. As a result, costs tend
to be significantly higher, often by as much as two to
three times. Still, for short-term testing solutions,
this may be a good option.
Other Matters
As with any kind of testing environment, security, data
integrity, and disaster recovery are critical. You should
address these concerns when designing your test lab. Make
sure your lab is in a locked or restricted area, accessible
only to team members and necessary personnel. Don’t set
up a lab in an open office or cubicle when security can
be compromised. Consider setting up in a climate-controlled
environment similar to your server room. (Actually, if
there’s extra space in your server area, this is an ideal
place!) In terms of disaster recovery, be sure to use
several UPSs with the proper wattage to support your test
environment, as well as regularly updated emergency repair
disks (ERDs) and automatic system recovery (ASR) disks,
as they’re referred to in Windows 2000.
Hardware Testing
Before testing your hardware, complete a thorough inventory
of all hardware currently in your environment.
For computer testing, your units should be Advanced Configuration
and Power Interface or ACPI-compliant. Their components
should also be included in the Windows 2000 hardware compatibility
list (HCL). Your hardware list should include items such
as:
- Modems and PCMCIA cards
- Tape drives
- Video cards
- Sound/multimedia cards
- SCSI cards
- Printers
- Other peripheral devices
Along with your inventory, document the URLs of popular
vendor sites that may post updated Windows 2000 drivers
for their hardware. Download the drivers to a local server
for future testing. Some plug-and-play hardware may require
manual configurations under Windows 2000, so it’s important
to have updated drivers.
Remember that your hardware testing should focus on setting
a standard moving forward.
Software Testing
You should follow the same guidelines for software testing
as for hardware testing. After conducting an inventory,
you may find several applications and executables designed
for platform-specific purposes. These applications may
need to be upgraded or replaced, depending on their functionality.
Once again, document the vendor URL for software upgrades
and patches.
When you begin testing software, focus on the business-critical
applications first. As I mentioned earlier, email, remote
access, and Internet applications, as well as your office
suite, should fall into this category. Test deployment
scenarios of your software, including the following:
- Clean installation
- Upgrade for Windows 9.x, NT
- Via SMS
- Imaging (such as Symantec Ghost and Microsoft’s Sysprep)
- Windows Installer
- Uninstallation
If your software encounters errors in any of your deployment
scenarios, contact the vendor or Microsoft for resolution.
Testing Results
A crucial component of a successful test lab is documentation,
and that includes documenting results. Without results,
you and your company’s management may have a difficult
time considering an upgrade to Windows 2000. Make sure
your documentation provides quantitative and qualitative
results. The more measurable information you provide,
the better your transition to Windows 2000 will be. You
should top off your lab efforts with a final presentation
to management, and be sure to distribute hardcopy of all
your testing results at your meeting.