Windows Azure Connect Team Blog

Upgrade to the latest Connect endpoint software now

2012-08-31T23:08:00Z

On 10/28/2012, the current CA certificate used by Windows Azure Connect endpoint software will expire. To continue to use Windows Azure Connect after this date, Connect endpoint software on your Windows Azure roles and on-premises machines must be upgraded to the latest version. Depends on your environment and configuration, you may or may not need to take any action.

For your Web and Worker roles, if they are configured to upgrade to the new guest OS automatically, then you don’t need to take any action. When the new OS is rolled out later this month Connect endpoint software will be automatically refreshed to the new version. To upgrade endpoint software manually, you can set below to true in your .cscfg and “Upgrade”.

For PaaS VM role, the on-premise VHD image can be either updated via Windows Update or manually updated, and then re-uploaded.

For the new IaaS roles and on-premise machines, you can use Windows Update to upgrade or manually install.

To verify that upgrade worked, in the Silverlight portal, go to “Virtual Network” –> “Activated Endpoints” –> “Properties” to make sure the version is 1.0.0960.2.

If you plan to do manual upgrade, below is Microsoft Update Catalog upgrade link for manual install.

http://catalog.update.microsoft.com/v7/site/ScopedViewInline.aspx?updateid=f100960b-3ba9-4463-8efd-b0ae86c4dfd5

Place the “update” in the “basket”, click “download” to a temp folder, and run either the x86 or the amd64 upgrade package.

Directory of C:\temp\Update for Windows Azure Connect Endpoint Upgrade (1.0.0960.2)

08/24/2012 10:05 AM 2,948,720 AMD64-en-wacendpointupg_prod_d0e8b5df2bdf2587cdbb75fdfdef1946de7f5f56.exe

08/24/2012 10:05 AM 2,316,424 X86-en-wacendpointupg_prod_f2f3fe266e7a3399691042ce8eb4606dc82a6925.exe

--Jason Chen

Windows Azure Connect is now open CTP

2011-11-15T20:36:00Z

Windows Azure Connect CTP is now open to everyone. In the past, you needed to request CTP access and be approved before you could use Connect. Starting today, no approval is needed. You can use Windows Azure Connect as long as you have a Windows Azure subscription. To start using it, go to the Windows Azure Connect portal.

--Jason Chen

Windows Azure Connect Endpoint Upgrade also available from Microsoft Update

2011-07-23T03:19:00Z

As part of the Windows Azure Management Portal update, a new release of the Windows Azure Connect (which is in CTP) endpoint software (1.0.0952.2) is available. In addition to bug fixes, the Connect endpoint is localized into 11 languages, with a language choice selection at the beginning of the interactive client install.

For corporate machines distributing updates with WSUS (Windows Server Update Services) or SCCM (System Center Configuration Manager), the endpoint update can be imported into WSUS from the Microsoft Update Catalog http://catalog.update.microsoft.com/v7/site/Search.aspx?q=windows%20azure%20connect .

For machines not receiving updates from WSUS (Windows Server Update Services), just start Windows Update, Check for updates, and select Windows Azure Connect Endpoint Upgrade.

--Jason Chen

HPC Pack 2008 R2 SP2 uses Windows Azure Connect for hybrid Cloud

2011-07-02T00:06:00Z

The recent released HPC Pack 2008 R2 SP2 is focused on providing customers with a great experience when expanding their on-premises clusters to Windows Azure. One of new features include a tuned MPI stack for the Windows Azure network, support for Windows Azure VM role (currently in beta), and automatic configuration of the Windows Azure Connect preview to allow Windows Azure based applications to reach back to enterprise file server and license servers via virtual private networks.

--Jason Chen

Speeding Up SQL Server Connections

2011-06-03T20:57:00Z

We’ve heard from some customers that initial connections to on-premise SQL servers using Windows Azure Connect sometimes takes a long time if the Azure machines are domain-joined. On investigating the issue, we’ve found out that all current versions of SQL Client attempt to connect via IPv4 before IPv6 regardless of system settings (more details here). Normally, when you connect to a machine using Windows Azure Connect, the Connect endpoint looks up the name and returns an IPv6 address. However, when your Azure VM is domain joined, it can look up the name in your on-premise DNS server as well, which returns an IPv4 address. When that happens, SQL client chooses to use IPv4 address first and needs to time out the IPv4 connection attempt before it can connect through IPv6.

