Eli Weinstock-Herman

Building the Virtual Lab: VMWare and MS Windows 2008 R2

Original post posted on May 11, 2010 at LessThanDot.com

Asking me what I do for living could net you different answers, depending on what day you ask. Over the years, and through the course of several jobs, I have had a wide range of responsibilities that often stretched well beyond my current organizational role. I like to call these opportunities.

Recently I was considering the idea of building a virtual lab, as I've been worried that some of the varied experiences or skills I've picked up would rust away. While in Wisconsin visiting Ted Krueger (twitter | blog) for SQL Saturday Chicago, I realized that the lab could serve two purposes. I could use it to not only regain or sharpen aging skills, but I could also use it to start blogging on more technical matters. Don't get me wrong, I love process and personal improvement topics, but I need my tech fix too.

So here we are. If you don't already have a virtual lab at work or home then I invite you to follow along with me as I build one. Each blog entry will have a general level of difficulty, from basic installation propeller beanie to advanced administration wizard's hat. As the lab grows we will be installing a wide number of systems then later configuring and tuning them to meet different circumstances and needs.

Lets get started.

Virtual Lab: Building the First Windows 2008 R2 Virtual Machine

The purpose of today's article is to create a basic windows virtual machine that can serve as a template for later virtual machines. Having a basic image or set of images on hand can dramatically speed up production and non-production roll-outs as well as ensure standardization of systems across your environment.

Accidental Systems Administrator

Basic Difficulty
Virtual Lab entry on the LTD Wiki


Building the Lab Environment

Building your own lab can be both fun and a learning experience. A virtual lab provides you a safe place to try new technologies and configurations. When you create a really horrendous set of configurations in your lab, your halls are going to be remarkably free of end users with torches and pitchforks. The risks you should never take in production environments, even production development systems, are fair game here. But first we have to build it.

Environment

First we should determine what type of environment we want to run and what types of technologies or systems we would like to play with. Some of you will be planning no working with just development software and/or database servers, some will be want to create a virtual business environment (DC, Exchange, AD, etc), and some will even want to play with a mixed operating system setup. Identifying some general requirements will also help when your lab (or the market) grows past the current list of technologies you want to try.

Here is a sample set of questions you should consider:

  1. What OS's are you intending to run? Desktop, Server, Windows, Unix, Linux ?
  2. What major software packages or technical areas are you intended to explore in the lab?
  3. Will any of the systems be used for active development (ie, results will be ported directly to production)?
  4. Will any of the systems potentially move to production?
  5. Will any of the systems need to travel with you (between sites, work and home, or to conferences)?
  6. Will your systems need to run only some of the time, all the time, or a mix?
  7. Will they require network access to the outside world?
  8. Will the outside world be allowed to access your lab resources?
  9. Will you need a private network in your lab or can they coexist on your existing network?
  10. Will there be interdependencies? (for instance, Server A is running DNS and Active Directory and has to be on for Server B to work properly)

And some of the answers for my lab:

  • My lab will be running multiple Windows servers and 1-2 linux systems
  • Software packages: SQL Server (of course), TFS, Active Directory, Sharepoint, potentially a DC, possibly Exchange, ...pretty much anything in Microsoft's catalog or that comes in as a user request is fair game
  • None of these systems will go to a production environment or be accessed by active development environments
  • The only environments that may need to travel are the SQL Server ones
  • None of the systems will need to run all of the time
  • The lab systems will be on a private network with limited external access

Platform Selection

Once we have an idea what we our lab will be used for, we need to determine what type of platform to use. If this is a home lab or you have limited space for equipment, you will probably want to go with a virtualization platform. Using a virtualization platform allows us to have a smaller physical (and electrical) footprint and multi-purpose our equipment, since many of our test servers will not need to be running when we aren't directly using them. Virtualization also allows us to move systems to upgraded hosts if we later find ourselves having performance problems.

The hardware you use will depend on the types of answers you provided to the questions above. Using an old desktop might be a acceptable solution or you may need to incorporate higher end systems or even spare servers. My last setup (2007-2009) used an off-the-shelf Dell Precision work station as the host without any extra equipment or over-the-top upgrades. The system performed well as a low budget SQL Server and Windows server platform. On the other hand my new environment will need to support a far wider range and number of systems, so it will require higher performance hardware.

