Configure a content delivery (CD) server

Content delivery servers make your web content available to your website visitors. You can configure one or more content delivery servers for improved scalability and better performance. If you expect to have high numbers of visitors or want to configure servers in different geographic locations, you can arrange content delivery servers into clusters.

Recommendations

Before you configure a content delivery server, consider the following recommendations:

  • You should enable xDB analytics tracking, as content delivery servers require it to track contacts, goals, and outcomes, and to perform personalization.
  • You should use session state to share contact sessions across all browsers and devices. This is important if you configure clusters of content delivery or processing servers. For each server cluster, configure both private and shared session states and a session state database to ensure that contacts stay connected to the same server until the session ends.
  • If you run xDB Cloud edition, you must configure your content delivery environment according to the instructions in this topic and the instructions for configuring xDB Cloud.

Note

You should synchronize all servers to a single reliable time source, such as with the Network Time Protocol (NTP). Engagement automation state aggregation depends on the system time. Inconsistency in time sources can lead to incorrect aggregation results or loss of data.

Configuration and connections

Before you install a Sitecore server you must read the hardware guidelines for Sitecore Hosting Environment Requirements and Sitecore Client Requirements sections from Installation Guide 9.0. You can download the guide from the Sitecore Downloads page.

You can install a Sitecore server either manually or by using the Sitecore Installation Framework. We recommend you use the Sitecore Installation Framework according to the instructions in the Installation Guide 9.0. The Sitecore Installation Framework automatically configures your Sitecore server for the role you select.

If you install the server manually, you must configure it for the content delivery role:

  1. Remove or restrict access to the client. You do not need the Sitecore client on a content delivery server.

  2. Use rule-based configuration to configure the server to fulfill only the content delivery role by including this line in the web.config file:

    <add key="role:define" value="ContentDelivery" />
    
  3. Ensure the following connection strings are set in the \App_Config\ConnectionStrings.config file:

    Name Type Notes
    core SQL  
    web SQL  
    xconnect.collection HTTPS  
    xconnect.collection.certificate Certificate  
    xdb.referencedata.client HTTPS  
    xdb.referencedata.client.certificate Certificate  
    xdb.marketingautomation.operations.client HTTPS Required for live event tracking
    xdb.marketingautomation.operations.client.certificate Certificate  
    ExperienceForms SQL  

    Note

    If you have set up xConnect to use separate collection and search end points, you must configure them separately.

  4. Configure content search. Contact and interaction search is done through the xConnect Search service, as CM servers do not have direct access to the xDB core. Configuration depends on your provider:

    • Configure Solr
    • Configure Lucene

    In a scaled environment, you should use Solr or Azure Search. Lucene is only recommended for standalone servers. The Azure Search provider only supports Azure Cloud PAAS deployments.

Security

Refer to the Security Hardening Guide for comprehensive security hardening instructions.

Configure IP hashing

You should avoid storing IP addresses directly in the xDB database. Configure IP address hashing on all CD servers to store IP addresses securely.

Configure multiple CD servers

If you need to configure multiple content delivery servers, you must perform these additional steps on each server:

  1. Each instance must have a unique name. By default Sitecore assigns an instance name consisting of the machine name plus the IIS server name.

    If you need to assign a different instance name, use a patch file to set it manually. The following example sets the name to testCD1:

    <setting name="InstanceName">
        <patch:attribute name="value">testCD1</patch:attribute>
    </setting>
    

    Note

    ​You only need to do this if you need to change the default instance name.

  2. Ensure that the Publishing.PublishingInstance setting in the \App_Config\Sitecore.config file is empty. If it is not, you must patch in an empty value:

    <!--  PUBLISHING INSTANCE
        Assigns the instance name of dedicated Sitecore installation for publishing operations.
        When empty, all publishing operations are performed on the local installation of Sitecore.
        Default vaue: (empty)
    -->
    <setting name="Publishing.PublishingInstance">
        <patch:attribute name="value"></patch:attribute>
    </setting>
    

    Note

    In the \App_Config\Include\Examples folder you can find the ScalabilitySettings.config.example file. This contains the InstanceName and Publishing.PublishingInstance options, and other related settings. You can specify your settings in this file and remove the .example from the file name to activate it.

  3. Configure the CD instance to perform GeoIP lookups by using a patch file to set the Analytics.PerformLookup property to true in the \App_Config\Sitecore\Marketing.Tracking\Sitecore.Analytics.Tracking.config file. If you have more than one CD instance, this setting must be set to true on all of them.

    <!--  ANALYTICS PERFORM LOOKUP
            Determines if this server performs the lookups (DNS and URLs). Should be set to true on every server where Tracking is enabled
            Default: true
    -->
    <setting name="Analytics.PerformLookup" value="true" />
    

Load balancing CD servers

If you have two or more CD servers, you must configure load balancing and session state management for the servers. You must use out of process session state management, which means that you do not need to use a persistent load-balancing method.