Hyper-V for Developers Part 2

In Part 1 of this series we detailed a number of infrastructure tasks for getting your Client Hyper-V environments up and running quickly on a Windows 8 developer workstation.  With this post we will focus inward into our datacenter simulation and complete the work necessary to prepare for simulation of real-life application deployment scenarios.

What do you mean I can’t cut and paste into a VM?!?

One of the earliest pain points developers discover when using Hyper-V virtual machines is that unlike some other popular desktop hypervisor products the Virtual Machine Connection (VMC) does not allow files to be cut and paste from the host machine into a virtual machine.  Out of the box the options under the Clipboard menu of a virtual machine connection simply allow us to virtually type text via the Type clipboard text command.  These limitations have been the “way it is” for sometime

So what is the intrepid developer to do in order to copy his or her files into a VM for the purposes of installation, application deployment, or whatever other file transfer tasks are required? Enter the Internal Network to the rescue.  In Part 1 you may remember I showed that one of my two standard Hyper-V virtual switches is called Guest2Host which I configure on an internal network.  Now let’s setup a internal network between our APP1 server and the Windows 8 host machine.

First shutdown the APP1 server and navigate to the Hyper-V settings for this VM.  Under the Add Hardware section add a second virtual NIC to this server and set this NIC to be connected to the Guest2Host virtual switch.  Your setup should resemble the screen clipping below.

Network Setup

Now startup the APP1 server and login via the VMC.  A quick glance at the desktop wallpaper will show that the newly added NIC on the internal network has obtained an auto-configured address (which is actually working by design as part of RFC 3927).  This may be familiar to some people who have seen this type of address before when their PC experiences difficulty obtaining a lease for a new address on a DHCP network.  We are going to use this address as a means to access our VM’s from our Windows 8 host.

169.x Internal IP

From the Windows 8 host PC bring up a the RUN command via Windows+R keyboard shortcut and type a command similar to the one below based on your pseudorandomly assigned 169.x IP address and press the ENTER key.


Shortly you will be greeted with an authentication dialog similar to the screen clipping below.  What is happening here is that we have attempted to access the hidden administrative share for the C:\ volume on our APP1 VM from our host machine.  If we use the local administrator credentials for the VM of APP1\Administrator and the associated password we will have access to the guest virtual machine file system from our host via familiar Windows Explorer.

Authentication Dialog

One you complete the authentication you can save a desktop shortcut to this administrative share or create a dedicated fileshare within the VM such as “CodeStaging”.  For all intents and purposes you have simply mapped a network drive to your VM from your host machine and you may now easily copy files back and forth or use other programs that can accept a UNC path (such as the publish web site feature of ASP.NET from Visual Studio for example).

Creating the Active Directory

All of our servers created thus far are standalone member servers.  Since we wish to emulate a corporate style network as closely as possible it is time to create an Active Directory or AD.  The AD is defined as follows “The data structure and services that provide organization, management, and security of accounts and resources in a Microsoft network”.  In a nutshell the AD will allow our applications to use domain service accounts and leverage Windows integrated authentication along with providing other useful services like DNS, Security Groups, LDAP, etc. 

In order to create our domain we need to login to the DC1 server and bring up the server manager.  Under the option to Configure this local server select Add roles and features. Click the Next > button three times until you reach the server roles screen.  Check the box Active Directory Domain Services which will spawn a pop-up window so click Add Features and then click Next > three more times until you are at the summary screen.  Click the Install button.


Wait for the feature installation to complete.  Do not yet click close.  Instead you will notice hyperlinked text that offers to Promote this server to a domain controller which is highlighted in the screen clipping below.  Click this hyperlink.


The Active Directory Domain Services Configuration Wizard will start and allow us to quickly create a new AD forest and promote this VM to a domain controller.  Select the Add a new forest radio button and specify the root domain name.  In the screen clipping below I use the fictitious company “Contoso” and specify CORPNET.CONTOSO.COM as the FQDN for my new domain.  Click Next > to continue.


Now we need to configure the domain controller options.  If you are only planning on adding Windows Server 2012 machines to this domain in your simulation you can leave the Forest and Domain functional levels set to Windows Server 2012.  Otherwise select the oldest server OS you plan to add to the domain in both dropdown menus.  If you are curious want this is doing take a quick read on TechNet over here. Click Next > two more times to continue.


