In this article we’re going to take the Getting Started sample, make it scalable with the Service Bus backplane and deploy it to a Windows Azure Cloud Service with 4 instances. Let’s get started!

Creating the application

So the first thing I did was create a new Azure project in Visual Studio with a simple ASP.NET Web Role. After that I added the Microsoft.AspNet.SignalR and Microsoft.AspNet.SignalR.ServiceBus packages to the Web Role project:

And after adding the packages I did 2 simple things, creating a hub and creating the “chat page” (this is all based on the Getting Started sample). The hub is very simple, the only thing it includes is the Send method. If you compare this to the original hub in the Getting Started sample you’ll see that I added some extra information to the broadcast: the name of the machine and the ID of the instance. If you’re doing this on-premises you can just remove the last argument.

And the chat page is also fairly simple. I also made some changes to this code to display some info about the instance where the message was sent to (this is the server which sent out the broadcast).

Finally I created a Global.asax file in which I initialized the Service Bus backplane together with the SignalR routing:

As you can see from this code I’m using the CloudConfigurationManager class to get the connection string to my Service Bus namespace. If I’m running in a Windows Azure Cloud Service, the CloudConfigurationManager will get the setting from the Service Configuration (which can be changed after deploying the application). If the application runs as a normal web application (on-premises, in a Windows Azure Web Site, …) it will get the setting from the app/web.config

But before you can get the connection string you’ll need to create a new Service Bus namespace (or get the connection string for an existing namespace).

Service Bus Namespace

Creating a new namespace is easy, simply go to the Windows Azure Portal under Service Bus and press the Create button. After a few seconds the namespace will have been created and you’ll be able to click the Access Key button:

This is where you’ll be able to see the connection string which you can copy to your Service Configuration or to your web.config (depending if you’re deploying to a Cloud Service or not).

Note: Don’t use the owner account in production. Instead, click the Open ACS Management Portal link to create additional Service Identity for that namespace with limited permissions.

Deploy and test

As you can see it was really easy to add the Service Bus backplane. The last thing left to do is deploy the application. I decided to deploy it as a Cloud Service with 4 instances:

And now the only thing I had left to do was to test it out. I opened a few different tabs in IE to make sure that I would be connecting to different instances at the same time.

As you can see I’m sending the chat message to different servers which still manage to broadcast it to all connected clients thanks to the Service Bus backplane. And in the Windows Azure portal you’ll also be able to see that the Service Bus backplane created a topic for your application and a subscription for each instance in your Web Role:

The code for this sample is available on GitHub: https://github.com/sandrinodimattia/WindowsAzure-SignalRScaleOutDemo

Enjoy!

That’s why I decided to write this post… I’ll be covering step by step how Contoso moved from everything in their datacenter to a hybrid setup with their datacenter and Windows Azure Virtual Machines, connected with the Site-to-Site VPN available in Virtual Networks.

The original setup

This is how Contoso looked like before moving to Windows Azure. Besides the standard infrastructure like AD, DNS, … their network included the following:

1. A firewall + router which was directly connected to the internet. Everything behind that firewall + router was using NAT.
2. A developer (Contoso-DEV) connected to the wireless network. This wireless network was connected to the router.
3. A webserver (Contoso-WEB001). Using port forwarding (port 80 and 443) this server was available from the internet. Developers from within the network were able to connect to the machine using Remote Desktop, but this was only possible if they were connected to the corporate network.
4. A database server (Contoso-SQL001) which was not publicly available. Only the webserver and the developer workstations were able to access it.

Contoso decided to resell their application in a few additional countries so they needed some extra power. And instead of investing in additional hardware, licenses, … they decided to go for Windows Azure. The plan was to have multiple webservers running in Windows Azure depending on number of additional customers. If it would turn out that the application wasn’t selling good enough in these countries, they could just remove the Virtual Machines and that would be the end of it. They loss they would suffer would be minimal.

Preparing the hardware and the network

The first thing I did was install a new physical server with Windows Server 2012. Now take a look at the following picture:

The image in the lower left corner represents my new server. As you can see this server has a public IP since it’s connected to my modem, but it also comes with an internal IP since it’s connected to the firewall/router. The important thing to know here is that you machine needs direct access to the internet, meaning no NAT or blocked ports. If that’s not possible for you, I think it all ends here. Here in Belgium I think it’s almost impossible to get this on a residential line, so I had to buy a new modem + upgrade my internet subscription in order to get this.

