Installing SOLR

As we all probably are aware of by now, Sitecore 9.x requires on SOLR OOTB (of course, you can change this). There’s a load of blog posts on installing SOLR, but I ran into a couple of additional issues which no-one else seemed to have run into, and weren’t as easy to debug. I figured I’d share ūüôā Continue reading


Demystifying Sitecore’s licensing

Before I start: Sitecore’s licensing model changes occasionally, so it is always recommended to check in with your Sitecore sales representatives or your Sitecore contact.¬†As a partner, you can find who your Sitecore contact is (and get their details) by logging in to Sitecore’s Partner Network. As a customer, you can talk to your Sitecore account manager. Continue reading

Getting Sitecore VM to IaaS

Before letting you go on to the contents of the blog post, I’ve had this one in my draft for quite a while but figured I should finish it. Yes, we can use Sitecore on PaaS these days as well (which is great), but I feel like the info in here is still useful as IaaS is still alive and kicking! Anyway, without further ado:

Do you have a Sitecore Virtual Machine (preferably in Hyper-V), and do you want to get your website to Azure? In a rush to get there? Well, you might be in luck!

Continue reading

Sitecore on Azure‚Ķ With Unicorn

I’ve been trying to get our internal demo website running on Azure, and have it deployable in a very easy manner. Provisioning Sitecore onto Azure is really easy these days, and the code itself is also easily deployed to my environments (see these previous posts for more information).

The issue I was having was with Unicorn ‚Äď or more specifically the locations of my data folder. On my local machine, I have Sitecore running in a specific location, and can simply point my Unicorn to a specific location on my machine (i.e. c:\development\demo\data\unicorn). Since all my colleagues working on the projects have the same file structure and we never have to deploy to an actual server that works perfectly.

However, I’m now adding a new deployment server to the mix, with a different file structure. I can’t simply use the same path as it might not exist there. Continue reading

Automatically scale Sitecore on Azure PaaS

Since Sitecore 8.2 update 1, we can simply scale our App Service plans up or out. You can find these options on the App Service Plan as well as the App Service themselves.

Scaling up means selecting a different tier for our subscriptions – more RAM and cores for instance.


As you can see, I’m currently running on the S1 tier – which I can’t recommend to anyone as it’s quite slow (of course, it is way below the minimum specs found in the installation guides)…

Our other option is to scale out. That means we can add (or remove) a number of instances¬†based on… something. Let’s take a look.

Continue reading

Application Insights for Sitecore (or, where have my logfiles gone?)

With¬†Sitecore’s new Azure PaaS offering, you might’ve noticed in your Azure resource group that there’s an Application Insights resource there.

Application Insights can be used to monitor the live web applications and helps with diagnosing issues and figuring out what users are doing with your app. More information here.¬†Application Insights is quite a big and powerful tool, and I won’t be able to cover everything juts quite yet. I will however run through some of the cool features. Continue reading

Deploying code to Sitecore on PaaS

Now that we have our Sitecore environment on Azure PaaS, lets get some code on there!

I’m going to use Visual Studio to deploy my code, in the same way we can publish code locally to the website if we’re not working in the web root of the project. Of course, you can have your deployment process fully automated using things like FTP, PowerShell and more.

In the Azure portal, I can¬†select the server I’d like to deploy to and select the ‘…More’ option to be able to download the PublishSettings file.


Little side note, if you wanted to upload your code through FTP you can get the username and password to use from the PublishSettings file as well – just open the file in your favourite text editor.


All details required for the FTP connection are there. Also, if you were silly enough to put your username and password on the Internet, you can reset your publish settings by going going back to the Azure portal and in the server blade select the ‘Reset publish profile’ options.

Back to deploying our code through Visual Studio: We now can open (or create) our solution in Visual Studio and select ‘<New Custom Profile>’ in the Publish dropdown.¬†Just give the profile a name, go back to the Profile button and select the ‘Import’ option. Here, you can select the PublishSettings file we downloaded earlier.


At this point you’ll get an overview of the connection Visual Studio created for you, which we can then validate.


Now all that’s left is to click the Publish button, and we’ll have our Sitecore environment all up-to-date with the latest and greatest code!

Awesome. So now I have my code online – but oh no, an error. How can I debug this, when I just get a simple yellow screen? Well, first of all you could dive into the logfiles to get some more information. In addition I could turn off remote errors, but neither of those might actually tell me what’s happening within my code. What I’d really like to do is to start debugging. This first needs to be enabled in the Azure portal. You can find it in the Application Settings¬†of your app service.


Simply set Remote Debugging in the Debugging section to On, and set your Remote Visual Studio version to the version you use. Alternatively, Visual Studio also asks if it can enable remote debugging if you skip setting  it manually.

Then all that’s left is to publish your website with the Debug Configuration. In your Server Explorer in Visual Studio you can then right click on the Azure website and select Attach Debugger. The browser will then automatically open to the home page, so you might have to browse around a bit to find your error page :-).

Don’t forget to deploy your code using the Debug profile rather than the Release profile if you do want to debug.

PS. If any of your code has a dependency on the data folder, it has set it to the /App_Data folder by default.


It has been pointed out to me that we don’t actually need to download the publish settings from the portal. Instead, when creating a new Publishing Profile, click the ‘Microsoft Web Apps’ publishing target. Sign in the pop up window, and there’s an option to select a web app (or create a new one)


Getting started with Sitecore on Azure PaaS

