Windows Azure

Performance in Windows Azure and Azure Storage

2010-12-16T02:47:00.000+05:30

Check this link below.

http://convective.wordpress.com/2010/10/08/performance-in-windows-azure-and-azure-storage/

Diagnostics in Windows Azure

2010-12-16T02:31:00.000+05:30

Hi Friends,

Check this link below

http://convective.wordpress.com/2009/12/08/diagnostics-in-windows-azure/

Configuration Changes to Windows Azure Diagnostics in Azure SDK v1.3

2010-12-16T02:24:00.001+05:30

The configuration of Windows Azure Diagnostics (WAD) was changed in the Windows Azure SDK v1.3 release. This post is a follow-on to three earlier posts on Windows Azure Diagnostics – overview, custom diagnostics and diagnostics management – and describes how WAD configuration is affected by the Azure SDK v1.3 changes ...

Check this link for continuation

http://convective.wordpress.com/2010/12/01/configuration-changes-to-windows-azure-diagnostics-in-azure-sdk-v1-3/

Detail topics on Azure

2010-12-16T01:59:00.000+05:30

Check the links for Detail topics on Azure

Service Runtime in Windows Azure --> http://convective.wordpress.com/2010/03/18/service-runtime-in-windows-azure/

Auto scaling in Windows Azure --> http://convective.wordpress.com/2010/10/12/autoscaling-in-windows-azure/

Local Storage on Windows Azure --> http://convective.wordpress.com/2009/05/09/local-storage-on-windows-azure/

Interrole Communication Example in Windows Azure

2010-12-16T01:54:00.000+05:30

Hi Friends,

Check this links below which describes about Internal End Points of Azure with examples

Inter role Communication Example in Windows Azure

http://blogs.msdn.com/b/hakoman/archive/2010/06/26/interrole-communication-example-in-windows-azure.aspx

Creating an external facing Azure Worker Role endpoint

http://microsoft.realdolmenblogs.com/post/Creating-an-external-facing-Azure-Worker-Role-endpoint.aspx

Limitation on the number of internal endpoints per worker/ web role

You can have a maximum of 5 incoming endpoints per role (input or internal, doesn't matter). You can have a maximum of 5 roles. 5 * 5 = 25

Developing Sequential Workflow In ASP.Net Applications

2010-12-14T00:02:00.000+05:30

Check this link below for that sample

http://sunilyadav.wordpress.com/2009/10/16/developing-sequential-workflow-in-asp-net-applications/

Persisting a workflow Sample

2010-12-14T00:00:00.000+05:30

Persisting a workflow means to store a workflow in a durable medium to be loaded for later use. Some workflows are executed very shortly that they don’t need to be persisted. However, some workflows are long-running and are not completed for some period of time. This article shows how a workflow is persisted to a database and how to load it to continue execution.

Check this Aryicle below for more details. (To demonstrate how to persist a workflow, I’ll be reusing an application from my previous article entitled WPF and the Model View View Model pattern. Currently, it lets a user submit a new sales order and is added to a collection. In this article, a workflow will be use to submit and approve a sales order.)

http://www.eggheadcafe.com/tutorials/aspnet/93c7cf86-d7d8-46bf-a7f4-d5df69e3cbd1/persisting-wf-workflows.aspx

About Persistence WorkFlow

2010-12-13T23:48:00.001+05:30

Check the links below

Explanation with Example

http://doc.snyderit.com/essentialwindowsworkflowfoundationoct2006/pref04.html http://doc.snyderit.com/essentialwindowsworkflowfoundationoct2006/pref04.html

Another Persistence Workflow Sample

http://consultingblogs.emc.com/owainwragg/archive/2009/07/07/15661.aspx

SqlWorkflowPersistenceService in Windows Workflow Foundation

http://nayyeri.net/sqlworkflowpersistenceservice-in-windows-workflow-foundation

Windows Workflow Foundation in .NET4

2010-12-10T00:49:00.000+05:30

WWF sample developed in .Net 4.0

http://blogs.msdn.com/b/somasegar/archive/2010/03/22/windows-workflow-foundation-in-net4.aspx

Execute a Long-Running Workflow Using Persistence in Windows WF

http://www.devx.com/dotnet/Article/32247/1954

Use the Windows Workflow Persistence Service

2010-12-10T00:47:00.001+05:30

Check this link:

http://msdn.microsoft.com/en-us/library/ms735722(VS.85).aspx

Window Workflow Foundation Runtime Services: The Persistence Service

2010-12-10T00:46:00.000+05:30

Check this link for detailed explanation:

http://weblogs.asp.net/gsusx/archive/2005/10/05/426699.aspx

Windows Workflow 4.0

2010-12-10T00:42:00.000+05:30

Using Persistence Services Sample

Check this link below

http://msdn.microsoft.com/en-us/library/ms741700%28VS.90%29.aspx

Custom Persistence Service Sample

Check this link below

http://msdn.microsoft.com/en-us/library/ms741725%28VS.90%29.aspx

SQL Workflow Instance Store

http://msdn.microsoft.com/en-us/library/ee383994%28VS.100%29.aspx

One thing I've noticed is that if I persist a Workflow in the SQL Database persistence store, and then load it back into the application later and complete the workflow, the record is removed from the persistence store when the last activity of the workflow completes. I need to find out if this functionality is by design to keep the database from getting huge, or if I'm doing something wrong.

This delete behavior is configurable. For example, if you are using the WorkflowServiceHost and are using code to configure your service host, you could set the SqlWorkflowInstanceStoreBehavior.InstanceCompletionAction to InstanceCompletionAction.DeleteNothing as in the following example:

WorkflowServiceHost host = new WorkflowServiceHost(workflow, baseAddress);
SqlWorkflowInstanceStoreBehavior persistenceBehavior = new SqlWorkflowInstanceStoreBehavior(connString);
persistenceBehavior.InstanceCompletionAction = InstanceCompletionAction.DeleteNothing;
host.Description.Behaviors.Add(persistenceBehavior);

For more information on features of the SQL workflow instance store and how you can configure it, check out this MSDN article.

Azure + Bing Maps: Federated authentication with AppFabric ACS and Windows Live Messenger Connect

2010-12-09T00:55:00.000+05:30

Hi Friends,

Check this link below

http://blogs.msdn.com/b/windows-azure-support/archive/2010/12/07/azure-bing-maps-federated-authentication-with-appfabric-acs-and-windows-live-messenger-connect.aspx

Hybrid Cloud Solutions With Windows Azure AppFabric Middleware

2010-12-09T00:53:00.002+05:30

Hi Friends,

Check this Link below

http://blogs.msdn.com/b/appfabriccat/archive/2010/11/29/hybrid-cloud-solutions-with-windows-azure-appfabric-middleware.aspx

Windows Azure: Connecting to web role instance using Remote Desktop

2010-12-09T00:51:00.000+05:30

My last posting about cloud covered new features of Windows Azure. One of the new features available is Remote Desktop access to Windows Azure role instances. In this posting I will show you how to get connected to Windows Azure web role using Remote Desktop.

I suppose you have other deployment settings in place and only Remote Desktop needs configuring. Open publish dialog of your web role project in Visual Studio 2010.

In the bottom part of this dialog you can see the link Configure Remote Desktop connections… Click on it.

Also Remote Desktop needs certificate. You can create one from dropdown – there is option in the end of options list. After creating certificate you have to export it to your file system (Start => Run => certmgr.msc).

When certificate is exported add it to your hosted service in Windows Azure Portal.

Now fill username and password fields in Remote Desktop settings windows in your Visual Studio and click OK. After deploying your project you can access your web role instance over Remote Desktop. Just click on your instance in Windows Azure Portal and select Connect from toolbar. RDP-file for your web role instance connection will be downloaded and if you open it you can access your web application. For username and password use the same username and password you inserted before.

This is System window of my web role instance. You can see that Small instance account provided to MSDN Library subscribers has 2.10 Gz AMD Opteron processor (only one core is for my web app), 1.75 GB RAM and 64bit Windows Server Enterprise Edition.

Using Remote Desktop you can investigate and solve problems when your web application crashes, also you can make other changes to your web role instance. If you have more than one instance you should to same changes to all instances of same web role.

Reference: http://weblogs.asp.net/gunnarpeipman/archive/2010/12/04/windows-azure-connecting-to-web-role-instance-using-remote-desktop.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+gunnarpeipman+%28Gunnar+Peipman%27s+ASP.NET+blog%29&utm_content=Google+Reader

How to Resolve “SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used” After Moving to Windows Azure SDK 1.3

2010-12-09T00:31:00.001+05:30

If you’re receiving this exception after migrating a web role from Windows Azure SDK 1.2 to SDK 1.3, this may have to do with changes associated with the new full IIS model introduced in SDK 1.3. This post will help you to understand the change and how to use the FromConfigurationSetting method correctly under the full IIS model. If you want to simply go back to using the Hosted Web Core model (as in previous SDK releases), you can do that too.

The Full IIS Model

Full IIS in Windows Azure introduces new capabilities, such as hosting multiple web sites within a single web role and advanced IIS configuration. For a discussion of the new full IIS hosting model in Windows Azure SDK 1.3 and how it differs from the Hosted Web Core model used previously, see “New Full IIS Capabilities: Differences from Hosted Web Core” on the Windows Azure blog.

The following diagram from that post illustrates one difference that impacts how FromConfigurationSetting is used:

With the Hosted Web Core model, RoleEntryPoint code (e.g., WebRole.cs) and web application code (e.g., Default.aspx.cs for ASP.NET) were executed in the same app domain. Under full IIS, these are two distinct app domains. This means that static objects are no longer shared between these two parts of your application, and that’s the key to understanding how to use FromConfigurationSetting in the new full IIS hosting model.

Before: FromConfigurationSetting with Hosted Web Core

The Hosted Web Core model, where everything ran in the same app domain, lead to a common pattern for initializing CloudStorageAccount objects. This is how SDK 1.2 code was commonly written:

In the OnStart method of WebRole.cs:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSettingPublisher) =