You will be presented with an option to verify or change the domain NetBIOS short name.  If you have every joined your developer workstation to a domain before and specified a NetBIOS style name for the domain here is where that value originated.


Click Next > three more times to continue to the Prerequisites Check screen.  Now might be a good time to go grab a beverage and a smile perhaps checking the weather outside.  Once complete the screen on the wizard will resemble the screen clipping below.


Click Install to create your domain and promote the server to a domain controller.  Please note there are many configuration options in this wizard that were glossed over most of which can be reconfigured at a later time if you are attempting to mirror the settings your companies’ corporate network.  You may also note the warning about the lack of a static IP address for the domain controller which occurred because the screen clipping was taken before this server was configured with the static IP address specified in Part 1 of this series.  Once complete the server will reboot.

The local administrator account we were using on the DC1 server has now been promoted to an Enterprise Domain Administrator account and we can login to the server specifying CORPNET\Administrator as the username and the same password we used for the local administrator account earlier.  This account is the highest privileged user account in our new domain.  With great power comes great responsibility so let’s be careful okay?

Our last step here is to join our member severs APP1 and APP2 to our newly minted CORPNET.CONTOSO.COM domain.  Login to the APP1 server via the VMC.  Bring up the Server Manager and click on the Local Server icon. 


Next click on the WORKGROUP hyperlink to change from the default workgroup and specify our domain.  This will bring up the System Properties dialog.  Click the Change button to specify our domain and enter the NetBIOS name we created for the domain earlier as CORPNET.


Next click OK.  Since we are logged in with the local APP1\Administrator user we will need to provide a domain user account who has the rights to add a member machine to the CORPNET domain.  Specify our all powerful enterprise domain account created earlier as CORPNET\Administrator.


Click OK and await confirmation of the domain join. 


We’re all set with the APP1 server!  Click OK and reboot this server.  Upon reboot validate the domain connectivity by logging in with the CORPNET\Administrator domain account instead of the APP1\Administrator local account.  It’s time to repeat this exercise for the APP2 server but this time let’s use PowerShell to automate the domain join.  There are a couple ways to perform this task and I suggest the PowerShell 2.0 method even though PowerShell 3.0 is available on my Windows Server 2012 machine because the commands as described nicely here on the Scripting Guy’s blog work across any recent flavor of Windows.



Upon rebooting validate the APP2 domain membership by again logging in with the CORPNET\Administrator domain account.

Setup the APP Servers as Web and Application Servers

I typically setup my application servers employing a combination of Web and Application server features.  It can be somewhat tedious to repeat this exercise so I strongly suggest moving through the Add Roles and Features wizard to add the Application Server and Web Server (IIS) roles along with other components you may need for WCF, WAS, MSMQ, debugging, etc.  Once you have selected what is needed export the configuration options to XML and cancel out of the dialog.  We’ll perform the installation via PowerShell on both the APP1 and APP2 servers programmatically so that they are identically configured.

One benefit of this approach is that it’s feasible for your operations team to export the feature configurations on your organizations production machines and import them right into your virtual machines.  No guess work required to determine if your virtual environment is configured as the production server may be configured.

In the screen clipping below I have highlighted the hyperlink text that will allow us to export our Web/App server configuration to an XML template file.


In this case I have saved off the file on the APP1 server to C:\AppServerDeploymentConfigTemplate.xml.

Now to install the features from this template, open a PowerShell command prompt and type the following command:

Install-windowsFeature –ConfigurationFilePath C:\AppServerDeploymentConfigTemplate.xml

That’s it! In a few moments you will have a server fully configured per your XML template specification.


Confirmation of success or failure for adding the Roles and Features.


Repeat this exercise for the APP2 server and note that UNC style paths are supported on the –ConfigurationFilePath switch so it’s possible to reference the configuration file from a central location such as a fileshare.

A special note on the .NET Framework 3.5 framework installation on Windows Server 2012.  If you need the .NET 3.5 bits for your application or for a client component such as SQL Server Management Studio you will need to have installation media handy such as an ISO image for the Windows Server 2012 OS.  As an example assuming the ISO for Windows Server 2012 is mounted as the D:\ volume on the APP1 and APP2 servers, you can run the following command to install the .NET 3.5 Framework:

Dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Additional details of .NET Framework 3.5 related installation woes on Windows Server 2012 are available here.

The Speed of Light