We’ve identified a simple workaround to avoid the timeout and speed up connections: create a firewall rule on your Azure roles to block outbound connections to SQL over IPv4. That causes the incorrect IPv4 connection to fail immediately instead of timeout. The easiest way to accomplish that is to add a startup task to your role that runs a command like:

netsh advfirewall firewall add rule name="BlockIPv4SQL" dir=out action=block protocol=tcp remoteport=1433 remoteip=(your on-premise IPv4 range)

Note that if you use SQL Azure in addition to SQL over Windows Azure Connect, you will need to ensure the the remoteip range in the rule exempts traffic to your SQL Azure servers.

If you’re looking for other performance improvements, make sure you’re using a relay close to you.

--Morgan Brown

Windows Azure Connect–Certificate Based Endpoint Activation

2011-05-06T22:08:34Z

If you have deployed Windows Azure Connect endpoint before, you know that the endpoint will be required to present an activation token (which you can get from Windows Azure Management Portal) for activation. This activation token can be specified in the .cscfg file for Windows Azure Roles (this can also be done via Visual Studio). For the endpoints that live on your corporate network (local endpoints), the activation token is part of the install link. We are happy that you like the ease of use and simplicity of this approach. We also heard some of you request an option for secure activation.

To address this feedback, we introduced certificate based activation in our latest CTP Refresh. You can now choose to use existing activation model (token based only - this is the default) or certificate based activation (token + certificate). In this refresh, certificate based activation is only available for local endpoints.

If you already have PKI and/or have a mechanism to securely distribute X509 certificates (private + public key pairs) to your endpoints within your organization, you are just few steps away from benefiting from this new feature:

1. On your corporate network, pick a Certificate Issuer that issues certificates to endpoints via manual/auto-enrollment policies.

For example, the above snapshot shows that a machine that receives certificate from the issuer with CN=SecIssuer. In this case, the public key (.cer file) of CN=SecIssuer will need to be exported and saved for step 3 below.

Note: If you have deeper PKI hierarchy (example: CN=RootIssuer -> CN=SecIssuer -> CN=myendpoint), make sure you export the public key of the direct/immediate issuer i.e., CN=SecIssuer.

2. From the Windows Azure Management Portal, Click on the “Activation Options” as shown in the snapshot below.

3. This will bring up the certificate endpoint activation dialog (shown in the snapshot below):

a. Check the box that says “Require endpoints to use trusted certificate for activation”.

b. Click on “Add” button and choose the certificate (.cer file with public key only) file from Step 1 above.

4. At this point, all the new endpoints (excluding Azure roles) in this subscription will be required to prove their strong identity via the possession of a certificate issued by the issuer in step 1 above. The endpoint must have private keys for this certificate, but there is no requirement for the subject name to match the endpoint’s FQDN or hostname (example: CN=myendpoint can be used on a machine with name ContosoHost.Corp.AdventureWorks.com).

5. If you run into activation issues with this model, you can troubleshoot by checking the event viewer for any error messages such as below:

a. Verify that you have a certificate in the Local Computer\Personal\Certificates store. This certificate should have been directly issued by the issuer in step 1 above.

b. Verify that there is a private key for this certificate.

Choose Relays Close to You

2011-05-05T22:59:00Z

Throughout Windows Azure Connect CTP, many customers have asked for Windows Azure Connect relay presence in geographic locations outside US. Today we are very happy to announce that we have added new relays in Europe and Asia, with the launch of Windows Azure Connect CTP refresh, you can now choose a relay region that is close to your own geographic location to optimize network performance.

To change the relay location, click on “Relay Region” (the new button added in CTP refresh) and pick the relay location you desire, by default USA is chosen for you.

Please be aware that if you change your relay location, there will be a transition period of up to 5 minutes while your existing endpoints refresh their policy (which contains the relay location information), close their existing relay connections, and re-establish connections with the new relay location. During this time period, endpoints may not be able to communicate with each other until they have completed the transition to the new relay location.

--Jason Chen

Windows Azure SDK 1.4 refresh

2011-04-25T23:25:00Z

We have found an issue with the new Windows Azure SDK 1.4 refresh which causes Windows Azure Connect endpoints to fail to deploy on Windows Azure Roles built using this SDK release. We have since fixed the issue and updated the Web Platform Installer feed.

If you downloaded and installed the Windows Azure SDK 1.4 refresh from the Windows Azure web site before 4pm PST 4/25/2011, you will have to uninstall and reinstall it.

