Blog

Azure Sitecore Deployment: Preparing the Default Scripts and Packages

July 17, 2017 | Charlie Turano

This is the second in my series of blog posts on Sitecore deployments on Azure. The other posts in this series can be found here:-

Part 1: Setting Up the Solution and VSO Build
Installing Sitecore in an Azure environment can be complex due to the large number of options available to the user. I chose to use the XP environment (the most complex) with the lowest settings. This was done purely for research purposes, other environment configurations should work well with minor modifications to the scripts included here. This post goes over preparing a default setup for a Sitecore Azure deployment. Later (in the next post) we will be extending this to add a custom module to the install.

Azure Deployment Package Storage

The Sitecore Azure packages and Azure templates need to be stored in an online blob container so the deployment scripts can access them. The arrangement of the azure templates is dependent on relative paths, so it is important to follow the exact procedures in this post.

Sitecore Components

The first set of files to upload to blob storage are the Sitecore deployment files. These should be located in a single folder. I called my storage container sitecore82u3:

Azure Sitecore Deploy Sitecore Assets

The Sitecore 8.2 rev. 170407_cd.scwdp.zip, Sitecore 8.2 rev. 170407_cm.scwdp.zip, Sitecore 8.2 rev. 170407_prc.scwdp.zip and Sitecore 8.2 rev. 170407_rep.scwdp.zip packages are the default packages from Sitecore. They can be downloaded for any particular Sitecore instance from that version's download page (i.e. you can find the packages for Sitecore 8.2 Update 4 under the 'Download options for Azure AppService' section)

These files contain the full Sitecore installations, and should be stored in a non-public blob. This means you will have to use the Azure Storage Explorer to create a shared access signature for each file. The full URL's for each file with the shared access signature should be added to the appropriate location in your azuredeploy.parameters.json file. An example file is included in our GitHub.

Note: The _nodb and _Bootload packages seen in the image will be discussed later in this blog post series. They will not yet be needed for the default setup described in this post.

Deployment Scripts

Additional Change Required for Sitecore 8.2 Update 4 (rev. 170614)

When testing with Sitecore 8.2 Update 4, we found that the deployment failed with the following error: "message": "Package deployment failed\r\nAppGallery Deploy Failed: 'Microsoft.Web.Deployment.DeploymentClientServerException: Missing source parameter 'Social Link Domain' (Social Link Domain). This must be set for successful synchronization.

As it turns out, there is an additional parameter in the deployment package, which is not referenced in the parameters. Bas Lijten pointed out to me that to fix this, you can either manually add that parameter to the ARM template, or rebuild the Web Deploy Package, removing the parameter. We opted to add it to the ARM template, passing in a hard-coded value. The following was added to the nested/application.json template file, for the CM deployment (the parameter is only required on CM for the xp setup) "Social Link Domain": "http://mywebsite.com/" The updated version of this file can be found on our Github repo. Within there we currently hard code the domain used by the Social Connect module....but you can modify it to read from parameters if you like, passing in a correct value. For now, the hard coded value gets us past the deployment issue, so grab the file and rename it to application.json, overwriting the default one that comes from Sitecore's repo. (it's a copy of the files from Sitecore's repo with the change above added, is up to date as of the 13th of July, 2017).

Uploading the Default Scripts

One of the problems we ran into building our deployments for Sitecore 8.2 update 3 (using v1.1 of the Sitecore Azure Toolkit) was that the scripts and templates needed to be referenced via a URL instead of the local file system. The 8.2 update 1 scripts (with v1.0 of the Sitecore Azure Toolkit) worked fine if they were on the local file system, but the newer method did not. This initially caused us problems because certain scripts needed to be stored in specific folders relative to other scripts and the shared access token got in the way of constructing the urls.
Deployment Scripts: Option 1 - Give public access

Our solution to this was to create a public blob storage container called sitecore and store all of the scripts in there. Since it was public, no shared access token was needed and everything worked correctly.

This was the option we went with....being the easiest to setup. You can see an alternative to this method further down the page.

The default ARM templates need to be uploaded into a storage container. Download the default ARM template scripts from the Sitecore GitHub repository. These scripts need to be uploaded into the sitecore Blob Container into a folder called xp. Everything in the /Sitecore 8.2.3/xp folder from Sitecore's default repository should be uploaded to the xp folder in the storage container.

Azure Sitecore Deploy Upload Azure Templates Blob Storage

Finally, grant public access to the container by right clicking it, and selecting 'Set Public Access Level...'. Grant Public read access for container and blobs, and click Apply.

Azure Sitecore Deploy Set Public Access Level

Deployment Scripts: Option 2 - Give a single SAS to the entire templates container
An alternative way of granting access to the ARM templates is to grant a Shared Access Signature on the container (instead of giving it public access), and then set the $templatelinkAccessToken parameter. You can do this by passing in the $templatelinkAccessToken value though the -SetKeyValue argument in your deployment. A full explanation can be found here. Now you have the ARM templates in a storage container, and the packages also in a container, this should be everything you need to install the default XP instance in Sitecore Azure.

Preparing your local PowerShell Environment

Be sure to prepare your local PowerShell correctly. Open PowerShell using Administrator privileges, and make sure you have the appropriate prerequisites installed/prepared. Be sure to install the Azure and AzureRm modules. Install-Module Azure -AllowClobber Install-Module AzureRM -AllowClobber

Allow PowerShell to have the correct Execution Policy to run scripts. Set-ExecutionPolicy Unrestricted

Note that once you have the Azure and AzureRm PowerShell modules installed into your system, they are on the local machine....so future attempts won't require you to reinstall it.

Unblock, and Unzip the Azure Toolkit v1.1 to your system, noting the path, which can be pasted into the Install.ps1 script mentioned below.

