Dev GuideAPI ReferenceUser Guide
HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

You can install Optimizely Content Management System (CMS) through XCOPY deployment by copying application files. An XCOPY-style file transfer simplifies deployment and maintenance of Optimizely sites because no registry entries are created, and no shared components are registered.

The XCOPY architecture in CMS has no machine- or site-specific information stored in configuration files, so you can use a shared folder for multiple servers. When you develop in a shared environment with source control, you can keep configuration files checked-in and still create a site that you can duplicate in a multi-site deployment.

You can have one single IIS application with multiple sites, or multiple IIS applications pointing to the same physical directory. The machine to which you install additional sites does not need to have CMS installed.

## Deploy a site

The following procedure shows how to deploy a CMS site from development to production. You can automate this using MSDeploy 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.

  • **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\. Create the deployment artifacts

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

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

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

  3. Include all files in _modules_, _modulesbin_ and _App\_Data_ folders in the project. (You also can copy those folders manually to the output folder.)

  4. _If Optimizely Search is installed,_ include the **IndexingService** folder into the project.

  5. Right-click the project in Visual Studio and click **Publish.** Specify a publish destination of type **FileSystem**.

  6. Under **Settings**, make sure **Exclude files from the App\_Data** folder is not checked to restore those files on the destination. (Do not select **Precompile during publishing** because it disables required functionality such as Virtual Path Providers.)

  7. 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\. Deploye 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 installed. You also need SQL Server Management Studio to connect to the database server. To use Optimizely Search, you also need the Windows feature HTTP Activation (**Roles and Features** \> **.NET Framework 4/4.5 Features** \> **WCF Services**) installed on the web servers.

  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/restore to attach a database. See [Back up and restore of SQL server databases on MSDN](🔗).

  2. Create a **new SQL Login**: a. Right-click on the **Security** node and select **New** \> **SQL Login**. b. Select **SQL Server Authentication**. c. Unselect **User must change password at next login**. d. Under User Mapping, select the new database and make sure the user is 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. Set access rights on the _App\_Data_ folder so that the group **IIS\_IUSRS** have **Change** access.

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

  6. Create a **new IIS site:** a. Right-click the **Sites** node. b. Select **Add Website**. c. Select the **wwwroot** subfolder as the **Physical path** for the new site.

  7. 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.

  8. If Optimizely Search is installed, update the **episerver.search** section to make sure the `baseUri` refers to the new IIS site.

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\. Add 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 the default provider for events (WCF over UDP) and the default provider for storage of BLOBs.

Note

UDP broadcast is not supported by Azure virtual networks. Use the dedicated [Azure Service Bus provider](🔗) instead or [Configuring events over WCF over TCP](🔗).

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

  2. Edit _EPiServerFramework.config_ and add configuration for the file BLOB providers. Make sure the path-attribute is valid:

    
  3. 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.
  4. Enable the default provider for **remote events** by configuring the endpoints `RemoteEventServiceClientEndPoint` and `RemoteEventServiceEndPoint` in _web.config_. This automatically enables the default provider.
Code example for CMS 11.1 and higher:
    
    Code example for CMS 10.x
    
  5. If [Optimizely Search & Navigation](🔗) is installed, you cannot load-balanced the search index. You must store it on a master server. Change the service to allow remote callers by setting an access key under the **clients** list in the **episerver.search.indexingservice** section in _web.config_:
    
  6. Change the client to access one of the servers with the specific access key by changing the **services** list **episerver.search** section in _web.config_:
    
  7. 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.
  8. 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 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](🔗).
You should 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 **Settings > Application Settings** and enable **ARR Affinity**.
You can also set ARR Affinity in _web.config_ as follows: