Deploy to Windows servers

Deploy an Optimizely Content Management System (CMS) application to Windows servers using dotnet publish. The published output contains all required files and can be copied directly to one or more target servers: no separate Optimizely installation is needed.

To host the application on IIS, see Microsoft Host ASP.NET Core on Windows with IIS.

Before you begin

• An existing CMS application that you can build with dotnet publish.
• A Windows server with IIS and the .NET Hosting Bundle installed.
• SQL Server Management Studio to attach the database and create a SQL login.
• Familiarity with IIS site configuration and SQL Server administration.

Deploy a site

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

• Site – the published application output (from dotnet publish).
• SQL Server database – stored content and so on.
• Application Data – media BLOBs, search index. These are files normally stored in App_Data.

The procedure has three stages: create the deployment artifacts, deploy them to the target server, and add load-balancing support.

Create the deployment artifacts

Run dotnet publish from your project directory to produce a deployment-ready output folder:

dotnet publish -c Release -o ./publish

This restores NuGet dependencies, builds the project, and outputs all required files to the ./publish folder.

If your project uses files in the App_Data folder (such as media BLOBs or search indexes), copy them into the publish output manually or include them in your project file so they are published automatically.

Deploy the artifacts on the target server

Perform the following steps on the target server. The steps assume that you have moved the artifacts from the previous section to the new server. The web server must have IIS and the .NET 10 Hosting Bundle installed. You also need SQL Server Management Studio to connect to the database server.

1. 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 or restore to attach a database. See Backup and restore of SQL server databases on MSDN.

2. Create a new SQL Login:

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

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

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

5. Create an IIS site:

   1. Right-click the Sites node.
   2. Select Add Website.
   3. Set the Physical path to the published app's root folder (the folder that contains the generated web.config).

6. Update the EPiServerDB connection string in appsettings.json with connection details to the database (server, database, SQL login, and password).

📘

Note

For security and performance reasons, always move media BLOBs to a folder outside the application root (see the next section), either on a fileshare or a local folder. The App_Data folder is designed for development only.

Add load-balancing support

This section describes how to enable load balancing, configure remote events, and external storage of BLOBs (files on a fileshare). The example uses the Azure Service Bus and the default provider for storage of BLOBs.

📘

Note

Use the dedicated Azure Service Bus provider.

1. 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 the share and the folder to the user running the Application Pool for the site in Windows.

2. Edit appsettings.json and add configuration for the file BLOB providers. Make sure the Path property points to the correct path of the shared folder in step 1:

   C#

   {
     "EPiServer":{
       "Cms":{
         "FileBlobProvider":{
           "Path": "\\\\dbserver\\blobs"
         }
       }
     }
   }

3. Clear the browser cache and test the setup by browsing the site. Images on the site should work as before, but CMS now serves them from the shared location.

4. Configure the default provider for remote events by setting the endpoints. The site is now ready for load balancing.

5. Copy the site folder to a second server and create a site in IIS with the same settings as the previous server. No configuration changes are required.

6. Test remote events: log in to one of the servers and publish a change to a page. The change appears on the other server. Search from both servers to verify the configuration.

A hosting provider can load-balance incoming traffic between the servers for you. Alternatively, use a software load balancer such as HAProxy, Network Load Balancing (NLB), or Application Request Routing (ARR).

📘

Note

The core parts of CMS do not use session state, but some functionality does (for example, certain audience criteria). If your load-balanced setup requires session state, enable sticky sessions (session affinity) on the load balancer or configure a distributed session provider.

If you host on Optimizely Digital Experience Platform (DXP) or Azure App Service, enable ARR Affinity so remote events can invalidate the cache correctly. In the Azure portal, go to your App Service, select Configuration > General Settings, and set ARR Affinity to On.