Running the install script

An install script called Install.ps1.example has been included in our GitHub. This will need to be renamed to Install.ps1 and modified slightly to contain paths to your Sitecore license file, Sitecore Azure Toolkit and the ArmTemplateUrl described above. If you went with Option 2 for getting the URLs for the ARM templates, you may also need to modify the script to pass in the appropriate parameters as well. Once the file has been modified, update your local azure.deploy.parameters.json file with your blob storage URLs (to the CM, CD, PRC and REP packages), and Mongo connection strings (you can setup some free ones using MLab. You also need to update the other parameters with usernames/passwords as you wish, as described here.

Save the file, and run the Install.ps1 script from PowerShell. It will prompt you for credentials and create your default environment. After about 20-30 minutes, you will have a working, default Sitecore instance.

Next we will look into adding custom modules to our install process! Catching up? Check out Part 1 of our series, or read the complete project on Github.

Azure Sitecore Deployment Development

Related Blog Posts

TDS Classic Best Practices: Validators and the Sitecore Package Deployer
TDS Classic can be used in many ways, but the goal is always the same: make development (and developers lives) easier. Whether it's using the Sitecore Package Deployer or using validators, following best practices can make your entire experience run much more smoothly.
Azure Sitecore Deployment: Setting Up the Solution and VSO Build
<p>The first in our series on setting up a Sitecore instance on Azure, with an initial deployment that includes custom built modules as add-ons to the setup.</p>
Troubleshoot and Prevent Failed TDS Classic Project Builds
When building an .update package with TDS Classic, the build might fail with no additional information. From increasing log verbosity to using validators, there are ways to minimize or prevent this type of error.
TDS Classic How-To: Disable Automatic Code Generation
Code Generation is automatically triggered after every change in the TDS Project tree. If a project contains many items, users can disable this feature for their convenience.
TDS Classic Sitecore Deploy Folder
Sitecore Deploy Folder is a setting, located in the build tab of the TDS Classic Project's Properties page, and used to tell TDS Classic where the webroot is located.<br>
TDS Classic Builds on Jenkins Build Server with NuGet Packages
Our simple scenario includes 2 developers using TDS Classic and checking-in changes to source control. The Jenkins build server takes the changes and performs the build, and then deploys the created package to two Sitecore environments.
Features to Improve Sitecore Development: TDS Classic Strikes Back
Each and every feature in TDS Classic is aimed at helping developers. Whether the feature is out front or running quietly in the background the goal is always the same: make the development experience better. &nbsp;&nbsp;
Feydra and the Virtual Sandbox
Feydra virtualizes all front end assets (css, js &amp; cshtml) of a Sitecore instance. With Feydra, front-end developers can commit their changes to Source Control without requiring the intervention of a back-end developer. We call it a virtual sandbox.&nbsp;
Feydra Frequently Asked Questions
Answering a number of excellent questions we've gotten from the community regarding Feydra, including how long it takes to set up a Feydra environment and how to install the product.&nbsp;
TDS Classic Features to Improve Sitecore Development
Each version of TDS Classic comes with the same goal: to make Sitecore development and, by extension, developers, lives easier. Every feature in our products is aimed at making the process better - some of these features aren't quite as well-known as others, but they all help smooth and improve the development experience.
Deployment Properties and the Deployment Property Manager
When working with TDS Classic, you will eventually need to deploy your items to a Sitecore instance and you might not want the default behavior of every item in your TDS project deploying every time. This is where the TDS Sitecore Deployment Property Manager comes in!
Feydra: A Front-End Assessment
Feydra allowed me to start building the front-end in a very short time with no Sitecore experience, and it let me use tools that I was comfortable and familiar with.
Feydra: A Quick Start Guide
A step-by-step guide for installing, configuring and, most importantly, using Feydra from the front-end.
TDS Classic 5.6 Feature Spotlight - Prevent Deployment of Incorrect Assemblies
This feature, new to TDS Classic 5.6, will prevent a solution from deploying unless all assemblies (except the excluded assemblies we allow you to specify) match what exists in your webroot.&nbsp;
Feydra from the Front-End
Feydra eliminates common roadblocks for designers and front-end developers working on Sitecore projects by getting them up and running more quickly and allowing them to use the development environment and workflow tools they prefer.&nbsp;
TDS How To: Install the TDS Connector for Rocks 2.0
Manually install the TDS connector for Sitecore Rocks 2.0
Using NuGet Packages in TDS
New to TDS 5.5 is the ability to create and consume NuGet packages in your TDS project, allowing developers to capture their Sitecore items and easily distribute them across multiple teams.
Occasional Issue Seen with TDS Installer
When upgrading to TDS 5.5.0.x from an older version and trying to load a solution with a TDS project inside, the following error might occur:
TDS: The Evolution of Auto-Sync
Auto-Sync has been described as a new feature, but in reality has existed in TDS since 2010 and has taken a new form in TDS 5.5, due to be released March 22, 2016
TDS for SC Hackathon 2016
For all those participating in the Sitecore Hackathon, check out our Habitat for TDS and some other cool surprises.
Config Transforms for Config Files
If you don't want to use a third party development tool for your config transforms, I have good news. Config transforms are supported natively within TDS!
Package Installer from the Command Line
The TDS package installer allows you to install packages through the command line. Learn how...<br>
New Build for TDS 5.0!
A couple bugs were reported over the last few months. We've been able to fix the bugs and now have a stable CTP version for use.
It's finally here!
Team Development for Sitecore has finally been released go download it now!
Team Development for Sitecore Webinar
Our Sitecore MVPs Charlie and Sean recently did a demo of TDS to all Sitecore partners. We recorded the demo to share with the world.