Deploying to Windows servers

November Happy Hour will be moved to Thursday December 5th.

Deploying a site

The following procedure shows how to deploy an Optimizely site from development to production. You can automate this using dotnet command or other tools.

You need three artifacts to bring over to the production server:

Site (the Optimizely platform and templates with dependencies and modules). These are normally the root of a Visual Studio project. (Output from dotnet publish on project)

SQL Server database (stored content and so on).

Application Data (media BLOBs, search index). These are files normally stored in App_Data for a Visual Studio project. (Versions prior to CMS 7.6 store these files by default in parallel with the Visual Studio project.)

Note: The following steps assume you have an existing site and good knowledge of using Visual Studio, Internet Information Services Manager and SQL Server Management Studio.

1. Creating the deployment artifacts

Create the deployment artifacts on the development machine to publish a package that can be installed on the target server.

Open a Visual Studio project for the site you are deploying.

Establish NuGet dependencies for the Optimizely products used. (This is done by default for CMS 7.6 and later.)

Include all files in modules, modulesbin and App_Data folders in the project. (You also can copy those folders manually to the output folder.)

Right-click the project in Visual Studio and click Publish or dotnet publish on the project. Specify a publish destination of type FileSystem.

Under Settings, make sure Exclude files from the App_Data folder is not checked to restore those files on the destination.

Publish the project.

Note: If the database files are not stored in App_Data, see Back Up and Restore of SQL Server Databases on MSDN for details about moving databases.

2. Deploying the artifacts on the target server

Note: The following steps are performed on the target server and assumes you have moved the artifacts created in the previous section to the new server. The web server should have IIS and ASP.NET Core installed. You also need SQL Server Management Studio to connect to the database server.

Attach the database. See Attach a database on MSDN.

To complete this step, move the database files from the App_Data folder to the designated data folder for Microsoft SQL Server.

You can also use backup/restore to attach a database. See Back up and restore of SQL server databases on MSDN.

Create a new SQL Login:

Right-click on the Security node and select New > SQL Login.
Select SQL Server Authentication.
Unselect User must change password at next login.
Under User Mapping, select the new database and make sure the user is member of the db_owner group.

On the web server, create a new folder for your site (for example c:\inetpub\Site1), and copy the contents of the deployed site.

Set access rights on the App_Data folder so that the group IIS_IUSRS have Change access.

Open Internet Information Services Manager and connect to the web server.

Create a new IIS site:

Right-click the Sites node.
Select Add Website.
Select the wwwroot subfolder as the Physical path for the new site.

Update the EPiServerDB connection string in the configuration file in the site root (such as web.config or connectionStrings.config, depending on setup) with connection details to the new database (server, database, SQL login and password).
Make sure your db connection string contains MultipleActiveResultsSet=true. It is enabled by default when you install a website from a scratch, but not if you are generating a connection string from the server explorer in Visual Studio.

Note: For security and performance reasons always move media BLOBs to a folder outside the application root (as described in the next section), either on a fileshare or a local folder. Storing BLOBs in the App_Data folder is only designed for development purposes.

3. Adding load-balancing support

This section describes how to enable load-balancing, configure remote events and external storage of BLOBs (files on a file share). The example uses Azure service bus and the default provider for storage of BLOBs.

Move the Blob subfolder of the App_Data folder to a shared server, such as the database server, and then share the folder. Give access rights for both the share and the folder to the user running the Application Pool for the site in Windows.

Edit appsettings.json and add configuration for the file BLOB providers. Make sure the path-attribute is valid:

{
  "EPiServer":{
     "Cms":{
            "BlobProvidersOptions": {
                "DefaultProvider": "fileShare",
                "Providers": {
                    "fileShare": "EPiServer.Framework.Blobs.FileBlobProvider, EPiServer.Framework"
                },
             } 
             "FileBlobProvider":{
                 "Path": "\\dbserver\blobs"
             }
     }
  }
}

Clear the browser cache and test the setup by browsing the site. Images on the site should work as before but now are delivered from the shared location.

Configure an event provider today there is athat can take cae of if the default provider for remote events by configuring the endpoints .
The site is ready to be load-balanced. Copy the site folder to a second server and create a new site in IIS with the same settings as the previous server. No configuration changes required.

Test remote events by logging in to one of the servers and publish change to a page. The published changes appear on the other server. Use the search functionality from both servers to verify it was configured correctly.

A hosting provider can help you load-balance incoming traffic between the servers. You also can use other software load-balancers such as HAProxy, Network Load Balancing (NLB) or Application Request Routing (ARR).

Note: The core parts of Optimizely 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 that depend on the sticky session feature (also known as session affinity) provided by a load-balancer that makes sure a user is reaching the same server combined with the default in-memory session state provider. You also can use an optimized provider for load-balancing, such as the built-in StateServer.

Optimizely recommends that you enable the ARR Affinity setting for applications in DXC to ensure proper functioning and saving of contents, in respect to cache invalidation by remote events. In Azure, go to the App Service where you want to make the change, select Configuration > General Settings and enable ARR Affinity.

You can also set ARR Affinity in web.config as follows:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Arr-Disable-Session-Affinity" value="false" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Deploying to Windows servers

Deploying a site

1. Creating the deployment artifacts

2. Deploying the artifacts on the target server

3. Adding load-balancing support

Related topics

Blog posts