Cloud computing, like any new technology, should make financial sense.  An example of an ideal cloud application is one with minimal use for months followed by huge spikes (e.g. sites that process taxes, yearly stockholder proxy votes, etc.).  This makes sense because of the ability to “dial up or dial down” resources in the cloud.  While this is a specific example, there’s a more general guiding principal behind moving to the cloud.

Ultimately, cloud computing allows IT staff to focus on strategic business issues and systems vs. base infrastructure.  Because of this, when systems need to be upgraded, it makes sense to consider cloud based solutions.

At Intertech, as we look to renew licenses for on-premise servers, we’re doing a compare, contrast of hosting inside our walls vs. hosted.  For most of the off-the-shelf software we use to run our firm, from CRM to our mail server, we’re finding cloud based solutions are more economical.  As noted, they also allow our IT folks to focus on areas that make our firm strategically different (such as our world-class online classroom training infrastructure/solution).  We’re not alone in this thinking. 

Andrew McAfee, of MIT, states the cloud is ideal for IT groups “stretched thin” and the cloud offers an opportunity to pursue new activities “nimbly” and “cost effectively.” For further insights from Mr. McAfee, check out the November Harvard Business Review.

Before diving into cloud-related pros and cons of cloud computing, let’s do a quick summary of the three primary cloud computing service offerings:

IAAS:  INFRASTRUCTURE-AS-A-SERVICE.  This is the simplest.  It’s similar to hosting.  In short, it’s one or more servers in the cloud.  The benefit is flexible storage and bandwidth.  IAAS allows outsourcing of the machines and base technology (OS).  The management of what runs on the IAAS is up to you or your IT provider.

PAAS:  PLATFORM-AS-A-SERVICE:  PAAS allows firms to be up-and-running quickly on a platform like Java, .NET, or Python.  With this platform in place, you can quickly provision an application development space for developers.

SAAS:  SOFTWARE-AS-A-SERVICE:  This is the largest, and most mature, of the offerings.  It’s simple to use.  SAAS is software accessed over the web (think gmail, Microsoft 365, or, the granddaddy of SAAS, Salesforce.com).

Intertech had a record 2011.  Luckily, we hit or exceeded all of our goals except for one.  The goal was around creating custom cloud-based applications.  With all the hype around cloud computing, it left me asking “Why?”

We believe cloud computing is the future of IT.  From creating Microsoft’s course on Azure to national briefings on cloud computing, we’re working to be the best provider of cloud-based development services.  At first, I thought it was our client base.  Turns out, our clients are not alone in their movement to the cloud.

InformationWeek in a 2011 survey stated only 29% of respondents analyzed the impact of the cloud.  Further, Gartner, a leading research firm, predicts:

• Cloud computing will grow at 19 percent per annum thru 2015 (sounds like a lot)
• Cloud computing in 2015 will account for < 5% of worldwide IT spending (yet... seems surprisingly small)

So, given the above, why should companies care about the cloud? 

Here are a couple of reasons and examples… leading thought leaders like MIT scientist Andrew McAfee states the economics of building and running a technology infrastructure favors the cloud vs. on-premise computing.  The CIO for the U.S. called for moving a quarter – or $20 billion – of fed IT spending to the cloud.  That’s a heavy bet for the CIO of our country.  As a CEO, have you given much thought to the implications of the cloud?

• Do you think the cloud will displace you or your department?
• Because “cloud” is overused, almost like the word “leadership”, are you unsure what “cloud computing” means?
• Are you concerned about the benefits vs. risks?

If you answered yes to any of the above, my hope is one of my next posts will help.  In part, it’s information from the article, “What Every CEO Needs to Know about the Cloud” by Andrew McAfee, Harvard Business Review (HBR) November 2011.

by Jim White (Director of Training and Instructor)

With Windows Azure SDK 1.3, you can run multiple Web Sites in a single Web role.  Prior to Windows Azure SDK 1.3, each Web role ran a single Web application.  This constraint was largely because Web roles were hosted in IIS Hosted Web Core where a single application was bound to a single HTTP/HTTPS endpoint.  Now, Windows Azure supports full IIS capabilities allowing Web roles to support multiple Web sites and Web applications.

Create or Add Existing Web sites to a Cloud Project

