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.