November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
This document describes how to set up an EPiServer CMS site to run on Azure Web Sites. In this scenario an Alloy sample site is created from the EPiServer Visual Studio plug-in (at least version 7.7), but most steps can also be applied to sites created in other ways. Refer to Azure Websites for more detailed information about Azure.
The following apply when deploying EPiServer CMS websites to Azure:
This is an example of a CMS website running on Azure Web Site environment with multiple instances. The website instances share the same Azure SQL database, and the blob storage in Azure is used for storing of the file binary data. Load balancing is applied, and the Azure Service Bus manages events between the CMS websites. Note that deploying to Azure Web Sites requires that each deployed application and module is designed for cloud.
Using elastic scaling, the number of CMS sites can easily be increased or reduced depending on capacity needs at the time, from the Azure administration interface.
Follow the steps below to create an EPiServer CMS website running in an Azure website environment.
Add the cloud license to the website, this will be used and activated later when deploying the website to Azure.
Log in to the Azure management portal and follow the steps below to create a website.
When running on Azure, the media (for example images) should be stored in the Azure BLOB storage to enable scaling.
Follow the steps below to create a BLOB storage account.
To be able to scale the site to run on several instances, we need to set up a Service Bus in Azure to handle messages between the site instances.
Follow the steps below to create a service bus.
In Visual Studio, update the configuration as described below.
Open web.config and add the following configuration under the episerver.framework-section to map BLOB and event providers to Azure
<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>
Example of database connection strings in web.config, defined for Azure:
<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>
Removal of workflow persistance configuration in web.config:
<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>
There are many options to deploy code and data to Azure, you can for example upload the site manually using FTP or integrate your source control system to get the process fully automated. In these steps we will describe the publish functionality available from within Visual Studio:
This topic applies to Visual Studio 2012 and later and covers features that are included in the latest Visual Studio Web Publish Update, previous versions does 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).
Important Make sure the modules and modulesbin folders are included in the project to make sure these as published as well.
Publishing the database schema as described above should only be performed 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 Management Portal, the script you should run is available relative to the project as mentioned in the steps above (which means [SolutionDir]\packages\EPServer.CMS.Core.7.6.0\tools\EPiServer.Cms.Core.sql). You can also deploy an existing database using the migration wizard available from Codeplex.
It is possible to configure Azure Web Sites so that it uses continuous deployment from source code control. It supports for example Git, GitHub and TFS. Refer to Publish from source control on Azure for a full description. Basically it works in the way that when you do a commit to your source control, Windows Azure will get the latest code from the source control, build it and deploy the output to the website. When working with a local Git repository you can instead push your changes to Azure Web Sites.
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 will only happen if the site does not have any previous content. For cloud deployment this means that it can be a good idea to first publish the project to the cloud environment before starting a local site configured against the cloud database. Then the bootstrap will happen in the cloud environment which is much faster (the site and database is likely in same datacenter) and also sets the SiteUrl to the cloud url for the created site.
An alternative way to transfer data to an EPiServer site running on Azure Web Sites is to use the 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.
To be able to login to the site on Azure you need to create a user with access to the edit/admin view, start the local site while connected to SQL Azure and perform the following steps. Note that the source IP address must be allowed to access the Azure database server, you can enable this in the Azure Management Portal on the specific SQL Azure server.
Depending on how the site was created (see section Deploying/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 Manage Websites in the CMS Admin view under Config, 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 Management portal under WEB SITES when selecting the created website, and selecting dashboard in the top menu. Then the site URL is given in the right column.
When hosting in Azure the best practice is to use a scalable search solution such as EPiServer Find. Since EPiServer Find is a hosted service that you connect to, it will work the same way as when your site runs on-premise.
If you want to use the built-in EPiServer Search when running in Azure Web Sites the suggestion is to install EPiServer.Search NuGet package on an empty web site (see Installing and Deploying Search Service section) and then deploy the Search Service as a separate Azure Web Site instance. The baseUri attribute for the search client configuration on the site using the Search Service should be set to the Azure Web Site hosting the Search Service.
Note that if you add search capability after you have added the content, you need to trigger a build of the index. Go to the following URL on the website: http://<MySite>/<MyUIFolder>/Cms/Admin/IndexContent.aspx.
The core parts of EPiServer CMS do not use Session State but some functionality does, such as some of the Visitor Groups criteria. There are two approaches to enabling session state, either depend on the sticky session feature (also known as session affinity) provided by Azure Web Sites that makes sure 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 Sites.
Last updated: Mar 31, 2014