I came across a situation where I needed to change the AppInsights instrumentation key for a bunch of web apps that one of my client has. We wanted to have all the web apps to have the same AppInsights instrumentation key, so I figured that it would a good use case for Azure CLI. I could have just copy pasted the values for every app using the Azure portal, but there we’re many apps, and I’m stubborn!

In order to add or update a setting for a web app the command that needs to be invoked is:

az webapp config appsettings set --name $appName --resource-group $yourResGroup --settings APPINSIGHTS_INSTRUMENTATIONKEY=SOME_KEY

If you needed to set more than on setting you could just provide a space separated list of items in the form of key=value

Now that command will set the new key in the desired webApp….. but I have a bunch of them to update, no way I’m doing all of them by copy pasting this line for every single one of my apps. After some digging in the docs I almost found what I was looking for a command to list all  webaps:

[sourcecode language='powershell' ]
az webapp list [--resource-group]  --out tsv

That will give me a nice list of all the web apps in my subscription. Since I’m not a scripting (apologies for any non-sense I could write), I was kinda hitting a wall… I can display a list of what I need but how the heck can I loop through that list and set that setting. Well it turns out that I could just declare a variable to capture the output instead of having it display on the screen. So after some tweaking this is what I ended up with:

[sourcecode language='powershell' ]
 $webApps = az webapp list --query "[].{ name: name}" --out tsv
    $resGroup = "sharegate-ops-$env"
    $webApps | ForEach{
        Write-Host "Updating $_"
        az webapp config appsettings set --name $_ --resource-group $resGroup --settings APPINSIGHTS_INSTRUMENTATIONKEY=SOME_KEY

And that was it, all my webapps we’re updated, there is a massive amount of scripts samples and explanation on the Azure CLI docs and I would suggest looking at it every now and then

[sourcecode language='powershell'  padlinenumbers='true']
az webapp config appsettings set --name $appName --resource-group $yourResGroup --settings APPINSIGHTS_INSTRUMENTATIONKEY=SOME_KEY



We are currently in the process of moving our entire infrastructure to a different region in Azure. When we first started no datacenter were available in Canada (East), so we went with an hybrid stack Website in Azure (US-East) and a Virtual Machine hosting our DB in the required province. We had an OK experience, but some errors occurred once in a while. With the new datacenter being up and running for a while now in Canada, our client has decided to make the move


Previous Production Setup:

Current Production Setup

We have, of course, already sent out a maintenance email to our clients in order to NOT disrupt their work. Our full infrastructure is created using custom ARM templates and we have everything in place to move our data.

We wanted to do most of the operations before the planned shutdown, some were easily done while others demanded some investigation or just had to be done when the old production was down and the new one was up.

I was responsible for the DNS, Domain Name (in Azure) and SSL, you know the fun ones!! It turned out OK in the end, besides the SSL config from Let’s Encrypt everything else was done prior to the maintenance window:

  • TTL of our site was lowered to 10 minutes two days prior
  • Registered the domain name in our new production site using TXT entries
  • Added the Let’s encrypt extension in the new production while copying the correct values in my Application Settings

Like I mentioned the SSL config using Let’s Encrypt with the extension will generate a certificate once it communicated with the site for which the cert is required, in our case that was already setup and traffic was already transferred to https so that had to wait until the new prod was up anyways.

Production DOWN

Once the production site was taken offline everything else went almost smoothly (it never does). The cert was installed by running the extension, the TTL was increased as well as redirected to the proper AppService, and we just went our merry way.




So you are all setup with your production website using continuous deployment from your master branch and everything, but you are still stuck with this <yourappname>.azurewebsites.net URL and would now like to have it use your well thought of custom domain name. It’s fairly easy provided you have access to your DNS registry.


Brand new website

When your site is new it’s pretty simple:

  • In the Azure portal in your website blade:
    • Click on custom domains then Add hostname
    • enter the hostname you wish
    • if you click validate now it will fail

In your DNS registry you must now add new CNAME entry that will point from your desired hostname to your <yourappname>.azurewebsites.net once that is done you can now click on validate and your good to go


Existing website without traffic disruption

This one is pretty simple but not much broadcasted. It’s basically the same procedure as a new website, but in your DNS you must add a TXT entry with a value of awverify.<your desired hostname> that points to your <yourappname>.azurewebsites.net. Once this entry has been added in your DNS you can now validate your hostname in azure and it will work. The only caveat is that your website must not be in the same resource group as the one that already exists otherwise you may experience errors when trying to validate the host name.






I know this subject has been covered extensively, but I wanted to do a simple how to, for the fact that it is … simple.


New Azure Website

In Azure when creating a new CUSTOM website, you will find a checkbox at the bottom "Publish from source control"…check it. This will give you the option of choosing your source control provider, after choosing your provider depending, on which on it is (in my case Github or Bitbucket), then select the repository and then you must select which branch you want this website to be on.

That's it!

If by mistake you chose the quick create …no worries goto Existing website.

Existing Website

From the dashboard of an existing website look for "Set up deployment from source control", click it. You will then have to choose which one is your provider, depending on which it is (in my case Github or Bitbucket), then select the repository and then you must select which branch you want this website to be on.

That's it!

Once your website is setup for source control deployment, ANY commit that you do in this repositor/branch will now trigger a deployment of your website.


This Saturday (June 7 2014), I will take part in the azure camp redux hosted by the Montreal .NET community. You don’t need to be a member and the entire camp (a full day with donuts and pizza) is free. We will be focusing on the Web Sites module of Azure. You can register here or go straight to the Montreal .NET community for more info and upcoming presentation