One of the most difficult tasks for developers to simulate when building, testing, and debugging applications is determining how their applications will deal with network latency and anomalies.  As more and more applications become decentralized pulling in data from a combination of on premises and cloud based sources it becomes all the more important for applications to be resilient to real world network conditions.  Wide Area Network (WAN) simulation is particularly difficult to simulate.  There are expensive devices form a host of communications companies that offer both WAN simulation and acceleration but unfortunately the vast majority of developers don’t have access to labs outfitted with this type of gear.  As often is the case the open source community comes to the rescue with a small and fascinating open source project called WANEM or the Wide Area Network Emulator.

This project was built to address the problems describe in he preceding paragraph from a LAN perspective so why not employ this tool within our Client Hyper-V environment?  In a nutshell WANEM is a Knoppix Distro Linux based software router built in the same vein as the Windows Server Routing and Remote Access Feature (RRAS) discussed earlier in Part 1 of this series.  There are features in the 2.3 release of WANEM however that prove interesting for developers such as configurable latency, packet loss, network jitter, and all sorts of additional simulations we can provide for our Client Hyper-V server farm.  So let’s swap our existing RRAS ROUTER1 server out for a CD ISO based Linux Distro and see what happens.

First things first you will need to download the WANEM 2.3 ISO image from SourceForge over here.  I save this ISO off to the C:\ParentDisks directory on my setup.  Next you need to shutdown or save the existing ROUTER1 server that is acting as the bridge between our APP1 server on the 10.x subnet and our APP2 server on the 20.x subnet.  This will effectively break our network bridge between the APP2 server and it’s domain controller on the DC1 server as well as its sister APP1 server – but just for a little while so don’t worry the APP2 server will be just fine.  As a quick note if you elect to save (pause) the ROUTER1 server you are essentially persisting it’s memory state to disk so you can quickly resume it later if needed (similar to hibernation of your PC).

Let’s create the Linux WANEM router.  Head over to the Hyper-V manager and select New->Virtual Machine and name the virtual machine WANEM. 


Next assign 512MB of RAM to this server which should be more than enough.  If needed I have run WANEM with as little as 256MB if memory is tight in your environment.  Click Next > to navigate to the Configure Networking Screen and select Not Connected (more on why in a moment).


Since WANEM is ISO based we do not need a virtual hard drive.  On the Connect a Virtual Hard Disk screen select the radio button Attach a virtual disk later – which of course we will never really do.


Click Next > once more and Finish to create the virtual machine.  Now select Settings from the WANEM virtual machine we just created.  By default the virtual machine is configured to boot from a CD which is ideal since WANEM is distributed as an ISO image.  Keep in mind that Hyper-V virtual machines can boot from a number of sources including the network!  Examples of other boot options are shown in the following screen clipping.


Select the IDE Controller 1 virtual DVD drive and check the radio button Image file providing the path to the WANEM ISO file as show in the screen clipping below.


Next we need to add a number of virtual NICs to the WANEM virtual machine to provide the bridge between our networks similar to what was performed with RRAS in Part 1 of the series.  We are going to remove the existing network adapter add three legacy network adapters (it is important to choose legacy network adapters as the WANEM Linux Distro has drivers that work with this type of virtual NIC and not the Network Adapter virtual hardware).

  1. eth0 – For the gateway
  2. eth1 – For the gateway
  3. eth2 – For NAT out to the Internet using our Guest2External virtual switch


When completed your setup should resemble the following screen clipping.


The setup is complete for the virtual machine.  Select start from the Hyper-V Manager and boot the WANEM virtual machine.


ZOMG we have penguins!  Don’t worry they are just cute and cuddly and more than safe inside Hyper-V.  Press any key to boot the image or wait a few moments and the WANEM software will load.  Now before you go clicking into this VM there are a few things to discuss.  We have no ability to install Hyper-V guest additions because we are booting from read-only media.  This means that we have no mouse  integration support just the good ole’ trusty keyboard.  Once we click into this VM our mouse will be captured and in order to get the mouse control back to our host Windows 8 PC you will need the key combination CRTR + ALT + LEFT ARROW to have the VM release your mouse.

At the boot screen of WANEM select the ‘n’ for NO option to configure all devices using DHCP.


This will bring us up to the configuration screen for WANEM.  Anyone else feel like they need to go out and rent the movie Wargames now?  I know, I know everyone streams movies these days right?  Ah the memories…


