It is possible to deploy TFS on Azure IaaS with no on-premises equipment. TFS requires Active Directory service accounts for service authentication, so to deploy in Azure, you will need to configure an Active Directory instance in IaaS. To deploy TFS in Azure, you should:
Normally, you would configure a virtual network to connect machines in a subscription to on-premises resources through a VPN tunnel. However, a virtual network will also ensure you have IP address consistency. The IP addresses managed by an Azure virtual network allow IP address assignment within a known range that you can always depend upon. Azure provides DHCP services for this. Unlike traditional DHCP services, Azure reserves an IP address for the lifetime of a virtual machine. In other words, you can start and stop, reboot a virtual machine and always receive the same IP address from Azure DHCP. If you de-allocate a virtual machine, however, then IP address assignment is lost.
You may naturally think of leveraging Azure Active Directory for this, but that will not work here. Azure Active Directory provides a great way to integrate identity into cloud applications, but it does not have interfaces to support NTLM (Windows Integrated) logins at this time. Azure Active Directory support SAML 2.0, OAuth and other federation protocols to act as a single-sign on solution.
The TFS retail version supports NTLM (Windows Integrated) logins, so you must have Active Directory identities for your users. Service accounts are also used to interconnect TFS components, such as the timer service. This will require a domain account know across servers in the farm, so you will also need AD domain accounts for configuration of TFS services.
When planning your AD deployment, be sure to read through the MSDN article Guidelines for Deploying Windows Server Active Directory.
When using TFS in Azure, one key benefit is the ability to span the globe with your TFS deployment. That involves placing TFS Proxy instances close to developers, while the main farm may be in a completely different data center. However, there is no direct connectivity between any two Azure subscriptions. You need to route connections across subscriptions though an external gateway to achieve this. Today, the easiest way to do this is to route connections through on-premises VPN services. You can do this by using Windows Server Routing and Remote Access as we did in the Rangers guidance, or you can use physical on-premises VPN equipment.
By default, you must have on-premises VPN tunnels to both your primary TFS farm subscription and the subscription hosting your proxy servers. Another recently released alternative is to use Azure ExpressRoute, which has now reached General Availability. ExpressRoute leverages MPLS, a network optimization mechanism which routes connections through an ISP. ExpressRoute can also dramatically reduce the number of hops needed to traverse subscriptions. It will also enable a dedicated circuit with your on-premises data center if needed. For more information, read through the ExpressRoute Technical Overview. Keep in mind, you need to involve an ISP in configuration of Express Route, so you should expect additional charges for your TFS implementation.
In many cases, you may find the TFS capabilities offered through Visual Studio Online will provide the geographically-distributed team support you need. There are some features that VSO does not support today, however, and that’s where TFS in Azure plays a role.
For more guidance on TFS in Azure, please see the newest ALM Ranger guidance announcement on Willy-Peter Schaub’s blog.