How I Use Azure IaaS for Lab VMs

   Many years ago I posted How I Blog walking through my blogging process.  Over the past few months many of my coworkers and customers have been talking or asking about how to use Azure IaaS for dev / test environments (especially for SharePoint).  In this post I’ll walk through the configurations I use, tools that have helped me, and other tips.

Note: This is not meant to be a post on best practices for rolling out your Azure IaaS infrastructure to support SharePoint.  This is just my current setup as an reference example for others to learn from.  For some best practices please read Wictor Wilen’s post on Microsoft Azure IAAS and SharePoint 2013 tips and tricks and listen to the Microsoft Cloud Show podcast interview  Episode 040 – Talking to Wictor Wilen about Hosting SharePoint VMs in IaaS he participated in.



   For over 6 months now I have been running my primary set of lab VMs in Azure Infrastructure as a Service (IaaS) VMs.  Prior to using Azure VMs I had been using Hyper-V on my laptop (either dual booting into a server OS or the latest iteration on Windows 8 / 8.1) but was always limited by machine resources.  Even with a secondary (or tertiary) solid state hybrid drive (this is a newer version than what I currently have in my laptop), 24GB of RAM, and quad core i7 it seemed like I was always juggling disk space for my VHDs or CPUs / RAM for my VMs.  Battery life in a hulking laptop like I had is very short and the weight can easily cause strain on your back when carried in a backpack.  Nowadays I carry a Lenovo T430s which cut the weight down to almost 1/3 of my old W520.



   I host 4 SharePoint farms (along with a few one-off VMs) in Azure IaaS using my MSDN benefits.  My MSDN benefits include $150 Azure credit per month, 10 free Azure websites, and a host of other freebies.  My farms includes a SharePoint 2007 farm, a 2010 farm, and two 2013 farms.  I tried to make the configuration between farms as consistent as possible.  As such I have a single Windows Server 2012 domain controller that also hosts DNS for all of my VMs and a similar 2 server topology for SQL Server and a SharePoint App / WFE server in each farm.

Note: The names and sizes for Azure IaaS VMs have changed since I first rolled them out (remember the days of small / medium / large / extra large for you early adopters?).  The Azure folks seem to have standardized on a naming schema of “A” followed by a number now which I appreciate but there is always a chance that things could change again in the future.  As such the names and sizes I list will be what is currently offered.



  • Domain Controller – I use an A0 instance (shared core, 768 MB) running Server 2012 with a (mostly) scripted out configuration.  This includes all of the SharePoint service accounts, OUs, and test accounts that I use.  If something were to happen to my domain controller I could easily spin up a new one very quickly.  I have talked with a few coworkers who host their AD infrastructure in a Windows Azure Active Directory instance.  I am not as familiar with AD in general so I stick with what I know and get by with the PowerShell commandlets I need to spin up my domain controller.
  • SQL Server – I typically use an A2 instance (2 cores, 3.5 GB) running SQL Server 2012 (except for SharePoint 2007 which runs SQL Server 2008 R2).  If I am trying to roll out business intelligence features like SSIS, SSAS, etc. I will increase the VM up to an A3 (4 cores, 7 GB).  I also have a SQL Server 2014 VM for my secondary SharePoint 2013 farm which is running the latest and greatest of everything (OS, SQL, patch level, etc.).
  • SharePoint Server – I run both SharePoint WFE and APP roles off a single A3 instance (4 cores, 7GB) running Server 2012 during normal operation.  Similar to my SQL limitation on the SharePoint 2007 farm I am running Server 2008 R2 for that farm.  For my 2013 farm this machine also hosts Workflow Manager 1.0 and Visual Studio 2013.  If I need extra horsepower or am running all SharePoint services (or even just SharePoint search) I will increase this to an A4 (8 cores, 14GB).  I also have (almost) the entire SharePoint install and configuration scripted out.
  • Office Web Apps – While it is technically not supported to run Office Web Apps Server 2013 in Azure I do have a working scenario for one of my SharePoint 2013 farms.  This VM is an A2 instance (2 cores, 3.5 GB) running Server 2012.


