By Richard Fennell, Engineering Director at Black Marble and Microsoft Most Valuable Professional (MVP) for Visual Studio (ALM)

As I'm sure many of you know, if you have an MSDN subscription you get some Windows Azure credit each month. The question is how to use this as a developer within a corporate environment where you, as an individual developer, might not have the ability to alter the network infrastructure?

The recent announcement that is part of the Visual Studio 2013 launch means there are great tools to allow you to debug into Windows Azure from the Visual Studio 2013 IDE, but what if you want to use the features of Lab Management?

Lab Management, in both TFS 2012 and 2013, supports two broad modes of operation:

• SCVMM environments – In this mode all provisioning of virtual machines (VMs) is done via System Center Virtual Machine Manager, hence only Hyper-V is supported.
• Standard environments – In this mode the machines in the environment (using any virtualisation stack and/or physical boxes) are managed directly as individual devices on the LAN.

For Windows Azure we can rule out the use of SCVVM, as it currently doesn't support Windows Azure VM management. This means we're left with Standard environments.

However, we still need to remember that for the standard environment to work both the developer’s PC running Microsoft Test Manager (MTM) and the TFS Test Controller need to be able to connect to the Windows Azure hosted VM(s) and the Windows Azure VM(s) need to be able to communicate back to the Test Controller.

This means we need to use some form of VPN, Windows Azure VM endpoints are not enough. But which type of Windows Azure VPN?

Site to Site VPN
Arguably the primary means to do this is to use a Site to Site VPN. 


This is a standard feature of Windows Azure, it allows you to extend your corporate LAN giving you a hybrid cloud. As far as your systems are concerned your local and Windows Azure resources are all on one big network; thus you can make use of your corporate Active Directory and DNS.

Using this model your TFS Lab Management can make use any local SCVMM resources, local standard environment as well as Azure hosted standard environments ones.

You have the choice where you place your Test Controller, it is all one big network after all. It can be at either side of the VPN, or both. You can have multiple test controllers in you system, choosing the most appropriate location for your environments, to minimise VPN traffic.

The problem with this solution is that it involves configuration of the corporate firewall (with a fairly short list of supported firewalls) and the use of a single Azure subscription. You can't ‘pool’ all the developers’ MSDN Azure benefits onto one MSDN subscription.
So this model is perfect for a corporate implementation, with a single Enterprise Agreement Azure Subscription, with the discounts this brings, but maybe inappropriate for many smaller development teams.

So what can you do if you just want to use your MSDN Windows Azure benefits and not bother your IT department?

Point to Site VPN

The answer is to use a point to site VPN, this is a new feature on Windows Azure current available in CTP.


With a point to site VPN, the VPN goes from your Windows Azure subscription to a single PC endpoint. Assuming the VPN is from the developer’s PC, the developer alone can access the Windows Azure hosted VM(s). A point to remember here is that if the developer connects out to the internet via a company firewall, the firewall needs to allow VPN traffic to pass through it. This should not be an issue over home ADSL links or the like.

The issue with this model is that only the developer with the VPN link can see the resources in their Windows Azure subscription. However, remember that each developer could have their own Point to Site VPN linked to their own Windows Azure subscription, so this does scale to allow use of many MSDN Windows Azure benefits.

This lack of shared usage can be a bit of a problem, as if you wish to make use of Standard Lab Management environments you need to make sure that it is possible for both the Test Controller and the developer’s PC (running MTM) can access the VPN to be able to configure the Windows Azure VM(s) in the new environments.

Put simply, this means that the Test Controller needs to be on the same PC as the developer is using for MTM; or that both the developer’s PC and the Test Controller have their own instances of the same Point to Site VPN (i.e. to the same Windows Azure subscription) so they can communicate independently – I've not tried this in practice with Lab Management, but initial trials show this is an allow configuration.

So this all sounds good, we can get suitable access to create a new environment without the need to bother the IT department, but what's the downside?

• We're looking at an increase in the number of Test Controllers, one per developer, or some complex multiple VPN work for a single Test Controller.
• We're opening links to Windows Azure from PCs on your corporate LAN, this might be blocked by your company firewall or at least a questionable activity in the eyes of the firewall manager.
• Finally and probably the worst pain point is that of DNS resolution. You need to make sure the Windows Azure VM(s), developer’s PC and Test Controller can all resolve the each other by name, not by IP address. When you create the standard environment you can give the VPN IP address of the Windows Azure VM, but when the Test Controller tries to install the test agents, it is the VM name that will be used, and the test VM will try to call back to the Test Controller also by name. In practice I think this means editing the host files on the Test Controller and Windows Azure VM(s) to add the required entries; it is simple and it works. You can of course provide a DNS service on one of the machines in the setup, but this is getting more complex, and probably pushing you towards a Site to Site VPN.

So this is not a perfect solution, there's work to do, but it does provide another means to make use of your MSDN Windows Azure benefits from within your corporate LAN without too much network reconfiguration. Providing a methodology that allows you to make use of the automation and traceability that TFS Lab management provides to control Windows Azure resources