Multiple Web sites and applications are accomplished using Web sites, virtual applications, and virtual directories features in IIS 7.0.  You can find more information about these IIS 7 features here.  Once you have a Windows Azure project with an existing Web role, you can create or add existing Web sites to the project.  With the new Windows Azure Tools for Visual Studio version 1.3 (or better), there is nothing Azure-specific that needs to be done to create or add a Web site to the solution.  Simply use the existing VS means of creating or adding a Web Site to the solution containing your Windows Azure project.
In this example, a virtual application and virtual directory Web sites were added to a HelloWorld project.However, without any other work, if you were to run this application in the cloud or on the Compute Emulator, only the HelloWorld Web role would be accessible.  Neither of the two new Web sites could be reached.

Making Web Sites Accessible

In order to incorporate the Web sites into the Windows Azure project, new elements need to be added to the service definition file (.csdef).  Specifically, you need to add a new <VirtualApplication> and <VirtualDirectory> elements for the Web sites added to the solution.  Unfortunately, there are no tools to accomplish this task at this time.  You must open the service definition file and add the XML necessary to define your Web sites.  When you open the service definition file, you find there is an existing <Site> child element to the <Sites>.

<WebRole name="HelloWorldWebRole">
  <Sites>
    <Site name="Web">
      <Bindings>
        <Binding name="Endpoint1" endpointName="Endpoint1" />
      </Bindings>
    </Site>
  </Sites>
  ...
</WebRole>

This site is for the existing Web role endpoint ? the HelloWorldWebRole in this example.  Add child <VirtualApplication> and <VirtualDirectory> elements to the <Site> in order to add virtual application and virtual directory Web sites.  The example virtual application and virtual directory from above are added here.

<WebRole name="HelloWorldWebRole">
  <Sites>
    <Site name="Web">
      <VirtualApplication name="HelloWorldVirtApp"    
        physicalDirectory="../../WebSites/HelloWorldVirtualApplication" />
      <VirtualDirectory name="HelloWorldVirtDir"  
        physicalDirectory="../../WebSites/HelloWorldVirtualDirectory" />
      <Bindings>
        <Binding name="Endpoint1" endpointName="Endpoint1" />
      </Bindings>
    </Site>
  </Sites>
  ...
</WebRole>

Now the Web sites (virtual application and virtual directory) can be accessed through Azure or the Compute Emulator.  Simply use the virtual application name with the Web role URL to access the virtual application Web site. Use the virtual directory name and resource name with the Web role URL to access a resource in the virtual directory.

Using the Old Hosted Web Core

You can still run in the old-style Hosted Web Core mode.  This limits the capabilities of your application ? such as having multiple Web sites per role.  To run in Hosted Web Core versus full IIS 7, simply remove the <Sites> element from the service definition file.

<WebRole name="HelloWorldWebRole">
  <!-- <Sites>
    <Site name="Web">
      <Bindings>
        <Binding name="Endpoint1" endpointName="Endpoint1" />
      </Bindings>
    </Site>
  </Sites> -->
  ...
</WebRole>

A better understanding of the differences (and impact) of running Full IIS 7 versus running in Hosted Web Core can be found in a blog post by the Windows Azure Team here.

More Information

I found the following MSDN articles and blog posts to be helpful in learning about Multiple Web Sites with Azure.

http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
http://msdn.microsoft.com/en-us/library/gg433110.aspx
http://blog.bareweb.eu/2011/01/azure-running-multiple-web-sites-in-a-single-webrole/
http://blogs.msdn.com/b/avkashchauhan/archive/2011/01/24/dissection-of-a-windows-azure-sdk-1-3-based-asp-net-web-role-in-full-iis-mode-amp-hwc.aspx

Wrap Up

I recently completed writing the update (version 3) of Intertech's Complete Windows Azure class.  Here's a list of what's new in the class.

-    All text and labs have been updated to cover the new Windows Azure Developer Portal 
-    All labs have been updated to use Windows Azure SDK ver. 1.3 
-    A chapter on Windows Azure Administration was added to include material on subscriptions, how to set up and utilize co-administrators, understanding Windows Azure OS Family and Guest OS, Remote Desktop to Windows Azure virtual machines, and more. 
-    A new lab was added to try Remote Desktop into an Azure virtual machine. 
-    Lab material was added to explore co-administration of Windows Azure. 
-    A new lab was added to explore SQL Azure and tools for creating and exploring databases in the cloud. 
-    Lab material was added to explore how to see how to publish to Azure directly through Visual Studio (bypassing  the Developer Portal). 
-    Material was added to explore Web roles with multiple Web sites. 
-    All labs and text have been updated to include Visual Basic code samples and lab solutions (in addition to C# samples and lab solutions). 
-    An explanation of the new extra small VM and use of the extra small VM in labs. 
-    A quick look at the VM Role and how it relates to the other parts of Windows Azure Compute. 
-    A look at using IntelliTrace in Visual Studio to debug and examine applications running in the cloud.

Click here for more details on Intertech's Complete Windows Azure class.  If your team needs help implementing an Azure solution, contact Ryan McCabe (Intertech's account representative for Azure) at rmccabe@intertech.com.  As always, I also encourage you to register with the Virtual Azure User Group (azureug.net).  We meet monthly in virtual space and share our knowledge and experiences on Azure.

