---
title: Configuring web farm servers
related:
  - https://docs.kentico.com/13/configuring-xperience/setting-up-web-farms/creating-custom-web-farm-synchronization-tasks.md
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

To utilize web farm synchronization, all servers in the web farm must be registered and configured in the system. To start using the web farm synchronization:

1. Choose a web farm mode:
   - [Automatic web farm](#configuring-web-farms-automatically)
   - [Manually configured web farm](#configuring-web-farms-manually)
2. [Perform further configuration.](#further-configuration-of-web-farm-servers)

You can also perform additional low-level settings for web farm synchronization by adding the keys listed in [Web.config file settings](https://docs.kentico.com/13/configuring-xperience/reference-web-config-application-keys.md#web-farm-synchronization-settings) into the **/configuration/appSettings** section of your web.config file.

## Configuring web farms automatically

For most web farm environments, we recommend the automatic web farm mode. This mode dynamically adds and removes web farm servers from the system.

> **Info:** When running Xperience on **Microsoft Azure**, automatic web farm mode is enabled by default.

To set the automatic mode, we recommend that you first enable the automatic web farm on **one server** and after that start adding other servers to the web farm (connect them to the database).

1. Open the **Settings** application.
2. Select the **Versioning & Synchronization -> Web farm** category.
3. Select **Automatic** as the **Web farm mode**.
4. Click **Save**.

Now you can start adding other servers to the web farm (connect the servers to the database). The system will register them automatically.

> **Note:** **Automatic server name format**
>
> The system generates the names of automatic web farm servers by combining the following:
>
> - The **machine name** of the server where the application is running.
> - The **virtual directory** in which the application is running.
> - For external web applications running the Xperience API (typically [MVC](https://docs.kentico.com/13/developing-websites/mvc-development-overview.md) or [ASP.NET Core](https://docs.kentico.com/13/developing-websites/developing-xperience-applications-using-asp-net-core.md) live site applications), the **\_AutoExternalWeb** suffix is added by default.
>
> If this combination of variables is not unique in your environment (for example if you run your web farm instances on the same machine without virtual directories, e.g. distinguished by port numbers), you need to manually ensure unique server names for the web farm servers. Either specify a custom suffix for the automatic server name by setting the _CMSInstanceNameSuffix_ [web.config key](https://docs.kentico.com/13/configuring-xperience/reference-web-config-application-keys.md) on individual instances, or override the automatic server name completely via the _CMSWebFarmServerName_ key (see _Step 5_ in [Configuring web farms manually](#configuring-web-farms-manually)).

## Configuring web farms manually

If you need to have a complete control over your web farm or you are running a web farm with a static number of web farm servers, which you do not plan to change, configure the web farm servers manually in your system.

First, enable the manual web farm mode.

1. Open the **Settings** application.
2. Select the **Versioning & Synchronization -> Web farm** category.
3. Select **Manual** as the **Web farm mode**.
4. Click **Save**.

Now you must configure the web farm servers in the system.

1. Open the **Web farm** application.
2. Click **New server**.
3. Fill in the following fields:

   - **Server display name** – a descriptive name for the server displayed in the administration interface.
   - **Server enabled** – allows you to manually enable or disable web farm synchronization for the particular server.
4. Click **Save** to register the server.
5. Open the web.config file on the particular server and add the **CMSWebFarmServerName** key into the _appSettings_ section:

   ```csharp

   <add key="CMSWebFarmServerName" value="ServerCodeName"/>

   ```

   Replace **ServerCodeName** with the server code name that the system created for the server (or the code name that you manually entered). Every server must contain only one such key with its own name.

   > **Note:** Setting the server name in the web.config file overrides the automatic naming done by the system in the Automatic web farm mode.

Repeat the process for every server in your web farm.

Keep in mind that if you remove a machine from a web farm, you also need to disable or remove the corresponding server from the system.

## Further configuration of web farm servers

When you have defined the web farm servers and enabled the web farm, go through the following configurations to ensure that your web farm works correctly.

### Storing session state on a web farm

The default session state mode for ASP.NET applications is the **InProc** mode, which stores session state in the memory of the server. InProc session state mode is not supported on most types of web farms because requests for the same session can be served by different servers. This can cause unexpected behavior and data loss. For example, items stored in a shopping cart can disappear after making another request on the website.

If you are using a load balancer in sticky-session mode, you can use the default InProc mode. However, visitors may still experience session loss when a server in the web farm becomes unavailable.

To configure your web farm to store session state data correctly, use one of the following modes:

- **StateServer** mode – stores session state in a separate process.
- **SQLServer** mode – stores session state in an SQL server database.

To use one of these modes, adjust the __ element and its attributes in the **web.config** file. For more information, see the [Session-State Modes](https://docs.microsoft.com/en-us/previous-versions/aspnet/ms178586\(v=vs.100\)) article.

> **Info:** To learn how to configure Azure projects to store session data, see [Storing session state data in an Azure environment](https://docs.kentico.com/13/deploying-websites/running-xperience-on-microsoft-azure/storing-session-state-data-in-an-azure-environment.md).

### Configuring the machineKey element in web.config

By default, the Internet Information Services (IIS) server uses an automatically generated machineKey to encrypt and validate view state and forms authentication information. If a user tries to access the same session from two servers with different machine keys, the validation fails, and a Message Authentication Code (MAC) view state validation error occurs. To prevent this, the machineKey element needs to be the same across all Xperience administration instances in the web farm configuration.

#### Generating a machineKey element

> **Warning:** Never use any websites that generate a machineKey for you with the click of a button. It is impossible to know whether these keys were created securely or if they are being recorded to a secret database. You should only ever use machineKey configuration elements that you created yourself.

**For IIS 7.5**:

Machine keys can be generated in the **Machine Key** section under ASP.NET in the IIS Manager:

1. Select your preferred encryption and decryption methods.
2. Clear the **Automatically generate at runtime** and **Generate a unique key for each application** check boxes.
3. Click **Generate keys**\*.\*
4. Insert the machineKey element into the  section in the **web.config** file of all Xperience administration instances in your web farm configuration.

   ```xml

   <system.web>
   ...
       <machineKey decryption="..." decryptionKey="..." validation="..." validationKey="..." />
   ...
   </system.web>

   ```
5. Copy the generated decryption and validation keys into the **decryptionKey** and **validationKey** attributes.

   > **Note:** The **decryption** and **validation** attributes need to contain the names of your specified encryption and decryption algorithms. If you left the **Decryption method** set to _Auto_ when generating the machine keys in the IIS Manager, enter _AES_ as the decryption.

**For IIS 8 and newer**:

The ability to generate machine keys is not available in the IIS Manager 8 or newer. You can use a PowerShell script to generate the machineKey element according to the instructions in [this article from Microsoft](https://support.microsoft.com/en-us/kb/2915218#bookmark-appendixa). Insert the generated machineKey element into the  section in the **web.config** file of all Xperience administration instances in your web farm configuration.

### Configuring servers for synchronizing macros

The system uses signatures to ensure the security of [macro expressions](https://docs.kentico.com/13/macro-expressions/entering-macro-expressions.md). Macro signatures contain the user name of the macro's author (or an assigned macro identity) and a hash of the given expression.

The hash function used to create the signatures appends a [salt](http://en.wikipedia.org/wiki/Salt_%28cryptography%29) to the input. To ensure that macro expressions work correctly in a web farm environment, you need to configure all servers to use the same hash salt:

- Set the **CMSHashStringSalt** key in the _appSettings_ section of the web.config file to the same value on all web farm servers. For example:

  ```html

  <add key="CMSHashStringSalt" value="e68b9ad6-a461-4707-8e3e-ece73f03dd02" />

  ```

The best option is to set the hash salt value before you start creating content for your website. Changing the salt causes all current hash values to become invalid. To fix existing macro expressions in the system after changing the hash salt, you need to re-sign the macros. See [Working with macro signatures](https://docs.kentico.com/13/macro-expressions/troubleshooting-macros/working-with-macro-signatures.md) for more information.

### Setting up a shared file storage for a web farm

The web farm synchronization mechanism synchronizes files reliably up to the size of 250 MB. Larger files take a long time to synchronize. Even though the synchronization for larger files may work without problems in your environment, we recommend that you configure a **shared storage** for your web farm in such cases.

You can configure the following shared file storages for your web farm:

- [Azure Blob Storage](https://docs.kentico.com/13/custom-development/working-with-physical-files-using-the-api/configuring-file-system-providers/configuring-azure-storage.md)
- [Amazon S3 storage](https://docs.kentico.com/13/custom-development/working-with-physical-files-using-the-api/configuring-file-system-providers/configuring-amazon-s3.md)
- Custom network storage – you need to [configure a file system provider](https://docs.kentico.com/13/custom-development/working-with-physical-files-using-the-api/configuring-file-system-providers.md#changing-content-file-paths-to-a-shared-storage).

When you configure a shared storage for you web farm, the system automatically recognizes this setup and stops creating synchronization tasks for these files.

### Configuring scheduled tasks to be executed on every server of a web farm

If you are using a web farm, [scheduled tasks](https://docs.kentico.com/13/configuring-xperience/scheduling-tasks.md) will be executed randomly by one of the servers. However, scheduled tasks that work with the application file system should be executed by each server in the web farm.

The following scheduled tasks must be **executed by each server** in a web farm, if you are NOT using a shared file storage (Azure Blob Storage or Amazon S3 storage):

- Execute local [search tasks](https://docs.kentico.com/13/configuring-xperience/setting-up-search-on-your-website/monitoring-search-indexing-tasks.md)
- Optimize local search indexes
- Delete image editor history
- Delete old temporary upload files
- Delete old temporary attachments
- Clean Azure storage cache

The following scheduled task must be executed by each server in a web farm regardless of the used file storage:

- Clean unused memory

To configure these tasks to be executed by each server in a web farm, clone the original tasks and configure them to be executed on specific servers:

1. Open the **Scheduled tasks** application.
2. Edit the scheduled task.
3. Type the **Server name** according to the name of one of the servers in the web farm and click **Save**.
4. Return to the main page of the **Scheduled tasks** application.
5. Click **Other actions** (**...**) next to the scheduled task and select **Clone**.
6. Choose a name for the cloned task and click **Clone**.
7. Edit the cloned scheduled task.
8. Change the **Server name** to the name of a different server in the web farm and click **Save**.
9. Repeat for each server in your web farm.

Perform this procedure for all scheduled tasks listed above.

### SSL in a web farm environment

If you use an SSL offload device or accelerator as part of your web farm and your website is configured to require SSL for the administration interface or on specific pages, you may encounter problems with redirection loops.

For this type of scenario, you need to add some custom code to your website according to the instructions in [SSL accelerator support](https://docs.kentico.com/13/securing-websites/deploying-websites-to-a-secure-environment/configuring-ssl/ssl-accelerator-support.md).

### Using port numbers to identify web farm servers

If your environment uses unique port numbers to identify web farm servers (for example with a load balancer that internally maps URLs to ports), the system generates certain types of URLs with the internal port number. Such URLs may not be processed correctly, leading to problems with related features (for example _GetResource_ requests for files).

To resolve these problems, add the following key into the _appSettings_ section of the web.config file on all servers:

```xml

<add key="CMSURLPort" value="80" />

```

The key ensures that the system generates all URLs without the port number (the default HTTP port is used).

### Web farm instances with a shared file system

If your web farm environment contains multiple instances of a single Xperience administration or live-site project mapped to a [shared storage](#setting-up-a-shared-file-storage-for-a-web-farm), perform the following configuration to avoid issues with synchronization of physical files across web farms.

1. Map the following folders from **both** projects to a [storage](https://docs.kentico.com/13/custom-development/working-with-physical-files-using-the-api/configuring-file-system-providers/configuring-azure-storage.md) shared by both applications (to ensure files are accessible from both the administration and live-site):
   - \~/App\_Data/CMSModules/SmartSearch – Contains smart search index files.
   - \~/##SiteFolder## – named after the site's code name. Contains primarily media library files and documents.These folders contain all files Xperience synchronizes via web farms.
2. Add the _CMSSharedFileSystem_ key to the _web.config_ of **both** applications. The key disables the generation of web farm tasks related to synchronization of physical files (media library items, smart search indexes, etc.).

   ```xml

   <add key="CMSSharedFileSystem" value="true"/>

   ```

For clarification, see [Setting up shared storage for physical files](https://docs.kentico.com/13/deploying-websites/running-xperience-on-microsoft-azure/deploying-to-azure-web-apps/scaling-azure-web-apps.md#setting-up-shared-storage-for-physical-files).