Sherry Abercrombie <[email protected]> wrote on 08/27/2009 11:59:24 AM:
> Yup, build yourself a test domain in VMWare, different ip and subnet > address range for it. Set it up like your domain is in production, > snapshot your servers before doing any migrations or upgrades, then > practice all you want. Revert back to the snapshot and start all > over again. That's pretty much my plan, yeah ... > You will find that there will be many benefits of having a test > domain. Mine was originally setup to practice the migration from > Exchange 2003 to Exchange 2007, so I've got OWA & ActiveSync > working, plus other applications that interact with Exchange, test > workstations with users & mailboxes etc. That's still in progress, > but in the midst of all that, we got a couple of new Cisco ASA > boxes, all the configuration & switching over was done to the test > domain first, all the bugs got worked out before we went to > production with it. I'm confused here. When you set up your test domain, with different IP addresses from the production domain, did you do it as I mentioned? vSwitch, but with no physical NICs bound to that switch? If so, how did the VMs communicate with the Ciscos? There should have been no way for any device that was not part of the vSwitch to talk to any device on the vSwitch, and with no physical NICs to transmit over, how did the Ciscos talk to the test domain? > Basically a miniature version of my production domain that I can > test with any time something new comes up that I don't want to risk > blowing up production with Oh, I plan to. :-) Our Group Policies are a spaghetti mess of horribleness and redundency, and I plan on cleaning them up - first by testing in the virtual domain, then copying to production. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