Ok so let’s take a look at what we’ve done so far:

1. Install a Windows Server 2012 (name: Contoso-RRAS)
2. Connect this server to the internet using a direct connection without NAT (so no firewalls, routers, … between your server and the internet)!
3. Connect this server to our corporate network. For this connection, NAT is OK

And this is how an ipconfig on the new server looks like:

Here you can clearly see the 2 network interfaces: Ethernet is the one connected to the internet and the Wireless one is the one connected to the corporate network. Note that for the connection to my corporate network I’ve set this to a fixed IP address and remove the gateway (explained here: http://blog.concurrency.com/featured-post/site-to-azure-vpn-using-windows-server-2012-rras/).

Creating the Local Network in Windows Azure

The first thing we’ll need to do in Windows Azure is define our local network. You can create a new local network under Networks > New > Add Local Network. Start by giving it a name and the IP address of the new Windows Server (in my case the public IP address of Contoso-RRAS, 93.221.80.21).

On the next page I’ll enter the internal IP range of the corporate network (this matches the second IP address you saw in the ipconfig screenshot):

And that’s it, your corporate network has been defined in Windows Azure. Next stop, creating a Virtual Network!

Creating the Virtual Network in Windows Azure

So I created a new Virtual Network which I called Contoso-AZURE:

On the next page I defined the DNS server which runs on-premises (in my case 10.0.0.9). This is really important if you want your Virtual Machine to resolve your local resources like a SQL Server (in my case that would be Contoso-SQL001). And on the third page I configured the Virtual Network with a subnet called Web-Frontends and a gateway subnet. The Web-Frontends subnet will hold the Virtual Machines running the webapplication.

After a few seconds the Virtual Network will be created. Now it’s time to set up the gateway as described in my previous post: Setting up software based Site-to-Site VPN for Windows Azure with Windows Server 2012 Routing and Remote Access.

1. In the Virtual Network, create a gateway with static routing
2. Download the VPN Device Script for Microsoft / RRAS
3. Replace the weird characters in that file
4. Replace the settings in that file
5. Save the file as a *.ps1 file
6. Run it on the new server (in my case Contoso-RRAS)
7. Wait for the installation to complete

Here’s how I replaced the variables in that file, it might be a useful reference for when you’re comparing this with your own environment:

• SP_AzureGatewayIpAddress: 137.117.x.x (the IP address you’ll see in your Virtual Network after creating the gateway with static routing)
• SP_AzureNetworkCIDR: 10.1.0.0/16 (the address space of my Virtual Network, see previous screenshot)
• SP_AzureNetworkMetric: 10
• SP_PresharedKey: the key you’ll find when clicking Manage Key in your Virtual Network

After running the script on your new server you’ll see that the Routing and Remote Access Role has been configured. Open up RRAS and go to Network Interfaces. This is where you’ll see the gateway as a Demand-dial interface. Right click it and press Connect. The first time I had to do this a few times before it worked (Disconnect / Connect / Disconnect / Connect / …). After the first time everything kept working OK:

Creating the Virtual Machines

So the first part of the network configuration is done. Now we’re going to setup a new Virtual Machine which will allow the developers to deploy the application. And after that we will remove the web server which runs on-premises (in a real project this would keep running in parallel for a few days/weeks).

For the first Virtual Machine I had to create it as a stand-alone Virtual Machine. And it’s on this page that I decide to link the Virtual Machine to the Contoso-AZURE Virtual Network and in which subnet to place it (the Web-Frontends subnet). Finally on the next page I decided to create an availability set called WebFrontEnds in order to get the 99,95% SLA when I connect a second machine.

Immediately after creating the first machine I created the second machine, but for that one I connected it to the first virtual machine:

After a few minutes you’ll see the Virtual Machines popping up in your Virtual Network:

Did you notice that both machines received an IP address which matches the Web-Frontends subnet. This is how we’ll be able to address the Virtual Machines from our corporate network.

Time for some Routing

The networks have been connected, the web application has been migrated to Windows Azure Virtual Machines. This means we only have one task left: configure the routing to make sure that our developers can connect to the Virtual Machines from within our corporate network and to make sure that the Virtual Machines can access the SQL Server running on-premises.

You might be thinking that the developers already have access to the Virtual Machines (since they deployed the web application on the Virtual Machines). That’s true, but in order to do so they had to connect though the public endpoint for Remote Desktop. Now this might be a possible security risk, since anyone with an internet connection could be able to connect to your Virtual Machine (this leaves the door open for brute force attacks). Go ahead and remove these public endpoints and make sure you open ports which are really required for your application like HTTP or HTTPS:

The next step will depend on the type of firewall you have in your corporate network. Since I’m doing this at home I don’t have a fancy firewall, but I’m using a Netgear Genie WNDR4000 instead (which is my firewall + router). But this doesn’t really matter. The only thing you’ll need to do is setup routing in your firewall. In my case I created a static route to my Web-Frontends subnet:

Here is what this means:

• Name: I guess that’s obvious
• Destination: the subnet you want to connect to (the one you defined in the Virtual Network). In my case this is the 10.1.0.0 range.
• Gateway: the server that can “bring you there”. In my case this is the new server I deployed. This server is the only connected to Windows Azure using the Site-to-Site VPN and if you look back to the picture at the start of this post you’ll see that the IP address of the machine is: 10.0.0.2

Once that’s done I’m able to connect to the Virtual Machine from the developer workstation (or any other machine in the corporate network connected to the firewall):

But this also means we could use this for so many other scenarios like secure backup, secure Remote PowerShell, using Windows Shares, Web Deploy, integrating with System Center … And do you remember the DNS Server you assigned to your Virtual Network? Well, take a closer look: the Virtual Machine automatically uses this DNS Server. This means my Virtual Machine will be able to resolve the names of the machines in my corporate network.

Now the other way around just works thanks to RRAS, so from that Virtual Machine I’m able to ping any server in my corporate network like the SQL Server for example (10.0.0.4):

And we’re done! Our servers in the corporate network are able to connect with the Virtual Machines running in Windows Azure and those Virtual Machines can connect to our corporate network!

Improving security

Our RRAS server is connected to the internet without a firewall sitting in front of it. In order to improve security you could configure the firewall to only allow incoming connections from the internet coming from the gateway you created in the Virtual Network. For the VPN to work only these rules should be enabled for the public profile (besides the Core Networking rules):

The End

And there you go, this should be a good reference to get started with the Windows Azure Virtual Networks Site-to-Site VPN functionality for Routing and Remote Access. Here’s how the network looks like today:

Writing this article was very challenging for me (since I’m not an IT Pro) and it even cost me a few bucks (about 85€ for the line upgrade and the new modem), but I hope this can be a useful start for people who want to move their infrastructure to a hybrid cloud (with Windows Azure of course).

Enjoy!

Every time I tried to delete a Virtual Network I got this error message: Virtual network ‘ContosoCloud’ is in use and cannot be deleted. If you recently deleted resources, it might take some time to update the virtual network.

But my Virtual Network wasn’t in use because I made changes to it, it was in use because I didn’t remove the resources linking to this Virtual Network. This is what you’ll need to do to get rid of a Virtual Network and a Local Network (exactly in this order):

1. The first step is to delete the gateway in your Virtual Network. This can take a few minutes, so you will need to wait for it to complete before you can continue:
   
2. Once you’ve deleted the Gateway you will need to delete the next link to this Virtual Network. You can find them them under resources in the dashboard of your Virtual Network.

   

   Don’t worry about deleting the Virtual Machine. By deleting them, you’re deleting nothing more than an XML file which describes where to find the data disk, the size of the VM, which ports to open, … So its very easy to re-create the Virtual Machine (with the same data) through the portal or by using PowerShell.

3. After removing the gateway and the resources you’ll be able to delete the Virtual Network.
   
4. And the final step, if you linked the Virtual Network to a Local Network you can now also remove the Local Network (which was referenced by the Virtual Network):

   

Enjoy!

How we used to do it

When you create a new Windows Azure project in Visual Studio (a Cloud Service) you get to choose from different Web/Worker Role templates. One of these templates is the following: Worker Role with Service Bus Queue. This project is just a quick start that allows you to see how to receive and process messages coming from a Service Bus Queue from within a Worker Role:

By using the Receive method it was up to you to poll for messages, handle any exceptions, process multiple messages in parallel, Complete the message, … The new support for the Event-Driven Message Programming Model now does most of those things for you. Let’s take a look…

Sample application

To show this I created a sample application which requests and handles customer approvals. For this I’m using a simple class which contains the Id of the customer:

And then we also have a sample console application which makes sure the queue exists and sends out a message (with the Id of a customer) to the queue. The message is sent each time you press Enter:

This is how sending the messages looks like:

Receiver

Instead of polling the queue we’ll be using the new message pump. Take a look at how easy it is to get messages from the queue:

The first thing that happens is setting up the options for the message pump by creating a new OnMessageOptions. This class allows us to define a few settings:

• AutoComplete: call Complete on the message after it has been processed (after we leave the OnMessageArrived method)
• ExceptionReceived: the event to raise each time an error occurs
• MaxConcurrentCalls: define how many theads will be processing the queue (for improved performance)

After setting up OnMessageOptions we simply call OnMessage on the queue client with the method to execute each time a message arrives and the options. As you can see from my OnMessageArrived method I simply get the message and process it. I also introduced an exception for every 10th customer to automatically throw an exception. This allows us to test the ExceptionReceived method. Here is the result after I’ve sent a few messages:

As you can see the messages 1 – 9 are being processed very fast, and after processing each message, the message pump will set the message as complete (thanks to the AutoComplete option). But then for customer 10 we get an exception which will raise the ExceptionReceived even. In our case this will call the OnExceptionReceived method. This is typically the place where you’ll want to do something like logging the exception, sending out an email, …

Now the exception might not be a real problem. it could be possible that the issue is fixed the next time we process the message. That’s why it’s important not to handle the exception in the OnMessage action. If you handle the exception the message pump will not know anything went wrong and simply complete the message, which is something you don’t want. You want that, whenever something goes wrong, the message is retried for a few times. If it doesn’t work after a few times it will be placed in the Dead Letter Queue. But remember, this is only possible if you let the message pump handle the exception for you.

Finally we have the MaxConcurrentCalls option which is set to 5. This means that messages will be processed by a maximum of 5 different Threads in parallel, which increases the number of messages being processed on the receiver side. If you set this to 1 and re-run the application you’ll see that messages are being processed one by one. Anyways, this option makes it really easy to use more resources on your machine to process the messages.

Receiver without AutoComplete

Now there are times where you’ll need more control over your message, like when you want to complete it, when you want to abort it, … In that case you can set the AutoComplete option to false:

This code is very similar to the previous example except for 2 small differeneces: AutoComplete is set to false and we’re handling when to complete the message ourselves. This example is fairly simple, it will complete the message only if it’s a valid customer. The great thing about the AutoComplete option is that you can get more control if you need it. What you might notice is that I’m using a retry policy (TOPAZ) on my Complete method. This is to make sure we’re not affected by transient faults (ie: connection loss for a few seconds).

Small but nice

Now while this is a pretty small change, but it will make consuming messages from a Service Bus Queue / Subscriptions so much easier. Read more about the new release in the Release Notes.

Enjoy!

From time to time I tend to suffer from the “not invented here” syndrome, so I decided to write a little script which would do the following:

1. Parse a publish settings file to get the management certificate and the subscription ID
2. Find the public port for Remote PowerShell of a specific Virtual Machine
3. Download the certificate used by the Virtual Machine for Remote PowerShell
4. Install this certificate in the trusted root store
5. Give me some examples of how I could use Remote PowerShell for that machine

The result: Enable-RemotePowerShellForVM.ps1 (download)

Syntax

You can call the script like this:

Enable-RemotePowerShellForVM.ps1 “X:\mycredentials.publishsettings” “Name Of My Subscription” “Name of my Cloud Service” “Name of my VM“

Now this means that, after installing your Virtual Machine with Remote PowerShell enabled, you only need to run one line of code on  your machine to setup Remote PowerShell on your local machine. After that you can start doing things like deploy an application, install SharePoint, a TFS Build Server, …

Source

One of the reasons why I created this script was to test out a nice PowerShell feature that allows you to create types (which you can use in PowerShell) by using C# code. I actually wrote this script in a Console Application and then just copied the code to a .ps1 file. Finally, by calling Add-Type we turn the C# code into a type which can then be used in PowerShell. Call me lazy, but it’s so much easier to do C# in PowerShell

Enjoy!

Update: I created a script which makes this a lot easier, you can find it in my next blog post (Script to automatically configuring Remote PowerShell for Windows Azure Virtual Machines on your machine).

Just before the weekend Scott Guthrie announced a few improvements to Virtual Networks, Virtual Machines and Cloud Services. One of these improvements was the support for Remote Powershell. This means that, when you create a Virtual Machine you can choose to enable Remote Powershell on that machine.

You can enable Remote Powershell by simply checking the box after creating your Virtual Machine (not that this option only shows if you’re creating the Virtual Machine from the gallery):

After the machine has been created go to the Endpoints tab. There you’ll see which port maps to the remote Powershell port. In my case this is port 54355:

Now simply start a new Powershell console on your machine and use the Enter-PSSession command (replace the hostname, the port and the username):

Enter-PSSession -ComputerName mymachine.cloudapp.net -Port 54355 -Credential sandrino -UseSSL

Now when you try to connect you will see the following error:

Enter-PSSession : Connecting to remote server myserver.cloudapp.net failed with the following error message : The server certificate on the destination computer (myserver.cloudapp.net:54355) has the following errors: The SSL certificate is signed by an unknown certificate authority. For more information, see the about_Remote_Troubleshooting Help topic.

This is because Remote Powershell uses HTTPS and the certificate used for your Virtual Machine is a self signed certificate. To solve this open your browser and navigate to your VM and the public endpoint for Remote Powershell. In my case this would be:

https://mymachine.cloudapp.net:54355

Now since I didn’t find the certificate button in IE10 (sometimes it shows, sometimes it doesn’t) I used Chrome to get the certificate by clicking the little lock and then clicking the Certificate information link:

This will open the certificate. Go to the Details tab and choose Copy to File to save the file to disk. After that you’ll need to open the certificate and choose to install it under Current User > Trusted Root Certification Authorities. Press Yes to continue and you’re done.

After that simply reexecute the Enter-PSSession command and you’ll be prompted for the password. Enter your password and you’ll be connected to your VM using Remote Powershell:

And if you’re done, just type exit to leave the session.

Enjoy!

A follow-up post is available with a complete reference implementation: Reference implementation: Creating a hybrid cloud with Windows Azure Virtual Networks software based Site-to-Site VPN

Two days ago, only one week after Virtual Machines and Virtual Networks reached general availability, Scott Guthrie already announced a few new improvements to Virtual Machines and Virtual Networks. One of the big changes for Virtual Networks is the support for software based Site-to-Site VPN based on the Routing and Remote Access role available in Windows Server 2012.

Let’s take a look at how easy it is to setup a Site-to-Site VPN with RRAS based on a customer case. Contoso is a company with a datacenter in Belgium (Brussels). For a marketing campaign the created a new application and because they needed a quick time-to-marked they decided to deploy it on a few Windows Azure Virtual Machines in the Western Europe datacenter. These machines connect to some of their systems like the intranet, their Oracle database, … For security reasons they didn’t want to make these systems available through the internet, so that’s why they decided to setup a Site-to-Site VPN between their on-premises network (the datacenter in Brussels) and the Virtual Machines running in Windows Azure.

Works on my machine!

Before we start we’ll need to see if our network matches the requirements:

• Windows Server 2012
• The server is not behind a NAT (http://msdn.microsoft.com/en-us/library/windowsazure/dn133795.aspx)
• We opened the required ports for IKEv2 on the server: (http://blogs.technet.com/b/rrasblog/archive/2006/06/14/which-ports-to-unblock-for-vpn-traffic-to-pass-through.aspx)
  • IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv2 (IPSec control path)
  • IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv2 (IPSec control path)
  • IP Protocol Type=UDP, UDP Port Number=1701 <- Used by L2TP control/data path
  • IP Protocol Type=50 <- Used by data path (ESP)
    • This is not a port, it’s a protocol.
    • This one can be a show stopper if you’re using a residential line or a dedicated server somewhere.

Defining the local network

The first thing we need to do is define the local network (this would be our on-premises network). This can be done on the portal under the Networks option by clicking the New button:

After that simply define the name, the address space and the public IP of your server:

Creating the Virtual Network

Now go ahead and create a new Virtual Network. On the second page you’ll need to enable the Configure Site-To-Site VPN option. This is where you get to choose the local network:

On the next page you’ll simply need to define a gateway subnet and you’ll be able to complete the wizard. After a few seconds the Virtual Network will have been created.

Setting up the gateway

After the Virtual Network has been created you’ll need to setup the gateway. At the moment static routing is not supported for RRAS so you’ll need to create a gateway with dynamic routing (http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx):

And now  you’ll need to wait a few minutes. Once you’re done waiting you can download the VPN Device Script.

VPN Device Script

When you click the Download VPN Device Script link you’ll see the following dialog:

This is where you’ll get to choose RRAS. After downloading the script you might need to fix a small issue. When I downloaded the script (I tried several times) it looked like something was wrong with the file. Take a look at it:

It looks like double quotes have been replaced with a little square. Maybe an encoding issue? Just replace them with double quotes with any text editor (I’m using Notepad++) and you’re ready to continue. Now you’ll need to modify a few variables:

1. Line 75: Replace <SP_AzureGatewayIpAddress> with the IP address of your gateway (the big IP address you’ll find on the portal)
2. Line 75: Replace <SP_AzureNetworkCIDR> with the network CIDR you defined when creating the new Virtual Network (in my case this was 10.1.2.0/24)
3. Line 75: Replace <SP_AzureNetworkMetric> with your network metric (I used 10)
4. Line 78: Replace <SP_AzureGatewayIpAddress> with the IP address of your gateway (the big IP address you’ll find on the portal)
5. Line 79: Replace <SP_AzureGatewayIpAddress> with the IP address of your gateway (the big IP address you’ll find on the portal)
6. Line 85: Replace <SP_AzureGatewayIpAddress> with the IP address of your gateway (the big IP address you’ll find on the portal)

Finally save the file as a *.ps1 file and execute it on your server. This will install (if not present) RRAS and configure the site to site VPN:

Now the error you see here isn’t a real issue. It looks like the server wasn’t ready configuring RRAS when we executed the script. Wait a few seconds and open RRAS to see the result (the interface should have connected by now):

Connecting both Sites

You’re done! Go back to the portal, open the Virtual Network and press the Connect button. After a few seconds the Site-to-Site VPN between your on-premises network and your Virtual Network will be running:

And the link is working! Now you can go ahead and configure whatever needs to be configured in RRAS (routing to specific parts of your network for example).

Enjoy!

[CryptographicException: Key not valid for use in specified state.]
System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope) +450
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[] encoded) +150

As explained in the Windows Azure Training Kit this is caused by the DPAPI:

What does ServiceConfigurationCreated do?
By default WIF SessionTokens use DPAPI to protect the content of Cookies that it sends to the client, however DPAPI is not available in Windows Azure hence you must use an alternative mechanism. In this case, we rely on RsaEncryptionCookieTransform, which we use for encrypting the cookies with the same certificate we are using for SSL in our website.

Over a year ago I blogged about this issue but that solution applies to .NET 3.5/4.0 with Visual Studio 2010. Let’s take a look at how you can solve this issue when you’re working in .NET 4.5.

Creating a certificate

So the the first thing you’ll need to do is create a certificate and upload it to your Cloud Service. The easiest way to do this is to start IIS locally and go to the Server Certificates:

Now click the Create Self-Signed Certificate option, fill in the name, press OK, right click the new certificate and choose “Export…“. The next you’ll need to do is go to the Windows Azure Portal and upload the certificate in the Cloud Service. This is possible by opening the Cloud Service and uploading the file in the Certificates tab:

Copy the thumbprint and add it to the certificates of your Web Role. This is possible by double clicking the Web Role in Visual Studio and going to the Certificates tab:

As a result the certificate will be installed on all instances of that Web Role. Finally open the web.config of your web application and add a reference to the certificate under the system.identityModel.services element:

Creating the  SessionSecurityTokenHandler

The last thing we need to do is create a SessionSecurityTokenHandler which uses the certificate. To get started add a reference to the following assemblies:

• System.IdentityModel
• System.IdentityModel.Services

Once you added the required references you can add the following code to your Global.asax file:

This code replaces the current security token handler with a new SessionSecurityTokenHandler which uses the certificate we uploaded to the portal. As of now, all instances will use the same certificate to encrypt and decrypt the authentication session cookie.

Enjoy!

• Download/Upload the VM image yourself.
• Use the azure-cli to do all the work

But it looks like the VM Depot now seamlessly integrates with the Windows Azure Portal. Let’s take a look at how easy it is to create Virtual Machines based on VM Depot images from within the portal.

Create the image

If you browse to Virtual Machines in the portal you’ll see the new Browse VM Depot option under the Images tab:

Next you’ll be able to browse the images available in the VM Depot:

After selecting an image you will need to choose in which storage account it will be dropped:

Wait a few seconds for the copy to complete. Once it’s done you’ll see that the image appears in the Images tab with a Pending registration status:

Click the Register button to register the image which will change the status to Available.

Creating the Virtual Machine

That was the “hard” part. Now in order to create the Virtual Machine you’ll need to go to the Virtual Machine Instances tab and choose Create a Virtual Machine. Choose to create it from the Gallery. In the Gallery you’ll see the My Images tab and this is where you’ll find the image:

Select this image and go through the wizard (enter the name of the machine, username, password, …). The provisioning process will start and after a few minutes the VM will be ready. This means you’ll be able to connect to the VM through SSH (myvmname.cloudapp.net port 22):

If you want to connect to the Solr dashboard you can also add an endpoint for port 80:

And here is the dashboard:

This is really great. In just a few minutes I’ve set up a fully functional Solr deployment, which I can use in my applications to offer an improved search experience. If you want to use this in production I suggest you also look at Virtual Networks. This feature allows you to connect the VM to your applications (running in Cloud Services/Virtual Machines or even on-premises) without having to expose it to the internet.

Enjoy!

Windows Azure Caching introduces a new way to perform caching by using a portion of the memory of the virtual machines that host the role instances in your Windows Azure cloud services (also known as hosted services). You have greater flexibility in terms of deployment options, the caches can be very large in size and have no cache specific quota restrictions.

The .NET libraries depend on a library which is specific to Cloud Services, which makes them unable to use in Windows Azure Web Sites. This restriction applies to the official Windows Azure Caching libraries for .NET. But Windows Azure Caching also supports the memcache protocol, this means you can use it from any environment supporting memcache like Node.js, php, …

Let’s see how we can configure the memcache protocol in Windows Azure Caching, open it up for Windows Azure Web Sites and call it from a Node.js application.

Memcache support for Windows Azure Caching

We start by creating a new Dedicated Cache Worker Role as described here. Once this is done we’ll add support for the memcache protocol by using the Memcache Server Gateway.  The Client Shim is not an option here since it requires an installation on the consumer side: in our case this is the Web Site and Web Sites don’t support running custom installations at the moment (remember that you’re running in a shared hosting model).

Setting up the Memcache Server Gateway is pretty easy: add an endpoint called memcache_default to your Cache Worker Role (you can choose the port):

Allowing access from your Web Site

When using Windows Azure Caching within a Cloud Service you typically set the endpoint type to Internal. But since the Web Site is not part of the Cloud Service you’ll need to change the endpoint to Input. It’s important to know that, by changing the type to Input, your Web Site will be able to connect to the endpoint just like everyone else with an internet connection.

Chances are pretty small that anyone will find this endpoint (by guessing/scanning the IP+port), connect to it, find out that it can be used by a memcache client and do something with the data. But it’s better to be safe than sorry so here is what you can do: you can use the WindowsAzure.IPAddressRestriction library to restrict access to the Worker Role. If you look at the Examples on GitHub there’s an example that shows you how to restrict access to your Worker Role endpoint(s) based on hostnames:

Once you’ve set up this code in your Worker Role you can configure the hostnames in your Service Configuration:

Using Windows Azure Caching from your Node.js Web Site

So we’ve set up Windows Azure Caching, added memcache support and made sure that (only) our Web Site can access the cache. Let’s get started on our Node.js application. The application will use the node-memcache library to access Windows Azure Caching through the memcache protocol. Here is the sample application:

The code is pretty straight forward. We reference the library, create the client and connect to the endpoint we opened in the Cloud Service. The get and set methods allow you interact with the cache. If you access the page the first time you’ll see that the value is added to the cache:

Each subsequent request will get the data from the cache:

And that’s about it. You’re all set up to use Windows Azure Caching through the memcache protocol which can drastically improve performance of your site.

Enjoy!