Remember earlier what order we added the NICs as those get mapped to eth0, eth1, and eth2 devices.  Hit the ENTER key to bring up the configuration for the eth0 device and key the information in per the screen clipping below.


Hit RETURN once more an select ‘y’ to save the configuration.  I am getting all misty eyed at this point with fond memories of my college days in front of an HP-UX terminal programming FORTRAN – but I digress the UEFI BIOS on my Core i7 PC doesn’t look much better than this and that was built just last year.  Next hit the down arrow to select the eth1 device and configure it as follows.


Similarly hit RETURN and ‘y’ to save the configuration.  Hit the down arrow selecting the eth2 device and this time hit RETURN but select ‘y’ for DHCP configuration.  In my setup this adapter is plugged into the Guest2External virtual switch which is connected to my home Wifi network at the moment so we’ll just grab an IP address on the Wifi to allow our guest virtual machines to NAT out to the internet.  Hit RETURN and ‘y’ to save the configuration.  Hit ‘s’ to save and exit this screen which will lead to the final setup and configuration of WANEM (this can take a few moments).

Eventually we’ll be prompted to specify a password for the SSH server that is available for remote configuration of WANEM from a client machine (don’t worry there is a web interface too just like your home router).  Supply the password and hit RETURN which will bring us to the mini-shell for WANEM.  Type ‘help’ to get a list of available commands.


As a test type ‘status’ to see a report on our configuration and to bring up a test network connectivity command.  Enter the IP address of our domain controller on the DC1 server at to validate our connectivity.


It works!  Now we can setup NAT for our virtual machines by typing the ‘nat help’ command and specifying our eth2 device as the NIC we want to use for NAT.  To verify NAT is working open a web browser on any of our servers and attempt to reach an internet web site.


Finally login to the APP1 server and let’s attempt to ping the APP2 server.


Interesting. So first off all the network works, and that is great and all, but you may have noticed there is already a small amount of latency which is undoubtedly from the overhead of the WANEM server running on one virtual CPU boxed up in our Hyper-V environment.  Let’s add some serious latency between the 10.x and 20.x networks now via the WANEM web interface.  Bring up Internet Explorer on the APP1 server and navigate to the URL and note this is CASE SENSITIVE (any IP address in use by WANEM will work as well such as


Next click on the Basic Mode link and select the eth0 interface and enter 50ms of latency on this adapter and click the Apply settings button per the screen clipping below.


Finally return to the APP1 server and repeat the ping command.


Wow!  The speed of light isn’t so fast now is it within our virtualized network.  Most of the pings above took approximately 53ms to reach their destination from APP1 to APP2.  There are many other features to explore such as constraining the bandwidth of your connection as well as a host of other mean things to experiment with such as configuring packet loss.  Some examples are shown below of configuration options via the web interface.



One last and important note regarding the WANEM virtual machine.  Since this VM is not based on a virtual hard drive there is no means to ‘shut down the server’ so to speak.  The only options are to turn off the virtual machine and lose your configuration or save the virtual machine state.  Similar to what we did with the ROUTER1 server we can put the WANEM virtual machine in a state of suspended animation when it is not being used.

In Conclusion…

At long last our work with the basic infrastructure components in our Client Hyper-V environment is completed.  We have the means to create any number and configuration of various servers, networks, file transfer, and WAN simulation all within Client Hyper-V on our sandboxed developer workstation.  By no means have we covered all of the possibilities to simulate infrastructure within Client Hyper-V but what we have covered should allow the developer to build out most common types of infrastructure for a variety of applications.

In Part 3 of this blog series we focus on the developer portion of the title of our series and perform the following tasks:

  1. Setup a three subnet (multi site) SQL Server 2012 AlwaysOn cluster
  2. Deploy an availability group across the three nodes with one synchronous and asynchronous replica
  3. Test a simple application that utilizes the new MultiSubnetFailover and ApplicationIntent SqlConnection connection string keywords and see how the application responds to cross-subnet failovers while running.
  4. Demonstrate the SQL Server 2012 Availability Group read only routing feature and how applications can be resilient to a SQL Server failover.

Stay tuned and thanks for reading.


Comments (1)

  1. That is pretty cool!  Usually we don't want network latency but in some cases we cannot avoid it.  Great series.


Skip to main content