the midnight rambler

About a week ago PACKT published “Microsoft Windows Azure Development Cookbook” by Neil Mackenzie. I got it from Amazon on Thursday and have been reading it these last couple of days. I’ll share my thoughts below.

Cookbooks are rarely meant to be read cover-to-cover, so doing just that has been quite a dry read. Had this been a regular, educational book on Windows Azure I would say that it is missing a bit of spice; some war stories, some personal opinions or a pinch of humour would have done wonders for the reading experience. Thus, this isn’t the type of book you bring with you on vacation or read while commuting. It is meant to sit on a shelf next to your work station and to be consulted when you encounter a specific problem.

The book contains 80 or so recipes for solving various concrete tasks related to Windows Azure development. They are grouped into chapters on blobs, tables, queues, hosted services, diagnostics, the management API, SQL Azure and AppFabric. Within each chapter recipes are roughly sorted in order of increasing level of complexity and each recipe follows the same pattern:

• An introduction to the problem / scenario
• A list of prerequisites for the sample solution
• Step-by-step instructions on building the sample solution
• A summary of how the sample solution works

This feels like a sound approach and it works quite well.

In the preface of the book it says “If you are an experienced Windows Azure developer or architect who wants to understand advanced development techniques when building highly scalable services using the Windows Azure platform, then this book is for you.” However, if you are just starting starting out with Windows Azure, you shouldn’t let this put you off. There are quite a number of recipes in the book which will be of value to newcomers to the platform, and if you are just starting your first Azure project, you will find many recipes that are immediately applicable and very valuable.

I think this may be the book’s strongest point as well as its Achilles’ heel: If you have taken an introductory course to Windows Azure and been through the Windows Azure Platform Training Kit, you will, at least in theory, know much of the material in this book. That being said, for some recipes Mackenzie adds a “There’s more…” section which puts the material just covered into perspective or relates it to other parts of the Windows Azure Platform. This is my favourite section and is where even seasoned Windows Azure developers may find some valuable nuggets.

All-in-all I would highly recommend this book if you have had a general introduction to Windows Azure and is getting ready to get your hands dirty.

On the other hand, if you are an experienced Azure developer it won’t take you to the next level.

I will be giving a talk on .NET and Windows Azure at Miracle Open World 2011 in Billund on 15th of April.

I recently read a story that made me contemplate the relationship between website developers and the visitors to these sites. I’ll share my most obvious conclusion here.

The social implicit contract

When building a website that you expect people to use, you are implicitly entering into a mutual agreement with that website’s users: You expect the users to use your site, and they in turn expect you to take them seriously. In particular, they expect you to store their personal information reliably and inaccessible to others. This holds true even if your website doesn’t actually contain any confidential information per se. As soon as you have users, you have logins and passwords that need to be protected.

But if my site doesn’t contain confidential information, it matters little if a user’s account is compromised

you may say. However, that is just plain wrong. Users will most likely use the same username and password in multiple places. Thus, if a user’s password is compromised because of a flaw in your software, who knows what other systems you may inadvertently have compromised.

But best practices recommend that users never reuse a password. If they do, it is their own fault and they alone must face the consequences.

Not so fast, sailor. The fact of the matter is that the average person has a multitude of online accounts with various services and that it is utterly impossible for him/her to keep track of a similar number of unique passwords (let alone of which passwords goes with what service). To this day no one has really solved this problem.

Thus, you should expect people to reuse passwords and protect these passwords accordingly. Having a laissez-faire attitude to users’ passwords means you’re not doing your job properly. Period.

I’ll say it again:

You, yes you, need to store passwords securely

A compromised password in one system, no matter how insignificant, may have dire consequences for other and much more critical systems. Since Internet users invariably reuse passwords, web developers collectively need to protect these.

I realize that being a security specialist is a full-time job and that most developers don’t have the time to become experts in this area. However, I think every web developer who is worth his salt should at the very minimum