Virtual Network

  • I originally created a separate network for each farm, but after deciding to utilize a single shared domain controller for all environments I instead switched over to just a single virtual network.  This happened before the announcement of being able to create connections between virtual networks and I haven’t revisited this item.
  • Special tip on virtual networks.  When I first configured a virtual network in my environment I removed the Microsoft DNS IP address that was automatically assigned and instead put the “local” IP address for my domain controller.  This resulted in losing outgoing internet connectivity for all of my VMs.  I had to delete and recreate my virtual network with a working scenario (see below) of the default Microsoft DNS and then my domain controller IP to handle intra-VM communication.




  • Azure portal –  This is the new Azure portal design that presents a customizable view into your Azure components.  Not all of the features are currently supported but Azure web sites, IaaS VMs, and a few others are accessible.  For the older “full” portal site check out
  • Azure Commander – This is a universal app for Windows 8.x and Windows Phone 8.x from Wictor Wilen.  This app costs a few bucks but is absolutely worth it in my experience.  You can import your subscription file and then be able to stop, start, and view your VM instances (along with a few other Azure resources) on either your phone or PC.  I find this very helpful when I am presenting at a customer or conference using my Azure VMs and then need to pack up quickly and head out the door or to my next session.  I can quickly and easily stop my VMs from my phone as I head on my way.


Windows Store:

Windows Phone Store:



  • Portability – As mentioned previously I no longer need to lug around a laptop + power adapter that are 10+ pounds.  Instead my new laptop and power adapter are closer to 4 pounds.  I can also launch my VMs, kick off some processes, and then shut my laptop and go to another conference room or head home.  When I get there to my destination I pop up my laptop and my VMs are still running and ready for me to resume work quickly.
  • Flexibility – When I need to tear down and rebuild farms / servers I don’t have to worry about storage or other resources.  Previously when I wanted to rebuild a farm I would have to move VHDs or delete old ones in order to make space for the new set before I could delete the old set.
  • Connection speed – The primary source of software and applications on my VMs comes from the MSDN subscriber downloads.  There must be a mirror of all the products sitting in the rack next to my VMs because on average I get download speeds of 10-50MB/s (yes that is megabytes not megabits).  Download a copy of the SQL Server 2014 ISO takes minutes instead of hours now.
  • Cost – As mentioned above my MSDN benefits include $150 per month to use as I see fit on Azure.  On average I run my VMs for 5-8hrs a day for 5-10 days  in a month.  Overall with storage, bandwidth, compute, and other costs I rarely spend more than $50 of that $150 credit.  Compared with the electricity costs that I could be incurring from running local VMs in Hyper-V I’ll take my “free” MSDN VMs any day.



  • Lack of snapshots – Currently there is no concept of taking a snapshot of a running VM in Azure.  You can shut down a VM and copy the VHD blob to another storage account or download a local copy (quite a hefty download) but these don’t work as well when you need to set up a demo and capture it at a specific point so that you can roll back if needed.  With the pace of how quickly the Azure team is rolling out features and new innovations who knows if this might make it into a future release.
  • Require internet connection – Despite being in the age of fairly ubiquitous broadband and 4G signal there are still times that I am without a good internet connection.  As a backup plan when I don’t have an internet connection or good 4G signal on my MiFi device I do have Hyper-V with a local set of VMs on my laptop.  I use them maybe once a month if that.
  • Limit of cores (for MSDN subscribers) – This is not a limitation for me but it is worth mentioning since some of my fellow PFE coworkers have brought it up.  If you are using your MSDN Azure benefits you are limited to a total of 20 cores allocated to your VMs at one time.  The most I use at any time is 14 and that is when I have increased the size of SQL and SharePoint and have Office Web Apps running which is rare.  For some of my coworkers though they need to run lab environments with a dozen or more VMs to replicate deployments of Lync, Exchange, AD, SharePoint, and more and can easily use upwards of 80 cores.  For them their MSDN benefits are not sufficient to run their lab environments.



   I was hesitant about using Azure VMs due to fears about racking up costs that I (not my employer) would have to pay along with having to learn a new platform and set of tools.  Now I couldn’t imagine having to go back to running my lab environments locally full time.  Hopefully some of the tips and processes I covered in this post will encourage you to check out Azure as a replacement for your on-prem dev / test lab environment.  You can even get a 1 month Azure trial to try out $200 worth of services.


      -Frog Out

