I have had a number of people asking me about the hardware we use to run the reference network used for our national TechNet Tours. If you have attended an event delivered by one of the Canadian IT Pro team members recently, you have probably seen us carry a large transparent briefcase containing the guts of “the bot”. I felt it was time to share the configuration the Microsoft technology used to bring the Build ‘06 Tour and other events to life. A second post will have the hardware guts of the box.
Our CANITPRO reference network – what exactly is it’s makeup?
It is hard to believe I started delivering TechNet workshops and presentations using only a laptop and external USB based hard drive with one or maybe two virtual machines running. As you could expect – the performance was not there and the demos lacked relevancy to the audience – how could we make the experience better? After analysing your feedback from the early tours, we decided to create a more relevant “reference network” that could represent how our technologies fit together and could work in your network. It didn’t matter if you had multiple Data Centres full of servers or if you had a single Small Business Server looking after your company – the parts had to be representative of a working network that could scale up and out or scale down based on our audience. After brainstorming some more requirements with the team, I created the first attempt at the CANITPRO network and it has evolved into what we use for almost all of our sessions today.
Our reference network has now evolved into the following systems:
- DC-01 – Domain Controller, Certificate Server and infrastructure services of DHCP and DNS
- EX-01 – Exchange Server 2003 SP2 system that also doubles as our Outlook Web Access and Exchange Active Sync server. On occasion it also has been configured as a Live Communication Server 2005 Access Proxy.
- MOM-01 – Microsoft Operations Manager 2005 management server with SQL 2000 Reporting Services enabled
- FS-01 – Windows Server 2003 R2 enabled file server and Systems Management Server 2003 SP2. It also serves as our primary DFS replication server.
- WSUS-01 – newly added Windows Server 2004 R2 system used as the second DFS replication partner as well as our central patching solution running Windows Server Update Services
- WSPS-01 – Windows SharePoint Portal Server 2003.
- WSTS-01 – Windows SharePoint Services server and sometimes Live Communications Server 2005.
- XP-01 – Administrator workstation running Windows XP with Service Pack 2, Office 2003 and Office Communicator.
- XP-02 – A general purpose “user workstation” running Windows XP with Service Pack 2, Office 2003 and Office Communicator
How does it actually work? You can’t possibly run all those machines at once!
For the Build ‘06 tour that is currently underway, I have DC-01, EX-01, FS-01, MOM-01 and XP-01 constantly running throughout the day. When required I spin up XP-02 for desktop deployment and software deployment demonstrations as well as WSUS-01 for patch management with Windows Server Update Services and also DFS replication demos. Occasionally I will also spin up an older Windows 2000 Professional workstation called W2KPRO-01 for an upgrade scenario. These are a lot of virtual guests that take up over 50 GB of space on my hard drives. It is no easy feat managing the versions, changes and patches for this network, yet alone sharing it with the other team members for their events as well. Let me just say that external USB backup drives are our friends and they have saved my bacon a number of times over the last year or so.
How did I make the reference network guest machines?
I created the reference network by building a number of what we call “Gold Base OS Images” which were simply SYSPREP’ed virtual guest machines running Windows Server 2003 or Windows XP Pro. Whenever I needed a new server, I simply copied the VHD file, created a new Virtual Guest and pointed to the freshly copied VHD file. The resulting virtual guest machines would spin up, start the Mini-Setup wizard that was pre-populated with answers and keys with the exception of stopping to ask what computer name I wanted to assign to the machine. The guests are hosted on Windows Server 2003 running Virtual Server 2005. I have since upgraded the base OS to Windows Server 2003 R2 64 bit edition and a 64 bit version of Virtual Server 2005 R2 for even better performance. 64 bit host machines ROCK!!! The end result was I had a very fast way of creating a bunch of servers in a virtual environment using standard practices of SYSPREPing images. To further configure the systems, you can easily mount ISO files (see here on how to create ISO files) of the various server applications (Exchange, Microsoft Operations Manager…. etc) and configure them as your needs require.
After finishing the basic configuration required for the first tour that was designed to use the reference network – I turned on my FAVOURITE Virtual Server 2005 feature – Undo Disks. This allowed me the flexibility to change and tweak the configuration as required, but I always had a back-out option if things didn’t go just right. This process continued until the reference network was configured as required for the upcoming tour and the images were backed up and delivered (via a USB drive through inter-office mail) to the other team members.
On the road – actual use of the network.
While on the road and while delivering the tour – I am able to start the machines and complete any final prep the night before the presentation and then use my second most favourite feature Save State in order to have a fast startup the following day at the event venue. Save State lets you freeze the machine and dump the contents of ram to a hard disk file like you would get with a laptop going into hibernation mode. Once you need the systems back up and online the next day – it’s a very quick start up process that gets them running again just like they left off the night before.
The feature of multiple networks and routing.
Virtual Server 2005 R2 is a powerful and flexible product that can be used to create and control a very complex virtual world. We have a number of virtual networks that are either isolated or bridged into the real world by associating them with (or isolating them from) the two physical network adapters on the real server. This allows me to interact with things like Wireless Access Points with wireless devices, the internet / corporate networks and other things in the real world.. I run the server “headless” in the sense that while on the road I simply plug in a cross over cable between my laptop and the virtual server in order to use Remote Desktop with the /console switch to control the host operating system. All BIOS “halt on errors” have been turned off.
One more trick I wanted to share: how do I pass data back and forth from the virtual world to the real world?
This one is easy. You have two options. 1) bridge your virtual network onto your real network by associating a physical network card with your virtual network using the Administration Console website of Virtual Server. This can be both good and bad. Good because it is easy and gives ALL your machines access to the real world… Bad because it can introduce conflicts and issues with services on your virtual machines now being accessible to the real world. I sure wouldn’t want my internal DHCP server passing out address to live production machines! 2) install a local LoopBack adapter on your host machine running Virtual Server and hard code an address on it that matches the address range of your isolated virtual network. I then associate that LoopBack adapter with the isolated virtual network and voila – the virtual guests can now have access to the host machine. I create a share on one of my drives that I can then dump files and data from the real world into from the console and then I can map a drive or access it from the guest virtual machines.
To install a Local LoopBack adapter – from the control panel, select Add Hardware. When it is done searching for new hardware on your system, select Yes I have already connected the hardware. Then scroll down to the bottom of the list and select Add a new hardware device. Select the Install the hardware that I manually select from a list option and select the Network Adapters option. Then select Microsoft as the manufacturer and Microsoft LoopBack adapter. Finish off the wizard (you might be prompted for the install CD) and hit finish. Once that is done, open up your network connections to find your LoopBack adapter and then set it to a manual IP address configuration that matches your isolated virtual network. Make sure that you don’t put in a default gateway – you can only have one of those and I suspect that you want one of you REAL network adapters to be populating that field. That’s it. I assume you know how to associate a network adapter with a virtual network on the Virtual Server Administration website.
This post covers the setup of the infrastructure. The next post will cover the hardware used to run this whole reference network. Any suggestions on how to do it better – leave a comment!