1. Go to Control Panel\Programs\Programs and Features, uninstall SDK 1.4 refresh.

2. Install Windows Azure SDK 1.4 refresh from the Windows Azure web site.

We apologize for any inconvenience this issue may have caused. Thank you.

--Jason Chen

Easy VPN with Windows Azure Connect

2011-04-19T19:30:00Z

Windows Azure and Windows Azure Connect are like chocolate and peanut butter – awesome together, but pretty good on their own as well. As many blogs (e.g. Maarten's blog and Adam's blog) have pointed out, you can use Windows Azure Connect to create a secure network connection between your own machines, regardless of where they are. Let’s say you have an on-premise line-of-business (LoB) server and roaming users who want to access it from the field. Without network configuration or expensive VPN hardware, you can install the Windows Azure Connect Endpoint on your machines and configure them to connect in a matter of 5 minutes. The easiest way to set this up is to follow the below steps:

1. Install the Windows Azure Connect Endpoint software on the LoB server and laptop using the install link from the Windows Azure Management Portal. Full instructions are at here.

2. Create an endpoint group containing all of the machines you would like connect. In the “Create a New Endpoint Group” dialog, check the “Interconnected” checkbox. This checkbox allows all of the machines in the group to connect to each other.

3. Wait up to 5 minutes for the endpoints to implement the new connectivity. At this point, your machines can connect. (If you’re in a hurry, you can also manually refresh on your machines if you follow the instructions here).

One caveat worth noting: in certain networks, if both Windows Azure Connect endpoints are in the same LAN, connections will go through Windows Azure Connect instead of the local LAN connection. If some of your machines are always on the same network, consider putting them in a separate, non-interconnected group and following the next set of instructions.

Using the “Interconnected” checkbox works well if you’re ok with having all of your machines connect to each other, but sometimes you want a little more control. For instance, say you have two roaming laptops that you want to connect to your LoB server, but you don’t want them to connect to each other. Maybe they belong to customers or outside contractors, or maybe you’re connecting branch offices to the central office. Instead of using interconnection, you can create endpoint groups and connect them to each other. Machines in the first group will be able to connect to machines in the second, but not to each other. To set this up, follow the steps below.

1. Install the Windows Azure Connect Endpoint on the LoB server and both laptops.

2. Create an endpoint group for the LoB server.

3. Create another endpoint group for the roaming laptops and connect it to the LoB group.

4. Wait up to 5 minutes for the endpoints to implement the new connectivity. At this point your laptops can connect to your LoB server, but not to each other.

You can mix and match interconnection and connecting endpoint groups and Windows Azure roles to build whatever kind of connectivity suits your needs.

--Morgan Brown

Options for Deploying Windows Azure Connect Endpoint Software

2011-03-30T22:20:00Z

Installing Windows Azure Connect endpoint software is a one-click process – you get the install link from the Windows Azure portal and launch it to start the install. No questions are asked during installation except accepting the EULA. Pretty simple, right? But what if you have a handful of machines you would like to install the endpoint software in an automatic fashion? In this blog we show you how to do this.

1. Sign in to Windows Azure portal, click “Virtual Network,” and select the Windows Azure subscription that you use Connect for.

2. Click on “Install Local Endpoint” on the toolbar, copy the install link and launch it in the browser.

3. Choose “Save” instead of “Run” when prompted by the browser. You can save the installer in a network share (e.g. \\myshare\wacendpointpackage.exe).

4. Click on “Get Activation Token” on the toolbar, copy the activation token, you will use it in the next step.

6. Run below command on all the machines you want to the install endpoint software:

\\myshare\wacendpointpackage.exe /i /s /m en-us /token aa684278-ff75-4c85-bbd3-aa9b337cd9af

where /i is for install, /s is for silent, /m is for language and /token is for activation token. You need to replace the highlighted with your own activation token. You can use popular deployment tools such as SCCM (System Center Configuration Manager) and GP (Group Policy) to carry out this step. Note, the targeted machine group can include Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2, the installer does not run on Windows XP or Windows Server 2003.

Alternatively, you can also setup the activation token in the target machines’ registry first and then install the endpoint software.

6a. Set below registry value (type REG_SZ) using SCCM or GP, replace the highlighted with your own activation token.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Connect\Endpoint]

"ClientActivationToken"="aa684278-ff75-4c85-bbd3-aa9b337cd9af"