By Jim White (Director of Training and instructor)

Before a piece of code starts on a server, you often need to initialize the environment that will host that piece of code.  For example, you may need to install other software, register a component, start another process, etc.  The same might be true even when your code is a Windows Azure role and it is running in the cloud.  Windows Azure SDK 1.3 added the ability to run startup tasks with elevated privileges to access restricted features of the operating system and have more control over running the instance.

Startup tasks allow you to run an initialization script or program (batch file, PowerShell script, etc.) on the hosting virtual machine before your role is started.  Startup tasks are created and added to your role project.

How to Add Startup Tasks to your Cloud Project

To add a startup task to your cloud project, simply create a task and add it to your Azure role project of your cloud solution in Visual Studio.As a simple example, the GetIPConfig.cmd script below simply gathers the ipconfig information and stores it in a file called c:\ipdata.txt.

ipconfig > c:\\ipdata.txt

Obviously, your script can and probably will be more complex.  As a note of warning, VS attaches a byte order mark to all files by default.  A byte code order is a Unicode character used to signal the endianness (or byte order) of a text file.  You do not want the byte code order in your simple script/text files (which is the basis for most script files).  Therefore, make sure you select ?Advanced Save Options?? from the file menu before saving script files.Make sure the script files are saved with Unicode (UTF-8 without signature) ? Codepage 650001 encoding.

You want to make sure the task gets deployed with your cloud project and copied to the right location on the virtual machine.  Using the Properties editor in VS, configure the file to ?Copy to Output Directory.?This causes the file to be copied to bin folder of your role.  Windows Azure looks in the bin folder for the startup tasks.

Register the Task in the Service Definition

Once you have a startup task file in your role project, register and configure the task in the service definition file.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="HelloWorld" xmlns= "http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="HelloAzureWebRole">
    <Startup>
      <Task commandLine="GetIPConfig.cmd" executionContext="elevated" 
         taskType="background"/>
    </Startup>
    ...
  </WebRole>
</ServiceDefinition>

Notice the <Startup> element (and therefore the <Task> element) is a child element of the role element in the service definition file.  This indicates that each role can have zero to many startup tasks.  However, the startup task is specific to a role.  The commandLine attribute specifies the name of the script or program to execute before the role starts.  The executionContext attribute determines the level of permissions needed for the startup task.  Options include limited and elevated.  Under limited permissions, the task runs with the same privileges as the role.  Whereas, elevated permissions causes the task to run with administrative privileges. 

Task Execution

Lastly, the taskType indicates how the task should run.  Options include simple, foreground, or background execution.  A simple task type executes synchronously.  In other words, the task blocks execution of the role until the task completes.  Simple is the default taskType.  When run as a background type of task, the task launches and then Azure starts the role immediately.  In other words, background tasks are asynchronous.  Foreground task types are also asynchronous.  However, the role cannot be shutdown until all startup such tasks exit/complete.

The startup tasks will execute on your development machine when you run the solution in the Compute Emulator.  It is particularly important to test simple tasks since they will block role startup if they do not complete successfully.  Once running in the cloud, you may want to use Remote Desktop to check that the startup tasks executed correctly.

See here for more information on how to setup your roles for Remote Desktop.

Wrap Up

For more information about Windows Azure Startup Tasks see the MSDN site.  If you are just starting out in Windows Azure, consider taking Intertech's Complete Windows Azure class.  I just completed the third version of this class.  Here is a list of the new features covered.

