In many scenario, you would need to give somebody an access (regardless write, read, etc.) but you don’t want to give him / her full permission. Wouldn’t also be great if you could control the access on certain time frame. The “somebody” could be person or system that use various different platform other than .NET. This post is about to show you how to upload a file to Windows Azure Storage with REST-based API without having to expose your Storage Account credential.

Shared Access Signature

A cool feature Shared Access Signature (SAS) is built-in on Windows Azure Storage. In a nutshell, SAS is a mechanism to give permission while retaining security by producing a set of attributes and signature in the URL.

For the fundamental of SAS, I recommend you to read the following post:

• http://blog.smarx.com/posts/new-storage-feature-signed-access-signatures
• http://blog.smarx.com/posts/shared-access-signatures-are-easy-these-days
• http://msdn.microsoft.com/en-us/library/windowsazure/ee395415.aspx

Here’re the walkthrough how you can do that:

I assume that you’ve the Windows Azure Storage Account and Key with you.

Preparing SAS and Signature

1. Giving access to your container. You can either use tools or library to set SAS permission access on container or blobs. In this example, I use Cerebrata’s Cloud Storage Studio.

As could be seen, I’ve created a policy with the following attributes:

• Start Date Time: Jan 8, 2012 / 00:00:00
• Expiry Date Time: Jan 31, 2012 / 00:00:00
• Permission: Write only
• Signed Identifier: Policy1

By applying this policy to some particular container, somebody who possess a signature will only be able to write something inside this container on the given timeframe. I mentioned “a signature”, what’s the signature then?

2. You can click on “Generate Signed URL” button if you’re using Cloud Storage Studio. But I believe you can do similarly feature although using different tool.

In the textbox, you’ll see something like this:

https://[your-account].blob.core.windows.net/samplecontainer1?&sr=c&si=Policy1&sig=pjJhE%2FIgsGQN9Z1231312312313123123A%3D

Basically, starting the ? symbol to the end, that’s the signature: ?&sr=c&si=Policy1&sig=pjJhE%2FIgsGQN9Z1231312312313123123A%3D

*Copy that value first, you will need this later.

The signature will be signed securely according to your storage credentials and also the properties you’ve specified.

Let’s jump to Visual Studio to start our coding!!!

I use the simplest C# Console Application to get started. Prepare the file to be uploaded. In my case, I am using Penguin.jpg which you can find in Windows sample photo.

3. Since I am about to upload a picture, I will need to get byte[] of data from the actual photo. To do that, I use the following method.

        public static byte[] GetBytesFromFile(string fullFilePath)
        {
            FileStream fs = File.OpenRead(fullFilePath);
            try
            {
                byte[] bytes = new byte[fs.Length];
                fs.Read(bytes, 0, Convert.ToInt32(fs.Length));
                fs.Close();
                return bytes;
            }
            finally
            {
                fs.Close();
            }
        } 

4. The next step is the most important one, which is to upload a file to Windows Azure Storage through REST with SAS.

        static WebResponse UploadFile(string storageAccount, string container, string filename, string signature, byte[] data)
        {
            var req = (HttpWebRequest)WebRequest.Create(string.Format("http://{0}.blob.core.windows.net/{1}/{2}{3}", storageAccount, container , filename, signature));
            req.Method = "PUT";
            req.ContentType = "text/plain";

            using (Stream stream = req.GetRequestStream())
            {
                stream.Write(data, 0, data.Length);
            }

            return req.GetResponse();
        }

5. To call it, you will need to do the following:

        static void Main(string[] args)
        {
            string storageAccount = "your-storage-account";
            string file = "Penguins.jpg";
            string signature = "?&sr=c&si=Policy1&sig=pjJhE%2FIgsGQN9Z1231312312313123123A%3D";
            string container = "samplecontainer1";

            byte[] data = GetBytesFromFile(file);
            WebResponse resp = UploadFile(storageAccount, container, file, signature, data);

            Console.ReadLine();
        }

The signature variable should be filled with the signature that you’ve copied in step 2 just now.

6. Let’s try to see if it works!