{

           var connectionString =  

                    RoleEnvironment.GetConfigurationSettingValue(configName);

           configSettingPublisher(connectionString);

}

);

(Your function may look more complicated than this, but the information in this post still applies.) Then, in Default.aspx.cs (or an ASP.NET MVC controller):

var account = CloudStorageAccount.FromConfigurationSetting("MyConnectionString");

This code worked, because the call to SetConfigurationSettingPublisher was made in the same app domain as the call to FromConfigurationSetting. However, under the full IIS hosting model, these are two different app domains.

After: FromConfigurationSetting with full IIS

A convenient place to put the call to SetConfigurationSettingPublisher is in the Application_Start method, which runs as part of the app domain where all your web application code runs. This method is located in Global.asax.cs. (If you don’t have a Global.asax.cs already, you can add one by right-clicking on the web application project, choosing “Add,” “New Item,” and then “Global Application Class.”)

void Application_Start(object sender, EventArgs e)

{

          CloudStorageAccount.SetConfigurationSettingPublisher((configName,  configSettingPublisher) =>

{

               var connectionString = RoleEnvironment.GetConfigurationSettingValue(configName);

               configSettingPublisher(connectionString);

}

);

}

This is exactly the same code that would have been in WebRole.cs, just moved to a location that’s part of the web application’s app domain.

An Alternative

The combination of SetConfigurationSettingPublisher and FromConfigurationSetting abstracts the location of the configuration setting. Some people use this to write code that works both inside and outside of Windows Azure, reading configuration settings from Windows Azure when available and falling back to web.config or some other location otherwise.

If you don’t need this abstraction layer, you can use another method of initializing CloudStorageAccount objects from configuration settings:

var account = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("MyConnectionString"));

Reference : http://blog.smarx.com/posts/how-to-resolve-setconfigurationsettingpublisher-needs-to-be-called-before-fromconfigurationsetting-can-be-used-after-moving-to-windows-azure-sdk-1-3

Hosting workflow services in Windows Azure

2010-12-07T21:53:00.001+05:30

Since the latest release of the Windows Azure Development Kit (June), Azure provides support for .NET 4 applications, which is a real important step from the point of adoption, I believe.

The first thing we wanted to try was to host a XAMLX Workflow Service in a web role on Azure.

Example workflow service

I created a standard Workflow Service that accepted two parameters, on one operation (Multiply) and returns the result of the multiplication to the client. This service was called Calc.xamlx.