6b. Run wacendpointpackage.exe.

After installation, the endpoint software will retrieve the activation token and use it to activate itself with the Windows Azure Connect services. Once successfully activated, you will be above to see the newly activated endpoint in the Windows Azure portal, remember to move it to a local machine groups to connect to Azure roles or another local machine group.

.--Jason Chen

Windows Azure Connect Use Case: Web Role / Application Pool Access SQL Server using Windows Authentication

2011-03-16T20:20:00Z

We showed you how to domain join Windows Azure roles to on-premises Active Directory in an earlier post. Once the Azure roles are domain joined, it is easy to enable a very common use case – application pool uses domain credential to access SQL server on-premises.

The steps below assume that you have already configured your on-premises SQL server to use Windows Authentication, and you have set Integrated Security=true in your connection string.

0. First follow the instruction to enable domain join for your Windows Azure roles.

1. Specify the credential that your application pool will use in the .cscfg file.

a) To do that, you would need to define the settings in the .csdef first. Also it is important that you set executionContext to “elevated” because we would need to have sufficient rights to run appcmd.exe to set the identity for the application pool.

<ConfigurationSettings> <Setting name="AppPoolUserName" /> <Setting name="AppPoolUserPassword" /> </ConfigurationSettings> <Runtime executionContext="elevated" />

b) Then specify the value of the credential for your application pool in the .cscfg file. You need to encrypt the user password using a certificate (the same way you did for encrypting user password used for domain join). Here is an example:

<!-- Specify the user name for the Application Pool --> <Setting name="AppPoolUserName" value="corp4\jason" /> <!-- Insert encrypted password for the user specified above --> <Setting name="AppPoolUserPassword" value="MIIBFwYJKoZIhvcNAQcDoIIBCDCCAQQCAQAxgckwgcYCAQAwLzAbMRkwFwYDVQQDExBNeUVuY3J5cHRpb25DZXJ0AhCTEsiJ0zzrjktvASTLQh7qMA0GCSqGSIb3DQEBAQUABIGABGQW6efUv3fpewvgCcqxqfzJu5gmlUqXPg60aggvDeBYwyPL6xVqZ9DZYiYxbBmHSjJgzrIrLY+rP3EMtV/8G4f6hvyewasWvJgMe2vzwcMGSKqixcIRnCLuLov7zLgCsYylzZ1h4j/SIf0gUBtwC1leW4C07z+KtQb8fdDbi5wwMwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAiyEoiHBP8V8YAQ2PN+j2uY07qpS93N15uQkA==" />

2. Set up your application pool to use the credential specified above when the role starts up. This can be done with one line of code in OnStartup() if you include our WAConnectUtils class in your project.

a) Download WAConnectUtils class (WAConnectUtils.cs). We have created this utility class to help you do a few chores including:

Detecting if the role’s Connect connection is up
Detecting if the role is domain joined
Configuring IIS application pool
Decrypting password encrypted using a cert

b) Add WAConnectUtils.cs to your web role project.

c) Add necessary references to assemblies.

For Microsoft.Web.Administration, the component path is %windir%\system32\inetsrv\Microsoft.Web.Administration.dll

d) Add one line of code in OnStartup() as show in the highlighted below. ConfigureIISAppPoolAfterDomainJoin waits for the role to be domain joined and then launches appcmd.exe to set IIS application pool to use the credential you specified in the .cscfg file.

