In case you haven't heard, we're hard at work on the next release of Windows

As an IT Pro, you have to continually learn new things. A challenge many of us in IT face when a product is released/updated is "how to learn the new product." Additionally, in our day-to-day operations, we need a sandbox-type arena to test planned changes to production, validate our new scripts and win or lose our intra-team bets on the "this should work" ideas. No one tests changes in production, do they?

Some lucky folks work for employers who fund wonderful lab environments full of automation, WAN simulators and other enterprise-class equipment. Most make due with less.

Some lucky folks work for employers who fund wonderful training so their IT talent is retained and up to scratch on current technology. Most make due with less.

Many folks are at least somewhat on their own to manage and grow their knowledge. It's up to the individual to scramble for some lab equipment where she can try things out and learn. For many of us, we do this in some form of a lab in our own homes, often affectionately referred to as a 'basement lab.'

With the leaps and bounds in virtualization technology and hardware advancements, this is greatly improved.  One is now able to deploy an entire simulated "global infrastructure" in one's basement lab, with a minimum of hardware - one or maybe two physical machines.

In this post, I'll offer a few bits and bytes I've come up with for running basement labs of one sort or another.

  • Much of this can apply to a lab beyond your basement - perhaps one you've established at the office that is made up of retired and/or decommissioned systems.
  • Feel free to add comments to the post with your own great basement lab ideas.

Virtualization-capable Hardware

  • You'll need at least one 64-bit physical machine – this is the best bet for a virtual machine host
    • Newer versions of Windows Server OS (and the Hyper-V Role) are only available/compatible with 64 bit hardware platforms
    • Remember, though, that Hyper-V can host both x86 and x64 VMs (I still love this feature)
  • Consider that the bottleneck for most small lab virtual environments are typically disk-bound:
    • Many new desktops and laptops today have enough RAM and multicore processing power to run the host OS and at least a couple VMs at a suitable level.
    • However, most desktops and laptops today have only a single disk. No matter how fast the disk is, if you have more than a few VMs and the host OS all running from a single disk, performance is going to suffer, especially if you try to do more than one thing at a time with the system/VMs.
  • You can find a used server-class system that would do very well as a virtualization host from various vendors.  Often these older systems are less than or comparably priced to a new high-end laptop/desktop (I picked up a well-equipped HP Proliant DL 385 G2 for around $700) . Be sure to verify the chipset functionalities are there for virtualization, though.
    • A drawback to a server can be electricity use. Even if you only plug in one of the redundant power supplies, you'll most likely notice it on your electric bill.
    • They are ofen noisy, too, with lots of internal high-rev'ing fans.
    • Clustering adds obvious cost but sometimes not too much more when looking at used equipment. Let the vendor know if you'd entertain a discount for multiple systems for a cluster.

Once you get some capable hardware, I urge you to pause and create some structure for your lab design. Many of us preach process and standards in our day jobs only to come home to our own basement labs and just start spinning up VMs. Let us "do what we say" and plan this out a bit. This helps us stay sharp from a "process" standpoint and on-going, will make the lab much more useful. This alone can be an eye-opening experience and is part of 'staying current' in technology.

In our labs, we often create AD environments without planning beyond the Wizard interface questions.  We install OSes on VMs and don't follow any standards on naming them within the virtualization console or for the hostname itself. We create users, OUs, etc without really any thought beyond 'what do I need right now?' We ping until we get a free IP address, and then we set it and forget it. 