These are the steps I followed to make my service available. I added the exceptions, because that’s typically what users will search for J

Enable visualization of errors

Standard behavior of web roles, is to hide the exception for the users, browsing to a web page. Therefore, it is advised to add the following in the system.web section of the web.config:

Configure handler for Workflow Services

The typical error one would get, when just adding the Workflow Service to your web role and trying to browse it, is the following:

The requested url '/calc.xamlx' hosts a XAML document with root element type 'System.ServiceModel.Activities.WorkflowService'; but no http handler is configured for this root element type. Please check the configuration file and make sure that the 'system.xaml.hosting/httpHandlers' section exists and a http handler is configured for root element type 'System.ServiceModel.Activities.WorkflowService'.

We need to specify the correct HTTP handler that needs to be used for XAMLX files. Therefore, we link the workflow services and activities to the correct Workflow Service ServiceModel handler.

To solve this, the following needs to be added to the web.config.

<configuration>
       <configSections>
             <sectionGroup name="system.xaml.hosting" type="System.Xaml.Hosting.Configuration.XamlHostingSectionGroup, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
                   <section name="httpHandlers" type="System.Xaml.Hosting.Configuration.XamlHostingSection, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             sectionGroup>
       configSections>
       <!-- Removed other sections for clarity -–>
       <system.xaml.hosting>
             <httpHandlers>
                    <add xamlRootElementType="System.ServiceModel.Activities.WorkflowService, System.ServiceModel.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
                    <add xamlRootElementType="System.Activities.Activity, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             httpHandlers>
       system.xaml.hosting>
configuration>

Enabling metadata exposure of the workflow service

To enable consumers of our workflow service to generate their proxy classes, we want to expose the WSDL metadata of the service, by providing the following configuration section in the web.config.

Notice the simplicity of configuration, compared to WCF3.5. Making use of the default behaviors, allows us to only specify what we want to override.

<system.serviceModel>
       <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >
             <serviceActivations>
                    <add relativeAddress="~/Calc.xamlx" service="Calc.xamlx" factory="System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory"/>
             serviceActivations>
       serviceHostingEnvironment>
       <behaviors>
             <serviceBehaviors>
                    <behavior>
                           <serviceMetadata httpGetEnabled="true"/>
                    behavior>
             serviceBehaviors>
       behaviors>
system.serviceModel>

Testing and publishing

After successfully testing locally in the Azure Development Fabric, I uploaded and deployed the package, using the new Tools in Visual Studio to my Azure test account.

Author : Sam Vanhoutte, CODit

Taken from: http://www.codit.eu/Blog/post/2010/06/17/Hosting-workflow-services-in-Windows-Azure.aspx

A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4

2010-12-06T23:20:00.001+05:30

Check this link below to develop a WWF application

http://msdn.microsoft.com/en-us/library/ee342461.aspx

Simple MVC 2 App on Windows Azure

2010-12-06T22:59:00.000+05:30

Hi Friends,

Want to upload an MVC 2 Application on Windows Azure.

Check this link : http://www.barebonescoder.com/2010/12/simple-mvc-2-app-on-windows-azure/?utm_source=AzureMagic&utm_medium=twitter

Re-Introducing the Windows Azure AppFabric Access Control Service

2010-12-06T22:56:00.000+05:30

If you’re looking for a service that makes it easier to authenticate and authorize users within your Web sites and services, you should take another look at the Windows Azure AppFabric Access Control service (ACS for short), as some significant updates are in the works (at the time of this writing).

Opening up your application to be accessed by users belonging to different organizations—while maintaining high security standards—has always been a challenge. That problem has traditionally been associated with business and enterprise scenarios, where users typically live in directories. The rise of the social Web as an important arena for online activities makes it increasingly attractive to make your application accessible to users from the likes of Windows Live ID, Facebook, Yahoo and Google.

With the emergence of open standards, the situation is improving; however, as of today, implementing these standards directly in your applications while juggling the authentication protocols used by all those different entities is a big challenge. Perhaps the worst thing about implementing these things yourself is that you’re never done: Protocols evolve, new standards emerge and you’re often forced to go back and upgrade complicated, cryptography-ridden authentication code.

The ACS greatly simplifies these challenges. In a nutshell, the ACS can act as an intermediary between your application and the user repositories (identity providers, or IP) that store the accounts you want to work with. The ACS will take care of the low-level details of engaging each IP with its appropriate protocol, protecting your application code from having to take into account the details of every transaction type. The ACS supports numerous protocols such as OpenID, OAuth WRAP, OAuth 2.0, WS-Trust and WS-Federation. This allows you to take advantage of many IPs.

Outsourcing authentication (and some of the authorization) from your solution to the ACS is easy. All you have to do is leverage Windows Identity Foundation (WIF)—the extension to the Microsoft .NET Framework that enhances applications with advanced identity and access capabilities—and walk through a short Visual Studio wizard. You can usually do this without having to see a single line of code!

Does this sound Greek to you? Don’t worry, you’re not alone; as it often happens with identity and security, it’s harder to explain something than actually do it. Let’s pick one common usage of the ACS, outsourcing authentication of your Web site to multiple Web IPs, and walk through the steps it entails.

Outsourcing Authentication of a Web Site to the ACS

Let’s start by taking a vanilla Web site and enabling users to log in using a Google account.

Before we get started, let’s make sure we have the prerequisites covered. Here’s what we need:

Visual Studio 2010
Windows Identity Foundation Runtime
Windows Identity Foundation SDK and one of the following: Windows 7, Windows Server 2008, Windows Server 2008 R2 or Windows Vista SP1

Although it’s not a hard requirement, having IIS on the machine will help; if you don’t have IIS installed, you’ll have to adjust the steps of the walkthrough here and there.

While Visual Studio requires no introduction, it will probably help to expand a bit on WIF (pronounced “dub-IF”), and why it’s a prerequisite. (For a thorough explanation of WIF, see “Programming Windows Identity Foundation” [Microsoft Press, 2010]).

