How to allow a virtual test lab using VMware ESX 3.5 and Windows Server 2003 to mingle with physical network?

Using VMware ESX 3.5 and Converter 4, we have virtualized clones of four of our production servers to use for a performance test outside of production hours. All servers have Windows Server 2003 and are members of a domain: one is a domain controller, one is our ERP database server using SQL Server 2005, and the other two run middle tier services for the ERP. No SYSPREP or other SID modifier was run. All four systems work well when connected to an isolated virtual switch, and the ERP client runs.

We need to move the ERP systems over to a virtual switch that is connected to our production environment (shutting down the physical servers that were cloned) to allow for a wider-scale performance test of the ERP. One of the servers comes up fine, but the other two (including the SQL box) will not log in to the production network. If we authenticate them on the virtual network then point their NICs to the virtual switch connected to the production network, we can ping them from clients, and ping clients from them, but they still generate authentication errors on our production DCs, and the ERP doesn't work.

We are considering using Reset Account on the computer accounts in Active Directory for these three systems then rejoin them to the production network. We anticipate that our actual production systems might then experience the same problems, and we'd have to reset the accounts again. We need 2-3 rounds of performance testing, so the accounts would get reset quite a bit.

Is anyone aware of problems all this computer account resetting will cause?
Have any other suggestions as to how we can get the virtual clones (same computer name, IP, SID) to work on the production network?

Thank you
bfg01Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Paul SolovyovskySenior IT AdvisorCommented:
I have seen this before and you'll most like have to rese the computer account.  If you'll be connecting your production machiens on the same vswitch as your testbed VMs there may other niggling issues and are a pain to resolve sometimes.

I would use something like Symantec Backup Exec System Recovery and image the ERP system (if possible) and restore on a test physical box which would then be connected to the test vswitch.

I would recommend to keep production and testbed separated.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
vmwarun - ArunCommented:
I concur with paulsolov.

Its always a safe option to segregate your testing environment from Production.

The best approach would be to simulate everything using a vSwitch with no pNIC (Physical NIC) attached to it.

This would give you the best test bed which is akin to your Production Environment.
0
davismisbehavisCommented:
rejoin these Virtual machines to the production domain controller.  Depending on how long you've been running these machines in the isolated domain,  you can find that GUIDs for computers in AD actually change every 30 days.  It's either that or you have joined them to the domain in the isolated network and they have been assigned a new GUID within Active Directory that does not match the GUID in your production AD.  Rejoin the machines to the domain when on the production network and this should resolve your issues.
0
bfg01Author Commented:
Unfortunately we do need to mix the virtual test and physical environments, there is just no way to simulate 80-200 clients in our virtual environment at this point in time.

We have been able to successfully reset the AD account for the three computers, joining the virtuals to the production network, then reset and rejoin the production servers, all without a problem.

Thank you all for the input.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.