public override bool OnStart()
{
    RoleEnvironment.Changing += RoleEnvironmentChanging;

    try {
        // Use the name of site from your .csdef, in this case it is called "Web"

WAConnectHelpers.WAConnectUtils.ConfigureIISAppPoolAfterDomainJoin("Web"

);
    }
    catch (Exception)
    {
        // Catch all exceptions here, else the role will get recycled. // Trace Exception information here }

    return base.OnStart();
}

3. Build, publish and deploy your role to Windows Azure. Once the role is up and domain joined, you can remote desktop into a role instance (using existing domain credential if you wish) and verify that the application pool is set to use the credential specified.

4. Now your web roles will be using the specified domain credential to perform windows authentication when accessing SQL server.

--Jason Chen

Windows Azure Connect CTP refresh

2011-03-10T22:16:00Z

We are pleased to announce that the first CTP Refresh for Windows Azure Connect is now live. Here are some of the enhancements included in this release:

· Co-administrators of a Windows Azure subscription can now manage Windows Azure Connect functionality for that subscription through the Windows Azure portal.

· An updated Windows Azure Connect Endpoint UI, including improved and more accurate status notifications, as well as built-in diagnostic capabilities.

· Support for installing Windows Azure Connect endpoints on non-English versions of Windows.

· “Under the cover” improvements including bug fixes and performance enhancements.

To take full advantage of the CTP Refresh, you will need to upgrade your Windows Azure Connect endpoints. For your on-premises Connect endpoints this will happen automatically over the next day if your machine is connected to the internet. You can verify that your Connect endpoint has been upgraded by accessing the ‘About’ UI from the Connect tray icon as shown below. (You can also confirm this by checking if the “Diagnostics” option is available from the Connect tray icon, as this is a new feature for CTP Refresh.)

For your Windows Azure roles that have been enabled for Connect, you will need to manually trigger an upgrade to the CTP Refresh version. This can done in the following ways:

· Re-deploying your Windows Azure service.

· Deploying a new copy of the service and performing a VIP-swap operation (we recommend this option if you need to ensure no service downtime).

In both cases, as your Windows Azure role instances are brought online, they will be automatically updated to the CTP Refresh version of the Connect endpoint.

The current CTP Connect endpoints will continue to work fine and interoperate with upgraded Connect endpoints. For the best experience, we recommend that everyone upgrade all of their Connect endpoints to the CTP Refresh version.

We hope you find the CTP Refresh enhancements to be useful. If you have questions or run into any problems, you can post your issue to the Windows Azure Connectivity support forum - http://social.msdn.microsoft.com/Forums/en/windowsazureconnectivity

--Jason Chen

Windows Azure Connect Use Case: Enable File Sharing on Windows Azure VM

2011-01-20T18:07:00Z

Once Windows Azure VMs are connected with your local machines using Connect (see this blog if you are new to Connect), there are many interesting use cases you can enable.

As we mentioned in an earlier blog, 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. But sometimes these firewall settings are not so obvious, so we thought we would save you some time by showing you the steps required to enable some common use cases.

In this blog, we will show you how to enable file sharing on Windows Azure VMs. The steps below assume that you have enabled Remote Desktop for your Windows Azure role and have created an user account for it, and that you will be using this account to access file shares on your Windows Azure VMs. (Note, it is important to point out that any changes made during a Remote Desktop session don’t persist, so it should be for temporary use only. If you would like to create persistent file shares, you should use Windows Azure xdrive and skip step 4 through 7 below.)

0. First make sure the Windows Azure Connect connection is established. e.g. make sure you can ping your Azure VM from local machine and vice versa.

1. Remote Desktop to your Windows Azure VM instance using the user account you set up. (In this example we assume that you created an user account "my_account".)

2. Run "wf.msc" to open the "Windows Firewall and Advanced Security" UI.

3. Create a new inbound rule to allow file share:

Right click "Inbound Rules", choose "New Rule ...".

Select "Predefined", choose "File and Printer sharing" from the drop down list.

In the “Predefined Rules” page, select “File and Printer Sharing (SMB-in) from the predefined rules list.

In the next page, select “Allow the connection" and click “Finish”.

4. Create a folder on the VM machine, e.g. d:\share.

5. Create a network share

Right click on the folder, select “Share…”.

In the “File Sharing” dialog, add users you would like to give access to this share.

When done, click on the “Share” button.

If you prefer command line, you can accomplish the task by running command:

net share MyShare=d:\share /grant:my_account,FULL

8. Now you should be able to connect to this share from your local machine. e.g. Run "net use * \\RD00155D328928\MyShare", where RD00155D328928 is the hostname of your Azure VM.

--Jason Chen

Domain Joining Windows Azure roles

2010-12-10T21:23:00Z

Windows Azure Connect supports domain joining Windows Azure role instances (i.e. the Virtual Machines on which your role runs) to an on-premises Active Directory. This opens up many scenarios such as logging in to Windows Azure role instances using domain accounts, connecting to an on-premises SQL server using Windows Integrated Auth, and migrating Line of Business (LOB) applications to the cloud that assume a domain-joined environment. This blog post provides a step-by-step walk through of how to domain join Windows Azure roles using Windows Azure Connect.

0. If you are new to Windows Azure Connect and haven’t used it before, please read this tutorial to learn the basics about Connect.

1. First you need to prepare your domain for Connect.

a) In the current CTP release, Connect requires a domain controller with an AD-integrated DNS server running on the same machine