And yes, it works .

Hope this helps!

As I believe most people are aware that our application on Windows Azure is actually running on VM (Virtual Machine) that sits on top of Windows Azure Hypervisor, inside Microsoft Datacenter.

The objective of this post is to explain under-the-hood or deep view of what’s actually inside Windows Azure Virtual Machine.

This is NOT about VM (Virtual Machine) Role

Please do not be confused this post with VM Role. This post is purely discussing about the Virtual Machine of pre-provisioned by Windows Azure, specifically Worker Role and Web Role. While VM Role is another role type other than Web Role and Worker Role.

Fabric Controller – the “kernel” of the Cloud OS

Before moving on what inside the VM, I will explain how the Fabric Controller is, what it does, and how it relates to Windows Azure VM.

Fabric Controller is actually a Windows Azure service that is acting as the kernel on the Windows Azure Platform itself. It manages data center’s hardware as well as Windows Azure service. The Fabric Controllers run on nodes that will be spread across fault domains in the hardware. In order to ensure the high availability and multiple-fault tolerant, it has at least 5 instances, in most case it may be more.

Specifically, the main responsibilities are:

1. Data Center Resource Allocation

The Fabric Controller will manage the resource allocation over the hardware in Windows Azure datacenter including the blades and network. When you specify your input of your service (VM Size, number of instance, fault domain, upgrade domain),the Fabric Controller would be intelligent enough to allocate appropriate resource inside the datacenter.

2. Data Center Resource Provisioning

When appropriate node is found,the next step is to provision the VM for host our application to ensure the application and OS are up and running. The provisioning processes includes powering-on the node, perform a PXE-boot maintenance OS, download host OS, run sysprep, and eventually connect the Fabric Controller will communicate with host agent.

3. Service Lifecycle Management

Managing the deployment lifecycle of service. When you deploy your application on Windows Azure (regardless through portal or management API), your service package is actually passed to a service, namely RDFE (Red Dog Front End). The RDFE then subsequently send your service package to Fabric Controller based on target region. The Fabric Controller will then deploy your service accordingly given inputs that you’ve defined in Service Configuration and Service Definition files.

4. Service Health Management

When the service is successfully deployed, the responsibility of Fabric Controller is not done yet. However, it will manage and monitor the health of the VM. The monitoring process typically works by sending the heartbeat from guest OS to host OS and subsequently host OS to Fabric Controller. The Fabric Controller will then act appropriately should it encounters any issue.

Alright, having understand what Fabric Controller is, we can now just to our core topic about the Windows Azure VM.

Pre-provisioned VM sits on Hypervisor

A Windows Azure VM (regardless it’s web or worker role) is actually a pre-provisioned VM that is automatically placed and booted on top of Hypervisor, a custom version of Hyper-V to satisfy the needs. In the picture it’s reflected as “Guest VM”. This is actually the place where our service hosted on. The Guest VM will communicate to Root / Host VM to perform necessary management task such as as heartbeat-pinging.

Operating System Versions

At the moment, Windows Azure supports two type of operating system, namely:

• Windows Server 2008 (64 bit)
• Windows Server 2008 R2 (64 bit)

You can specify your preferred OS on either:

1. Service Configuration files by entering osFamily and osVersion attributes.

osFamily 1 represents Windows Server 2008, while 2 represents Windows Server 2008 R2.

On the osVersion, this is the setting where you tell Windows Azure, which version of OS your Guest VM will be using. Specify it with * (star) sign means Windows Azure will automatically upgrade the Guest VM OS when there’s new OS released. However, in some case customer does not want it to be automatically updated, then you can select the specific version of OS as could be found here.

2. Windows Azure Portal

You can also use user interface in Windows Azure Portal to select your preferred OS family and version.

What are the difference? Which one should I choose?

A few notable difference that I feel relevant to Windows Azure is some of the command utility exists in Windows Server 2008 R2 but not in Windows Server 2008, for example: tzutil command to set the timezone.

There’re indeed some more differences of each OS. I recommend you to check out more detail here.

VM Sizes

