November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
This topic describes how to set up an Episerver CMS site to run on Azure Web Apps. The example creates an Alloy sample site using the Episerver Visual Studio extensions, but you can apply most steps to sites created in other ways.
Note: See also the Installing the Episerver Alloy sample site in the Azure cloud video for information about cloud installation.
In this topic
The following image illustrates a CMS website running in an Azure Web Apps environment with multiple instances. The website instances share the same SQL database and BLOB storage that stores binary file data in the cloud environment. The sites are load-balanced, and a Service Bus manages events between the CMS websites.
Using App Service plans, you can increase or reduce the number of CMS sites from the Azure portal.
The following steps create an Episerver CMS website running in an Azure website environment.
Log in to the Azure portal and follow these steps to create the necessary Azure components:
When you run on Azure, you should store media (such as images) in Azure BLOB storage to enable scaling.
To scale the site to run on several instances, set up a Service Bus in Azure to handle messages among the site instances.
Next you need to change some configurations for the website to work with Azure.
Note: Do not skip this step! If you do, assets are stored locally, and will not deploy properly to the Azure Blob storage.
Open web.config and add the following configuration under the episerver.framework section to map BLOB and event providers to Azure.
The attributes container and topic are the names for the BLOB provider (the storage account) and event provider (the service bus) respectively. They should be unique per web app and per storage or service bus account. This means that you need to update the mapping for BLOBs and Events. (The connectionStringName attribute value is the name of the connection string from the connectionStrings section in the Azure portal.)
You can change the container and topic names "mysitemedia" and "MySiteEvents" to names of your choice.
<blob defaultProvider="azureblobs">
<providers>
<add name="azureblobs"
type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure"
connectionStringName="EPiServerAzureBlobs"
container="mysitemedia"/>
</providers>
</blob>
<event defaultProvider="azureevents">
<providers>
<add name="azureevents"
type="EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure"
connectionStringName="EPiServerAzureEvents"
topic="MySiteEvents"/>
</providers>
</event>
connectionString="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>"
You can find the connection string to your Azure BLOB provider in the Azure portal under your storage account > Settings > Access keys. <connectionStrings>
<clear />
<add name="EPiServerDB"
connectionString="Server=tcp:abcdefgh.database.windows.net,1433;Database=mySiteDB;User ID=dbadmin@abcdefgh;Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient" />
<add name="EPiServerAzureBlobs"
connectionString="DefaultEndpointsProtocol=https;AccountName=mystorageccount;AccountKey=abcdefghijklmnoabcdefghijklmnoabcdefghijklmno" />
<add name="EPiServerAzureEvents"
connectionString="Endpoint=sb://myservicebus.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=abcdefghijklmnoabcdefghijklmnoabcdefghijklmno=" />
</connectionStrings>
<profile defaultProvider="DefaultProfileProvider">
<properties>
.
.
.
</properties>
<providers>
<clear/>
<add name="DefaultProfileProvider" type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="EPiServerDB" applicationName="/" />
</providers>
</profile>
<workflowRuntime EnablePerformanceCounters="false">
<Services>
<add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" maxSimultaneousWorkflows="5" />
<add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowCommitWorkBatchService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<strong>REMOVE THIS: <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="true" /></strong>
</Services>
</workflowRuntime>
Disable workflows completely by adding the disabled attribute to the workflowSettings element. [Requires 7.14.]<episerver>
(..)
<workflowSettings disabled="true" />
(..)
</episerver>
You can upload the site manually using FTP or integrate your source control system to get the process fully automated.
The following steps describe the publish functionality available from within Visual Studio 2012 and later. Previous versions of Visual Studio do not have the database publishing capabilities described here. This option is also only available when the connectionstrings are defined in web.config (rather than in an external file such as connectionstrings.config).
Note: Make sure the modules and modulesbin folders are included in the project so they are published. Publishing the database schema should be performed only on the first publish operation.
Note: You can also deploy the database schema using SQL Server Management Studio or the tools available in the Azure Portal. The script you should run is available relative to the project ([SolutionDir]\packages\EPServer.CMS.Core.x.x.x\tools\EPiServer.Cms.Core.sql). See also Microsoft's SQL Server database migration to Azure SQL Database.
You can configure Azure Web Apps so that it uses continuous deployment from source code control. It supports Git, GitHub, Bitucket, and VSTS/TFS. See Continuous Deployment to Azure App Service on the Microsoft Azure portal. When you commit to your source control, Windows Azure gets the latest code from the source control, builds it, and deploys the output to the website. When you work with a local Git repository, you can push your changes to Azure Web Apps instead. See Local Git Deployment to Azure App Service.
From version 7.7 of CMS, there is a bootstrap feature for content. It works so that if there is an export package located at [SolutionDir]\App_Data\DefaultSiteContent.episerverdata then during initialization that package is imported and a site is created. The bootstrap happens only if the site does not have any previous content. For cloud deployment, you may want to first publish the project to the cloud environment before starting a local site configured against the cloud database. Then the bootstrap happens in the cloud environment, which is much faster (because the site and database are likely in same datacenter) and also sets the SiteUrl to the cloud url for the created site.
You can also transfer data to an Episerver site running on Azure Web Apps using the Episerver CMS export/import functionality. Export the start page from your local site and database and import on the site running in Azure before continuing to the next step. See Exporting and importing in the Episerver User Guide.
To log in to the site on Azure, create a user with access to the edit/admin view, start the local site while connected to SQL Database, and perform the following steps. You must allow the source IP address to access the Azure database server. You can enable this in the Azure Portal on the specific SQL Database server (select the SQL server > Firewall/Virtual Networks > Add client IP). How to create the first user depends on which identity provider has been configured; membership or AspNet Identity provider.
Go to the CMS admin view and activate your cloud license on both test and production environments. The running instances will be counted towards the total number of instances allowed by the license. See also: Managing cloud licenses.
Depending on how the site was created (see Deploying content), you might need to update the site definition for the Episerver CMS website created in the first steps after deployment. If so, log in to the website and go to the CMS admin view > Config > Manage Websites, and change the Site URL to the URL in Azure. This will also map a host name to the correct site in CMS. The URL can be found in the Azure portal. Select your web app > Overview, the site URL is given in the right column.
Episerver supports writing to the diagnostics log using BLOB storage. See Logging into .Net Diagnostics Trace for more details on how this works.
Follow these steps to activate the logging:
Note: The web app will restart when activating the logging.
The Azure SQL Database Automatic tuning is a feature that provides improved performance and automatic tuning of the database, based on AI and machine learning. It is recommended to leave the settings as default, and in particular leave CREATE INDEX as Off, as turning it on might cause problems with the Episerver Dynamic Data Store (DDS) and sub-optimal indexes.
You should use a scalable search solution when you host in Azure. It is not recommended to use the Episerver Search package in Azure Web Apps, as data corruption can occur in the Lucene index used by the built-in search, when scaling up to multiple instances.
If you need scaling, use Episerver Search & Navigation (formerly Episerver Find) instead. This is a hosted service that you connect to, and that works the same way as when your site runs on-premise. Episerver Search & Navigation is included when running your solution in Episerver Customer-Centric Digital Experience Platform (DXP).
Azure Web Apps supports deployment slots, so you can deploy new code into a staging environment before moving it to production. To make sure deployment slots do not interfere with the production environment, make sure you define the EPiServerDB, EPiServerAzureEvents and EPiServerAzureBlobs connection strings in the Azure portal as "sticky" (session affinity) to each slot. If a deployment slot re-uses the production connection strings, it is treated as a load-balanced server, part of the production environment, including licensing restrictions. See Microsoft documentation for details about using staging with Azure Web Apps.
Note: Defining EPiServerDB as a connection string in the Azure Portal requires at least EPiServer.CMS.Core 8.3.0. You must enable this feature by adding an app setting episerver:ReadOnlyConfigurationAPI in the portal (under your web app > Configuration > Application settings > Connection strings), with the value set to true.Applicatio
The core parts of Episerver CMS do not use Session State but some functionality does, such as some Visitor Groups criteria. There are two approaches to enabling session state, depending on the sticky session feature (also known as session affinity) provided by Azure Web Apps which makes sure a user is reaching the same server combined with the default in-memory session state provider.
Another approach to enable better scaling is using an optimized provider for Azure, such as the session provider for Azure Web Apps.
Last updated: Jun 14, 2021