More years ago than I really care to think about, I was working as a network administrator for a large, enterprise-class, company. To this very day, one of the things that really sticks out in my mind about that job is the way they handled hardware and software upgrades. The company had a lab that was an exact replica of its server room, complete with matching equipment. This duplicate network existed for the sole purpose of testing upgrades.
The idea was that no upgrade (hardware or software) was ever done to the production network unless it was first done to the test network and monitored for adverse effects. And that was actually pretty smart for the company to set things up that way, because doing so ensured that there were never any surprises on the production network after an upgrade. The thing that really made an impression on me, though, wasn't so much the testing procedure. Rather, it was the amount of money that the company spent on the lab.
The infinite resources method
Every time the company needed a new server, it would buy three of them. One would go into the production network, one would go into the lab and one would be kept in the box and saved in case of a catastrophic hardware failure on the production or test network. In addition to buying duplicate hardware, the company also purchased duplicate software licenses for the test network, although the test network didn't require nearly as many client access licenses.
The point is that the company had a great system for testing patches and upgrades prior to deploying them, but between the cost of duplicate components, duplicate licenses and having to pay the IT staff for the extra hours spent maintaining the lab, the company spent an absolute fortune on testing.
A lot of years have passed since then, and today I work for myself. I have to admit that I would love to have a duplicate network set up for testing purposes, but doing so is, to say the least, a little beyond my budget. That doesn't mean I don't test patches prior to deploying them though. I don't have nearly as elaborate of a setup as my former employer, but I have found a few tricks for testing patches on a much more modest budget.
Reducing hardware costs
The biggest costs related to creating a test lab are hardware and software. Although both are necessities, there are some ways that you can really hold down the costs. Let's talk about the hardware first. One way you can economize on hardware is to purchase PCs instead of servers. If all you do is test the impact of occasional patches, then you don't need things like multiple processors and RAID arrays. You can save an absolute fortune just by using a basic PC with plenty of disk space and memory for testing purposes.
Another cost-saving technique is to use virtual machines. Products such as Microsoft's Virtual Server 2005 and VMware from VMware Inc. allow you to simultaneously run multiple virtual computers on a single physical computer. As you can imagine, running multiple virtual computers simultaneously requires a lot of computing power. Therefore, if you are thinking about using virtual machines, make sure that the physical computer on which you are hosting the virtual machines is as powerful as possible. Specifically, the physical computer will need lots of processing power and as much memory as possible.
Reducing software costs
So what about saving money on software? As I said, you can save money because you won't have to buy as many client access licenses for your test network as you would for the production network. Even so, the software can still be expensive.
There are some ways to cut cost though. If you are only doing a quick test, try using evaluation software in your lab. Microsoft offers 120-day evaluation copies of most of their products for free. Therefore, if you are testing a configuration, patch, upgrade or whatever for less than 120 days, you could just download some evaluation software and not have to worry about the cost.
If you are going to be testing for an extended amount of time, one option is to get an MSDN subscription. A subscription to MSDN Universal costs about $2,000. That sounds like a lot of money but, along with the subscription, you receive multiple licenses for almost all of Microsoft's products. I don't know what Microsoft's official policy is regarding using MSDN software in testing labs, but because MSDN is intended for developers, I'm pretty sure that using MSDN software in a test lab would be allowed by the license agreement.
As you can see, you don't have to have a huge budget to create a test lab. All you really need is a PC or two -- and some imagination.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal Web site at www.brienposey.com.
