Deploying to Windows Servers

This document describes how to deploy EPiServer sites through Visual Studio. Installation of EPiServer can be done through XCOPY deployment simply by copying application files. An XCOPY-style file transfer simplifies deployment and maintenance of EPiServer sites since no registry entries are created, and no shared components are registered.

Another benefit of the XCOPY architecture in EPiServer CMS is that there is no machine- or site-specific information stored in configuration files, making it possible to use a shared folder for multiple servers. During development in a shared environment with source control, developers can keep configuration files checked in and still be able to create a site which can be duplicated 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 EPiServer installed.

Deploying a site

This is a walkthrough of deploying an EPiServer site from development to production, you can automate this using for example msdeploy or other tools but in this example we are doing the deployment manually to shed light on what steps is required when doing a deployment. There are 3 artifacts we have to bring over to the production server:

• Site (the EPiServer platform and templates with dependencies and modules). These are files on disk, normally the root of a Visual Studio project.
• SQL Server database (stored content etc).
• Application Data (media blobs, search index, geolocation database). These are files on disk, normally stored in App_Data for a Visual Studio project (versions prior to CMS 7.6 store these files by default in parallell with the Visual Studio project).

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

Creating the deployment artifacts

The following steps are performed on the development machine to publish a package that can be installed on the target server.

1. Open the project for the site you are deploying in Visual Studio.
2. Make sure NuGet dependencies are established for the EPiServer products used (this is done by default for CMS 7.6 and later).
3. Make sure all files in modules, modulesbin and App_Data folders are included in the project (only required to be able to publish all required files in a single operation, you can also copy those folders manually to the output folder)
4. If EPiServer Search is installed: Include the IndexingService folder into the project.
5. Right-click the project in Visual Studio and hit Publish.. and specify a publish destination of type FileSystem
6. Under Settings, make sure "Exclude files from the App_Data folder" is not checked to be able to restore those files on the destination (Do not select "Precompile during publishing" since 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 more details on moving databases.

Deploying the artifacts

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 EPiServer Search you also need have Windows feature HTTP Activation (Roles and Features->.NET Framework 4/4.5 Features->WCF Services) installed on the web servers.

1. Attach the database, for more details see Attach a database on MSDN. To complete this step you need to move the database files from the App_Data folder to the designated data folder for Microsoft SQL Server. Note An alternative to attaching a database is using backup/restore, see Back up and restore of SQL server databases on MSDN for more details.
2. Create a new SQL Login by right-clicking on the Security node and select "New->SQL Login". Select "SQL Server Authentication" and 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.
3. On the web server, create a new folder for your site (for example c:\inetpub\Site1), 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 by right-clicking the "Sites" node and select "Add Website". Select the wwwroot subfolder as the "Physical path" for the new site.
7. Update the connection string "EPiServerDB" in the file 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).
8. If EPiServer Search is installed: Update the episerver.search section to make sure the baseUri is refering to the new IIS site.

Adding load balancing support

To enable load balancing remote events and external storage of blobs should be configured, this example uses the default provider for events (WCF over UDP) and the default provider for storage of blobs (files on a file share). Note that UDP broadcast is not supported by Azure virtual networks, use the dedicated Azure Service Bus provider instead or WCF over TCP.

1. Move the Blob subfolder of App_Data folder to a shared server, such as the database server, and then share the folder in Windows. Access rights both on the share and on the folder must be given to the user running the Application Pool for site.
2. Edit EPiServerFramework.config and add configuration for the file blob providers, make sure the path-attribute is valid:
   

    <blob defaultProvider="fileShare">
       <providers>
           <add name="fileShare" path="\\dbserver\blobs" type="EPiServer.Framework.Blobs.FileBlobProvider, EPiServer.Framework" />
       </providers>
   </blob>

3. Images on the site should work as before but now be delivered from the shared location, clear the browser cache and test the setup by browsing the site.
4. Enable the default provider for remote events by configuring the endpoints "RemoteEventServiceClientEndPoint" and "RemoteEventServiceEndPoint" in web.config, this will automatically enable the default provider.
   

      <system.serviceModel>
         <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>
         <extensions>
           <bindingElementExtensions>
             <add name="udpTransportCustom" type="Microsoft.ServiceModel.Samples.UdpTransportElement, EPiServer.Events"/>
           </bindingElementExtensions>
         </extensions>
         <services>
           <service name="EPiServer.Events.Remote.EventReplication">
               <endpoint name="RemoteEventServiceEndPoint"
                       contract="EPiServer.Events.ServiceModel.IEventReplication"
                       binding="customBinding"
                       bindingConfiguration="RemoteEventsBinding"
                       address="soap.udp://239.255.255.19:5000/RemoteEventService" />
           </service>
         </services>
         <client>
           <endpoint name="RemoteEventServiceClientEndPoint"
              address="soap.udp://239.255.255.19:5000/RemoteEventService"
              binding="customBinding"
              bindingConfiguration="RemoteEventsBinding"
              contract="EPiServer.Events.ServiceModel.IEventReplication" />
         </client>
         <behaviors>
           <serviceBehaviors>
             <behavior name="DebugServiceBehaviour">
               <serviceDebug includeExceptionDetailInFaults="true"/>
             </behavior>
           </serviceBehaviors>
         </behaviors>
         <bindings>
           <customBinding>
             <binding name="RemoteEventsBinding">
               <binaryMessageEncoding />
               <udpTransportCustom multicast="True"/>
             </binding>
           </customBinding>
         </bindings>
       </system.serviceModel>

5. If EPiServer Search is installed: The search index cannot be load balanced and must be stored on a master server, steps below configtured all servers to contact to a central point:
   1. 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:
      <add name="ACCESSKEY_HERE" description="local" allowLocal="false" ipAddress="0.0.0.0/0" ip6Address="::/0" readonly="false" />
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:
    <add name="serviceName" baseUri="http://SERVER1/IndexingService/IndexingService.svc" accessKey="ACCESSKEY_HERE" />
7. The site is now ready to be load balanced, just 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 publishing changes should appear on the other server. Use the search functionality from both servers to verify it has been configured correctly.

To load balance incoming traffic between the servers is something the hosting provider can help you with. There are also other software such as HAProxy, Network Load Balancing (NLB) or Application Request Routing (ARR) that can be used as load balancers.

Session State

The core parts of EPiServer CMS does not use Session State but some functionality does, such as some of the Visitor Grous criteria. There are two approaces to enabling session state, either depend on the sticky session feature (also known as session affinity) provided by a load balancer that makes sure user is reaching the same server combined with the default in-memory session state provider. Another approach to is using an optimized provider for load balancing, for example the built-in StateServer.