?    All text and labs have been updated to cover the new Windows Azure Developer Portal
?    All labs have been updated to use Windows Azure SDK ver. 1.3
?    A chapter on Windows Azure Administration was added to include material on subscriptions, how to set up and utilize co-administrators, understanding Windows Azure OS Family and Guest OS, Remote Desktop to Windows Azure virtual machines, and more.
?    A new lab was added to try Remote Desktop into an Azure virtual machine.
?    Lab material was added to explore co-administration of Windows Azure.
?    A new lab was added to explore SQL Azure and tools for creating and exploring databases in the cloud.
?    Lab material was added to explore how to see how to publish to Azure directly through Visual Studio (bypassing  the Developer Portal).
?    Material was added to explore Web roles with multiple Web sites.
?    All labs and text have been updated to include Visual Basic code samples and lab solutions (in addition to C# samples and lab solutions).
?    An explanation of the new extra small VM and use of the extra small VM in labs.
?    A quick look at the VM Role and how it relates to the other parts of Windows Azure Compute.
?    A quick look at Windows Azure Startup Tasks.
?    A look at using IntelliTrace in Visual Studio to debug and examine applications running in the cloud.

If your team needs help implementing an Azure solution, contact Ryan McCabe (Intertech's account representative for Azure) at rmccabe@intertech.com.  Finally, I also encourage you to register with the Virtual Azure User Group (azureug.net).  We meet monthly in virtual space and share our knowledge and experiences on Azure.

by Jim White (Director of Training and instructor)

The process of moving an application into the Windows Azure runtime environment (the Microsoft data centers running Azure) is called publishing.  You may also find some documentation refer to the process as deploying.  In fact even the window prompt that appears when you ask to publish is labeled ?Deploy Windows Azure project.?  To publish (or deploy) an application, right click on your project in the Solution Explorer of Visual Studio 2010 and select Publish?. VS displays the Deploy Windows Azure project window when you request to publish.

Publishing Options

With Windows Azure SDK 1.3 and VS 2010, you can publish directly to the cloud, or use VS to create the necessary files (the service package) which you can later use to manually deploy at a later time.  The radio buttons at the top of the Deploy Windows Azure project window allow you to pick from these two options.

Regardless of how you deploy, VS creates two files when you publish:  a cloud service package file (.cspkg file) and cloud service configuration file (.cscfg file).
These files make up the service package.  You can find them in the .\bin\Debug\Publish folder of your project after you publish.

"Manual" Publishing

What I call "manual publishing" used to be the only deployment option for Windows Azure hosted services (apart from using the service management API).

Under this option, you create the cloud service configuration file (.cscfg file) and the cloud service package file (.cspkg file) and use the Windows Azure Developer Portal to upload the service package files and create (or update) your hosted service.

Publish Direct

In order to publish directly to the cloud through VS, you must have a Windows Azure account with a hosted service and storage account already configured.

Side note:  Even though your application may not use a storage account, you must still have a storage account associated to your Windows Azure account to use the direct publishing means.  The reason you need a storage account is that the service package will be stored in cloud storage before it is deployed.  If your application does use Azure Storage, the storage account used for deployment does not have to be the storage account that you use for the application.

In order to publish directly to the cloud from VS, you must first have established the target hosted service (and storage account) in the cloud.  To do this, login to the Developer Portal and click on the New Hosted Service icon in the menu bar at the top of the Portal page.

Create the Hosted Service

In the Create a new Hosted Service window that appears, enter the following data into the form fields (as shown in the picture below):
1.    A name for your service
2.    URL prefix (this must be unique for all of Windows Azure)
3.    Region or affinity group:  pick your favorite deployment region.  Usually, you want to pick a region closest to your users (or you)
4.    Pick Do not deploy radio button under the Deployment options.

As you can see, when you set up the hosted service for direct deployment from VS, you don't provide the service package yet.  Don't forget to also create the storage account.

Create and Upload the Authentication Credentials

With the hosted service (and storage account) now created, you can use Visual Studio to deploy Windows Azure projects directly to your Azure account.  In order to be able to deploy applications directly to Azure, VS must have and use appropriate authentication credentials for your Windows Azure account.  Authentication is accomplished by certificate.  So, you need to create a certificate and upload it to Windows Azure, and associate the certificate to your Azure account.

Side note:  While establishing and deploying the authentication certificate takes some time, this is a one-time procedure for your account.

In the Solution Explorer in VS, right click on your cloud project and select Publish? from the resulting menu.  Again, when you publish, a popup window should open allowing you to pick how you want to deploy your project.  Select the ?Deploy your Windows Azure project to Windows Azure? radio button.The Hosted Services <Not connected> section of the window should now be active.  Select the Credentials drop down box and select <Add?> from the menu.

 
In the resulting Windows Azure Project Management Authentication window that displays, pull down the list under ?1. Create or select an existing certificate for authentication:? Select <Create?> from the resulting drop down menu.In the dialog prompt that appears, provide a meaningful name for your certificate and then hit the OK button.  This has the effect of creating a certificate and putting the certificate in your personal store on your machine.Next, you need to upload the certificate to the Windows Azure Developer Portal and associate the certificate to your Azure account.  Back in the Windows Azure Project Management Authentication window, click on the ?Copy the full path? link listed at #2.  This copies the path to your certificate to your clipboard so it is easy to upload to Windows Azure.You should get a message prompt indicating VS successfully copied the certificate?s public key file path to the clipboard. Now return to the Windows Azure Developer Portal.  Click on the Management Certificates folder on the Portal.

Click on the Add Certificate button in the icon menu bar at the top of the Portal.In the Add New Management Certificate window that appears, push the Browse? button and then paste the contents of the clipboard (the path to the certificate public key file) into the File name entry in the resulting Open window.Once the certificate file location is pasted into the window, hit the Open button and resulting Done button on the Add new Management Certificate window.  Your certificate should now be displayed in the listing under Management Certificates in the Portal.

Side note:  This certificate is now permanently associated to your Windows Azure account.  You should not have to do this part of the process again.  You can use it for a number of activities ? to include publishing/deploying applications to your account.

Before you leave the Portal and return to VS to continue the publishing exercise, you need to copy your Windows Azure account subscription ID.  Locate the Subscription ID in the Properties area on the right side of the Portal.

Select the text of Subscription ID and hit CTRL-C to copy the value to the clipboard.  You will need this value to establish your Azure credentials in VS.

Publish the Application through VS

With the authentication certificate in place, you can now return to VS to publish/deploy your application.  Back in the Windows Azure Project Management Authentication window (in VS), paste the just acquired Azure account subscription ID into field #3.  Also, provide a name for your credentials (your certificate and authentication credentials will be saved to VS under this name).  Hit the OK button once these final pieces of information are added.In the Deploy Windows Azure project window, your new credentials display in the drop down.  Also displayed is the hosted service and storage account names you created above.  Your project is now ready to be deployed to this hosted service.
If you pull down the menu from ?Deployment environment to deploy to:? drop down list, you should see your option to deploy to either the hosted service?s stage or production environment (stage is selected by default).

Lastly, before deploying, provide a deployment name (a.k.a. Deployment Label in VS).  The label will be used as the deployment name in Azure.  By default, it is the name of the project with a date timestamp.  You can change the label or use the default.  Once entered, hit the OK button on the window to deploy your project to Azure.It will take VS several minutes to deploy your project to Azure.  It will also take Azure several minutes to create and ready your deployment (just as you experienced in the manual deployment).  The status of the deployment can be observed in the activity log in VS.At the same time, the same status should be reflected in the Portal.Once the deployment is complete and the service is ready, you can test as you did in step 3.3 above.  You can also test by clicking on the link displayed in the Activity Log in VS.

Wrap Up

For more information about Azure and publishing/deployment, see the MSDN site.  If you are just starting out in Windows Azure, consider taking Intertech's Complete Windows Azure class.  I just completed the third version of this class and details are soon to be released (stay tuned to this blog site for details).  If your team needs help implementing an Azure solution, contact Ryan McCabe (Intertech's account representative for Azure) at rmccabe@intertech.com.  Finally, I also encourage you to register with the Virtual Azure User Group (azureug.net).  We meet monthly in virtual space and share our knowledge and experiences on Azure.

By Jim White (Director of Training and instructor)

I just returned from The ServerSide Java Symposium early this morning.  Some of the keynotes this year were delivered by James Gosling, Rod Johnson, and other distinguished members of the Java and software engineering community.

It is evident from the talks and discussions that cloud computing is forefront on the minds of platform providers and is of growing interest to the development community at large. 

On the provider side, Steve Harris, Senior VP of Application Server Development at Oracle, indicated that Java EE 8 needs to support cloud development.  Rod Johnson, General Manager, Spring Source Division of vmWare, was demonstrating Code2Cloud (a "turnkey suite of cloud-based development, deployment and collaboration tools") to be offered in beta format by May and suggesting we should all look forward to cloud products in GA offered by vmWare yet this year.

While platform providers and vendors are busy planning, building and presenting their products, it was clear from discussions I had with many conference attendees, that most organizational developers are just starting to get their arms around cloud computing, what it can do for their organizations, and what they need to do to start to leverage the cloud.

It would seem that the marketplace offerings (as is usually the case) are just a little out in front of actual demand and implementation at this point - but I think that is about to change.  Interest in cloud computing has never seemed higher - although this is the ServerSide conference so if one ever expected an audience to be receptive to cloud computing it would seem the TSSJS community would be it.  I believe that within 5 years, "the cloud" will be the server side for most organizations (if not in whole, at least in part) and I think all those mobile devices (smart phones, pads, and the like) will be the client side for most organizations.

Its way to early to know what products and services in the cloud community will thrive, but suffice it to say that for most software engineers, "cloud" will be in their work vocabulary and not just their daily forecast for the foreseeable future.

For those that attended my talk on Java in the Microsoft Cloud - first a thank you!  Find the the slide presentation and the demo code I showed at this link: http://www.intertech.com/materials/Talks/ServerSideSymposium/.  Thanks also to the ServerSide and TechTarget organizations for giving me the chance to speak and providing a great conference.

By Jim White (Instructor and Director of Training)

Along with many features added to Windows Azure recently (see a full list of new features in the new Azure release here), one praised by the system administrator community is the ability to add co-administrators.  Co-administrators can help manage the services and data stored in the Windows Azure cloud.

Subscriptions and Administrators

Understanding co-administrators requires a bit of background and broader understanding of the term "administrator" in Azure.   In order to deploy services and data to Windows Azure, you need a Windows Azure subscription.  To set up a Windows Azure subscription you must setup an account with Microsoft Online Services.  When establishing the subscription, you also establish the Account Administrator and Service Administrator. 

Account Administrator

The account administrator is also known as Account Owner.  The Account Administrator is the person responsible for paying the subscription bill.  He or she has access to and works through the Microsoft Online Services Customer Portal (MCOP) to view and manage the subscription bills.  Normally, the Account Administrator has financial responsibilities in your company.

Service Administrator

The Service Administrator is also known as the Service Owner.  The Service Administrator manages the services that run in Windows Azure.  He or she has access to and uses the Window Azure Developer Portal or Service Management API to orchestrate the applications and data running in Azure.  Normally, the Service Administrator is a developer, system administrator, or other IT person responsible for IT services in your company.

When creating your subscription, the Account Administrator and Service Administrator can be setup as the same person.  Having different administrators allows for separation between financial responsibilities and operational responsibilities.  However, this role/responsibility separation is not required.

Co-administrators

The task of a system administration can be a big one.  In large enterprises, the number of applications and servers can be overwhelming.  It often requires the participation of many individuals.  Prior to November 2010 (the release of Windows Azure SDK 1.3), an Azure subscription had only one system administrator.  This meant that in a large enterprise, an organization had to have many separate subscriptions, or system administrators had to share a logins/passwords to Azure.  Neither of these alternatives proved ideal for system administration.

Since Windows Azure SDK 1.3, the Service Administrator can establish co-administrators.  More precisely, the Service Administrator can create co-Service Administrators that help manage Windows Azure operations.  When the subscription is created, only a single Service Administrator can manage the operations of the account.  Co-administrators help manage the services and data running in Windows Azure.

Co-administrators are identified by Windows Live ID.  Therefore, a person that you want to be a co-administrator of your subscription must have his or her own Windows Live ID.  If they do not have a Windows Live ID, they can create one at login.live.com.  Co-administrators have complete access to the subscription services.  They can even add or delete other co-administrators.  However, they cannot remove the Service Owner (the Service Administrator).  Also, co-administrators do not have access to payment/billing information (things managed by the Account Administrator).

Adding/Managing Co-administrators

To add a co-administrator to your subscription, first sign-in to the Windows Azure Developer Portal (as Service Administrator) at windows.azure.com.  Select the User Management folder on the Portal.

Next, click on the Add New Co-Admin button on the icon menu bar at the top of the Portal.

An Add New Co-Administrator Role window prompts you for the Windows Live ID of the new admin along with the applicable subscription.

The Manage Co-Admin button in the Portal icon menu bar allows you to remove the co-admin from a subscription or add additional subscriptions to a co-admin.

Wrap Up

For more information about Azure and co-administrators, see the MSDN site.  If you are just starting out in Windows Azure, consider taking Intertech's Complete Windows Azure class.  If your team needs help implementing an Azure solution, contact Ryan McCabe (Intertech's account representative for Azure) at rmccabe@intertech.com.  Finally, I also encourage you to register with the Virtual Azure User Group (azureug.net).  We meet monthly in virtual space and share our knowledge and experiences on Azure.

