Windows Server

Replicating your infrastructure in a lab

Scott Lowe discusses the options for replicating your infrastructure in a lab setting so that testing can be done safely before a migration. It can be done, but it might not be easy or cheap.

A TechRepublic reader wrote in with the following scenario:

"My company is currently running Exchange 2003 on Windows Server 2003.

We want to do a test run of Windows Server 2008/Exchange Server 2007 running together in a test environment. I have few concerns, I do not want to add Windows Server 2008 to the domain and run into problems but I want to flexibility to duplicate our current environment and run them simultaneously. "

There are a number of different ways that the reader could accomplish his goals. In this posting, I'll talk about two different options the reader could take.

The physical route - Plan A

This is perhaps the most painful and most obvious option, but will provide the reader with the best comparative baseline analysis. In short, our dear reader would need to replicate at least a chunk of his infrastructure in a lab environment. This lab would be physically separate from the primary network and each server would be individually reinstalled to match the production environment as closely as possible.

This is an extremely laborious option and introduces significant potential for error. For example, how likely is it that the full Exchange environment would be appropriately replicated? So, on to Plan B.

The physical or virtual route - Plan B

In this case, Plan B is a breeze compared to Plan A. Whereas Plan A would require massive staff time and would not guarantee an identical environment, Plan B corrects both of these deficiencies. One of my favorite products of all time is PowerConvert from PlateSpin. PowerConvert promises (and delivers!) what they call "anywhere-to-anywhere conversion." In short, PowerConvert automatically moves a server workload from any physical or virtual machine to any other physical or virtual machine. I've used PowerConvert to perform a number of physical-to-virtual migrations and the product has saved countless hours and perfectly replicated my servers to VMware ESX hosts. PowerConvert, however, isn't designed solely for physical-to-virtual migrations.

The reader in this scenario could in his lab deploy a bank of servers similarly configured to the production systems. Once replicated, the reader could run the lab on a separate network and perform his product evaluations in a safe environment complete with at least some level of performance analysis. Sure, this isn't perfect since the lab network is still isolated and not accessible by all users, but it's still better than testing in the production environment.

If the reader isn't that concerned with performance baselines but is instead more concerned with how easily his environment can be migrated to Windows Server 2008 with Exchange Server 2007, a virtual environment -- rather than a physical one -- might be an ever better option. Although Microsoft doesn't support Exchange Server 2007 on virtual machines, it's still an appropriate platform for testing and will provide the reader with an adequate environmental replica on which to work.

Summary

You probably gathered that the key solution to this problem lies in PowerConvert. Although I am a huge fan of the product, it's not cheap. Pricing starts at $200 per workload converted. So, if the reader converts just two servers -- his Exchange 2003 server and his Windows Server 2003 domain controller -- he's still looking at a minimum outlay of $400 plus the cost of a lab server. An ESX license is not essential, however. PowerConvert also supports Microsoft Virtual Server 2005 virtual hosts. I've used PowerConvert with both Virtual Server and ESX Server with excellent results. There are also other products out there from companies such as Vizioncore. VMware also produces the VMware Converter. In any case, the reader will be able to safely test his migration plans.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

10 comments
mandms7
mandms7

I have a question related to the article's scenario. Assuming you setup a duplicate lab environment on a separate network (or virtual environment), I imagine the duplicated servers would have the same IP addresses and dns names as the production servers. Given that, I'm assuming you couldn't test external e-mail delivery because of dns/routing issues associated with having the same ip addresses and dns names. Wouldn't this be the case for any lab environment in which you're duplicating your production environment. Is there a way of getting around this, or am I not thinking this through correctly?

mandms7
mandms7

I've always had the same questions as what the original poster asked regarding setting up a duplicate lab environment that wouldn't impact my production environment. I've never had much luck finding an article on how to handle this situation, so I'm glad I saw this one. I wouldn't mind seeing even more detailed information on setting up a lab environment as well as getting input from other readers.

Jamsan
Jamsan

I've never use PowerConverter, but have used VMWare converter in the past. At $200 per server, VMWare converter can do the same exact thing for the most part, for free (unless your converting to ESX).

amiic
amiic

you can test external email by using either a test domain, or creating & registerring a sub-domain with the IP address for the test environment. using a separate test domain is the least risky in that you don't have to worry about the internal address spaces that may exist. however, you will need to hit every internal relay to adjust for the test domain.

ryumaou@hotmail.com
ryumaou@hotmail.com

No, you're pretty much on the money. Without jumping through a lot of hoops, you either have to change the IP addresses on the test network or have it physically separate from the main network. I suppose it might be possible to connect the two via some strange system of two routers and an essentially empty network between them. But, honestly, I think that would have a whole lot of problems with it.

IT Generalist
IT Generalist

Imaging would be another way to replicate a production envrionment. There are many imaging utilities such as Ghost, Acronis that you can use for this purpose. Ofcourse using these utilities may require some downtime but I think Acronis allows you to image your system on the fly.

ryumaou@hotmail.com
ryumaou@hotmail.com

If you've got the hardware, why not test your backups by doing a restore to new hardware? Seriously, I know everyone loves all the virtualization stuff thats come out in the ten years or so, but setting up a lab environment is a perfect opportunity to test your backups. After all, there's no way to know they work until you try to restore! Also, it might help justify the costs on the hardware, using it for the dual purpose of testing.

alanmcrae
alanmcrae

We are looking into the possibility of creating a virtual network on a separate PAN/SAN test bed. Once we had successfully created a virtual network between two Vista laptops, one of which also ran Windows Server as a DC, we began designing a Virtual Lab that will utilize a processor farm connected to a virtualized SAN. Theoretically we should be able to simulate most production environments in this configuration, and utilize it to test major upgrades (like XP to Vista plus Server 2003 to Server 2008) without risking production downtime. We'll keep you posted on progress.

IT Generalist
IT Generalist

I would recommend putting your lab network in a VLAN or a seprate physical network. And if you are planning on putting your test servers on the internet, change the name and the IP address and make sure that those changes are reflected on the DNS database of your ISP. Also make sure that there is a Firewall between your test network and the internet.

Editor's Picks