an abstract image of a grid adhering to waves with various spotlights of teal and purple

Sitecore Azure Tips

Ben Golden
Ben Golden

The Sitecore Azure module is designed to remove almost all of the complexity from deploying a Sitecore site to Azure.

It does a good job of it too, as long as you stick to the primary use case: keeping your content management environment on premises and delivery environments on Azure. Once you stray from that things get a bit more complicated. While the module allows you to customize just about every aspect of how it works, there is very little documentation to guide you. This post is a compilation of tips that I have gathered from real-world use of the module and quite a few tickets with Sitecore Support.

How to view log files

If you’re anything like me, one of the first things you will do when you get your first Sitecore role deployed to Azure is check the log files. If you try to open up the log viewer application in Sitecore, you will be in for a bit of a surprise.

You can access the logs if you set up an RDP connection to your cloud service instances. Instead of their normal location in the Data folder outside of the web root, you will need to look in the App_Data folder within the web root. However, eventually you will notice that only the most recent log files are present. This is because the VMs that are used for azure cloud services are temporary.

The log files do have a more permanent home. For each region that you deploy a Sitecore role to, the Sitecore Azure module also creates an Azure Table Storage account. This is where you can access all of your log files. You will need a client application in order to access your storage accounts. There are a number of tools available that can help you access your table storage.

If you only want to view your log files, a better bet is the Sitecore Log Analyzer. You will need to follow the instructions in the documentation to enable the Azure module. Once you do, you will be able to read and filter the log files directly from your table storage account. 

Prevent link database warnings in log files

The link database only allows 50 characters in the SourceDatabase and TargetDatabase columns. Under normal circumstances, that is more than enough. However, Sitecore Azure creates very long database names for publishing targets. If the name of a publishing target database exceeds 50 characters, the database name will be truncated when written to the link database and your log files will get filled with warnings when you publish. To prevent this situation, you should keep your project name short when requesting your environment file. I recommend keeping it to 10 characters or less.

Deploy a custom database

Many Sitecore implementations include additional, non-Sitecore databases. These databases could contain anything from user profiles to user generated content to data for other applications that are integrated with the Sitecore sites.

The Sitecore Azure module automatically deploys all of the standard Sitecore databases, but it is not immediately obvious how to get it to deploy a custom database. It’s actually really easy. So easy that my first attempts failed because I was trying to do too much.

When you start a new deployment, select the “More options” link. This will open the Content Editor to the deployment definition. Under the deployment item, expand the Database References item, duplicate one of the database reference items under the deployment and name it the same as the name of the connection string for your custom database. That’s it. Don’t set the Database Id field or duplicate a database item under the SQL node. The module will take care of all that for you when you deploy. 

Share a database between deployments

By default Sitecore sets each deployment up with its own set of databases. However, under some circumstances, you may want to share a database between deployments. For example, a site that gets a modest amount of traffic with both CM and CD deployments on Azure may want to share the core and analytics databases to keep costs down. Similar to deploying a custom database, sharing a database is deceptively simple.

Run your first deployment as normal so that the database you want to share is created. When you start the second deployment, click the “More options” link. This will open the Content Editor to the deployment definition. Under the deployment item, expand the Database References item and select the reference for the database you want to share. In the Database Id field, select the database item created by the first deployment.

Note that you would probably only want to share databases between deployments in the same geographic region. Otherwise, the latency will likely cause performance problems.

Install wildcard SSL

The new Sitecore Knowledge Base site includes an article about how to configure SSL in Sitecore Azure. The instructions tell how to use a self-signed certificate. Maybe it’s just my tendency to over-think things, but I ran into a problem when I tried to apply that to a real wildcard certificate. I assumed that I use “*” as the certificate name, since that is what I entered as the friendly name in the IIS Certificate Request dialog. Unfortunately, doing so causes the deployment to fail with complaints about invalid characters in the configuration XML. The solution is simple. Leave the name attribute alone. As long as you use the same name in all three locations (steps 14 & 15 of the KB article), it doesn’t matter what the name is. Azure actually uses the thumbprint to match up your certificate and the name is more of an alias for use in your configuration XML only.

Prevent module from creating publishing targets

When keeping your CM environment on premises and deploying CD environments to Azure, it is very helpful how the Sitecore Azure module modifies your config files and adds items which define publishing targets for your deployments. However, if you are deploying both your CM and CD environments to Azure, this is rather problematic. It will not be long before the environment from which you are initiating your deployments has stale content and it is far too easy to accidentally publish to all publishing targets and wipe out all of your production content.

Since the publishing targets are only created on your initial deployment, you can go back and remove the database configurations that were added to your Sitecore.Azure.config file and delete the publishing target items that were created.

A more permanent solution is to modify Sitecore Azure’s pipeline configuration so that it doesn’t make these changes in the first place. In the /App_Config/Include/Sitecore.Azure.config file, locate the AddPublishingTarget pipeline and comment out the SaveChanges processor. That’s all there is to it.

      type="Sitecore.Azure.Pipelines.Configuration.PublishingTarget.SaveChanges, Sitecore.Azure" />

Make custom error pages work

After deploying your site to Azure, you may notice that your custom error pages don’t work even though you configured them properly as per usual. Don’t fret, you’re not going crazy. The Sitecore Azure module actually changed your configuration and set CustomErrors=”Off”. This has been registered as a bug in the Azure module and will hopefully be fixed in the next release. For now, you can ignore the “[Do not edit!]” warning on the Global Web Config Patch field on the deployment item and remove the following lines:

<xsl:template match="configuration/system.web/customErrors">
  <customErrors mode="Off" />

You will need to make this edit on each of your existing deployment items. To prevent the problem on future deployments, you can make the same change to the branch items that are used to create the deployments. They can be found at

/sitecore/templates/Branches/Azure/Azure Cd Deployment/Deployment Cd and
/sitecore/templates/Branches/Azure/Azure Ce Deployment.

Let's Get Started

We'd love to hear from you. We probably have a lot in common. I mean, you like chatting about data-binding, UX patterns, and javascript functions, right?


Cookies help us improve your website experience. By using our website, you agree to our use of cookies and our privacy policy.