Posted at: 11:05 AM on 22 March 2011 by Muhimbi
Today’s article is another guest post by John Dent from BlueHub Solutions, who have been using our popular PDF Conversion Services to convert documents in MS-Office, AutoCAD, HTML, Image and many other formats to PDF from a Windows Azure based solution.
Over the next few weeks we’ll publish a number of posts related to using our software in combination with the Azure platform, so make sure you subscribe to our RSS feed or follow us on Twitter.
The following posts are part of this series:
- Using Windows Azure in combination with an internet facing web service.
- Using Windows Azure in combination with a web service hosted inside an organisation’s private network. (This post)
- Using Windows Azure in combination with a 3rd party web service hosted inside a custom Azure VM. (Coming soon)
If you have any questions then please contact us, we are always happy to talk to our customers. For now I’ll hand you over to John.
Welcome to my second post on using the Muhimbi PDF Converter Services from within an Azure application. As you may remember, and depending on the condition of your short-term memory cells, as we left it previously our web application was calling into the Muhimbi web service through an Internet URL.
For a number of reasons, including security and architectural elegance, this architecture could be considered undesirable – we are effectively being forced to host what is essentially an Intranet application on the Internet. It would be better to be able to run the Muhimbi web service as an Intranet application on our local business network, and still have our Azure application connect to it.
As luck would have it, Microsoft have provided exactly this functionality under the “Azure Connect” banner – this is a way of creating a secure channel through which an Azure application can communicate with local network resources. Even better, it’s really easy and seems to work really well.
Azure Connect is still a Beta feature at this stage, so the first step is to register for the Windows Azure Connect Beta program – you do this by logging in to the Azure Management Portal, then selecting Home and Beta Programs. You have to wait for your request to be manually accepted, which can take a couple of days.
Once you’re a fully paid up Beta program member, log onto the Azure Management Portal and select the Virtual Network section. (The Virtual Network button didn’t always work for me, instead I used the ‘Connect’ button at the top of the screen.)
Having done this, select your Azure subscription from the tree control on the top-left.
You may at this point be prompted to update your subscription options - complete the requested information as necessary.
The next step is to install a Local Endpoint on the server that is running the Muhimbi PDF Conversion Service. Do this by clicking the Install Local EndPoint button on the toolbar. This generates a connection token and gives you a download link for the software to install on your Intranet server.
This will then download and install the Windows Azure Connect software (a Windows Service), which then automatically allows your server to be securely accessed via TCP from Azure and vice versa. Effectively this creates a kind of VPN between the machine on which the software is installed and your Azure applications, and allows the machine to be accessed by network name from Azure.
Internet facing firewalls are effectively bypassed in the process, though note that Azure Connect itself needs port 443 on the Windows Firewall to be open for outgoing traffic (as would normally be the case).
Installing Azure Connect is then delightfully straightforward …
Finally, even though Azure Connect tunnels its way over the public internet, it still adheres to any locally (as on the server) configured firewall rules. The Muhimbi PDF Converter Services listens on port 41734 by default, so add a rule to your server’s firewall to allow incoming requests on this port. In our case we had to specify this on the Private Profile in the Windows Firewall. Alternatively, as a quick test, disable the entire Private Profile firewall (Note that in Windows 7 / Win2K8 R2 there is no longer a single option to disable the entire firewall).
Configuring the Azure application to use the new end-point
Once this is done, your new end-point should appear in the Virtual Network section of the Azure Management Portal.
After this we can update our application to connect though this end-point simply by specifying the computer name, in my case jonny-PC.
Going back to our Azure PDF Conversion Application, as developed in part 1 of this series, we can now reconfigure the web reference so that it uses jonny-PC via Azure Connect (as I’ve installed the Muhimbi PDF Conversion Services on my PC).
The next step is to set up the Azure project so that it can work as an end point for the virtual network. To do this go the Virtual Network section of the Azure Management Portal and click the Get Activation Token button.
We need to enter this into our application - to do this we go into the properties of the Azure project (under the Roles folder), select the Virtual Network tab, and enable Windows Azure Connect for this project. At this point enter the activation token into the box.
After we save this project we need to change a value in the ServiceConfiguration.cscfg configuration file. Change the following line from
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value=" " />
<Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value="false" />
This setting means that for simplicity we don’t have to set the application up to join a domain when we enable the Azure Connect functionality, which would be the alternative approach.
At this point it is worth checking the web.config of the application to verify that the web service URL is correct.
The next step is to republish the application to the Azure server. I recommend at this point to delete the old Azure application in the Management Portal and create a fresh “Staging deployment”. This is because at the time of writing there seems to be a small bug with the service definition configuration not getting updated properly.
The Virtual Network section of the Azure Management Portal should now look like this:
We need to group the endpoints together so that they can talk to each other, so to do this click on Create Group, and:
- Enter a name
- Add the PC end point
- Check Allow connections between endpoint in group
- Add the Azure role
You should end up with a screen that looks like this:
You may need to wait a few minutes before it is activated, so be patient if you get an error about the host name not being resolved. After this you should be able to launch the Azure hosted application and convert a document using the Muhimbi PDF Converter Service instance on your local network.
Next post – The Azure VM Role
For my next post I’m going to explore how to host a custom VM Role in Azure, i.e. a complete virtual server, again themed around the Muhimbi PDF Converter Services.