Tutorial: Setting up Windows Azure Connect

• You must have a subscription for Windows Azure: http://manage.windowsazure.com.
  
  
• You need to have the Windows Azure SDK and Windows Azure Tools for Visual Studio release 1.3.
  
  
• The local machines that you connect using Windows Azure Connect must be one of the following platforms: Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2.
  
  

In this document, we will walk through how to set up network connectivity between a Windows Azure service (that is, its roles and underlying role instances) and a set of local machines using Connect.

Note
During the CTP period, you can use Windows Azure Connect free of charge. There is no Service Level Agreement for the CTP, so we recommend that you do not use Windows Azure Connect for any mission-critical, high-availability services.

This document is organized into the following sections:

• Enable the Connect Service for your Windows Azure Subscription
  
  
• Enable your Windows Azure Hosted Service for Connect
  
  
• Using the Virtual Machine (VM) Role and Connect
  
  
• Enable your Local Machines for Connect
  
  
• Configure and Manage Connectivity
  
  
• Connectivity Experience
  
  
• Additional Connect Functionality
  
  

1. Log on to the Management Portal (http://manage.windowsazure.com). Click the “Virtual Network” tab.
   
   
2. Under the “Connect” tab in the left-hand pane, click the subscription you would like to enable for Connect.
   
   
3. Confirm that you would like to enable Connect service by clicking OK.
   
   

You are now ready to start using Windows Azure Connect.

To use Connect to connect local resources with your Windows Azure hosted service, you need to enable one or more of its roles. You do this by provisioning the role with the Connect plug-in that is part of Windows Azure SDK 1.3. Only roles of the service provisioned with the Connect plug-in will be able to connect to local resources.

1. First you need to retrieve the activation token for your Connect service. In the Management Portal, click “Virtual Network,” select the Windows Azure subscription that you enabled for Connect, and then click “Get Activation Token” on the ribbon. In the dialog box that pops up (see below), copy the activation token – you will need this in the next step.
   
   
2. Open your Windows Azure project in Visual Studio 2010 (VS), and then double-click the role you are enabling for Connect to bring up the properties page. Click the “Virtual Network” tab, check the “Activate Windows Azure Connect” checkbox, and paste the activation token from the previous step as shown below.
   
   
   
   At this point, you will notice that VS has updated your ServiceDefinition.csdef file and .cscfg file. In the ServiceDefinition.csdef file, for the role that you are enabling for Connect, Visual Studio will have added a line about importing the Connect plug-in in the <Imports> section:
   
   
   Copy

   
   <Imports>
      <Import moduleName="Connect" />
   </Imports>
   

   And in the ServiceConfiguration.cscfg file, VS will have created Connect-specific settings in the <ConfigurationSettings> section for the role you are enabling for Connect. One of these setting is “ActivationToken.”
   
   
   Copy

   
   <Setting name="Microsoft.WindowsAzure.Plugins.Connect.ActivationToken" value="your_ activation_token_guid" />
   

3. Once you “Publish…” your hosted service, you can then deploy it to Windows Azure. You can deploy the hosted service to either the production or staging deployment environments.
   
   
4. Once your Windows Azure roles are successfully deployed and they are running in a “Ready” state, within a few seconds you should see the Connect-enabled roles appear in the Virtual Networks section of the Management Portal. In the “Roles & Groups” tab, your roles and the instances associated with each role will appear in a hierarchical fashion, with information about the associated name, hosted service name, and deployment environment. In the “Activated Endpoint” tab you will see Connect-enabled role instances. This is illustrated in the following screenshots which show a single Connect-enabled role named “SydneyCustomersWebRole” that has two role instances.
   
   

To use Connect with the VM role, you must install the Connect Endpoint software on the machine that will be used to create the VM image, using the following link: http://waconnect.blob.core.windows.net/client/latest/x64/wacendpointpackagefull.exe. Before installation, make sure you haven’t disabled IPv6 on the machine (by default IPv6 is enabled). Also make sure there are no pending updates or reboot from Windows Update. If there are, you should install the updates and/or reboot prior to proceeding with Connect Endpoint installation. After installation, Connect Endpoint should not be in activated state. When you build your VM role package for upload into Windows Azure, you will need to provide the Connect activation token in the ServiceConfiguration.cscfg file as described in the step above.

To enable local machines to connect to your Windows Azure roles, you need to install the Connect Endpoint software (Connect agent).

1. In the Management Portal, click “Virtual Network,” select the Windows Azure subscription, and then click the “Install Local Endpoint” button on the ribbon. In the dialog box that pops up (see below), copy the installation link – you will need this in the next step.
   
   
2. Using the above link, install Connect Endpoint on all of the local machines that you wish to connect. Before installation, you should make sure there are no pending updates or reboots from Windows Update. If there are, you should first install the updates or reboot prior to proceeding with Connect Endpoint installation. The installation wizard will look as follows:
   
   
3. Within a few seconds after Endpoint installation is complete, you should see the Connect Endpoint tray icon appear as shown below.
   
   
4. Repeat this process on all of the local machines you want to connect.
   
   

After Connect Endpoint is installed, it will automatically “activate” itself with the Connect service which should take around 10 to 30 seconds. Once a local machine is activated, it will appear in the Virtual Network of the Management Portal when you select the “Activated Endpoints” node or the “Groups and Roles” node.

Now that you have enabled your Windows Azure roles and local machines to use Connect, you can define your network connectivity policy in the Virtual Networks section of the Management Portal.

1. Create a machine group that includes your local machines. You use these machine groups to manage connectivity between resources. To create a machine group, select the “Create Groups” button on the ribbon. In the pop-up dialog, name the group, select the local machines to add to it, and then connect the group to other groups –either Windows Azure roles or other machine groups. This is illustrated in the sequence of screenshots below. (Note that a local machine can only belong to one machine group).
   
   

   Note
   If the “Interconnected” check box is set to true (is checked), then machines that belong to the group will be able to communicate with each other via Connect. If it is set to false, then machines in the group will not be able to communicate with each other.

   In the screenshot below, you see that local group “My Servers” has one member machine (server-2k8x64) and is connected to a Windows Azure role group named “SydneyCustomersWebRole”.
   
   
2. You have now set up Connect! In order to connect, your Windows Azure role instances and local machines need to pick up the new connectivity policy. For Windows Azure roles, this should happen automatically – whenever a role is connected to a local group, Connect will automatically perform a configuration update for the role that triggers the new policy to take effect. For local machines, the Connect agent automatically refreshes policy every 5 minutes. If you don’t want to wait 5 minutes, you can manually “refresh” the policy through the Connect Endpoint tray icon as shown below. The Connect agent user interface shows the way in which the last policy update occurred. You can also view this information in the Virtual Networks section of the Management Portal.
   
   
   
   

At this point, your Windows Azure role instances and local machines should have IP-level network connectivity.

Connected machines can communicate bi-directionally over an IPv6 address that Connect provides. This connection is secured with IPsec and will work through firewalls, network address translation (NAT), and so on. You can view the assigned IPv6 addresses in the Virtual Network section of the Management Portal (note a machine will only acquire an address when its policy is configured to allow it to connect to other machines).

DNS name resolution is provided. Here are some examples:

• A Windows Azure machine can resolve the name of a local machine by using its single-label name, such as myPC1, or fully qualified domain name (FQDN), such as myPC1.redmond.corp.microsoft.com.
  
  
• A local machine can resolve the name of a Windows Azure role instance by using its name, which is visible in the Virtual Networks section of the Management Portal (for example, RD00155D3242F8).
  
  

As an example, if you have configured the Windows firewall on your local machines and Windows Azure role instances to allow “ping” (ICMP) traffic, you can exercise Connect’s network connectivity very easily. From a local machine, ping your Windows Azure role instances as shown below. If you have set up remote access to your Windows Azure role, you can log on and ping back to a local machine.

A common use case for Connect is having your Windows Azure web role communicate back to an on-premises SQL Server database. Or you may want to join your Windows Azure role instances to on-premises Active Directory domain (see details in the next section). Or you can use Connect to remotely administer your Windows Azure role instances, such as using the remote event viewer or remote service manager. Or you can remote access your Windows Azure role instance and copy files from an SMB share on a local machine. Since Connect provides low-level network connectivity, you can use it in basically any way you choose.

Note that application connectivity in Connect is governed by Windows firewall policy, just as within a normal network. If your application requires specific firewall settings to work, you will need to set appropriate firewall rules manually.

For example, by default Windows Azure machines don’t allow ping. In order to change that, you will need to create a firewall rule to allow ping request on the Windows Azure role. To do this automatically for all of your role instances, you can create a <Startup> task by following the steps below. For more information on <startup> tasks, see Define Startup Tasks for a Role.

1. Create a .cmd file (for example, "EnablePing.cmd") and copy the lines below to the file.
   
   
   Copy

   Echo Enable ICMP
   netsh advfirewall firewall add rule name="ICMPv6 echo" dir=in action=allow enable=yes protocol=icmpv6:128,any 
   exit /b 0
   

2. Add the .cmd file to your Windows Azure project.
   
   
   1. In VS, right-click the role you want to run <Startup> task.
      
      
   2. Click “Add”, click “Existing item”, and then choose the .cmd file.
      
      
   3. When you see the .cmd file is listed under the role, right-click it to bring up “properties,” Make sure you set “Copy to Output Directory” to “Copy Always”.
      
      
3. In your ServiceDefinition.csdef file, insert the following lines:
   
   
   Copy

   <Startup>
   <Task commandLine="EnablePing.cmd" executionContext="elevated" taskType="simple"/>
   </Startup>
   

4. Build and deploy your Azure role.
   
   

Connect will automatically track changes made to your Windows Azure role and maintain connectivity. If you increase the number of Windows Azure role instances, Connect will automatically connect those new role instances based on the current network policy.

Likewise, if you decrease the number of instances you should see that reflected in the Connect portal as well. (Note that while these changes should be synchronized automatically, if you feel things are out-of-sync you can use the “Refresh Role Information” button in the Virtual Networks section of the Management Portal to force a re-sync of the Connect user interface.) If you suspend or delete a Windows Azure hosted service, you should see its associated roles and role instances disappear from the Management Portal. When you resume a suspended hosted service, its roles and role instances should reappear.

In addition to connecting to your Windows Azure hosted services, you can use Connect to network your local machines together as well. For example, you could set up connectivity between your roaming laptop, home machine, and hosted server. As mentioned above, if a machine group has its “interconnected” property set to true, all member machines will have network connectivity with each other. In addition, machine groups can be linked together to enable connectivity between the members of each group, which enables very flexible networking topologies.