b) The DNS server should be configured to listen on all IP address. You can verify this by going to DNS Manager, right click on your server -> Properties, as shown in the below dialog.

c) We recommend you create a separate Organization Unit (OU) in Active Directory for your Windows Azure Role instances so that they can be easily managed. This step is optional, if you don’t specify an OU in the Connect plug-in settings, Azure Role instances will join the default computers container in AD.

d) In the Connect plug-in settings, you will need to specify a domain user account with permission to join machines to the domain and (optionally) the OU described above.

e) You will need to encrypt the password for this user account.

Start the Visual Studio Command Prompt as Administrator

Create a certificate by typing the following command, provide your own CN value and certificate file name in the highlighted area.

makecert -sky exchange -r -n "CN=MyEncryptionCert" -pe -a sha1 -len 2048 -ss My -sr localMachine "MyEncryptionCert.cer"

After creating the certificate, you will need to export it. Open mmc snap-in for certificates -> Computer Account -> Personal -> Certificates. Find the certificate you just created, right click on the certificate -> All tasks -> Export -> Check Export private key -> enter a password -> follow through the wizard

Sign in to the Windows Azure portal, click on “Hosted Services, Storage account and CDN” on the left side, then select the “Hosted Services (n)” node. Under your Azure subscription, select the Azure service you are working on, select “Certificates”, then click “Add Certificate” on the tool bar. In the pop-up, select the certificate you just exported, provide the password for the certificate, and click on “Create”.

In Visual Studio, go to the Property page of the Role you are domain joining. Click the “Certificate” tab, then “Add Certificate”. Select “LocalMachine” as the Store Location, and “My” as Store Name, and choose the certificate you created in the previous step.

Now that you have prepared a certificate for encrypting your domain password, the next step is to actually encrypt it. Open notepad.exe, copy the script below into the notepad, change my_password (highlighted below) to the password you want to use.

$password = "

my_password

"
$certs = dir cert:\LocalMachine\My
[System.Reflection.Assembly]::LoadWithPartialName("System.Security") | Out-Null
$collection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$certs | ForEach-Object { $collection.Add($_) } | Out-Null
$cert = [System.Security.Cryptography.x509Certificates.X509Certificate2UI]::SelectFromCollection($collection, "", "Select a certifciate", 0)
$thumbprint = $cert[0].thumbprint
$pass = [Text.Encoding]::UTF8.GetBytes($password)
$content = new-object Security.Cryptography.Pkcs.ContentInfo -argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:\LocalMachine\My\$thumbprint)))
write-host "Writing encrypted password, cut/paste the text below the line to CSCFG file"
[Convert]::ToBase64String($env.Encode()) | Out-File .\encrypted_password.txt
Invoke-Item ".\encrypted_password.txt"

Launch a Windows Powershell console, copy and paste the modified script to the Powershell window and run it. Choose the certificate you just created when prompted. This script will output your encrypted password, for example:

MIIBDQYJKoZIhvcNAQcDoIH/MIH8AgEAMYHBMIG+AgEAMCcwEzERMA8GA1UEAxMIUFJBU0hBTlQCEJ00PIqEIdO0TksyqpDloL4wDQYJKoZIhvcNAQEBBQAEgYCPLv216vYMWnf/y1Q2jfGxopRwwSscpYlpvfH92c8S2MQ1JRUEe+urhZ9+GLmtuinUSlCu3gfov+NyNdaTLNps+7NO+y1uHd9qqhGB4tDqoDvxN5yyQa7pfAs8QiVL3lPWZhW0fO2VAmTPNuv5Q0JiJcXUSENngDxMm8+0EMubZjAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECI2FhKjyfBKBgBDh89w0B7z6zEQp/bhRGMw2

You will use the encrypted password in the next step.

2. Next you need to enable your Windows Azure role for Connect (see steps listed in this tutorial) and configure it for domain-joining, by providing the domain join settings in your ServiceConfiguration.cscfg file. These settings are listed below.