Then, a few weeks/months pass where we have been away from our basement lab and when we fire up the VMs, we don't recall how we left things.  What were the server names? What did I call the AD domain? What in the world was the password I used? At that point, we often rebuild the lab and this process repeats itself. Let's implement some controls in our 'global IT infrastructure' and practice what we preach.

  • Data Storage –establish a system to manage ISOs, software, utilities, etc so you can easily find what you need and won't have to download it again (and again and again).
    • ISOs and software – I try to put my source software on a USB thumb drive or other 'less-capable' storage
      • Think about the common pre-reqs in addition to the OS and product ISOs
        • DotNet framework versions
        • Windows Installer updates
        • MMC updates
        • SQL Express
        • Service Packs and key patches/updates for the OSes and products
        • GPP client-side extensions for XP/2003
      • Some folks purchase a TechNet or MSDN subscription and get a TON of full-version software for a bargain. Consider asking your manager if this can be expensed - I've seen that usually gets approved, if requested. Also, this is often a benefit of a Premier contract with Microsoft, yet folks might not be aware that their company already owns this value-add. 
      • Some people use trial versions for their labs since they usually don't require keys 
        • Using trial versions on certain aspects of the lab can result in recurring lab rebuilds
          when the trial period expires but that repetition can be good practice, too
      • Speaking of license keys – if you have them, come up with a system to manage them (even just a notepad txt file)
        • How many of us have scrambled around looking for a CD key?
  • System Provisioning – establish the ability to rapidly provision systems. Virtualization offers us some great features here and one of the benefits of this lab effort is learning virtualization.
    • Think about VM naming
      • VMs within the management console/interface
      • VM config file storage within the file system/folder structure
        • Be aware of and consider changing the default storage location for VMs, VM config files and snapshots
      • VHD names associated with the VMs they're attached to
        • Example: 
          • VM name in the VM console "W2K8R2-DC01"
          • In a folder called "W2K8R2-DC01"
          • Based on a VHD file called "W2K8R2-DC01.VHD
          • Server hostname = "W2K8R2-DC01
    • VM templates and documentation
      • Build an OS instance, patch it, install virtual integration services, other tools/utilities, fully bake it, then SYSPREP it with the "shutdown" option.
        • Now you have a file that can be copied and then attached to additional VMs to quickly generate a system or an entire global infrastructure in your basement lab.
        • Store these VM hard disk images somewhere and copy as needed to the VM folders that are created as part of creating new VMs
        • Consider a common local admin pwd for your base templates so you're not stuck trying to remember what you set it to two months ago
          • In our basement lab enviro, I consider it passable to write pwds down on the whiteboard, or at least give yourself a reminder or hint of what you set the password to be.
          • You can put this right next to the diagram of the lab infrastructure layout you are deploying. You do document your environments, don't you? You do have a whiteboard for your lab area, don't you?  At least a pad and pen?
          • A fellow PFE had a great idea to use SkyDrive to store your lab docs - always available and from pretty much anywhere.
        • I put these VM templates on less-capable storage, too.
        • Also, consider there are many pre-configured fully-baked and ready to use VHDs files from Microsoft that can be directly downloaded for evaluation use. 
  • Storage for running VMs
    • Here's where you want to try to get some speedy storage
      • This could be a RAID array on a high-end desktop or possibly a used server with a dedicated storage controller, cache module and a few high speed SAS drives
    • At the least, try to have at one dedicated drive(s) for the VMs to run from that is separate from the OS
    • Having said that, many-a-PFE (including me) has used a laptop with a single drive running a host OS and one or two light-duty VMs for demos with success but I'd aim for "more" and "better" for our basement labs.
    • Consider the space needed if you intend to do a lot with snapshots – these can add up exponentially
      • I've seen snapshots used to manage service-packed OS instances
        • Base OS <snap>
        • Base OS + SP1 <snap>
        • Base OS + SP2 <snap>
  • Networking
    • Consider a common internal IP addressing scheme to easily IP systems as needed
    • Consider using a 'private' or 'internal' network for your virtual network/VMs to insulate or isolate the work you do in the lab
    • Consider IP address ranges
      • Server IP 'range' = 100-199
      • PC IP 'range'= 200+
    • Consider a different IP subnet to that of the rest of your home Internet users (i.e. 10.x for your lab space while your home users are on 192.x)
      • It's not fun to tick off your significant other or kids with your lab efforts
      • An alternative is to schedule recurring "change management" meetings with the family – these don't usually pass as fun, or quality family time, though, and turn-out is usually on the low side. J
    • Remember DHCP is often running on broadband routers and if you install DHCP on a server in your lab and you're sharing an IP subnet, you'll likely cause some disruption
  • Active Directory
    • You can establish a longer-term plan to keep the AD forest(s) around or you can plan to spin-up AD as needed, too.
    • Like the other aspects of your basement enterprise, though, you'll want a simple 'system' to make it easier to use and operate.
      • Think about server names – in my labs, I often base my names on the OS and role for the system
        • W2K8R2-DC01 (domain controller)
        • W2K3R2-INF01 (infrastructure server)
        • W2K8-APP01 (application server)
      • Don't forget a common Directory Services Restore Mode for your DR practices.
      • Think about AD domain names
        • FQDNs can get loooooonnnnnggg to type over and over as you're tesing/learning
          • HILDE.LAB is much shorter than HILDEBRANDBASEMENT.LAB
      • Think about AD contents and naming
        • User ID syntax/format ideas:
          • First InitialLastname
          • FirstNameLastInitial
        • Groups – local, global, universal
          • I use a scheme so I can sort effectively and tell by the name what type of group it is
            • SQL Users-D
            • SQL Users-G
            • SQL Users-U
          • Try to get in the habit of putting something useful in the Description fields
        • Sites and Site Links –
          • I use HQ and BRANCH01, 02, etc for site names
          • I combine the Site names to make the Site Link names
            • HQ-BRANCH01
          • Remember, in the AD Sites GUI, you can enter a single IP address with a /32 for the subnet mask and then link it to an AD Site, then your various individual systems will 'discover' their AD Site 
      • Think about OU structures and names
        • GPOs and delegation should drive the creation of OUs, not a pretty folder layout
        • Consider the ease of viewing within in the GUI and the sort order
          • Notice below, I added a simple 'dash and a space' before my OU name and that puts it at the top of the ADUC view.
          • I also used all caps to make it stand out in the UI
          • Create some simple standard to use for the Description fields that are found throughout Windows and get in the habit of using them.
          • <Brief description> – <last name> – <date>

       

Some closing thoughts...

  • A fellow PFE will be doing a future post with information on using RRAS for setting up subnets/routing for VMs and also some NAT tips for enabling VMs access to the Internet – stay tuned!
  • I just began exploring the use of QoS via GPOs linked to AD Sites to see if I can simulate a slower WAN-type connection between devices in the Sites (as is often the case between AD Sites)
    • How are you in the field simulating WANs in your labs?
  • It is helpful for me to have some "tasks" rather than just wandering around in a lab. So here's a "go-do" list for those of you who'll benefit from it.

Team, the Summer of 2012 is upon us – how far will you go between now and the end of the summer?  Set aside time on the schedule and do some of the things discussed here.  Soon, you will have learned a great deal (and might be ready for another certification test?). 

Have fun in your lab and expand your skills!

Hilde