WIF is an extension to the .NET Framework that provides you with a new model for dealing with authentication and user identity, a model that decouples your application from the details of how authentication takes place. Traditional authentication systems (such as the ASP.NET Membership provider APIs) force you to cope with the details of how authentication takes place. This requires you to use low-level APIs to deal with low-level constructs such as passwords, certificates and the like. WIF changes all this by offering a handy abstraction that allows you to specify an external entity to handle user authentication.

With Forms-based authentication, you specify a given page—typically login.aspx—where requests are redirected whenever the caller is not yet authenticated. With WIF, you can enlist an external entity—an IP—to be invoked whenever a user needs authentication. The ways in which the IP is chosen at design time and engaged at run time follow well-known protocols. WIF takes care of discovering which protocols should be used and enforcing communication policies accordingly. Once again, this is much easier to show than to explain.

Create the Initial Solution

Open up Visual Studio. Create a new Web site by selecting File | New | Web Site. Let’s create a new ASP.NET Web site—but first, be sure that you’ve selected the Web location as “HTTP” and configured the URL so that it’s running in IIS (see Figure 1).This will ensure a smooth run when using the WIF tools. If you have HTTPS available on your Web server, it’s a good idea to use it; although not strictly necessary for this walkthrough, it’s highly recommended on production systems and will save you some warnings from WIF.

Figure 1 Selecting an ASP.NET Web Site with HTTP as the Location

When you hit F5, you’ll see that you have a basic ASP.NET Web site, and by clicking the “Log In” link you’ll get prompted to enter a username and password. This is what we’re going to change—instead of using a username and password and handling authentication directly in the Web site, we’re going to use WIF to outsource authentication to the ACS. The ACS will in turn allow us to open up access to external IPs.

Configure an ACS Project

To begin, we need to create a project in the Windows Azure AppFabric LABS portal. The LABS portal is an environment set up specifically for allowing the community to access early bits. There’s no cost associated with AppFabric LABS, but there are also no service-level agreements or guarantees.

Open your browser and go to portal.appfabriclabs.com. You’ll be prompted to log in with a Windows Live ID. Once logged in, you’ll need to create a new project—click the “create a project” link. You’ll have to choose a project name—select something appropriate and click OK. Once complete, you’ll see an active project name (“acsdemoproject” in our example)—click it (see Figure 2).

Figure 2 Creating a Project in the Windows Azure AppFabric LABS Portal

Before you can outsource authentication to the ACS, you need to define a service namespace. Think of the service namespace as providing you with your own slice of the AppFabric LABS environment and—for the ACS—the unique component for all the URIs of the resources you’ll use when interacting with the ACS from your application. Everything contained within the service namespace is yours to control. Click “Add Service Namespace,” specify a name, choose a zone—in LABS you can only select “United States (South/Central)”—and click Create. Note that the URIs used by AppFabric are available on the public Internet and are meant to uniquely identify services; hence you must choose a namespace that hasn’t been picked by anybody else.

It’ll take a few moments, but after your service namespace activates, you’ll be able to click the “Access Control” link to start configuring the ACS for your Web site.

Now you’ve made it to the management portal, where you can configure the ACS for your Web sites (see Figure 3).

Figure 3 The Windows Azure AppFabric Access Control Service Management Portal

Click the “Manage” button to get started. The management portal provides some guided steps to walk you through the process of getting started, and that’s just what we’re going to do.

Choosing the Identity Providers You Want

Click the “Identity Providers” link. Here we want to configure the various social IPs we want to leverage from within your application. Windows Live ID is present in the list by default; let’s add support for Google accounts.

Click the “Add Identity Provider” link, which will show a list of providers. Click the “Add” button next to Google. You can specify a custom image URL for the IP, but go ahead and just click “Save.” Just like that, we’ve added Google as a recognized source of user identities.

Getting the ACS to Recognize Your Web Site

Now that our IPs have been configured, we need to provide information to the ACS about our Web site. In identity jargon, we often refer to applications as “Relying Parties,” an expression that refers to the fact that the application relies on one or more IPs to take care of authentication on their behalf. The ACS UI is consistent with this terminology.

Click the “Relying Party Applications” URL, and then “Add Relying Party Application.” Let’s specify the following information:

Name: My Website
Realm: https://localhost/Website/
Return URL: https://localhost/Website/
Token format: SAML 2.0
Token signing: Use service namespace certificate (typical)

The Token Format field deserves at least a short explanation (we’ll spend more time on the topic later in the article). A token is an artifact—typically an XML fragment or something in another serialization format—used by IPs to indicate that a successful authentication operation took place. Once a user authenticates, using whatever system the IP chooses, the user’s browser will be redirected to the ACS carrying a token that certifies the user has been recognized. The token format and protocol used will be determined according to the IP. The ACS will examine the token and, if it finds it satisfactory (more about this later), will emit a new token of its own and send it back to your application. The settings you change in this step determine which token format you wish the ACS to use for communicating back to your application. The ACS is capable of emitting three types of tokens—SAML2.0, SAML1.1 and SWT—representing different trade-offs between expressive power, security, applicability for certain client types and so on. Just pick SAML2.0 here; the details aren’t imperative at this point.

It’s important that the realm corresponds to the URL for the Web site we created earlier. Once the authentication with the IP of choice takes place, the ACS will redirect the user back to your Web site using the URL you specify here. Note that, by default, “Create New Rule Group” is selected—we’ll leverage this in the next step. Click “Save” once you’re done and return to the management portal.

Adding Rules

Rules are interesting constructs that give you fine-grained control over user identity information. The scenario we’re enabling right now, however, doesn’t require the explicit use of rules in order to enable sign-on from multiple IPs. Therefore, we’ll postpone all explanations about what rules are to a later section in the article, where they’ll actually come in handy; here we’ll just go with the default settings.

Click the “Rule Groups” link. You should see the rule group created when we added the relying party application (“Default Rule Group for My Website”). Select this rule group, click the “Generate Rules” link, confirm that both Google and Windows Live ID are selected, and then click the “Generate” button—that’s all you need to do in regard to rules in this scenario.

Collecting the WS-Federation Metadata Address

At this point, we’re finished configuring the ACS. However, before we jump back to Visual Studio, let’s grab some information from the Application Integration page. Click the “Application Integration” link and copy the “WS-Federation Metadata” URL—we’re going to use this with WIF to set up our Web site to leverage.