Here is the current hardware setup for the lab:
  • CPU: A Intel i7 920 quad-core
  • Memory: 10 GB of DDR3 RAM w/ room to upgrade up to 24GB
  • Storage #1: Raid 10 Array - (4) SATA2 7200RPM 500GB drives, mixed manufacturers
  • Storage #2: Vantec external enclosure w/ 500GB SATA2 drive (USB2/eSata) - raw storage for some backups, MSDN images, and other purchased software
  • Storage #3: Bytecc two-bay docking station (USB2/eSata) - more disk (will be critical in a later article)

I have selected VMWare for my virtualization platform. There are a number of reasons for this (for instance, Microsoft hard-blocking virtual server installations on Windows 7) and I actually would have preferred MS Virtual Server, but such is life.

Installing our First Virtual Server

From this point forward we will be working from the comfort of my home lab, so examples will be based on VMWare Server 2.1 and I will point out versions for other software as it is introduced. The purpose of this first virtual machine is to serve as a template for later machines, allowing me to build out one image that with a standard base configuration, installs all common services, then apply all the outstanding Windows updates. Though I will be using the term 'template' in the article, this shouldn't be confused with the template capability in VMware's vSphere.

In a production environment it is extremely helpful to have a basic server image already pre-configured and up to date. Not only does it provide a faster alternative to building each server from scratch, but it ensures that each server goes out with all of the required services and configurations and does so without adding a checklist to your process. Not that I am a process improvement fan or anything.

Though the software is different, many of the concepts will be similar if your lab is going to be based on Microsoft Virtual Server 2005 and I have successfully followed almost the same exact steps through Virtual Server in the past.

Build the Server

First we need to build our virtual machine. Opening the VMWare Server Host and logging in with administrative credentials, we are presented with a dashboard view of our system.



VMWare, Freshly Installed

Clicking the "Virtual Machine" menu provides an option to "Create Virtual Machine" and a wizard to walk us through the creation of our virtual machine.


Create a new VM

While it isn't critical to pick a good name at this point, it couldn't hurt either. Later as we create servers for specific purposes the VM names will reflect the actual names of their servers.


New VM - Provide a Name

In my case I intend to use Windows 2008 R2 as my main server environment, so this basic image will reflect that in it's name and I will choose the Windows 2008 option from the operating systems tab. Before choosing the 64-bit image I made sure to run the 64-bit compatibility check offered by VMWare to ensure I could run a 64-bit guest on my host. If you are using Virtual Server 2005 then you will be limited to 32-bit guests so be sue you buy/download the correct versions.


New VM - OS Selection

For this first server I am going to allocate 4GB of RAM for use during the installation process. When making later copies of the system we will tune these values accordingly. As I intend to use these systems in a lab environment and may need the images to be portable to another single core system, I'm going to select the 1 CPU option. For later articles we may create 2- or 4-CPU options, but for most of our non-production needs a 1-CPU system will be sufficient. While technically it would be possible to "tune" the CPU setting at a later time, since we really only care about the hard-drive file at this point, changing CPU architectures on a system after installation ranges from tricky to absurdly-painful-with-no-hope-of-working.


New VM - RAM and CPU Settings

The final lasting decision (though not the last step) is how large we want to make the virtual drive and whether we want to allocate the space ahead of time or use a growth model. In my last environment I pre-allocated space for my base windows installation and then attached or created secondary drives for the installed applications. In this case, Microsoft is suggesting a minimum of 32GB of space and, while I don't want to give up the space, I've decided to use pre-allocation again to simplify the process.


New VM - Drive Settings

The final options, optical drive access and network method, are only going to be used for this image during the Windows installation process. Later copies will again have values assigned based on the project or technology that's being installed. For the purposes of the installation we will use an ISO file for the optical drive and bridged networking.

