Chapter 15
Azure Connect
What’s in This Chapter
- Defining Windows Azure Connect
- Exploring Windows Azure Connect versus Service Bus
- Understanding Windows Azure Connect fundamentals
- Setting up Windows Azure Connect
- Troubleshooting Windows Azure Connect
In cloud computing, many developers and their corresponding applications and infrastructure may not move to the cloud overnight, if at all. There may be a number of factors including security, latency, business requirements, functionality, or performance requirements that may require an on-premises deployment. However, these developers may still benefit from the Azure Cloud by finding a way to bridge their on-premises and cloud components. To connect to on-premises resources or applications, Windows Azure provides the Windows Azure Connect technology that makes connecting the Azure cloud to an on-premises resource as easy as a simple configuration. Without Azure Connect, you need to create and maintain secure connections, authentication, authorization, and troubleshooting between Azure and your on-premises resource, which takes valuable developer and IT professional time.
What Is Azure Connect?
One of the major blockers in moving to the cloud has been the capability to support a hybrid model between private clouds and public clouds. There may be instances of workloads that cannot move from on-premises servers to a public cloud infrastructure because of a myriad of reasons ranging from technology to policy and compliance reasons. To help remove this blocker, the Microsoft Azure team introduced Azure Connect. Azure Connect is similar to an on-demand virtual private network that connects your Azure instances to your on-premises computers. Azure Connect enables you to connect public and private clouds without having to worry about setting up complex infrastructure including IPSec, IP addresses, and other complexities. Azure Connect also enables location transparency; you do not need to know which Azure cluster you connect to: The software does all the location awareness, negotiation, and setup of the infrastructure layer. For example, you can use Azure Connect to connect to a local file share, a SharePoint Server, and a local SQL Server, or even join an Azure instance to your AD domain.
One fundamental piece of Azure is that it operates at the network layer, so applications do not need to be modified or coded to the network layer. Instead, developers can use logical names and addresses to access their resources, and Azure Connect can make sure the calls get to the appropriate resource, whether in the public or private cloud.
Windows Azure Connect Versus Service Bus
You may wonder how Azure Connect compares to the Azure Service Bus, discussed in Chapter 13. Remember that the Azure Service Bus is at the application level and relays messages at the application level between application endpoints. These endpoints could exist on-premises, in the public cloud, or in both places. The Azure Service Bus requires a developer to write the service, configure the endpoint, and then run the endpoint to make sure that the service is available.
How the Azure Service Bus Works
Azure Service Bus provides a relay service that allows an on-premises client to connect to another service via this intermediary. Both the on-premises client and the Azure cloud client connect to the relay service through an outbound port, and then both create a bidirectional endpoint that they can communicate using a particular common address created by the relay service. Then, when one client needs to talk to the other client, it calls the outbound connection, which passes to the relay, which passes to the other service. The following are some things to remember about the Service Bus:
- No client location or direct connection needed: Neither the client nor the server needs to know where the other is located nor do they need a direct connection to each other.
- The client doesn’t need to be open to a firewall: The on-premises client does not need any ports opened in the firewall because the bidirectional socket that the client creates with the relay service can traverse different network topologies.
- The Service Bus operates at the application layer: This enables you to secure your connections using transport security, message security, or both.
- Multiple listeners are allowed: The Service Bus allows for multiple listeners on a single endpoint. An example of this is if you need to multicast your message to multiple subscribers listening on a single Service Bus endpoint. You may want your application to notify multiple subscribers that something has changed. With multiple listeners on a single endpoint, you can deliver the message once, and the Service Bus relays the message to the multiple listeners on your behalf.
- The Service Bus is a durable messaging infrastructure: Transient failures of any part of the delivery of the messages between clients will be retried. The Service Bus ensures the messages are delivered whenever the message receiver is back online.
How Azure Connect Works
In contrast to Azure Service Bus, Azure Connect works at the network layer rather than the application layer. This means that Azure Connect is less focused on application constructs, such as setting up application level transports and message queuing, but instead focuses on setting up the networking pipeline between the different endpoints. Rather than forcing you to set up a VPN between your on-premises instances and your Azure roles, Azure Connect makes this setup as easy as installing software on your on-premises servers and making a small configuration change to your Azure role instance. In addition, Azure communicates over IPv6 between Azure and your on-premises servers using IPSec. Some things to remember when working with Azure Connect:
- Azure Connect works at the network layer: Because Azure Connect works at the network layer, it does not provide durable messaging like Service Bus. Your application would need to realize that the call or function failed and try the call again.
- Azure Connect does not allow for communication between Azure role instances: Instead Azure Connect targets private and public cloud integration scenarios. So, if you want to connect two applications running in two separate Azure roles instances, you must use the Service Bus as your communication layer.
- Azure Connect does not require application changes: This is in contrast to the Service Bus, which does require application changes. This means you can to connect directly to applications such as file shares, SQL Server, or SharePoint without writing a Service Bus endpoint. Accessing these applications are exactly the same as accessing them as you would on your corporate network. Azure Connect handles all the protocol and security negotiation on behalf of the caller.
- Azure Connect is not as rich in security: The Service Bus has a much richer security model through the use of the Windows Azure Access Control Services (ACS). Using ACS, you can authentication and authorize users using a variety of sources including Active Directory, OAuth sources, or custom authentication mechanisms. With Azure Connect, you will be limited to the configured network policy you create in the Azure portal, which defines which Azure roles and which local endpoints connect together. From there, authentication can be based on your local AD groups and users.
- Azure Connect provides more control options: You can remotely connect, administer, and debug your Azure role instances. You can use existing tools such as network or application monitoring tools or remote PowerShell using Azure Connect.
Which Technology Should You Choose?
Which technology you choose to use depends on what you want to achieve. If you make mostly minimal changes to your existing on-premises infrastructure and do not want to write a Service Bus frontend to your existing applications, Azure Connect is a good option to explore. If you want the ultimate flexibility in the services you expose and how your users access and authenticate against those services, the Service Bus can provide the most flexible approach, but the flexibility comes at the price of needing to write custom code and maintain that code over time.
Windows Azure Connect Fundamentals
Looking at the core architecture for Windows Azure Connect, Azure Connect is made up of three key components:
- Name Service: Provides name resolution so that the Azure and on-premises machines can locate each other through logical names that are translated to IPv6 addresses.
- Relay Service: Allows the connectivity between the on-premises machines and the hosted Azure machines.
- Client Installation: There is a client component that needs to be installed on the on-premises machines that configures and connects the on-premises machine to the relay server.
If you drill deeper into the networking fundamentals, each connected machine has a routable IPv6 address even if the machine has only an IPv4 address. One of the requirements of Azure Connect is having IPv6 enabled even if you do not use IPv6 as your main network addressing mechanism. The Azure Connect client agent sets up the virtual network adapter for Azure Connect, and there are no changes to the existing networks because all the changes Azure Connect makes are additive to your existing network stack and implementation.
The reason Azure Connect uses IPv6 is because of the larger address space, its native support for IPSec, and the better routing performance compared to IPv4. The IPv6 traffic is encapsulated over IPv4 using the SSTP SSL VPN protocol. All the connectivity of Azure Connect can work as long as your network has the capability to route traffic through the outbound HTTPS port. This allows Azure Connect to work through firewalls and NAT devices.
In addition, DNS name resolution for connected resources are based on the machine names through the name server. For local, non-connected resources, the on-premises machines continue to use their local DNS for name resolution. The Azure instances always use the Connect Name Service for all name resolution. Developers do not need to change code that uses logical names rather than networking addresses in their applications.
Finally, all communication between the resources is secured via an end-to-end certificate-based IPSec tunnel. The tunnel is scope to the Azure Connect virtual network. In addition, the Azure Connect agent automates the management of the IPSec certificates so that the IT administrator or developer does not need to configure or deploy these certificates. The authorization follows the network policy that you configure through the Azure Connect portal. IPSec also operates in the Encapsulating Security Payload (ESP) mode, which uses AES encryption and SHA-2 to ensure integrity of the payloads. To enable troubleshooting, the ping command and protocol ICMP is exempt from the IPSec policy rules.
Network Policy Model
To authenticate and authorize your machines in Azure Connect, your local machines need to be organized into Endpoint Groups. You can name these groups whatever you like, such as SQL Servers or Directory Servers or whatever logically makes sense. Within an Endpoint Group, you have computers, and a computer can be only in a single group at a time. Newly-activated computers are, by default, unassigned and require you to explicitly add them to an Endpoint Group.
Azure roles can be connected to the Endpoint Group, which allows connectivity between the role instances and the local computers in the group. Azure Connect does not control or connect Azure roles together. It only controls and connects Azure roles to local computers. This lack of connectivity between Azure roles is intentional because the Azure runtime controls this connectivity, and Azure Connect should not interfere with this capability.
In addition, you can connect Endpoint Groups to other Endpoint Groups. This allows connectivity between local computers within each group. Connectivity between Endpoint Groups is not transitive in that if Group A is connect to Group B and Group B is connected to Group C, Group A cannot connect to Group C without an explicit connection. You can also set a single Endpoint Group as interconnected, which allows connectivity between local computers within the group. Figure 15-1 shows the Network Policy management in the Windows Azure Portal.
The Azure Role Architecture
In order to make use of your Azure Role, you can make some architectural and configuration changes using Azure Connect.
Azure Connect Client Agent
As part of your Azure Connect deployment, you need to install the Azure Connect agent on your on-premises machines. This agent can be installed either through a web-based or standalone package install. If you use the web-based install, your per-subscription activation token is embedded in the URL, so there you do not need to enter that information. If you use the stand-alone package, you must provide your activation token either through the install or embedded in an unattended setup package. Whichever way you install the agent, you need to make sure that TCP 443 outbound port is open.
After install, the agent creates a Tray icon and also has a client UI that you can use to interact with the agent. Through this UI, you can view the activation state and connectivity status and also refresh your network policy, as shown in Figure 15-2.
The agent sets up the virtual network adapter, connects to the relay service, and gets an IPv6 routable address. The agent also configures the IPSec policy based on the network policy you configured in the Azure Connect administration portal. The agent enrolls for a certification for IPSec for authentication purposes. The policy rules are kept in sync with the Azure Connect service, and the certificates are automatically renewed by the agent before they expire. The agent also installs the DNS name service provider for name resolution using the Azure Connect name service.
One caveat is that you can install only one copy of the Azure Connect agent and have only one activation token enabled for that agent. If you want to use a different subscription and activation token, you must uninstall the Azure Connect agent on your on-premises instance and reinstall using the new activation token.
If you are domain-joining your Azure instances to your on-premises AD deployment, you need to install the Azure Connect agent on a Domain Controller (DC) and a DNS server. You must have at least one DC with the agent software on it, and it is recommended that you install the agent on a Global Catalog server.
Setting Up Windows Azure Connect
To set up Windows Azure Connect, you need to do some on-premises and Azure role instance configuration and meet some system requirements. This section steps you through both the configuration and requirements.
System Requirements
Windows Azure Connect has some specific system requirements especially for your on-premises computers. In particular, you need to run the following:
- Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2.
- Windows Azure SDK.
- Windows Azure Tools for Visual Studio release 1.3. These tools enable you to configure and deploy your Azure instances that connect using Windows Azure Connect.
Requesting Access to the Azure Connect CTP
At the time of this writing, Azure Connect is in Community Technical Preview (CTP). You need to request access to the CTP through the Windows Azure portal. During the CTP period, Azure Connect is free of charge and has no service-level agreement (SLA). The pricing and SLA will change when Azure Connect is released, so be prepared to possibly pay for the service and understand what will and will not be covered by the Azure Connect SLA.
Enabling and Configuring Azure Connect for Azure Roles
Before you work with Azure Connect, you need to retrieve your Activation Token, as shown in Figure 15-3. This token will be used in the configuration for your Azure role.
When you have the Activation Token, you can create an Azure project in Visual Studio. Bring up the properties for the role you are creating and you can activate Azure Connect by checking the Activate Windows Azure Connect check box under the Virtual Network tab, as shown in Figure 15-4. You need to paste your Activation Token in the dialog box so that Azure knows which subscription to connect to.
Although you don’t need to use the visual interface to configure Azure Connect, it does make it easier. And you can perform the steps that Visual Studio does on your behalf. What Visual Studio does is modify your ServiceDefinition.csdef to add an import directive for the Azure Connect plug-in as shown here.
<Imports> <Import moduleName="Connect" /> </Imports>
In the ServiceConfiguration.cscfg file, Visual Studio adds to the <ConfigurationSettings> section of the activation token that you pasted, as shown in the following code in addition to other Azure Connect plug-ins.
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.ActivationToken" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.Refresh" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.Diagnostics" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.WaitForConnectivity" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.Upgrade" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainFQDN" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainControllerFQDN" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainAccountName" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainPassword" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainOU" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DNSServers" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.Administrators" value="" /> <Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainSiteName" value="" />
After you set up these settings in your role, you can continue to develop your role as you normally would. When finished, you can publish the role to Azure. When the role is in a ready state in Azure, you should see the Azure Connect enabled roles you published in the Azure Connect portal, as shown in Figure 15-5.
Enabling and Configuring Azure Connect for a VM Role
Enabling a VM role is different than enabling an Azure role. You need to download and install the Azure Connect software on your VM image from http://waconnect.blob.core.windows.net/client/latest/x64/wacendpointpackagefull.exe. When installed, you need to manually edit your ServiceConfiguration.csfg file to provide your Azure Connect token.
Enabling and Configuring Your Local Machines
To set up your local machines with Azure Connect, you need to install the Azure Connect agent. This software is available from the Azure Connect portal in the Ribbon as Install Local Endpoint. Your Activation Token is automatically appended to a URL for downloading the client, as shown in Figure 15-6, and the setup automatically configures your activation token for you.
The setup screen, as shown in Figure 15-7, allows you to select the language you want to install for the client. The setup then installs the client on your machine. If successful, you should see a Taskbar icon, as shown in Figure 15-8.
After the client is installed, it auto-configures and connects to the Azure Connect service. When connected, your local machine appears in the Azure Connect portal as an activated endpoint, as shown in Figure 15-9.
From here, you can configure the network connectivity for your Azure Connect to set the policies for your local machines to connect your Azure role instances.
Configure Your Network Connectivity Policy
To configure your network policies, you need to perform two steps: Create an endpoint group, and add machines to your machine endpoint group from your local and Azure role instances.
You interconnect your endpoints if you have multiple local machines that need to communicate to each other through the service. For example, if you have multiple developers who are in different geographies, you can use Azure Connect to allow their local machines to access the Azure service in addition to each other’s development machines.
Although connectivity to Azure roles may make sense, you may wonder why you may need to connect to other Endpoint Groups. Connecting Endpoint Groups is useful if you break your local machines into different endpoint groups. For example, you may create an endpoint group that contains your local development machines and a separate endpoint group for all your databases.
To create an endpoint group, in the Azure Connect portal, follow these steps:
Testing Connectivity to SQL Server
One of the most common scenarios for Azure Connect is to use it to connect your Azure instances to a locally installed SQL Server. Because Azure Connect utilizes low-level connectivity, you can use local names to connect to your SQL Server instances. The web application, as shown in Figure 15-11, runs in Azure and connects to a local SQL Server.
To connect your local SQL Server to your role instance, you need to perform a number of steps to make sure that the network infrastructure for SQL Server supports the calls and also that your local SQL instance and your Azure role instance connect through the Azure Connect network policy. Now you walk through these steps, outlined in in the following sections, to see how you can connect the two together.
Configuring SQL Server
The first step to configure your SQL Server instance involves making sure that both the security credentials can be passed to SQL Server from your Azure role instance and also the port and protocol that Azure uses will be accepted by your SQL Server:
Configuring Firewall Rules
The next step is to configure your firewall to allow inbound connections on port 1433. This section shows how to use Windows Firewall, but if you use a different firewall technology, you should follow the steps for your firewall provider.
Installing the Connect Agent on SQL Server
In the next phase, make sure to install the Azure Connect agent on your SQL Server machine through the Azure Connect portal. You can do this by using the Install Local Endpoint button from the menu for your Azure Connect subscription.
Creating Your Azure Role Instance
The next phase is to create your cloud project inside of Visual Studio that connects to your local SQL Server instance.
Your project is ready to be published, so you can now use the automated publishing tools in VS to compile and upload your project to Azure, as shown in Figure 15-21.
Creating Endpoint Groups
When your role is successfully deployed and initialized, you need to add it to an endpoint group. In the Azure Connect portal, create a new Endpoint Group to connect your local SQL Server to your Azure role instance. If your instances are all correctly configured and network connectivity works, you should see a dialog box similar to Figure 15-22 which shows your local instances and your Azure role instance.
That’s it! You can now connect your Azure role instance ASP.NET application and see data from your local SQL Server.
Troubleshooting Tips
If you find that you can’t connect the Azure role instance to your SQL Server, you can try the following troubleshooting tips to get it to connect.
- Make sure the Azure Connect agent is connected on your local machine. You can do this via the Azure Connect icon in your taskbar. It displays the status of the agent, as shown in Figure 15-23.
- Check the edge traversal option. When you create your firewall rule, there may be times in which the traffic is still blocked because there is an edge device between Azure and your local instance, such as a firewall or NAT device. By default, when you create your SQL Server firewall inbound rule, edge traversal is blocked. Try changing this setting to Enabled by looking at the Advanced settings for your inbound rule.
- Create firewall rules to block IPv4 traffic. When domain-joined, there may be times when your connection to SQL Server times out because the SQL client software attempts to connect over IPv4 by default rather than IPv6. This won’t happen with non-domain-joined machines because the Azure Connect service always returns back an IPv6 address. However, with a domain joined Azure Connect instance, Azure Connect uses your local DNS, which may return IPv4 addresses. Therefore, the SQL client software attempts to connect over IPv4 first, which won’t work, and then attempts IPv6. Depending on the timeout for your application, this could cause application issues. The simplest way to fix this problem is to create a firewall rule that blocks IPv4 traffic to the SQL Server port 1433. You can do this through the Windows Firewall UI or the following netsh command, customized with your IPv4 range, which also creates a Windows Firewall rule.
netsh advfirewall firewall add rule name="BlockSQLIPv4" dir=out action=block protocol=tcp remoteport=1433 remoteip=(on-premises IPv4 range)
Building a Domain-Joined Configuration
There may be times when you want to domain-join your Windows Azure instance to your local instances. This is convenient if you want to extend your network and security boundary to include your Windows Azure deployment. The benefit is that the Azure instances are trusted by your on-premises instances so that authentication is seamless whether a user accesses an on-premises resource or accesses an Azure-based resource. Domain-joining is useful if you want to determine which users and groups have access to your application, want to apply AD policies to your Azure machines, and want to manage your Azure instance like you manage your on-premises instances because your Azure instance appears on your network with your policies and management tools.
Because the steps are complex and more IT-oriented, you must use the following overview to configure your domain-joined instances, which is outside the scope for this book: http://blogs.msdn.com/b/windows_azure_connect_team_blog/archive/2010/12/10/domain-joining-windows-azure-roles.aspx.
Troubleshooting Windows Azure Connect
When dealing with hybrid solutions that span networks, firewalls, and applications, you will have some issues and need to troubleshoot those issues at some point. Azure Connect attempts to make the setup, deployment, and running of your interconnected application easy, but in the cases in which you run into issues, Azure Connect also provides some troubleshooting tools to help you figure out where the errors could be. This section steps you through some of the tools and techniques you can use to troubleshoot your Azure Connect deployments.
%programfiles%Windows Azure ConnectEndpointdiagnose.exe /collectlogs
If you have connectivity issues, you can do a couple things to make sure that you have network connectivity:
- Make sure to check that you have IPv6 enabled on your local network adapter on your local instance.
- Make sure you have the outbound port 443 enabled to allow connectivity.
- Allow IPv6 ping communications in your firewall by running the following command line:
netsh advfirewall firewall add rule name="Pingv6" dir=in action=allow enable=yes protocol=icmpv6
- Make sure you have any proxy settings configured correctly. You can also try removing the proxy to see if connectivity works.
Summary
In this chapter, you learned about Windows Azure Connect and how you can use Azure Connect to bring together your Azure and on-premises instances to build a single solution that ties both together. Azure Connect makes it easy to set up and maintain secure network connectivity between your instances and also enables you to join your Azure instances to your local Active Directory domains.