It is easy to overlook the good old TIFF format when developing applications as it has been eclipsed in the recent years by more modern, browser friendly, image formats such as JPG, PNG and GIF. However, there are a number of scenarios for which TIFF is still widely used, particularly because a single TIFF file can hold multiple pages.
Two of the more popular uses for multi-page TIFF files are the scanning of multiple pages into a single file and the reception of multi-page faxes. As these kind of document management scenarios are very common, particularly with our SharePoint customers, we have decided to add native support for this format to our popular range of PDF Conversion products.
The key features are as follows:
Convert multi page TIFF files to a single PDF file.
Automatic page size detection.
Compatible with PDF/A.
Supports all TIFF formats recognised by the underlying operating system.
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.
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
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.
As you may be aware, SharePoint’s native auditing capabilities are somewhat limited. You may, with a lot of effort, be able to track that an item has been changed (by Item ID, sigh), but there is no way to find out which field has been changed and what the old or new values are.
Sure, you can enable ‘Version History’ on a list, but that only provides a little bit of detail, must be enabled manually on every list and the details cannot be queried as part of an Audit Report.
As tracking field level changes is rather useful, we have decided to add it to the core product and treat it the same as any other audit even type, resulting in the following advantages:
Auditing of this kind of information is automatically enabled when a Site Collection or list is created. There is no need to manually enable it.
Field changes are automatically included when the audit logs are queried or reports are generated, including all filtering and pivoting options.
So, if you are familiar with the product then it all works like any other audit event type. You specify either at the Farm, Web Application or Site Collection level that you want to track the Field Change’ event type and the system sorts it all out for you.
Once enabled, all field level changes are audited automatically. See the following screenshot for an example that shows a single audit entry for a change to the standard Task List.
When generating a full Audit Report all changes are grouped together as follows (Click to enlarge)