When you install VMWare initially it will ask for a folder for your standard store (default is "C:\Virtual Machines" on Windows). ISOs placed in this folder will be available for mounting in VMWare or you can create a new store that points to a folder elsewhere. Having a dedicated drive for software storage, I created an 'MSDN Library' store and pointed it to that location.
VMWare Gotchas:
Firefox 3.6 is documented as not working with the console viewer right now, so you are going to have to downgrade or switch to IE. 3-3.5 also had issue at one point but there are either fixes or workarounds for this.

VM Setup Complete

Install the OS

We are now ready to turn our machine on for the first time and install Windows. This part is actually fairly boring, which is yet another reason that we want to limit how many times we have to do it.

This is the point I ran into an issue with VMWare's console. VMWare continued to present me with a black screen when I opened the console. I believe the change that fixed this issue was setting the DNS address on the vmnet1 network connection, but it could just as easily have been the firewall being turned off when VMWare started or the couple changes I made to IE's trusted sites. An excellent, practical example of why you should always make one change at a time and write down what you changed when you are troubleshooting a systems problem.

The first decision the installer requires is selection between the various versions of Windows. Based on the options available, the trade-offs outlined in the feature comparison, and the fact that I have already written down my MSDN Enterprise key, I will be installing Enterprise edition. I'm not actually sure how long the installation took, I wandered off and found something else to do for a while (Peanut butter jelly time, peanut b...oh). I've installed windows a few more times than your average developer, so my bet is on 39 minutes. ;)

The default Windows password policy is probably going to annoy you if you haven't run into it before. It will not tell you what the policy is when your password fails and the policy itself is well-defined. In a production environment one of our first steps would likely be to change it to meet our business needs or current setup.

Official policy information can be found here

After the initial login there are a couple key things we should do prior to starting the update cycle. First we are going to install the VMWare tools to make the interface easier to use and second, we are going to increase the screen resolution.


Installing VMWare tools - Server OS View

Installing VMWare tools - Guest OS View

After these two tasks we will begin by applying service packs (none for Windows 2008 R2 at this time) and then windows updates. Windows 2008 offers a handy dashboard to manage these tasks on the first install and, being lazy, I'm not going to turn it down.


Windows Server "Configuration" Dashboard
If you haven't worked with server much in the past you may be surprised by a strange dialog when you attempt to restart your system. When you shutdown or reboot a server it asks you to provide a reason and note, I advise that you get in the habit of always typing up a short note on why you are shutting down or rebooting. It only takes a few seconds and one day it's going to save you hours because these notes are entered into the event log before the system shuts down.

Next I am going to glance through the features and see if there any others that I would want installed on all of my servers. In this case the only one I can see if SNMP, so a quick installation and configuration and we are ready to move on.


Server Features - Configuring SNMP
Installing SNMP services as part of your basic image gives you the opportunity to ensure you have consistent coverage and passwords across all your systems, which in turn makes deployment easier when it comes time to point your network or systems monitoring software at the new server.

The step we might normally move on to in a production or corporate environment is installation of base antivirus, client license, or and inventory management software client. This is an excellent time to install software packages that are part of your standard or that can be pre-installed and updated later. Another consideration would be whether you need to set up VNC, RDP, or another remoting technology.

The last item on my personal setup list is to assign a background image and set up BGInfo. Having a common background and system information on every server is extremely handy and helps show critical information at a glance (like disk usage or IP addresses). An easy solution is a utility called BGInfofrom SysInternals. BGInfo is a free download and there are many examples and articles available on the internet for setting it up.


Windows Server "Configuration" Dashboard
Once upon a time I had scripts and standard layouts to add other interesting information to the background (such as uptime counters and such), but that can wait for another day. For this initial example I have grouped the information in a way that is meaningful for me, but haven't done anything fancy.
If you run into difficulties on 2008 R2 with permissions then follow the instructions posted near the bottom by prrawls here: SysInternals Forum Post

Last Shutdown of the Basic Image

Basic Image Done

The basic server is complete and ready to serve as the foundation for the rest of the lab. In coming weeks we will use this basic image to create more systems, such as a basic database server and a domain controller.

Additional Links:
Virtual Lab: Basic SQL 2008 R2 Virtual Machine
Virtual Lab entry on the LTD Wiki

Comments are available on the original post at lessthandot.com