Cloud Zone is brought to you in partnership with:

Michael Collier is a Windows Azure MVP and serves as a National Architect for Neudesic, a Microsoft SI partner that specializes in Windows Azure. He has nearly 11 years of experience building Microsoft-based applications for a wide range of clients. Michael spends his days serving as a developer or architect – helping clients succeed with the Microsoft development platform. He also enjoys speaking about Windows Azure at local user groups, as well as regional and national conferences. Michael is also the founder of the Central Ohio Cloud Computing User Group in Columbus, OH. You can follow Michael on Twitter at www.twitter.com/MichaelCollier and on his blog at www.MichaelSCollier.com. Michael has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Configuring Connectivity with Windows Azure PowerShell Cmdlets

03.01.2013
| 912 views |
  • submit to reddit

I’ve been noticing an increasing level of confusion about how to set up connectivity between Windows Azure and a person’s machine using the Windows Azure PowerShell cmdlets.  I’d like to try to set a few things straight.

It seems that nearly all the tutorials, examples, and quick starts on using the Windows Azure PowerShell cmdlets start with one command:

Get-AzurePublishSettingsFile

I view this is a convenience command.  Executing the command will do the following:

  1. Opens a browser window to https://windows.azure.com/download/publishprofile.aspx.  You’ll authenticate with your Microsoft Account.
  2. You’ll be prompted to download and save a .publishsettings file.  The .publishsettings file contains a list of all subscriptions for which your Microsoft Account is an admin or co-admin, as well as a base64 encoded management certificate.
  3. Windows Azure will automatically associate the newly created management certificate with every subscription for which your Microsoft Account is an admin or co-admin.

With the .publishsettings file you can execute the Import-AzurePublishSettingsFile command to configure connectivity between your machine, the Windows Azure PowerShell cmdlets, and Windows Azure.  This same file can also be imported into Visual Studio to configure connectivity between Visual Studio and Windows Azure.

Import-AzurePublishSettingsFile <subscription1-subscription2>.publishsettings

WindowsAzurePublishImportWizard

I’ve noticed some people repeatedly following step 1 in the many tutorials and quick starts – repeatedly executing Get-AzurePublishSettingsFile.  There is really no need to follow those same steps each time.  In fact, it’s probably a bad thing (to do each time).  Instead, manually configure the connectivity between your machine and Windows Azure.  If you already have a management certificate on your machine and in the Windows Azure subscription you want to manage, you can use that certificate (instead of one created by Get-AzurePublishSettingsFile).  You just need to write a few more lines of PowerShell, such as the following:

$subscriptionName = ‘<SUBSCRIPTION_NAME>’
$subscriptionId = ‘<SUBSCRIPTION_ID>’
$thumbprint = ‘<MANAGEMENT_CERTIFICATE_THUMBPRINT>’
$mgmtCert = Get-Item cert:\\CurrentUser\My\$thumbprint

# Configure the subscription details in the Windows Azure PowerShell cmdlets
Set-AzureSubscription -SubscriptionName $subscriptionName -SubscriptionId $subscriptionId -Certificate $mgmtCert

# Make the default
Set-AzureSubscription -DefaultSubscription $subscriptionName

# Configure the subscription to use the storage account
Set-AzureSubscription -SubscriptionName $subscriptionName –CurrentStorageAccount ‘mystorageaccount’

Personally this is the approach I use nearly all the time.  It’s a little more work, but I gain more control over the subscriptions that I’m managing using either PowerShell or Visual Studio.  I hope this helps to clear up some confusion on how to configure your machine to work with Windows Azure.

Published at DZone with permission of its author, Michael Collier. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)