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 
to advanced administration 
. 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
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:
- What OS's are you intending to run? Desktop, Server, Windows, Unix, Linux ?
- What major software packages or technical areas are you intended to explore in the lab?
- Will any of the systems be used for active development (ie, results will be ported directly to production)?
- Will any of the systems potentially move to production?
- Will any of the systems need to travel with you (between sites, work and home, or to conferences)?
- Will your systems need to run only some of the time, all the time, or a mix?
- Will they require network access to the outside world?
- Will the outside world be allowed to access your lab resources?
- Will you need a private network in your lab or can they coexist on your existing network?
- 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.
- 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.
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.
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.
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
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
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
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