VM Size is to define the hardware specification of VM you want Windows Azure to provision to you. There’re 5 available VM Size at this moment from Extra Small all the way to Extra Large. Obviously, the higher specification the more expensive.

Extra Small VM Size

Extra Small VM Size was announced in PDC 2010 with more affordable price. Selecting Extra Small VM in development or testing environment will fits properly. However, you are not recommended to use in Production environment.

VHDs (Virtual Hard Drives) inside Windows Azure VM

Windows Azure will provide three VHD images when a role is provisioned.

1. C Drive – Local Storage Drive

This drive is to store temporary file such as logs or to store local resource. The size of this VHD varies from 20 GB (Extra Small) to 2 TB (Extra Large) depending on what VM Size you choose. We can utilize this local resource drive to store temporary file, but keep in mind that it’s considered not persistence.

2. D Drive – OS Drive

The D Drive is to store the Operating System files. The foldering structure is as almost similar to the on-premise OS. It has Program Files, Windows, etc.

3. E Drive – Application’s code

The E Drive is the place for Windows Azure to store our application code. Our code will typically to be placed inside the “approot” folder.

Runtime Installed

As a PAAS (Platform as a Service) cloud provider, Windows Azure will take care of the OS and runtime level. As such, there are several pre-installed runtime in Windows Azure VM:

• NET 3.5 SP1
• NET 4
• ASP.NET
• VC80 CRT (8.0.50727)
• VC90 CRT (9.0.30729)
• URL Rewrite Module 2.0
• VC10 CRT (e.g. MSVCR100.DLL) is not fusion-ized and can be packaged together with the application

In future, there’s a plan (as mentioned by Mark) from Microsoft that Java will be pre-installed as well.

References

• Inside Windows Azure VM – Hoi Vo (PDC 2010) http://channel9.msdn.com/Events/PDC/PDC10/CS63
• Inside Windows Azure – Mark Russinovich (PDC 2010) http://channel9.msdn.com/Events/PDC/PDC10/CS08
• Inside Windows Azure – Mark Russinovich (TechEd NA 2011) http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/COS301

That’s all for this post and hope it’s useful to you!

Introduction

Various Options to Manage Session State in Windows Azure

1. InProc Session

Advantages

• Very fast access since the session information is stored in memory (RAM)
• No extra cost as it will be using your VM’s memory

Disadvantages

• As mentioned above, this will only valid for single instance. If you use more than one instance, the inconsistency will happen.

2. Table Storage Session Provider

Advantages

• Cost effective. In essence, Windows Azure Storage only charge you $ 0.15 per GB per month.

Disadvantages

• Not officially supported by Microsoft
• Performance may not be very good. I experience a pretty bad experience on performance when using Windows Azure Storage provider.
• Need to clear unused session.

For each time a session (with properties including expiry time) is created on a session table. For the subsequent request, it will be check against the table to see if it exists. For the scenario we need delete the record which expiry time equals or older than current time. This is to enable timeout when there is no activity against session.

In order to automatically delete expired session, most of the time we use Windows Azure Worker Role to perform the batch activity.

SQL Azure Session Provider

.

Advantages

• Cost effective. Although it may not be cost effective compare to table storage, it’s still pretty affordable, especially when combining it into the main database.

Disadvantages

• Not official support by Microsoft
• Need to clear unused session

For each time a session (with properties including expiry time) is created on a session table. For the subsequent request, it will be check against the table to see if it exists. For the scenario we need delete the record which expiry time equals or older than current time. This is to enable timeout when there is no activity against session.

In order to automatically delete expired session, most of the time we use Windows Azure Worker Role to perform the batch activity.

Windows Azure AppFabric Caching

Windows Azure AppFabric Caching is actually the recommended option and officially supported by Microsoft. AppFabric Caching is distributed in-memory cache service. It is automated provisioned based on Windows Server AppFabric Caching Technology.

Advantages

• In memory cache, very fast access
• Officially supported by Microsoft

Disadvantages

• The cost is relatively high. The pricing starts from $ 45 per month for 128 MB and all the way up to $ 325 per month for 4 GB.