By Jim White (Director of Training and instructor)

Another new feature added to Windows Azure as of the Nov 2010 release (Windows Azure SDK 1.3) is Remote Desktop.  Side note:  per my last post, you can see a full list of new features in the new Azure release here.

Just as you have used Windows remote desktop to gain access to a server in your data center, you can now use remote desktop to access the virtual machine running your Windows Azure role (Web, worker or the new VM role).  Why remote desktop into an virtual machine running one of your roles?  You use remote desktop to configure or troubleshoot your role.

Assuming you have the latest Azure SDK 1.3, here are the steps necessary to use remote desktop in Azure:

1. Obtain (or create) a Personal Information Exchange certificate.
2. Upload the certificate to the Hosted Service in Windows Azure.
3. Using Visual Studio, publish your Azure role and configure the virtual machines for remote desktop connections (using the certificate).
4. Connect to the virtual machine once the instance is deployed and running.

1.  Obtain the PFX Certificate

Azure Certificates

There are a couple of types of certificate files you may need when building applications in Azure.  X.509 certificates are used to authenticate operations in Windows Azure.  X.509 certificates have a .cer extension.  Personal Information Exchange certificates are issued by a signing authority and verifies the authenticity and security of the hosted service.  Self-signed certificates can be used for testing purposes.  Personal Information Exchange certificates have a .pfx extension and are therefore usually referred to as PFX certificates.  Importantly, PFX are used for creating remote desktop connections.  Specifically, a PFX certificate is used to encrypt the password used to obtain a remote desktop connection. See here for more details on Azure certificates.