• understand the most basic attack vectors like SQL injection attacks and cross-site scripting attacks and how to mitigate these
• know how to properly store a password (or, better yet, avoid building a password system but use someone else’s)

I’ll end this post with the illustrative tale that inspired me to write it.

The HBGary attack

There was once a security firm called HBGary (at the time of writing there still is). This was a reputable company providing training and malware protection software to Fortune 500 companies and high profile organizations.

In its quest to rid the world of Internet scumbags, it one day happened upon a group of anonymous scoundrels and threatened to expose them. HBGary barely lived to regret it.

The scoundrels exploited a basic SQL injection chink in HBGary’s armor and leveraged this weakness to open a floodgate for attacks on the organization: HBGary’s emails were publicized, their data, including backups, were destroyed, and their website and twitter profiles were defaced.

For the unabridged story, read the inside version.

What do you think? Which implicit responsibilities do we as web developers take upon us when we deliver a product?

Well, the headline may be a bit presumptuous, but at least they are trying.

I was pretty impressed when I saw the extent of the Cloud Power advertisement campaign in major Danish newspapers a few weeks back. However, if you live in Denmark, you may not realize just how much marketing muscle Microsoft is putting into this campaign.

I recently travelled to the United Kingdom and found that Cloud Power is everywhere: In the subway, on train stations and in the airport. I took these pictures with a slightly shaking HTC Desire (I was probably shaking from an overdose of bangers and mash).

It will be exiting to see where this will take Microsoft on the Cloud scene. I’ve never seen any of the other players in this space do advertisement like that.

I will be teaching a 3-day training session on the Windows Azure Platform starting on the 8th of February. Last time I facilitated a similar event was back in December 2010, when 30 Microsoft partners showed up. It was great fun, so I am very much looking forward to repeating the exercise.

This particular event is by invitation only, but if you are interested in a similar training course or just an introductory session on Cloud Computing in general and Windows Azure in particular, please contact my company, Copenhagen Software.

As part of the launch of Windows Azure SDK 1.3 Microsoft has provided us with the possibility of connecting to our Windows Azure VMs using Remote Desktop.

Using Windows Azure Tools for Visual Studio 2010 it is straight forward to configure your application to allow remote desktop access to the VMs:

• Right-click the service in VS2010 and choose “Publish”
• Click the link “Configure Remote Desktop Connections…”
• Check “Enable connections for all roles” and choose or create a certificate to encrypt the password
• Enter username, password and the user’s expiry date and click “OK”.
• Perform the rest of the deployment as usual (make sure to upload the certificate, if you chose to create a new one)

If all you want is remote desktop access to your Azure instances this will do. If you want to understand what is going on and how to manually configure your application for remote desktop access then read on.

Manually configuring the application for remote desktop access is a two-part process:

• The application must be configured to allow RDP connections on port 3389
• You need to create an encrypted password and enable the Fabric Controller to access the certificate used for the encryption.

Configuring the application

In order for the Windows Azure load balancer to allow inbound RDP-connections, you have to enable this in your service definition. Open the ServiceDefinition.csdef file and locate the WebRole-/WorkerRole sections describing the roles for which you want to allow remote desktop access. Import the module “RemoteAccess” in each section:

<Import moduleName="RemoteAccess" />

Because of this import the Fabric Controller will set up internal TCP endpoints on port 3389 for each role.

In addition to these internal endpoints, exactly one role needs to define an input endpoint to which the load balancer can route inbound RDP connections. When you access an instance via RDP, this role will forward the connection to the instance to which you intend to connect.

Thus, you have to add the following to exactly one of the sections in ServiceDefinition.csdef:

<Import moduleName="RemoteForwarder"/>

Assuming that we started out with a service containing one web role and one worker role, our service definition now looks like this:

<?xml version="1.0" encoding="utf-8"?>

<ServiceDefinition name="RDService" xmlns="http://schemas.microsoft.com/