So now that Sitecore 8.2 update 1 has been released, we can finally stop using the Sitecore Azure module and go use the true power of Azure PaaS.

Be aware that at this point in time Sitecore only has an XP1 and XM1 delivery using the Azure Resource Manager (ARM) templates Рmore on ARM here Рand XM1 only on the Azure Marketplace. Keep your eyes peeled for further updates on this, as other options will be released.

Before we get into this, make sure you have the following installed on your machine:

By now, you should have downloaded the ARM templates for Sitecore – or alternatively you can also use the Azure Marketplace to install Sitecore on Azure as well, so lets see how this works.

First of all, Sitecore’s ARM templates will not¬†create the MongoDBs for us, so we need to¬†start by getting that set up. I’m going to use mLab‘s free Sandbox tier¬†for that in this blog post, but feel free to use other options (such as the xDB Cloud offering by Sitecore themselves).


At the moment of writing I can’t select Azure’s West Europe (Amsterdam) location, as mLabs¬†does not provide a single node there (the only option that’s free).


I’ll need to create the database for each of the MongoDBs. After the creation of¬†my database is complete, I just add a user to each as well and copy and paste the connectionstring it’s giving me into the appropriate xX.Template.params.json file. In this file, I need to change:

  • The connection strings to all 3 MongoDB connection strings: analytics, tracking_live and tracking_contact – these need to be set to the correct connection strings given to us in the mLabs overview
  • sqlserver.login – the username for the sql server user. This user will be created in the databases automatically
  • sqlserver.password – the password to use for the user created (make sure this has 8 or more characters or an error will be thrown)

Lastly, I need to update the PowerShell script Run.ps1 to use the correct parameters. I need to set the following options:

  • $ArmTemplatePath – needs to be set to the correct xX.Template.json file location
  • $ArmParametersPath – needs to be set to the file location of our updated .params.json file
  • $licenseFileContent – this needs to point to a valid license.xml file
  • $Name – the name for the deployment
  • $location – the¬†Azure region to deploy in. A good overview can be found here, including which functionality is or isn’t available in the region.¬†Make sure the region you select supports Azure Search – not all of them do.
  • $AzureSubscriptionId – Your subscription ID to use for the deployment. You can find this in the ‘Billing’ blade in the Azure portal.

As an additional (optional) change, one¬†could set up a principle service and use that.¬†I just want to get up-and-running ASAP, so I’ll take the manual login option instead for which I don’t have to make any changes.

I also noticed that in my xP1.Template.json file the Application Insights were set to the location of “Central US”:

  "type": "Microsoft.Insights/Components",
  "name": "[variables('appInsightsNameTidy')]",
  "apiVersion": "[variables('appInsightsApiVersion')]",
  "location": "Central US",
  "properties": {
    "ApplicationId": "[variables('appInsightsNameTidy')]",
    "Application_Type": "web"
  "tags": {
    "provider": "[parameters('sitecoreTags').provider]"

That’s technically fine, but I’d rather have it in¬†the same region as my other resources, so changed the “location” line to the following instead:

"location": "[variables('resourceGroupLocation')]",

Of course, you’ll need to make sure that¬†location supports the Application Insights.

After this I’m all set so I can run the PowerShell Script. It is at this point that you can safely go get a cup of tea, as this will take a little while. In fact, my deployment took 23 minutes and 49 seconds.¬†I didn’t bother moving the blobs used to install Sitecore in my own data center so I could’ve had an even faster deployment – but just under¬†24 minutes is still pretty impressive, no?


Improving the usability of Sitecore’s bucket facets

My dear colleague Steve McGill pointed something out to me I never noticed before. However after noticing it I could not help but be extremely bothered about it.

A true case of:

what has been seen

(I might or might not be exaggerating just a tad here)

In any case, I’m talking about the search facets when searching for bucketable content in the Sitecore Content Editor:


So far so good. Lets select a couple of facets.


It’s still not too bad – but now imagine if we’ve have multiple custom facets selected¬†– especially booleans. The facet, when selected, would just say ‘0’ or ‘1’ – but we don’t know which facet this would be.


This is definitely less useful… So how can we make this more useful? The file that we’d be interested in changing here is webroot/sitecore/shell/Applications/Buckets/Scripts/ItemBucket.js.

A quick fix might be to change one line of code in that JavaScript. In line 263 (on Sitecore 8.1 update 2 at least) the line is:

facetList += '<li class="filter"><a href="javascript:void(0);" onclick="javascript:RemoveFacet(\'' + this.value + '\');" title="' + escapedText + '" class="facetClick facetClickSelected">' + innerText + "</a></li>";

Which we can change to (I’ve added the bold for emphasis):

facetList += '<li class="filter"><a href="javascript:void(0);" onclick="javascript:RemoveFacet(\'' + this.value + '\');" title="' + escapedText + '" class="facetClick facetClickSelected">' + this.value.split('|')[0] + ':' + innerText + "</a></li>";

‘this.value’¬†is simply the field¬†name Sitecore facets on.¬†I added ‘.split’ as well because it passes the value in there as well (so for English language facet it would pass ‘culture|en’).


This isn’t flawless either, since the ‘Author’ facet is using¬†the ‘parsedcreatedby’ field in the index. If we wanted to change anything there we’d have to change the AppendFacet method in the same file to take in the display name of the facet as well (rather than the field).

One¬†big consideration to keep in mind here is that we’re overriding a Sitecore file, which of course might change with future updates in Sitecore, so use with caution.