Without going into too much detail, the WS-Federation Metadata document is a machine-readable description of how the ACS handles authentication. Your application will need it in order to be configured to outsource authentication to the ACS.

Configuring the Web Site to Use the ACS

Return to Visual Studio and your Web site. We now want to  leverage WIF to outsource authentication to the ACS, which will in turn enable Google accounts to access our application. In the Solution Explorer, right-click the Web site project and select “Add STS Reference.” This will launch the Federation Utility wizard, which will configure the Web site to use WIF as the authentication mechanism and the ACS as the authenticating authority. STS stands for “Security Token Service,” which indicates a special kind of Web service or Web page that offers an entry point for requesting tokens; usually every IP or token issuer uses one.

You can just click “next” most of the time; the steps in which you’ll have to enter information are precious few. Advance to the “Security Token Service” step, and specify “Use an existing STS.” Paste the federation metadata URL you copied from the ACS portal (see Figure 4).

Figure 4 Starting the Federation Utility Wizard in Visual Studio

From there, leave the defaults, click through to the end and select Finish. The wizard will add all the required WIF assemblies, add some files to your Web site and (most importantly) update your web.config with the information required to engage with the ACS at authentication time.

Testing the Authentication Flow

It’s finally time to give your newly secured Web site a spin! Hit F5. You’ll immediately be redirected to the Home Realm Discovery page, which offers the user the chance to pick among the IPs we configured earlier in the ACS management portal (see Figure 5).

Figure 5 The Home Realm Discovery Page

After you select Google and enter your Google account credentials, you’ll see an approval page that requires you to allow the ACS project access—this is important to understand, as it’s not your Web site that’s requesting permission, but instead the ACS (see Figure 6).

Figure 6 The Windows Azure AppFabric Access Control Service Asking for Permission to Get Information from Google

Once you’ve allowed the ACS the access it requires, you’ll get redirected back to the Web site (see Figure 7). That’s it—you’re logged in!

Figure 7 Success! Logging in to the Web Site

If you want to verify that the same experience would work with Windows Live ID, the other IP configured in your namespace, all you need to do is close the browser, hit F5 again and at the Home Realm Discovery page pick Windows Live ID instead of Google.

If you have any experience in enabling authentication protocols on Web sites, you know that, traditionally, adding an IP means studying its protocols and API, writing fairly challenging code and testing, testing, testing before getting it right. And every additional IP requires the same, plus the extra complication of understanding from the request which protocol is being used.

Here, we didn’t need to do any of that; in fact, you may have noticed that we didn’t write a single line of code. If we want to add extra identity providers, all we’ll need to do is go through a couple of screens on the ACS management portal, with no impact whatsoever on the application itself. If the IPs evolve their protocols, the ACS will change its code to accommodate the new conditions, and our application won’t even know anything changed at all.

The ACS: Structure and Features

Now that you’ve had a chance to experience firsthand the power of the ACS, you’re ready for a brief overview of what the ACS really is and what makes it tick. This will require a bit of theory, but you’ll discover that you already learned most of what you need to know while walking through the scenario described earlier.

The ACS operates according to the principles of claims-based identity. The main idea behind claims-based identity is that every entity in an identity transaction plays one or more canonical roles, taken from a short list of four: subject, identity provider (IP), relying party (RP) and federation provider (FP). In the walkthrough, you’ve seen all those in action. The interaction among those entities boils down to requesting, obtaining and forwarding security tokens, as shown in Figure 8.

Figure 8 Requesting, Obtaining and Forwarding Security Tokens

The subject is the role played by the user—that is, the entity that needs to be authenticated. The IP is the entity that stores the account for the subject: username, credentials, attributes and so on. The IP uses one or more STSes for exposing its authentication capabilities and for issuing tokens. The RP is the application that the subject wants to use. Those three roles are enough for describing the most basic case: the subject obtains a token from an IP that the RP trusts, uses that token with the RP and the authentication is done.

One thing we didn’t cover during the walkthrough is that the tokens aren’t just representing the successful outcome of the authentication operation, but they’re also used to transport attributes describing the user: name, e-mail address roles and anything else that the RP needs to know and that the IP makes available. If you recall the properties of signed security tokens, you’ll see how those attributes can’t be tampered with and are cryptographically guaranteed to come from a specific IP. That means that one RP can choose to consider valid the attributes it receives according to how much it trusts the IP that originated them. Think of real-life situations in which you need to prove something—for example, that you actually live at a certain address. Companies often ask you to provide a utility bill, mainly because they trust the utility company more than they trust you. The information is the same (the address), but the IP that produced it makes all the difference.

When an attribute is issued as part of a security token, we call that attribute a claim. This concept is so important that it gives the name to the entire approach, and practically everything the ACS does revolves around claims. We just need to get another concept out of the way and then we’ll go in the details.

Although you could use the subject-RP-IP roles for modeling every system, in practice it’s not very handy. If one RP trusts multiple IPs, as was the case in our scenario, the model would require the RP to maintain multiple relationships, handle different protocols and so on. This is where the fourth role, the FP, comes into play. An FP is an intermediary between one or more RPs and one or more IPs, as shown in Figure 9.

Figure 9 The Federation Provider as an Intermediary

The FP trusts multiple IPs, behaving like an application and expecting tokens from the IPs. In turn, the RP trusts the FP; to that purpose the FP exposes its own STS, which issues tokens for the RP. The FP takes care of the details of engaging with the various IPs, while always presenting to the RP the same façade, so IPs can be on-boarded and de-provisioned without affecting the RP. The FP can also transform the claims coming from different IPs to make them more useful for the RP. It can normalize different incoming claim types, add extra claims such as roles or permissions, and so on.

As you may have guessed by now, the ACS plays the role of the FP, as illustrated in Figure 10.

Figure 10 The Windows Azure AppFabric Access Control Service Playing the Role of Federation Provider

When you create a service namespace, you get your very own full-featured FP in the cloud. Out of the box, that FP includes four different STS endpoints, all offering different protocols that are suitable for different application types: WS-Federation for signing in to Web sites; WS-Trust for invoking SOAP Web services; OAuth WRAP and OAuth 2 for REST Web services; and Web APIs in general. Those are the endpoints you use to configure your application to outsource authentication.