ServiceHosting/2008/10/ServiceDefinition">

  <WebRole name="WebRole1">

    <Sites>

      <Site name="Web">

        <Bindings>

          <Binding name="Endpoint1" endpointName="Endpoint1" />

        </Bindings>

      </Site>

    </Sites>

  <Endpoints>

      <InputEndpoint name="Endpoint1" protocol="http" port="80" />

    </Endpoints>

    <Imports>

      <Import moduleName="RemoteAccess"/>

      <Import moduleName="Diagnostics" />

    </Imports>

  </WebRole>

  <WorkerRole name="WorkerRole1">

    <Imports>

      <Import moduleName="RemoteAccess"/>

      <Import moduleName="RemoteForwarder"/>

      <Import moduleName="Diagnostics" />

    </Imports>

  </WorkerRole>

</ServiceDefinition>

If you have used VS2010 to edit ServiceDefinition.csdef you will see that a number of settings have been added to each role in the service configuration file, ServiceConfiguration.cscfg (if you haven’t used VS2010 you will have to add them yourself):

<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="" /><Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="" /><Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="" /><Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="" />

Moreover, for the role acting as Remote Forwarder VS2010 has added:

<Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="" />

and, finally, a new element has been added to the Certificates section:

<Certificates>   <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption"     thumbprint="" thumbprintAlgorithm="sha1" /></Certificates>

The first four settings are obviously there to allow the Fabric Controller’en to configure each VM when the application is deployed. At this point, we can fill in all these fields with the exception of the AccountEncryptedPassword field. In my case, I enter “true”, “rune” and “2010-11-06 00:00:00Z” (see ‘Setting Up A Remote Desktop Connection For A Role’ for information on the date/time format). Moreover, for WorkerRole1  I put “true” for the “Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled” field.

Specifying the password

We need to choose a password for our remote desktop user, and for security reasons it needs to be encrypted before we enter it into ServiceConfiguration.cscfg. Thus, we need to perform the following tasks:

• Create a X509 certificate
• Encrypt a password using this the certificate 
• Put the encrypted password in ServiceConfiguration.cscfg
• Provide the certificate to the Fabric Controller
• Specify the certificate’s unique name (thumbprint) in ServiceConfiguration.cscsf

To create a X509 certificate run a Visual Studio Command Prompt  as administrator and execute the following command:

makecert –sky exchange -r -n "CN=AzureRD" -pe -a sha1 -len 2048 -ss My "AzureRD.cer"

(you can run makecert –! to see a descriptions of the flags used and read general guidelines for creating a certificate here).

This will create a certificate and store it in the file AzureRD.cer as well as install it into the local certificate store. You can verify this using PowerShell:

PS C:\Users\Rune Ibsen> cd cert:\CurrentUser\My

PS cert:\CurrentUser\My> dir

    Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Notice that this listing contains the certificates’ thumbprints. You will need your certificate’s thumbprint shortly.

Next, we need to actually use the certificate to encrypt the password. Fire up PowerShell and run the following commands:

[Reflection.Assembly]::LoadWithPartialName("System.Security")
$pass = [Text.Encoding]::UTF8.GetBytes("yourpassword")
$content = new-object Security.Cryptography.Pkcs.ContentInfo –argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:\CurrentUser\My\55825F4612F9EDCAB073DE98AA5419FA710A2973)))
[Convert]::ToBase64String($env.Encode())

The encoded string resulting from the last command is what you need to put in the fields AccountEncryptedPassword in ServiceConfiguration.cscfg. Moreover, put the certificate’s thumbprint as the value for the thumbprint attribute in ServiceConfiguration.cscfg.

In order for the Fabric Controller to configure the virtual machines with the chosen password, the Fabric Controller needs to have access to the certificate that was used to encrypt the password. In particular, you will have to provide a personal information exchange (PFX) certificate.

To create a PFX certificate go to a command prompt on your local machine and run

certmgr.msc

This will bring up the certificate manager. Locate the newly created certificate, right-click it and choose “All Tasks –> Export…”. Follow the wizard, indicating along the way that you want to export the private key. Once complete, this process will create a .pfx file.

