I have seen in few instances deployed on Azure PAAS an issue with recompilation leading to the app pool restart…
my recommendation for the <compilation> tag in the web.config is to add the following attribute numRecompilesBeforeAppRestart=”100″
this attribute will prevent restarting when it reaches 10 recompilations (note that 10 is the default value in case you do not specify it)
Note that hosting your instance in Azure PAAS I have seen this issue in several instances…
I have seen few Sitecore instances deployed on Azure having issues with the filesystem watcher forcing the instance to restart, however in my experience file system watchers are not very useful since code got change only within the deployments…
Best way to ensure if you are experiencing any issue is to check your Sitecore logs and find the reason for the restart of your webapp… if the reason for restart points you to the file system changes, I would suggest applying the following patch to stabilize your sitecore instance…
I am not sure if I have been particularly “unlucky” or if that’s going to become a common issue for Sitecore administrators but I found myself in a particular scenario where on the public website AD-B2C was used to authenticate external users and at the same time they wanted to use AD to access to the Sitecore content authoring….
the exact scenario is the following:
http://www.myclient.com –> using ADB2C to authenticate website customers
cms.myclient.com –> using AD to authenticate content authors
investigating the issue, came lear to me that there was an issue with the AD Cookies between the .AspNet.Cookies cookie issued for the CD and the cookie issued for the CM…
note that within the AD provider you cannot really change the name of .aspnet.cookies (or at least it is not trivial to do it…)
the simplest solution that I come up with was to clear this cookie on the Sitecore login page so that I can ensure that Sitecore CMS AD provider won’t be confused with the cookie issued from the CD server…
As you probably know, Sitecore is shipping from version 9.1 with the Identity server….
If you want to integrate Sitecore with Azure Active Directory, this resource will walk you through the configuration step by step:
However once you have followed all the steps, you will have an unpleasant surprise when you discover that the Sitecore UserName is mapped with some random unfriendly characters…
As you can probably agree, this is not very user-friendly since the user-name is used in the item version history and within the workflows…
this code snippet will help you to use as user-name, either for the email address as username or the cleaned name of the active directory user…
I am happy to celebrate with you my 200th blog post and still counting…
This year has been a great year for the Sitecore community having fun with Sitecore 9 & DevOps… in case you have missed I would suggest you take a look at my posts talking about Azure, Powershell, Gulp, Helix and best way to build your deployment pipeline…
https://sitecorecommerce.wordpress.com/2019/10/25/sitecore-9-2-dev-environment-setup/
As previously discussed, if you have an Helix style solution, and you want to replace Gulp with PowerShell this script can come quite useful…
The principle is not to use Gulp for Build and packaging neither on your local environment (see this other post to see how to do it: https://sitecorecommerce.wordpress.com/2019/11/02/powershell-to-publish-helix-base-solution-with-visualstudio-2019-without-gulp/
neither on your Build server / Azure Pipeline….
as you can imagine PowerShell is your friend 🙂
In my specific example, I have instrumented it with VS 2017 but this script would work with any version of MS Build assuming that all parameters are supported….
The principle is a pretty simple loop through all the project in Feature / Foundation / Project and just calling a simple MSBuild command to publish the project within my Temp folder…. Msbuild will build each project, and publish each project copying the Bin / Views / and configs in the Temp folder keeping your solution structure…
Once you have the temp folder, you can then Zip the package and use to deploy on your Sitecore instance…
In the case, you have an Helix style solution, you are using Unicorn and you use Azure Dev ops as your build pipeline to publish your solution on Azure PAAS and you want to use Gulp only for styles and scripts manipulations…
you will definitively need this snippet since you probably have already encountered this problem within your Build Pipeline…
The principle is pretty simple, you need to copy your YML files and keep all the folder structure within serialization… within the App_Data/Unicorn folder within a website Temp folder that you will later zip with the rest of Bin and Views so that you can install your changes once the package is deployed across the environment…
This is done within the Gulp – Package task typically, but if you want to get rid of it, I would recommend doing a separate PowerShell Task just to copy Unicorn files…
The content of the Powershell is pretty simple and copy the files keeping your serialization structure across Feature, Foundation, Project folders…
In case you are worried about an Azure region going down and want to make your Sitecore Azure infrastructure not dependent on a single region, deploying a region for disaster recovery could be an option…
Obviously, depending on the complexity of your website, Sitecore resilience may be the minor problem in case of a region failure and further conversation should be taken to ensure that your infrastructure and data can be available across multiple regions….
As you can imagine, if your site is relying on Sitecore Analytics for personalization features your task won’t be trivial due to the Sitecore architecture, however, is a fair assumption and common practice to have analytics turned off on the DR region…
A typical DR region for Sitecore, would need the following elements:
My recommendation to provision a DR region on Azure PAAS would be to use the XM scaled scripts to provision a new environment in your favourite “backup” region and then delete the unrequired resources:
The following Powershell script shows how to run the clean up of these resources…
As you have probably heard, SAAS is coming summer 2020… but if your Sitecore project cannot wait that long, ARM templates are what you need to provision your Sitecore application on Azure PAAS…
In case you have no idea where to start, a few things that you need to know and decide
Sitecore Topology: you will have to choose between XM in case you do not need analytics and XP in case you need the fully flagged platform…
The topology is very different adding several additional configurations and servers in case you decide to go with the analytics….
Size of your installation, this will preset the size and kind of services provisioned, the default setting is extrasmall so that you can save on costs….
The url to get the Sitecore templates for 9.2 is https://github.com/Sitecore/Sitecore-Azure-Quickstart-Templates/tree/master/Sitecore%209.2.0
In addition to this, you will need the WDP packages for the topology selected https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/92/Sitecore_Experience_Platform_92_Initial_Release.aspx# don’t forget to download WDP for the identity server…
In addition to this, you will need a valid sitecore license, an azure subscription and you can provision a certificate for your test instance….
Once you have all the resource ready you will have upload on azure the WDP and the ARM templates in a storage account / Container…
Assuming you are going for the XM Scaled template, will look like:
once you are ready with thearm template, you can start editing your powershell required for trigger the deployment:
here is a very good example…
https://github.com/Sitecore/Sitecore-Azure-Quickstart-Templates
once you are ready to start provisioning, keep calm since the XM templates took more than 30 minutes and the XP scaled will take you more than one hour to complete…
in case you are working with test certificates, do not forget to add a allowInvalidClientCertificates parameter and set it to true in the parameters.json file…
Also worth mentioning that the key command to launch to provision your infrastructure is New-AzureRmResourceGroupDeployment -ResourceGroupName $Name -TemplateFile $ArmTemplateUrl -TemplateParameterObject $additionalParams -Debug -Verbose
note that the additionalparams is a hashtable generated from the parameters.json…
If you are using Sitecore Form, probably you have the need to extend the SubmitAction… this code snippet is a good example to start creating a custom SubmitAction…
The simpler custom submit action could be used to save data on a log file, and maybe send an email with the data submitted in the form…
Other common scenarios for custom actions are integrating it with the CRM….
This example has been tested with Sitecore 9.02 and should work well also with other versions up to 9.2….
happy forms!