The ACS is already pre-configured to trust various Web IPs, as we’ve seen, and it facilitates the experience of choosing among them by providing pages or embeddable code for them. In addition to that, the ACS is able to establish trust with commercial IPs such as Active Directory Federation Services 2.0 (AD FS 2.0), which expose STS endpoints themselves. In practice, the ACS exposes the counterpart of the “Add STS reference” functionality you’ve seen when configuring your Web site to trust the ACS. Using AD FS 2.0 as an IP is extremely interesting, as it allows you to reuse user accounts whenever you want, including those in Windows Azure-hosted applications that would traditionally be valid only on-premises. Another interesting feature of business IPs is that they usually provide much richer claims sets that can be used for adding sophisticated identity-driven logic in the token processing.

The ACS allows you to describe your claims transformation login in the form of rules, a simple but powerful mechanism. For example, you can assign a role to a user as simply as entering something along the lines of “if the incoming name identifier claim has value X, please add an output claim of type role and value Y.”

All of the functionality discussed here can be accessed through the management portal you used in the walkthrough; alternatively, there’s an OData-based management service that gives you full control on the ACS settings while integrating with your existing processes.

As trite as it may sound, we did barely scratch the surface of what the ACS can do for you. We invite you to check out the hands-on lab in the identity developer training kit and the Windows Azure platform training kit for exploring more scenarios in greater detail. If you want to simplify access management for your Web site, Web service or Web API, the ACS can help!

Content Taken from : http://msdn.microsoft.com/en-us/magazine/gg490345.aspx

Author : Vittorio Bertocci and Wade Wegner

Pushing Content from SharePoint to Windows Azure Storage

2010-12-06T22:48:00.000+05:30

Hi Friends,

Want to push Sharepoint Content onto Windows Azure Storage?

Check the link below for more details

http://msdn.microsoft.com/en-us/magazine/gg490343.aspx

New Full IIS Capabilities: Differences from Hosted Web Core (HWC)

2010-12-05T23:12:00.001+05:30

The new Windows Azure SDK 1.3 supports Full IIS, allowing your web roles to access the full range of web server features available in an on-premise IIS installation. However if you choose to deploy your applications to Full IIS, there are a few subtle differences in behaviour from the Hosted Web Core model which you will need to understand.

What is Full IIS?

Windows Azure's Web Role has always allowed you to deploy web sites and services. However many people may not have realised that the Web Role did not actually run the full Internet Information Services (IIS). Instead, it used a component called Hosted Web Core (HWC), which as its name suggests is the core engine for serving up web pages that can be hosted in a different process. For most simple scenarios it doesn't really matter if you're running in HWC or IIS. However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.

One of the many announcements we made at PDC 2010 is that Windows Azure Web Roles will support Full IIS. This functionality is now publicly available and included in Windows Azure SDK v1.3. To tell the Windows Azure SDK that you want to run under Full IIS rather than HWC, all you need to do is add a valid section to your ServiceDefinition.csdef file. Visual Studio creates this section by default when you create a new Cloud Service Project, so you don't even need to think about it!

A simple section defining a single website looks like this:

You can easily customise this section to define multiple web sites, virtual applications or virtual directories, as shown in this example:

After working with early adopter customers with Full IIS for the last couple of months, I've found that it's now easier than ever to port existing web applications to Windows Azure. However I've also found a few areas where you'll need to do things a bit differently to you did with HWC due to the different hosting model.

New Hosting Model

There is a significant difference in how your code is hosted in Windows Azure depending on whether you use HWC or Full IIS. Under HWC, both the RoleEntryPoint methods (e.g. the OnStart method of your WebRole class which derives from RoleEntryPoint) and the web site itself run under the WaWebHost.exe process. However with full IIS, the RoleEntryPoint runs under WaIISHost.exe, while the web site runs under a normal IIS w3wp.exe process. This can be somewhat unexpected, as all of your code belongs to the same Visual Studio project and compiles into the same DLL. The following diagram shows how a web project compiled into a binary called WebRole1.dll is hosted in Windows Azure under HWC and IIS.

This difference can have some unexpected implications, as described in the following sections.

Reading config files from RoleEntryPoint and your web site

Even though the preferred way of storing configuration in Windows Azure applications is in the ServiceConfiguration.cscfg file, there are still many cases when you may want to use a normal .NET config file - especially when configuring .NET system components or reusable frameworks. In particular whenever you use Windows Azure diagnostics you need to configure the DiagnosticMonitorTraceListener in a .NET config file.

When you create your web role project, Visual Studio creates a web.config file for your .NET configuration. While your web application can access this information, your RoleEntryPoint code cannot-because it's not running as a part of your web site. As mentioned earlier, it runs under a process called WaIISHost.exe, so it expects its configuration to be in a file called WaIISHost.exe.config. Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily. This is one of the only cases I can think of where you'll have two .NET configuration files in the same project!

Accessing Static Members from RoleEntryPoint and your web site

Another implication of this change is that any AppDomain-scoped data such as static variables will no longer be shared between your RoleEntryPoint and your web application. This could impact your application in a number of ways, but there is one scenario which is likely to come up a lot if you're migrating existing Windows Azure applications to use Full IIS. If you've used the CloudStorageAccount class before you've probably used code like this to initialise an instance from a stored connection string:

var storageAccount = CloudStorageAccount.FromConfigurationSetting("ConnectionString");

Before this code will work, you need to tell the CloudStorageAccount where it should get its configuration from. Rather than just defaulting to a specific configuration file, the CloudStorageAccount requires you set a delegate that can get the configuration from anywhere you want. So to get the connection string from ServiceConfiguration.cscfg you could use this code:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

{

    configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

});

If you're using HWC with previous versions of the SDK (or if you deleted the configuration setting with SDK 1.3), you can happily put this code in WebRole.OnStart. However as soon as you move to Full IIS, the call to CloudStorageAccount.FromConfigurationSetting will fail with an InvalidOperationException:

SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used

"But I did call it!" you'll scream at your computer (well at least that's what I did). And indeed you did-however you called it in an AppDomain in the WaIISHost.exe process, which has no effect of your web site hosted in an entirely different AppDomain under IIS. The solution is to make sure you call CloudStorageAccount.SetConfigurationSettingPublisher and CloudStorageAccount.FromConfigurationSetting within the same AppDomain, most likely from your web site. While there used to be some issues with accessing Windows Azure SDK classes in your Application_Start event, these no longer apply and this is a great place to initialise your configuration setting publisher.