Conclusion

To conclude this discussion, there’re actually multiple ways of managing session in Windows Azure. All of them have pros and cons. It’s actually up to us to decide which one to use that fits better circumstance.

Introduction

I strongly believe that in most application we are building, we would need to store date and time. In some application, date and time play very important role, for instance: rental-similar application which could result big impact if date and time are incorrect. In other kinds of application, date and time may not be playing very significant role, for example: some of them is just as informational purpose, when the data is actually inserted in the system.

Regardless the importance level we discussed above, one essential factor that we need to be considered is the timezone of the system. Whether setting it as local country timezone or other timezone such as UTC / GMT, we would need to determine the it, typically on the server where our application is hosted.

Thus, when we type “DateTime.Now” inside your code, we should be able to get the correct result.

Timezone in Windows Azure

No matter which data center we selected in Windows Azure (remember, Windows Azure has 6 data centers world wide: 2 in America, 2 in Europe, and 2 in Asia), by default, Windows Azure VM would provide us UTC timezone.

If you are considering migrating your app to Windows Azure, you should ask yourself now what timezone your current application set. If it’s on UTC, you are safe, nothing to worry.

However, if you are running local time, (for example in Singapore, it’s UTC + 8 hour) and you want to ensure the consistency of your current data, then you will need to be cautious. You have “at least” 2 choice to go:

1. Use UTC on your app, which mean you would need to convert your current date/time data to UTC.
2. To set your preferred timezone in Windows Azure (it could be your local time).

I bet most of you will decline the first options .

How to set timezone in Windows Azure

Alright, I assume we go with option 2. To set timezone in Windows Azure, I believe there are actually a few ways via Powershell or by modifying registry. Honestly, I’ve not tried these option on Windows Azure, yet I am not pretty sure if it could be applied in Windows Azure. But there’s an option that is definitely working well.

Okay, there’s actually a command utility called “tzutil” that can be used to change timezone. Please take note that this command is only applicable in Windows 7 and Windows Server 2008 R2.

TZUTIL

You may try to run it using your command prompt by typing “tzutil /?” for the information.

To change to your preferred timzeon, simply run the following command.

tzutil /s "Singapore Standard Time" 

Run it as Start-up task

In Windows Azure, we would need to run this command as start-up task, to ensure that when is starting up, the command will be executed first.

1. To do that, create a empty file (using notepad), and paste the above tzutil command inside, just save the file as settimezone.cmd inside your Windows Azure Project.

In your project, ensure that this file is included, if not you’ll need to include it manually.

2. The next step is to set the properties of this file to Copy Always. This is to ensure that the file will be included when project is packaged before deployment.

3. Subsequently, we would need to tell Windows Azure to run the start-up task. This could be achieved by adding the following start-up section inside your ServiceDefinition.csdef file.

At earlier, I mentioned that the tzutil is only available in Windows 7 and Windows Server 2008 R2. Windows 7 is definitely out of context as there’s no such OS in Windows Azure.

Windows Azure at this moment allows us to choose either Windows Server 2008 or Windows Server 2008 R2. Both of them are running on 64 bit architecture.

By default (if you are not modifying anything in your configuration file), Windows Server 2008 will be selected.

In order to use tzutil, we would need to set the VM running as Windows Server 2008 R2. To do that, simply navigate to the ServiceConfiguration.cscfg file. In the ServiceConfiguration section, change the osFamily from 1 to 2.

*1 = Win 2008, while 2 = Win 2008 R2

We would also need to set the version of the OS. If you not preferring any OS, you can just simply put * and it will automatically perform update for you when there’s patch / new version of guest OS released.

5. Verification

If everything runs well, you should be getting your preferred timezone as expected.

Here’s how it’s look like, when I performed remote desktop to my Windows Azure VM.

What’s next?

In the app level, your are safe since you’ve successfully configure the timezone of your VM. But how about database level? What if there’s any stored procedure / function inside your code, use “getdate()” function?

I’ll discussed more on this topic in the next post. Stay tune…