Creating the certificate

There are a couple of ways to create a PFX certificate.  You can use the makecert tool provided with the .NET Framework.  Alternatively, you can use the Internet Information Services (IIS) Manager.  See here for more details on creating certificates using both tools.  For demonstrations purposes, let's look at the makecert tool option.  Open a Visual Studio Command Prompt (make sure you do so as an administrator). In the command prompt window, type the following command:

makecert -sky exchange -r -n "CN=[your certificate's name]" -pe -a sha1 -len 
2048 -ss My "[your certificate's name].cer"

To learn more about the details and options around makecert too, take a look at the documentation here.

Exporting the certificate

With a certificat created, the next step is to export the certificate from your systems certificate store in PFX format.  Again, there are a few tools you can use to export certificates to PFX format.  You can either use the Certificate Manager (certmgr.msc) tool provide as part of the .NET Framework or export one from the Internet Information Services (IIS) Manager.  Again, for demonstration purposes, let's look at using the Certification Manager option.  Start the Certificate Manager by executing certmgr.msc in a command prompt window or in the Start menu textbox.When the Certificate Manager starts, locate your newly created certificate under Personal > Certificates (as shown below). Right click on your certificate in the list and select All Tasks > Export... from the menu. A wizard will now assist you in exporting your certificate.

On the first page of the wizard, hit the Next> button.  On the next page, select the Yes radio button to indicate you want to export the private key.  On the next page, make sure the Personal Information Exchange format radio button is selected and then hit the Next> button.  In the next page, enter the password for your private key and then save the PFX file to your designated location on the next page of the wizard (note the .pfx filename suffix).  The last page summarizes your export request.  When you hit the Finish button, if the export is successful, you get an appropriate message prompt.

