Since we’re using ARM style provisioning and Sitecore deployments for a while now at Colours, it’s time for an update. First of all, because there were some changes per Sitecore 8.2 Update 3, and secondly, because we have improved our scripts and want to share a few learnings.

Check out the new scripts and templates at my GitHub repository Sitecore-Azure-Scripts!

Updated to Update 3

The smallest improvement is that I have changed the folder structure and naming slightly, to make it more self-explanatory, and to be ready for future updates. Then I updated all scripts to be used with Update 3. Mind that I did not use the 8.2-3 Sitecore templates as a starting point, and thus still not use the nested template style. I’m working on that. What I did do is update the API versions of all the resources being used, for which I have added extra parameters accordingly, to match the requirements of 8.2-3 (and up).

IP Whitelisting

Another small change, is that I have removed the manually added IP whiltelisting to the XP0 setup. I thought it would be useful, but it turned out to be confusing, needing changes to the stock SCWDP files, and more time consuming to maintain on updates. Besides, we still use IP whitelisting via config files from within our solution, translated per environment, so there wasn’t any need to mess with the default setup anyhow.

Which brings me to a very important finding:

adding IP security to your Sitecore web app may cause functional issues!

You can no longer visit your own local website, because frankly, there is no such thing as visiting your site locally as it was on conventional Virtual Machines or physical servers. When you visit your own web app hosted site, your visit will come from the outgoing IP address of your Azure region, which obviously doesn’t get through to your white-listed site. There are two occasions we discovered where this bites: the Sitecore Device Viewer does a local HTTP Request (thanks Kam!), and our own custom search crawler logic (based on either Lucene, Solr or Azure Search) does a local HTTP Request. The solution would be to add the outgoing IP of your Azure region to your whitelist, but this basically renders it useless (everyone hosting on the same Azure region can now access your website). In the future I would prefer to arrange access to secured Sitecore sites or Content Management instances via Azure Active Directory, maybe in combination with whitelisting. But that’s a whole different story…

Cleaning up scripts

Less PowerShell is more

Based upon a good suggestion from my colleague Anton I moved all login logic to a separate Powerhell module. All PowerShell scripts within my repository included the exact same logic (based on the example from Sitecore) and more annoyingly, all of them contained the exact same local variables to configure the Subscription ID and all the Service Principle settings. So this has been moved to one central file, being easier to maintain and cleaning up all my other scripts by simply logging in like this:

Accordingly, I did the same with the ConvertPSObjectToHashtable function.

Added README files

Because I like to receive suggestions and, ultimately, Pull Requests, I have added README files to all available setups. As Kam pointed out, for the double setup I created as an addition to the Sitecore template examples, it wasn’t clear I had used an XP0 Single SCWDP for the CM role, combined with a XP1 CD SCDWP for the CD role. I’ve copied this note into the new set and created a place for possible additional future instructions and remarks.

Cleaned up ARM parameter files

Also based on Kam’s PR (which was aimed at the double setup only), I now have removed all Mongo connection strings from the msdeploy and redeploy parameter files of all setups, since they were superfluous. Those values are actually being populated from the output parameter object of the first infra script, not by the parameter files. Furthermore, the reporting authentication API key has been removed from all infra scripts, as this value is only used upon application (re)deployment.

Key Vault support

Rickard Andersson has added Key Vault support to my scripts, which basically replaces the logic to add additional parameters to the hashtable, by checking if the parameter is a reference to a Key Vault secret and if so, retrieving the value of the secret. Because this requires you to be logged in into your subscription, the hashtable build up logic is moved to below the logging in.

You can now either use the conventional plain text parameters as well as safer key vault secret references when using the ARM templates.

Stability issues?

This article is worth sharing in this context: if you experience stability issues as described in this knowledge base article https://kb.sitecore.net/articles/983839, make sure to disable the \wwwroot\App_config\Include\Sitecore.Diagnostics.config file and add an App Setting for the impacted App Service with the name WEBSITE_DYNAMIC_CACHE and value 0.

If you would like to incorporate this setting into your scripted deployment, alter the infra ARM template like so:

But judging by the article, you might be better off by adding it manually via the Azure Management Portal, because it is only necessary when you actually experience issues, and it hopefully is a temporary solution too. That’s why I left them out of my boilerplate templates for now.

Rounding up

All in all, I now have a much cleaner and better structured set of scripts, easier to understand and to maintain, suitable for being used with Update 3.

I would like to thank Kam Figy, Rickard Andersson, Anton Kuryan and Valentin Shenderov for their testing, contributions and support!