Or alternatively, as long as you're happy to use the ServiceConfiguration.cscfg file for your connection strings, you can avoid setting up this delegate altogether by replacing the call to

CloudStorageAccount.FromConfigurationSetting(...) with this:

var storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("ConnectionString"));

Securing resources for different web sites and applications

One final thing to note is that if you configure your Web Role to run multiple sites or virtual applications, each will run in its own Application Pool and under its own user account. This provides you with a lot of flexibility-for example you could grant different virtual applications with access to different resources such as file system paths or certificates. If you want to take advantage of this you can leverage another new SDK 1.3 feature and specify a startup task to run under elevated privileges. This task could launch a PowerShell script that sets access control lists which allows each of your applications to access the resources it needs.

Conclusion

The option to use Full IIS with Windows Azure Web Roles gives you access to a lot of new functionality that makes it easier to migrate existing IIS-based applications and also gives you more options when developing new applications. With a better understanding of the underlying hosting and security model, I hope you're able to use these new features with fewer development headaches.

Reference: https://blogs.msdn.com/b/windowsazure/archive/2010/12/02/new-full-iis-capabilities-differences-from-hosted-web-core.aspx

App Fabric ACS -- Explained clearly.

2010-12-02T00:22:00.001+05:30

AppFab:ACS

I’m going to assume you understand a little of the basics of federation for this part of the post. If you don’t - read my federation primer to get yourself up to speed.

When you place an instance in Azure and you “protect” it using AppFab:ACS, you are typically crossing an organisational boundary. There are reasons you might not be doing that – which we’ll come to in a moment. For now, let’s assume you are say, a SaaS service provider. You have written the most fantastic expense submission application and everybody wants to use it.

You don’t want to go to the trouble of having to manage the users. You want to provide the service. So you set up federation trusts with those companies that want to use your service. They create the users, set their passwords, determine if the accounts are enabled or disabled. They delete the accounts when they are no longer relevant, they set password complexity policy, expiration policy and so on. If a user forgets their password they go to their own company’s helpdesk to get it reset, not yours.

They do this by configuring a service that sits on top of their Active Directory called Active Directory Federation Services 2.0 (ADFS 2.0). You in your turn configure the Windows Azure Application Fabric’s Access Control Service (AppFab:ACS) with details of your application and vice versa, you configure your application with details of your partition of AppFab:ACS.

You then set up a federation trust with any company that wants to access your application. This involves the exchange of URLs and certificates between their ADFS2 server and your partition of AppFab:ACS. There are metadata endpoints to simplify this process. Of course, you could set this up between your own company’s ADFS2 server and your own instance of AppFab:ACS, as shown below:

Now, when a user from your application wants to use the application you have deployed to the cloud, it will be as if the application lives inside your AD. It doesn’t, but the experience they would have is like this:

It’s 09:00, Fred comes in to the office, hits CTRL-ALT-DEL and enters his AD credentials to log in to the domain.
It’s 10:00 and he now needs to enter his expenses. He clicks a desktop icon which is a URL shortcut to the application in the cloud.
The application opens, says “Welcome back Fred” and he uses the application to submit his expenses.

He was never prompted for credentials because of the way the dance works with federation/ADFS2 and Active Directory. The dance is explained in my federation primer, but what essentially happens is this:

Fred clicks the icon and his browser takes him to the application
The application redirects his browser to your partition of AppFab:ACS
AppFab:ACS sees that Fred has come from its federation partner and redirects Fred's browser to his own ADFS2 server.
On trying to reach the ADFS2 server, an authentication takes place. It’s all built-in to Windows and done through Kerberos. It’s entirely invisible to Fred as a user, the same as when he goes to a domain-joined IIS machine using Windows authentication. The authentication just works under the covers.
On successful authentication, the ADFS2 server pushes Fred back to AppFab:ACS and appends a SAML token which it encrypts and digitally signs. If you need to understand encryption and signatures, read my crypto primer.
AppFab:ACS receives the token, decrypts it and checks the digital signature. It is now assured the token has been issued by its federation partner.
AppFab:ACS creates a new token and copies the claims in the original token in to the new token. At this point it might also do something called claims transformation. If you need to understand this – again, read the federation primer.
It digitally signs and encrypts the token (optional) and redirects Fred’s browser back to the application it started appending the new SAML token.
The application decrypts the token and checks the signature. It verifies the token was definitely issued by your partition of AppFab:ACS and grants access to Fred. Fred never had to enter a password, other than the password he entered when he logged on to AD at 09:00 when he started work.

Taken from Link : http://blogs.msdn.com/b/plankytronixx/archive/2010/11/06/difference-between-an-azure-app-domain-joined-to-your-active-directory-and-an-azure-app-joined-to-your-active-directory-through-appfab-acs.aspx

Article written by: Planky

Why you SHOULD NOT deploy an AD domain controller using Azure Connect with VM Role

2010-12-02T00:05:00.000+05:30

I’ve heard a lot of talk recently about the forthcoming Windows Azure Connect service, combined with the soon-to-be-released-to-CTP of VM Role giving the possibility of hosting an Active Directory Domain Controller in the cloud. Although technically feasible, this post is designed to tell you why you shouldn’t do that.

The Web Role, Worker Role and VM Role all include local storage. Even a Windows Server at idle is actually doing quite a lot and making constant updates to the disks – and so it is with an instance deployed to the cloud as well. In Windows Azure, the state of a virtual machine (an instance) is not guaranteed if ever it restarts because of some sort of failure.

Web and Worker Roles do persist the OS state across re-starts generated by automated updates; ones initiated by the fabric. With the VM Role there is no automated update process. It’s down to the owner of the VM Role to keep it up-to-date. Yes – there is a process for this which involves a differencing disk that is added to the base VHD that you supply when you first startup a VM Role in Windows Azure. However, the problem really exists with failures.

A failure of a VM Role can be caused by any number of things. Power Supply failure to the rack, hard drive head-crash, failure of the hardware server the VM is hosted on plus a decent range of other hardware problems. The same for software. As they say “there’s no such thing as bug-free software”. Every so often the host OS or even the guest OS – the OS running in the VM you created, could happen across an unusual set of conditions while in kernel mode for which there is no handler.