2.  Create the Hosted Service and Upload the Certificate

At this point, you are ready to create the hosted service and upload you certificate that will allow remote desktop connections.  In this example, the hosted service and certificate will be created using the Windows Azure Portal.

Create the Hosted Service

Sign into the Windows Azure Portal (windows.azure.com) using your Windows Live ID (assuming you have a Windows Azure account).  Once logged in, request to create a new hosted service.  When you create the hosted service in Azure, you are not yet deploying code into the cloud.  You just need to create the hosted service shell to hold the new certificate.  So, when you create the service, make sure you select the "Do not deploy" radio button (shown below) on the Create a New Hosted Service entry form.

Upload the certificate

With the hosted service created (but the application role(s) not yet deployed), upload the certificate you created in step 1.  In the Hosted Services listing, click on the Certificates folder listed under your new hosted service and then click on the Add Certificate button that displays on the top of the portal page (see example below).You will be prompted to supply the certificate file and private key password.

When you browse to the location of the certificate in your filesystem, you will notice the portal UI constrains your selection to .pfx file types.

Once you select your PFX file and enter your password, it takes only a few seconds for the Windows Azure Portal to create and associate you certificate to your hosted service.  The certificate should now be listed under Certificates for the hosted service.

3.  Create the Role(s) and configure the Virtual Machine