Now go to the Windows Azure portal and create a new hosted service. Then select the Certificates-folder and click the Add Certificate in the upper left corner. Upload the .pfx file you just created.

Next, deploy the application to the hosted service just created and, once deployment is complete, connect to a VM using RDP. Presto! You see the familiar Windows 2008 desktop!

I think it is worth noticing that you can enable and disable remote desktop access on a per role basis at runtime, that is, without having to do a redeploy.

Also notice that if you enumerate the instance endpoints for your roles, you will see that they now have an instance endpoint named “Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp”. I did this by connecting to an instance via RDP and enumerating the endpoints using Powershell:

If you inspect the endpoints closer, you will see that they are listening on port 3389.

References

• Setting Up A Remote Desktop Connection For A Role
• How To Create A Certificate For A Role
• How To Encrypt A Password
• Cloud Cover Episode 33

I will be teaching a 3-day training session on the Windows Azure Platform starting on the 30th of November.

The content will be a bespoke mix of Windows Azure subjects and alternate between presentations and hands-on labs, providing the participants ample opportunity to get their hands dirty in Microsoft’s training center.

This particular event is by invitation only, but if you are interested in a similar training course or just an introductory session on Cloud Computing in general and Windows Azure in particular, please contact my company, Copenhagen Software.

If you’re an ISV and you’re contemplating whether you should migrate your product to Windows Azure, you may be asking yourself if you can have your cake and eat it too, that is, have the exact same code base deployed with customers running on-premise as well as with customers running in the cloud. In this blog post I will offer some technical guidance on this issue.

These are my assumptions:

1. You want to offer your software as Software as a Service, that is, as a hosted service running on Windows Azure
2. Each customer will want to have a dedicated virtual machine for running the application (that is, I am not going to go into multi-tenancy here)

I am not making any assumptions on whether your application can currently be scaled horizontally. If it can’t, moving it to Azure will not change this. The Azure load balancers use a round-robin algorithm and have no support for sticky sessions of out the box, so making the application scale will most likely be a non-trivial exercise.

Isolating dependencies

The key to having an application be able to run both on-premise and in Windows Azure is to isolate the application’s dependencies on the hosting environment, hide these dependencies behind suitable abstractions and then provide implementations of these abstractions tailored at each hosting environment.

So, the first step in taking your application to the cloud should be to identify the dependencies for which we will need to provide abstractions. Obviously, we only need to consider the parts of the application’s environment which differ between Windows Azure and an on-premise environment. Typical examples include:

• Database (SQL Server vs. SQL Azure)
• Shared file systems

Thus, you need to re-architect your application from something that looks like this:

to something that looks more like this:

If you are in luck, you already have an abstraction which somewhat isolates the rest of your application from the particular database implementation. This would be the case if you are using an ORM like Entity Framework, Nhibernate or something similar. Isolating other dependencies may require more work.

Taking it to the cloud

At this point, you have an application with a nice encapsulation of external dependencies. Even though the application is only able to run on-premise at this point, the architecture has already been improved.  The next step is obviously to provide implementations of your abstractions suitable for running in the cloud. This is the fun part: If you have identified the right abstractions, you can go nuts in cloud technology, using massively scalable storage, asynchronous communication mechanisms, CDNs etc. This process should give you an application capable of running on Windows Azure:

Configuring dependencies

The code base now contains everything we need for an on-premise installation as well as for a cloud deployment. However, to truly decouple the application from its dependencies, the set of dependency encapsulations to use in a given installation should be easily configurable. To this end, use your favorite dependency injection tool. Unless you decide to roll your own tool, the tool you choose will most likely support multiple methods of configuration and you can choose whatever method you prefer.

If you want to get really fancy, you may even choose to have the application configure its dependencies on its own on startup. The application can use the Windows Azure API to tell it whether it is running on Windows Azure. The information is available through the Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment class, which has a static property called IsAvailable:

I usually hide the environment information provider behind a static gateway pattern.