Well, if there is no handler, it means nobody thought such a condition would ever occur. The default behaviour of the kernel is to assume something has gone wrong with the kernel itself: it’d be dangerous to continue with a kernel in an unknown state. Think of the damage that could be caused. And so control is handed to a special handler – the one that causes the blue-screen fatal bugcheck. The resulting dump file may be useful in debugging what caused the problem after the event, after the operating system was stopped in its tracks by the bugcheck code. But this could happen to either the host OS or your VM.

When it does happen, the heartbeat that is emitted to the fabric by a special Windows Azure Agent installed in every instance managed by the cloud will stop. Eventually the fabric will recognise a timeout has occurred. It’s first concern is to get a new responsive instance up and running. It is very likely it won’t be on a host even in the same rack, let alone exactly the same host. Therefore, no guarantee is ever given for these situations that state will be preserved.

The fabric will take the base VHD, plus the collection of differencing disks (the ones that contain your OS updates) and “boot” that back in to the configuration specified in your service model. This diagram explains the problem.

Use the numbered points in the diagram to follow along:

The base VHD plus the differencing VHD is used to create…
..a running instance of a Domain Controller as a Windows Azure VM Role
The downward pointing green arrow represents the life of this Domain Controller. Let’s assume the life between instantiating the VM and the catastrophic failure (at step 5) is 61 days (or longer).
As time advances, more and more changes are written to the Domain Controller. In the diagram I have shown this as being performed by a series of administrators. In reality though, it doesn’t matter how the changes get to the DC. Either directly or because of AD replication, say from an on-premise DC. The rules for hanging on to objects are the same. Deleted objects are tombstoned.
A catastrophic failure of some description occurs and the instance immediately goes offline.
The Windows Azure Fabric recognizes the absence of the heartbeat and builds a new instance from the base and differencing VHDs. These VHDs are used to create a new instance…
…and the result is that all the changes that have accrued in the intervening 61 days are now lost. If there is another online DC, say in an on-premise environment, it will refuse to speak to this “imposter”. The password will have changed twice in the intervening 60 days and the tombstone timeout will have occurred. You therefore cannot rely on replication to get this DC back in to the state it was before the failure.

Essentially, having the fabric fire-up a new DC based on an out-of-date image is a bit like the not-recommended practice of running DCPromo on a Virtual Machine and therefore getting a copy of the domain database on to the machine. Then taking it offline and storing the VHD as the “backup” of AD. Re-introducing that DC back in to the network after a time will cause it to be ignored in the same way for all the same reasons.

The risk with having applications that can use Windows Integrated Authentication in the cloud is that if the network between your on-premise Domain Controllers and the apps you have in the cloud goes down, the apps can’t be used.

It therefore appears to be the case that a VM Role deployed as a Domain Controller up in the cloud and using Windows Azure Connect to give full domain connectivity is a good idea. And indeed it is – until a failure occurs.

But remember, you can domain-join your Azure based apps to a local DC, and on that point, Windows Azure Connect is a great way to be able to quickly deploy AD-integrated apps to Azure without massive re-engineering effort. Because your local DC is part of your infrastructure it will be managed as such and won’t be subject to the service model that is the basis for anything running in Azure. If anything this scenario is a very practical demonstration of why it is that VM Role !== IaaS.

Of course if somebody could come up with a way for the DC to store its directory data in blob storage, which is persistent across instance reboots, then we’d have a neat solution. Maybe that’s an opportunity for a clever ISV partner to exploit. In the meantime – take the opposite sentiment to Nike’s strapline – “Just Don’t Do It”.

Windows Azure VM Role: Looking at it a different way

2010-12-01T23:28:00.001+05:30

The debate regarding PaaS vs. IaaS continues at pace. It seems as though no mention of this debate where Windows Azure is concerned, is complete without a frequently misunderstood notion of what the recently announced VM Role is. Many commentators are saying “It’s Microsoft’s IaaS offering”.

Let me put forward a way of explaining what it is:

With a PaaS service like Windows Azure, the developer creates an application package and hands that, plus a configuration, over to Microsoft and says “can you run this package in your Data Centre, according to this configuration”. Windows Azure goes ahead and runs the application. The fact that it spins up a VM to house the application, in theory, should not concern the developer. The existing Web and Worker Roles work in exactly this way.

When you hand over the package, it consist of all the files and resources needed to run the application. It’s rolled in to a file called a .cspkg file, a “cloud service package” file. The configuration or .cscfg accompanies the package. There is no guarantee of state for the application. If it fails for some reason, it must be capable of picking up where it left off and it’s down to the developer to work out how that is going to happen – perhaps by using persistent storage like blob or table storage.

The Windows Azure fabric has no knowledge of the internals of the application. Imagine a bug is identified – Windows Azure will not create and apply a patch to the application. We know that for the Web and Worker Roles, it will apply patches and fixes – ones that Microsoft has identified – to the operating system but not to the application itself.

The way to look at the VM Role is that the entire thing is a Windows Azure application. You don’t send a .cspkg file, but instead, the package is a .vhd file. Now, because these files are likely to be huge in comparison to a .cscfg, Windows Azure has created a method of updating with differencing disks, but that’s just an implementation detail. You can think of a VM Role application package as the .vhd file.

As is the case with the .cspkg, Windows Azure has no visibility to the internals of the application. Just as with a .cspkg application, it is the developer’s responsibility to keep it up to date, apply bug fixes, patches, updates etc. Only with an entire .vhd, the “application” updates are the patches, fixes and service packs of the OS itself plus any updates to the developer-built part of the “app”.

The application is still subject to the service model, it’s just the application package file-type that is diferent (.vhd) and the scope of the application is different (it includes the entire OS). Other than those differences, it’s a PaaS application that runs on Windows Azure, subject to the service model and all the other benefits and constraints, just like the Web and Worker Roles.

I hope this viewpoint helps describe VM Role as a PaaS offering and not the confusing IaaS that many folks think it mimics.

Article posted at http://blogs.msdn.com/b/plankytronixx/archive/2010/11/27/windows-azure-vm-role-looking-at-it-a-different-way.aspx

Article written by: Planky