Create your Cloud Project

Now the Azure host environment is prepped for remote desktop enabled roles.  The next task is to create your role(s) and configure the virtual machine instances than run those roles for remote desktop connections.  For example sake, I created a new cloud project (DemoRemoteDesktop) with a single Web role (DemoWebRole). Once your application has been constructed and tested and is ready to be deployed, right click on the cloud project and request to Publish... the project from the resulting menu (just as you normally would for any Azure Cloud application). When the Deploy Windows Azure project window comes up, select/enter your hosted service credentials, deployment environment (the new hosted service you just created in the last step),  the deployment label and then, importantly, click on the "Configure Remote Desktop connection" link shown at the bottom of the window (see below).

Configure Remote Desktop Configuration

In the prompt that results, check the "Enable connection for all roles" checkbox.  Then select the certificate used for the remote connection (the same certificate you created as part of step 1). Complete the entries in the Remote Desktop Configuration dialog.  Enter the username and password that you want to use to authenticate when you make a remote desktop connections into the virtual machine that will host your role(s).  The password must meet certain complexity requirements (it must contain a combination of capital letters, lower case letters, and numbers or symbols - the window will tell you if your password does not comply).  Also indicate the account expiration date.  After this date specified, remote desktop connections will be blocked.  This allows deployers/administrators to establish a small window of time whereby developers can remote in and configure/check on the roles, but then lock them out after things are running properly. Hit the OK button on the Remote Desktop Configuration dialog window and then again on the Deploy Windows Azure project window to complete the deployment. 

Make a Remote Desktop Connection

As always, it takes Visual Studio and Azure a few minutes to deploy and start your role(s).  Once your role(s) is up and running, you should now be able to remote desktop into the virtual machine running your instance(s).  First, you might notice that if you click on your roles listed in the Hosted Services display, the Azure portal indicates those that are are remote-desktop enabled via the Remote Access icons and indicators now enabled at the top of the page (see below). You can use the Enable checkbox to instantly turn off remote desktop connections.  Use the configure button to change the username, password, expiration time or certificate used as part of the connection.

When you click on one of the remote-desktop-enabled role instances, the Connect icon becomes enabled in the portal display.You might be wondering why you have to select a role instance?  Remember, you make a remote desktop connection to a virtual machine running a role and there may be (and probably will be) several instances for any role.  Pick the instance whose virtual machine you want to connect.

To make a remote desktop connection, having picked one of the role instances, simply click the Connect icon in the portal icon bar at the top of the display.  This causes a few pop-ups to appear.  First a File Download popup (the Remote Desktop Connection file) appears.  Push the Open button on this prompt.Next comes a security warning.  Push the Connect button on this prompt (since your certificate is not signed).Finally, you are prompted to sign-in to the virtual machine through the Windows Security popup.  Enter the username and password you created in step 3 above (when you configured your role for remote desktop connections) and press OK to login remotely.  Importantly, when you first login, proceed your username with a "\" indicating no Domain (as shown below).A final security alert window requires you acknowledge the warning by pushing the Yes button. Once authenticated, you should be be provided with a remote desktop screen just as if you connected to server in your data center.  The tip off that you are connected to Azure can be seen both in the remote desktop window's label (note the GUID and URL) and the background image that indicates the copy of Windows "is not genuine".

Wrap Up

So, as you can see, most of the work in getting remote desktop connections into Azure virtual machines is in creating and uploading the required certificate.  For more information about Azure and remote desktop, see the MSDN site.  If you are just starting out in Windows Azure, consider taking Intertech's Complete Windows Azure class.  If your team needs help implementing an Azure solution, contact Ryan McCabe (Intertech's account representative for Azure) at rmccabe@intertech.com.  Finally, I also encourage you to register with the Virtual Azure User Group (azureug.net).  We meet monthly in virtual space and share our knowledge and experiences on Azure.

This presentation is an introduction to Windows Azure Worker Roles. This session includes coverage of the Azure storage role and how messaging and queues work.