This was a quick run down of one path towards the cloud. Obviously, there is much more to be said, especially with respect to the ‘taking it to the cloud’-step. I’ll save that for another day.

I am spending a few days participating in the “Bringing Composite C1 to Windows Azure” workshop this week.

I didn’t know Composite C1 beforehand, but so far it has been a pleasure to get to know it.

The only major hiccup we encountered on the first day was that the Composite C1 application is not a Web Application Project in the Visual Studio sense, but is instead a Web Site.

Windows Azure web roles are per default Web Application Projects, so we set out to convert Composite C1 to a Web Application Project while discussing if it is possible to deploy a Web Site to Windows Azure.

Since Windows Azure is just Windows 2008 with IIS 7.0 I figured it should be possible to run a Web Site on Windows Azure, but whether we could get the management services to deploy the Web Site in the first place was another matter.

Coincidentally, Steve Marx recently wrote a blog post on manually packaging up an application for deployment to Windows Azure, so in this blog post I will attempt to deploy a Web Site to Windows Azure using a manual packaging approach. I will be using a generic web site instead of Composite C1 since using Composite C1 would probably cause some unrelated problems to surface.

So, I start out by creating a new Web Site:

Next, I need to create a service definition which will tell Windows Azure what my web site looks like. As for now, I will be define a service with a single webrole. So, I create a new file called ServiceDefinition.csdef:

and I fill in some basic parameters:

Now, I could go ahead and package up the application and deploy it. However, if I do this, the web role will be extremely sick and throw exceptions saying “Unrecognized attribute ‘targetFramework’”, referring to the targetFramework=”4.0” attribute in web.config.

Figuring out why this happens and what to do about it will require some further investigation. For now I just go ahead and delete the attribute. This also means that I need to delete the “using System.Linq;” statements in Site.Master, Default.aspx.cs and About.aspx.cs.

To package the application I need to use the cspack.exe that comes with the Windows Azure SDK. I’ve added the SDK’s bin directory to my PATH, so I can go ahead and package the application:

This is a pretty long command, so I’ll repeat it here for convenience:

cspack ServiceDefinition.csdef /role:MyWebRole;WebSite1
/copyOnly
/out:MyWebSite.csx /generateConfigurationFile:ServiceC onfiguration.cscfg
Windows(R) Azure(TM) Packaging Tool version 1.2.0.0 for Microsoft(R) .NET Framework 3.5 Copyright (c) Microsoft Corporation. All rights reserved.

c:\AzureWebSiteTest>

The cspack application certainly doesn’t seem very verbose. Anyway, I can now go ahead and deploy the web site to the Azure Development Fabric using another tool from the SDK, csrun:

And presto! I now have a web site running on the Development Fabric:

To actually deploy the web site to the cloud you need to create a proper deployment package. To do this, leave out the /copyOnly flag from the packaging command:

Again, I’ll repeat the command:

cspack ServiceDefinition.csdef /role:MyWebRole;WebSite1 /generateConfigurationFile:ServiceConfiguration.csfg

This will generate a file called ServiceDefinition.cspkg that you can upload through the Windows Azure Portal along with the ServiceConciguration.cscfg.

Once the Fabric Controller has done its thing we have a web site in the cloud:

I had to cut some corners in the proces, but at least this shows that the web site model _can_ run on Windows Azure.

When you are working with Windows Azure on your local machine, each time you deploy your application to the Development Fabric that particular deployment will receive a unique name along the lines of

deployment(<deploymentnumber>)

Here <deploymentnumber> is a number that is incremented each time you deploy an application to Development Fabric. This may start to look ridiculous after a while, so you may want to reset the counter.

The Development Fabric uses a temp folder,

C:\Users\<your name>\AppData\Local\dftmp,

for storing deployed applications.

To reset the deployment counter go to

C:\Users\<your name>\AppData\Local\dftmp\s0

and delete all the previous deployments. Next, use Notepad to open the file

C:\Users\<your name>\AppData\Local\dftmp\_nextid.cnt

and reset the sole value in that file to 0.

Voila!