Part 2 – Uploading Certificate on Windows Azure Developer Portal

This is the second part of this blog post series about Establishing Remote Desktop to Windows Azure. You can check out the first part here.

So far we’ve just only do the work on the development environment side. There’re still something needs to be done on Windows Azure Portal.

Export Your Certificate

1. The first step is to export the physical certificate file since we need to upload it to Windows Azure Portal.

There’re actually few ways to export certificate file. The most common way is using MMC. Since we use Visual Studio to configure our remote desktop, we can utilize the feature as well. I refer to step 4 of the first part of the post, where you’ve just create a certificate using Visual Studio wizard. With the preferred certificate selected, click on View to see the detail of your certificate.

2. Click on Details tab of the Certificate dialog box, and then click on Copy to File button. It should bring you to a Certificate Export Wizard.

3. Clicking on Next button will bring you the next step where you can select whether to export private or public key. On the first step, select “No, do not export private key” first, keep following the wizard and eventually it will prompt you to the last page where you need to name the physical file [Name].CER.

4. Repeat from the step 1 to 3 but this time, select “Yes, export private key” which eventually will require you to define your password and export it to another [Name].pfx file.

Upload the certificate to Windows Azure Portal

Since we are done exporting both private and public key of the certificate, the next step is to upload it to Windows Azure.

5. Log-in to your Windows Azure Developer Portal (https//windows.azure.com). I assume that you’ve your subscription ready with your live id.

6. Click on the “Hosted Service, Storage Account, and CDN” on the left-hand side menu. On the upper part, click on Management Certificate. If you previously have uploaded the certificate, obviously you will see some of them.

7. Next step is to click on Add Certificate button and a modal pop up dialog will prompt you to select your subscription as well as upload your .CER certificate.

As instructed, go ahead to select your subscription and browse your .CER file where you’ve exported in step 3. It may take a few second to upload your certificate. You’ve successfully uploaded your public key of the certificate.

8. Now, you will also need to upload the private key. To do that, click on Hosted Service upper menu. Click on New Hosted Service button on upper menu and you will see Create a new Hosted Service dialog show up. There are a few section which you need to enter here.

a. Enter the name of your service and well as the URL prefix. Please note that the URL prefix must be globally unique.

b. Subsequently, select your region / affinity group, where do you want to host your service.

c. The next one is about your deployment option, whether you want to deploy it immediately as staging or production environment or do not deploy it first. I assume that you deploy it as production environment.

d. You can give your deployment name or label on it. People sometimes like to use either version number or current time as the label.

e. Now it’s your time to browse your package as well as configuration where you’ve created on the step 9 in previous post.

f. Finally, you need to add certificate again, but this time it’s private key certificate that you’ve specified in step 4 above.

Click OK when you are done with that. In the case where an warning occur, stating that you’ve only 1 instance, you can consider whether to increase your instance count to meet the 99.95% Microsoft SLA. If you are doing this only for development or testing purpose, I believe 1 instance doesn’t really matter. You can click on OK to continue.

8. It will definitely take some time to upload the package as well as wait for the fabric controller to allocate a hosted service place for you. You may see that the status will change slowly from “uploading”, “initializing”, “busy”, and eventually “ready”, if everything goes well.

Remote Desktop to Your Windows Azure Instance.

9. Assuming that your instance has been successfully uploaded. Now you can remote desktop by selecting the instance of your hosted service. And click on the Connect button in upper menu.

This will prompt you to download an .rdp file.

10. Open up the .rdp file and you will see a verification are you want to connect despite these certificate error. Just simply ignore it and click on Yes.

It will then prompt your for username and password that you’ve specified in Visual Studio when configuring the remote desktop. But, here’s little trick here. Just just simply click on your name since it will use your computer as domain. Instead, use “” (backslash) and follow-up with your username. For example: “wely”. And of course you’ll need to enter your password as well.

11. If it goes well, you’ll see that you’ve successfully remote desktop to you Windows Azure instance. Bingo!

Alright, that’s all for this post. Hope it helps! See you on another blog post.