Press enter to see results or esc to cancel.

Sitecore Azure scripts update

My colleague Anton Kuryan revamped my Azure scripts, removing duplicate code and adding several new features.

Check out for the latest version!

One parameterized PowerShell script

When I first wrote these scripts, I used the Sitecore templates as a starting point, creating multiple folders for the different setups single, double and full (referring to the amount of separate server roles). To be able to run each setup independently I never combined the scripts, but as time passed by, it turned out we used the scripts more and more as a combined set, like single for the test environment, double for acceptance and the full setup for production. Hence, it made sense to remove duplicate code and combine the setups into one parameterized script. Anton did this wonderfully, so now the multiple folders only contain ARM scripts and the PowerShell script is centralized.

Removed hard-coded authorization

The hard-coded Service Principal based authorization originally present in the Sitecore template was also used in my code. However, despite being easy when running locally, it isn’t required when running the scripts from VSTS, because the Service Principal is configured in VSTS already and any PowerShell script will run pre-authorized by it anyway. Besides this, having your service principle ID, password and tenant ID  in your repository renders your KeyVault useless, exposing critical keys to everyone having access to the repository. Our best practise now is having a separate authorise file locally which you can add in your .gitignore file, so it won’t be exposed or distributed.

Automatic SAS generation

Previously, I just manually generated a Shared Access Signature (SAS) and concatenated it to the package URLs within the JSON parameter files. The disadvantage of this is, that this signature will expire (if configured correctly), and needs to be replaced manually at some point in time, possibly surprising the development team with a sudden deployment failure. Anton wrote a function to generate a SAS automatically at runtime, with a rather short validity. If the storage account automated or manual rotation is in place, as suggested by best security practices, the DevOps team or system engineer doesn’t have to update the SAS anymore in either configuration or KeyVault after a key rotation. This makes the process fully automatic and even more safe, because the SAS validity (duration) can be very short.

More to come

We’re currently working on an 8.2 update 6 script & template set for the latest Sitecore 8.2 version, and will probably add Sitecore 9 scripts to it once we run that in production as well. So keep an eye out for any updates, or drop me a message if you have a specific question, request or suggestion.


Comments are disabled for this post

Rob Habraken

Software Engineer, Technology Director, Senior Consultant, Sitecore MVP and overall technology addict. Specialized in web development, Microsoft technology and, of course, Sitecore.

Check out the iO tech_hub, our company tech blog with developer oriented articles about all aspects of web development and digital innovation.