Accessing Host Machine Files From Hyper-V Guest Virtual Machine

   Similar to a previous post I wrote on How To Configure Remote Desktop to Hyper-V Guest Virtual Machine I commonly get questions for “how do I access Hyper-V host machine files from inside a guest virtual machine?”  The solution I use is a combination of software and configuration but there are many other options as well.


   When connecting to a Hyper-V guest virtual machine you cannot easily transfer files into or out of the virtual machine.


   For almost all of my remote desktop needs I use a program called mRemote (Multi Remote).  The original mRemote developer has joined a new company and folded mRemote into a new product but you can still download a stable build of mRemote from CNET here.  There is also a forked version called mRemoteNG (Multi Remote Next Generation) that I have not tried out personally.

   One of the nice features of mRemote is that you can configure an RDP connection to map local host drives so that they are available inside the RDP session.  By RDP’ing to a virtual machine with the host drives mapped you now have access to transfer files into or out of the virtual machine.  Open mRemote and configure your RDP session as normal.  Under the Redirect heading change the Disk Drives setting to Yes as in the screenshot below.


   As an added bonus mRemote also allows you to store credentials to use for an RDP connection.  I find this very helpful to avoid having to retype credentials every time I bring up a virtual machine, especially with how many fake demo domains I deal with in various virtual machine farms I build out.

   When you connect to this RDP session you may be prompted to allow the remote desktop connection to access local resources (I do on Windows 8 at least, I didn’t previously on Windows 7).  Make sure to allow the Drives resources to be accessed.  If anyone knows a way around this prompt I would be interested to hear as I have not found any yet.


   After connecting to the virtual machine you now have access to the host machine drives.  See the example below.




   As I stated earlier there are a number of ways you can solve the issue of not being able to access host machine files inside a Hyper-V guest virtual machine.  My solution is a combination of RDP session with the mRemote application and configuring the RDP connection to map local host drives into the RDP session.  If you have other solutions or tips feel free to leave them in the comments below.


      -Frog Out



How To Configure Remote Desktop to Hyper-V Guest Virtual Machine


mRemote download from CNET


mRemoteNG project

4 Reasons Why You Should Use SYSPREP

    If you build virtual machines running Windows operating systems and aren’t using SYSPREP you are costing yourself untold amounts of time.  This post will explain be a brief explanation as to why.


    Over the past few weeks I’ve been rebuilding about a dozen of my virtual machines (VMs) due to getting a new work laptop and finally having the hardware to run 3+ of them at once.  The last time I went through a rebuild of VMs like this I started to dig into using SYSPREP so reduce the amount of time.  For those unfamiliar, SYSPREP is a Microsoft utility that allows you to create a single base VM using the operating system (OS) of your choice and then clone that VM as much as you want.  By itself that may not sound like much but in addition to cloning the OS you also carry over any of the system updates applied, applications installed, and most other configurations you perform.  This will be a very important point to keep in mind.


  1. Windows Updates – If you’ve ever installed a fresh Windows operating system and then gone into Windows Update you’re probably familiar with being greeted by a double digit (sometimes even triple digit) list of updates to apply.  SYSPREP allows you to install those updates just once on the base image and then all cloned VMs will already have them installed.  In my situations dozens of hours of Windows Updates are reduced to just an hour or two.
  2. Reduce install time of OS and applications – To a certain degree there is no install time.  When you SYSPREP a machine you can choose an option to generalize the install.  This means stripping out the SID and other personalization, so that when it reboots you can treat it like an entirely new machine with only minor configurations needed to get started.  Applications that you install on the base image are also carried over to cloned VMs.  There’s nothing like trying to sort out and remember all of the various 3rd party installs that you put onto your VMs.
  3. Quickly expand server farm – Most of the applications I work with (SharePoint specifically) are deployed to a server farm.  With my new hardware I am able to run multiple web front end servers (WFEs), additional “client” machines, and other configurations that were previously not possible.  If I want to spin up a fresh WFE I can clone the base image, join it to the farm, and be rolling in 30 minutes instead of hours it would take to create a fresh VM.
  4. Consistency – Consistency may not sound like a big deal, but when you are dealing with complex applications like SharePoint one less variable can mean far fewer headaches.  When you know that all of your VMs come from a base starting point that reduces overall variance.


    All said and done I can honestly say I’ve saved myself days (literally) of effort by using SYSPREP.  I keep a copy of Windows 7, Server ‘03 R2, Server ‘08, and Server ‘08 R2 in the before, during, and after stages of SYSPREP.  The before stage is important so that in a few months when more updates are released I can just apply them to that image and create a new base image to use instead of starting all over from scratch.  Hopefully after reading this post I’ve convinced you to at least look into SYSPREP if you’re not using it already.


      -Frog Out

How To Configure Remote Desktop To Hyper-V Guest Virtual Machines

<Update 6/7/2010 with feedback from Kelly Jones on network adapters />

