Adding custom domain names to Azure CDN

The Azure CDN (Content Delivery Network) service is a pretty awesome feature which enables you to serve your website content to an end-user from the closest geographical server to them, decreasing load times and cutting down on general internet traffic (which can only be a good thing)!

You can create a new CDN service in just a few clicks through the Azure Management Portal, and you can choose your content source to be Azure Blob Storage, a Cloud Service, a Web App or a custom source.

One great feature I’ve discovered with the Azure CDN service recently is the ability to use a custom domain name! So if I wanted to serve all my blog images through Azure’s CDN service using a custom domain such as I can do that!

First you have to set up your domain name in your DNS server. So set up a sub-domain such as and create a CNAME record, pointing to the Azure CDN end point you just set up. This will be something like and should look a bit like this when set up:


Once you have set up your domain name record, go back to your CDN service in the Azure Portal and click on the “Manage Domains” icon at the bottom of the screen. You will see a screen that looks like this:


Simply add in your custom domain name and Azure will attempt to verify it by ensuring the CNAME record is indeed pointing to the CDN endpoint Url. If everything is good, you should see a green tick next to your domain name. If you don’t see the green tick, then you’ve done something wrong with your domain name setup. Go sort that out and try again.


Once you click the ‘OK’ tick on this screen, Azure will do what it needs to do in order to set up that custom domain name on your CDN service.

The only other thing you need to do is have a bit of patience – it can take a while for these changes to kick in, and you might get 404 errors when you’re trying to access your CDN-ed content through your custom domain name. Go have a cup of tea, or two cups of tea and then try again.

Tagged with: ,

Manually trigger a database update after upgrading Umbraco

So here’s the scenario. You’ve just upgraded Umbraco in your development project to the latest version using NuGet (because why would you do it any other way?). You’ve built the solution, you visit the website and see this screen:


You click ‘Continue’ (and then immediately wish you had taken a backup of your database before you clicked that button, because that’s what good developers should do!) and Umbraco goes off and does some database bits and bobs behind the scenes before redirecting you back into Umbraco. Yeay it worked!

You click around a bit, publish a few items here and there, and you’re now ready to deploy your updated Umbraco installation to your staging and production environments. But how can you trigger that database update process again because it’s already happened? There has to be a secret command or spell you can use to initiate it, but you can’t remember for the life of you what it is (and it’s actually quite difficult to find the answer from Google too!).

So here’s how to do it in 2 easy steps:

Step 1 – ensure you have the umbraco/install folder present in the environment you’re updating. Of course we all know that it’s bad security practise to have this folder in any public-facing Umbraco installation, so please remember to remove it once your update has finished. (Oh you didn’t know that? Well, now you know – you can impress your friends with this new found knowledge!)

Step 2 – open up the web.config file of your Umbraco website and look for the key called “umbracoConfigurationStatus”. It should look something like this:

<add key=”umbracoConfigurationStatus” value=”7.2.6″ />

The value in this case is the version that you just upgraded to.

Decrease this value by 1 so it looks something like this:

<add key=”umbracoConfigurationStatus” value=”7.2.5” />

and that’s all you need to do.

Deploy your Umbraco codebase to your staging or production environment, and you will see that same upgrade splash screen. Click the ‘Continue’ button, promise yourself that next time you really will take a database backup before clicking that button, and let Umbraco do it’s magic.

Once the update is complete and you’re back in the Umbraco portal, look at the web.config file again and you will see the version number has been incremented back up to the current installed version.

P.S. after tweeting this article and before I even managed to get a cup of tea, Sebastiaan Janssen (Project Manager at Umbraco HQ) replied with some further info on this. I’m not going to re-write this article though as my cuppa is going cold, so here’s Sebastiaan’s tweets with that info:


So effectively you only have to worry about triggering this database update when you do minor version upgrades, and you don’t have to worry about it at all after version 7.3!

Tagged with:

New things I learned today part 2 – Azure WebJobs ignore app.config transforms

I recently posted a two-part article about getting started with Azure WebJobs and was raving about how awesome they are.

In a WebJob I built for my current project (which is about to finish so contact me if you want me to work on your awesome project) I set up some app.config transforms which contain a couple of entries – one for the database which my WebJob is saving data to, and another for the Message Queue that triggers my WebJob. These are different for dev, staging and live as you would expect.

So the “new thing I learned today” is that they’re not as totally awesome as I first thought – when you publish your WebJob to Azure, it process totally ignores app.config transforms! It’s not just me “doing it wrong” – there’s others out there that have reported the same thing like this dude and these dudes.

So until this functionality is added to the Azure SDK you will need to either manually edit your app.config file before publishing it to different environments, or come up with some hacky code to work around this issue.

Tagged with: , ,