Years ago, I was working as a network administrator for a large company. One of the things that 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. The company was pretty smart to set things up that way, because doing so ensured that there were never any surprises on the production network after an upgrade. But the thing that really made an impression on me wasn't so much the testing procedure. Rather, it was the amount of money that the company spent on the lab.
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. Today I work for myself. I would love to have a duplicate network set up for testing purposes, but doing so is beyond my budget, to say the least. But that doesn't mean I don't test patches prior to deploying them. I don't have nearly as elaborate of a setup as my former employer, but I have found a few tricks
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
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 hold down costs. 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, 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.
But running multiple virtual computers simultaneously requires a lot of computing power. If you're 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, it will need lots of processing power and as much memory as possible.
Reducing software costs
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 still ways to cut costs. If you're 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. So if you're 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 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.
This tip originally appeared on SearchWindowsSecurity.com