Configuring Remote Desktop (RDP) from a host Hyper-V machine to a guest virtual machine can be tricky, so this post is dedicated to the issues and resolution steps I went through to allow RDP.  Cutting to the point, below are the things to look for followed by some explanation about my scenario if you care to read.  This is not an exhaustive list of what is required, just the items that were causing problems for my particular scenario.


  1. Allow Remote Desktop Connections in guest OS.
  2. The network adapter type must allow communication with host machine (e.g. use an “Internal” or “External” virtual adapter.)
  3. If running Server 2008 R2 on guest, network discovery mode must be turned on.
  4. If running Server 2008 R2 on guest, the services supporting network discovery mode must be running:– DNS Client – Function Discovery Resource Publication

    – SSDP Discovery

    – UPnP Device Host

My Environment

A quick word about my environment.  I am running Windows Server 2008 R2 with Hyper V on my laptop and numerous guest VMs running Windows Server 2003 R2 or Windows Server 2008 R2.  I run a domain controller VM and then 1 or 2 SharePoint servers depending on my work needs.  I’ve found this setup to work well except when it comes to the display window for my VMs.

The Issue

Ever since I began running Hyper-V I haven’t been able to RDP to my guest VMs which means the resolution for my connection windows ha been limited to what the native Hyper-V connections allow.  During personal use I can put the resolution up to 1152 x 864, but during presentations I am usually limited to a measly 800 x 600.  That is until today when I decided to fully investigate why I couldn’t connect via RDP.

First a thank you to John Ross (@johnrossjr), Christina Wheeler (@cwheeler76) and Clayton Cobb (@warrtalon) for various suggestions while I was researching tonight.  As it turns out I had not 1, not 2, but 3 items preventing me from using RDP.  Let’s dig into the requirements above.

Allow RDP Connection

This item I had previously taken care of, but it bears repeating because by default Windows Server 2008 R2 does not allow RDP connections.  Change the setting from “Don’t allow…” to whichever “Allow connections…” setting suits your needs.  I chose the less secure option as this is just my dev laptop.


Network Adapter Type

When I originally configured my VMs I configured each to use 2 network adapters: one using the physical ethernet adapter for internet use and a virtual private adapter for communication between the VMs.  The connection for the ethernet adapter is an “”External” adapter and (as my co-worker Kelly Jones pointed out in comments below) does allow connections between host and guest.  After he pointed this out though I realized that my ethernet adapter is not always reliably enabled (power cord not in disables NIC.)  As such I need a secondary adapter that will always be on to connect the host and guest.  The virtual private adapter I had allowed communication ONLY between the VMs and not to my host.  There is a third option “Internal” which allows communication between VMs as well as to the host.  After finding out this distinction I promptly created an Internal network adapter and assigned that to my VMs.


Turn On Network Discovery

Seems like a pretty common sense thing, but in order to allow remote desktop connections the target computer must able to be found by the source computer (explained here.)  One of the settings that controls if a computer can be found on the network is aptly named Network Discovery.  By default Windows Server 2008 R2 turns Network Discovery off for security purposes.  To enable it open up the Network and Sharing Center.  Click “Change Advanced Sharing Settings” on the left.  On the following screen select “Turn on network discovery” for the currently used profile and click Save Settings.  You may notice though that your selection to turn on network discovery doesn’t save.  If this is the case then you most likely don’t have the supporting services running (as was my case.) ConfigureRDPHyperVGuest4


Network Discovery Supporting Services

There are a total of 4 services (listed again below) that need to be running before you can turn on network discovery (explained here.)  The below images highlight these services.  In my guest VM I found that I had DNS Client already running while the other 3 were disabled.  I set them all to enabled and started the ones that were stopped.  After this change I returned to the Sharing settings screen and found that Network Discovery was turned on.  I’m not sure whether this was picking up my attempt to turn it on previously or if starting those services turned it on.  Either way the end result was a success.

– DNS Client

– Function Discovery Resource Publication

– SSDP Discovery

– UPnP Device Host

ConfigureRDPHyperVGuest2 ConfigureRDPHyperVGuest3

Before and After Results

The first image is the smaller square shaped viewing window used by the Hyper-V native connection.  The second is the full-screen RDP connection in all its widescreen glory.

ConfigureRDPHyperVGuest6 ConfigureRDPHyperVGuest7


Over the past few months I’ve found Hyper-V to be very useful for virtualizing my development environments, but I’ve also had a steep learning curve to get various items configured just right.  Allowing RDP connections to guest VMs was one area that I hadn’t been able to get right for the longest time.  Now that I resolved these issues I hope that others can avoid the pitfalls that I ran into.  If you know of any other items I left off feel free to let me know.


-Frog Out



Turning on Network Discovery

Services required for Network Discovery