Settings	Description	Required
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value="true" />	Set “EnableDomainJoin” to true if you would like domain join Windows Azure role instances to on-premise AD.	Yes
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainFQDN" value="corp.contoso.com" />	Set “DomainFQDN” to the fully qualified domain name of which your role instances need to join (see highlighted example).	Yes
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainControllerFQDN" value="myDC.corp.contoso.com" />	Optionally, you can set “DomainControllerFQDN” to the fully qualified domain name of the domain controller (see highlighted example).	No
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainAccountName" value="corp\testuser" />	Set “DomainAccountName” to the domain account that has permission to domain join Windows Azure role instances (see highlighted example).	Yes
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainPassword" value="MIIBFwYJKoZIhvcNAQcDoIIBCDCCAQQCAQAxgckwgcYCAQAwLzAbMRkwFwYDVQQDExBNeUVuY3J5cHRpb25DZXJ0AhCTEsiJ0zzrjktvASTLQh7qMA0GCSqGSIb3DQEBAQUABIGABGQW6efUv3fpewvgCcqxqfzJu5gmlUqXPg60aggvDeBYwyPL6xVqZ9DZYiYxbBmHSjJgzrIrLY+rP3EMtV/8G4f6hvyewasWvJgMe2vzwcMGSKqixcIRnCLuLov7zLgCsYylzZ1h4j/SIf0gUBtwC1leW4C07z+KtQb8fdDbi5wwMwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAiyEoiHBP8V8YAQ2PN+j2uY07qpS93N15uQkA==" />	Set “DomainPassword” to the encrypted password you got in previous step (see highlighted example).	Yes
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DNSServers" value="myDC.corp.contoso.com" />	Set “DNSServers” to the fully qualified domain name of the domain controller (see highlighted example).	Yes
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainOU" value="OU=AzureMachines,DC=corp,DC=contoso,DC=com" />	Optionally, you can specify an OU container for your Azure role instances to join (see highlighted example).	No
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.Administrators" value="corp\user1, corp\group1" />	Optionally, you can specify existing on-premise AD users and groups (as a comma separated list) to add to the local Administrators group for your Azure role instances (see highlighted example).	No
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainSiteName" value="" />	Reserved for future use. Leave the value as an empty string.	No

Now that your Windows Azure roles is enabled for domain join, you can deploy it to Windows Azure. Once your Windows Azure role is successfully deployed and they are running in a “Ready” state, you should be able to see the role instances in the Connect portal (To enter the Connect portal, click the “Virtual Network” tab in the Azure portal, and then select the Windows Azure subscription that you want to use for Connect)

3. Next install the Connect endpoint software on the Domain Controller (see steps listed in this tutorial if this is new to you).

4. Using the Connect portal, create a local machine group, which is connected to the Windows Azure Roles that you wish to domain join and has the Domain Controller as a member (see steps listed in this tutorial if this is new to you).

Once the “connection” is created between the Windows Azure role and the local group with the Domain Controller, within a few minutes you should see that the Windows Azure role instances are domain joined. You can tell if this has happened because the role instance names in the Connect portal will have domain suffixes (e.g. RD00155D3292FC.corp.mydomain.com).

You should also see that the Windows Azure instances have been added as new computers in your Active Directory. In the screenshot below the Windows Azure instances were configured to join an OU “AzureMachines” in Active Directory.

You can verify that your role instances are actually domain-joined. For example, using the Remote Access feature in the Windows Azure portal, you can log into a role instance using a domain user account that was added to the Administrators group for your role. You can then view Computer Properties to confirm that the role instance is indeed domain-joined, as shown in the screenshot below.

Note: if you configured Active Directory to apply Group Policy to your domain-joined Windows Azure instances, please make sure that the Group Policy does not configure a proxy server that is not reachable by Windows Azure. This will ensure that your domain-joined role instances continue to work with Windows Azure Connect; otherwise they may lose connectivity.

--Jason Chen

Getting Started with Windows Azure Connect

2010-12-08T22:13:00Z

Windows Azure Connect (previously known as Project codename Sydney) is a new feature that enables Windows Azure users to setup secure, IP-level network connectivity between their Windows Azure services and on-premises resources. Windows Azure Connect is currently available as a CTP (invite-only, so if you are interested in trying out you will need to request access through the new Windows Azure portal.

In this first post, we wanted to provide a few links to help you get started with Windows Azure Connect.

Overview of Windows Azure Connect
PDC 2010 presentation on “Understanding Windows Azure Connect”
Step-by-step tutorial that walks through how to setup Windows Azure Connect

If you have questions or feedback, you can post them to the Connectivity forum. You can of course leave comments on the blog as well. We look forward to hearing from you!

--Jason Chen