Try our conversational search powered by Generative AI!

EPiServer CMS Operator's Guide

Product version:

EPiServer CMS 4.62

Document version:


Document creation date:


Document last saved:



This document is mainly intended for administrators and developers that operate EPiServer CMS or want to learn more about the EPiServer CMS operating environment. The document assumes that you have certain knowledge about Microsoft .NET and system administration in the Microsoft environment.

Table of Contents


Security Configuration of the Windows Environment
    - File Access Rights
    - Internet Information Server (IIS)

ASP.NET Configuration
    - Sessions 
    - Timeout for Logout
    - Release Mode

EPiServer CMS Configuration
    - Roles and Authority 
    - Encrypt web.config
    - Cache

Shared Hosting

    - Roles and Users 
    - Limitations in Windows 2000

EPiServer CMS Configuration Tool
    - Template Syntax
    - Download

Load Balancing
    - Files 
    - Cache
    - State and Sessions
    - ASP.NET

Performance and Load Measurements

    - Simulating Workload 
    - Performance Monitor
    - SQL Profiles

    - A Page Has Suddenly Started Requesting Login
    - Error Message: Could Not Load Type 'development.Global'


The document handles configuration of the main areas that an administrator manages: Microsoft ASP.NET, Microsoft Windows and EPiServer CMS. This includes information about everything from NTFS access rights to how the cache works in EPiServer CMS.

There is a chapter that handles shared hosting environment, i.e. when several totally separate EPiServer CMS installations exist on the same server, and a chapter that describes EPiServer CMS Configuration Tool, which is a tool to facilitate configuration of EPiServer CMS installations based on predefined templates.

This document also includes introductions to load measurements and load balancing, and also contains a reference list, where you can find further information about the different subjects and tools referred to in the text.

Microsoft Knowledge Base articles are referred to in the document, e.g. see KB Q815171. These articles are available on Internet via Microsoft’s Support Web site. Search for the article number at, e.g. Q815171. These references are also listed under Links and References.

Security Configuration of the Windows Environment

EPiServer CMS requires certain settings in the Windows environment in order to work correctly. This mainly concerns file and directory access rights and the configuration of Internet Information Server (IIS).

File Access Rights

ASP.NET and EPiServer CMS do not use impersonation, which is a change in how ASP.NET acts compared to ASP (see KB Q815171), as standard. This means that all code on the server will be run under the account that ASP.NET uses. There is, however, one exception that requires higher Windows access rights than the normal ASP.NET account has. System settings may also require a Windows account, if you choose not to give the ASP.NET account access rights to write to the web.config file.

The table below describes the access rights required for a standard EPiServer CMS installation. Note that specially developed templates may require additional access rights. The .NET files have been installed in the <.NET framework> directory, usually C:\WINNT\Microsoft.NET\Framework\<version>. Note that this path can vary and depends on how your system is installed. The EPiServer installation on the Web server is installed in the <EPiServer> directory, usually c:\inetpub\EpiServer.


Access right


<.NET framework>


Used to run system .dll files.

<.NET framework>/ASP.NET Temporary Files


Used by ASP.NET to compile code dynamically.

<Windows Temp>


Used by ASP.NET to compile code dynamically.



Path to the installation.



Used to be able to upload files.



Used for the generation of temporary files, e.g. thumbnails.



Used to be able to save system settings.

Internet Information Server (IIS)


The authentication mechanism you choose in IIS depends on the authentication you use in ASP.NET. If you use forms authentication, as we recommend, you should only allow Anonymous access, as IIS is not responsible for authentication then.

If you use Windows authentication in ASP.NET, you should configure IIS for Basic Authentication or Integrated Authentication. Integrated Authentication cannot normally be used over firewalls, which is why it is normally only an alternative for intranets.

Refer to the white paper, "Security in EPiServer CMS" for a more detailed description, including the advantages and disadvantages of using certain authentication mechanisms.

Directory Settings

EPiServer CMS 4 is a pure ASP.NET application and does not require any settings other than the standard settings. It is, however, advisable to secure directories so that certain file types are not allowed in certain directories. The ground rule is to only allow Read permission in directories with downloadable files, like images, and only Script permission in directories with script files, e.g. ASP.NET files. This is so that the code can only be executed and not read. An exception is that IIS 5.0 requires Read permission to be set on a directory in order for a default document to work, e.g. default.aspx. This mainly applies to the admin, edit and root directories.

Our recommendations for directory settings can be found in the table below:




Log access

Directory browsing allowed

Index this directory










































































Mapping of File Types and Error Pages

EPiServer CMS uses an adapted error page for "404 Not Found" to handle requests for directories that only exist in EPiServer CMS and not in the file structure. The page stated here is /Util/NotFound.aspx as standard. This is not a requirement and can be directed to any ASP.NET page without disturbing the EPiServer CMS functionality.

Document Security

It is standard for all uploaded files to be publicly available for visitors, i.e. there is no access check or dependence on the page's publication status. This is because the files are delivered directly from IIS and not via EPiServer CMS. This is acceptable in most cases, that is to say if you do not work with sensitive information, e.g. on extranet, or information that may not be publicly available before the publication date.

It is possible to configure uploaded files to be managed by EPiServer CMS instead, where you can set the access rights on directories directly from file management in Edit mode. You can also configure so that the page's directory inherits the same access rights as the page. This is so that documents will not be available before the page is. The EPiServer CMS file functions are called Unified File System and the configuration is described in detail in the Technical note, "Unified File System".

When Unified File System is set up, all files are moved to a protected directory, publicly unavailable from Internet, in the operating environment. All links that, for example, point to upload, will continue working as EPiServer CMS takes over all file access to this directory and handles access control. It is possible, for example, to give certain editors access rights to change in certain directories, or only extranet users access to a particular directory.

ASP.NET Configuration

This chapter focuses on some important points concerning the general operation of the ASP.NET environment, some of which are related to EPiServer CMS.


EPiServer CMS does not use sessions, neither in Edit nor Admin mode. If the templates on the Web site do not use sessions either, you can inactivate them, so as not to unnecessarily use server resources. Do this by setting the mode attribute to "off" in web.config under the sessionState part. See Microsoft KB Q306996 for more detailed instructions.

If a Web site saves information that is critical to the company in sessions, e.g. a shopping basket on a shopping site, you should consider not saving sessions in the ASP.NET process as is standard. You can choose to isolate the sessions handling to a state server, or to a database. See Microsoft KB Q311209. The advantage is that information in sessions will not be lost when ASP.NET or the IIS restarts. The disadvantage is that they negatively affect performance.

Timeout for Logout

If the Web site uses forms authentication, the users that are logged on will be automatically logged out by .NET after a certain period of inactive time. This period of time can be changed in web.config by setting the timeout attribute, which states timeout in minutes, on the forms part under authentication.

Release Mode

Make sure that the .dll files in the bin directory that belongs to the Web site are compiled in Release mode. A .dll file that is compiled in Debug mode is larger, uses more memory and is slower than the one compiled in Release mode.

Dynamic pages and user controls also have script-like code, which is compiled when needed by ASP.NET. In order for this to be compiled in Release mode, change web.config by changing the value for the debug attribute to "false". If it is a problem that pages compile when required, e.g. loss of performance, you can also state that all the pages should be compiled at once during compilation. This is done by setting the batch attribute to true.

EPiServer CMS Configuration

The EPiServer CMS installation program automatically applies a configuration template at first time installation. This, among other things, sets file access rights and certain settings in IIS. Refer to the EPiServer CMS Configuration Tool chapter for further information.

All settings configured by an administrator are saved in the web.config file. Some of these settings are also available in Admin mode under System settings and can also be displayed for all installed EPiServer CMS sites in EPiServer CMS Manager.

Roles and Authority

In web.config, you can define which roles will have access to which parts of EPiServer CMS. There are mainly two parts that need to be secured: Edit and Admin. These are limited to the roles WebEditors and WebAdmins as standard, but these settings can be changed as you wish. A role is normally the same as a group, if you log on with Windows or an EPiServer CMS user.

Encrypt web.config

EPiServer CMS has built-in support for encryption of sensitive information in web.config. From System Settings in Admin mode, select the Encrypt the web.config file check box to encrypt the information for the database connection, which also has a database login and password, and the user information to connect to the LDAP server. These settings will be saved in encrypted format.

You can also enforce encryption of approved settings in web.config under the <appSettings> section, by editing web.config in a text editor. To activate encryption for a setting, add the text ENCRYPT in the value attribute before the value in question, e.g. to encrypt the Upload directory (EPsUploadDir), change

<add key="EPsUploadDir" value="/upload/" />


<add key="EPsUploadDir" value="ENCRYPT:/upload/" />


Go to System Settings and save the settings. If you now look in web.config, you will see that the line has changed to

<add key="EPsUploadDir" value="ENCRYPTED:E5Gy6C+QpqCEbO0Xcq5oecIrMEy7E4qfil" />

Note that, for security reasons, EPiServer CMS will never save settings that have been encrypted once as decrypted. That is to say that if you have encrypted settings once, you can only view them in plain text in web.config by editing the file by hand and entering the required values.

If you encrypt information in web.config, it will only be available in plain text via the EPiServer CMS configuration object and not via ASP.NET's built-in configuration object. We recommend that developers always use the built-in object in EPiServer CMS.


EPiServer CMS has several built-in cache functions, some of which are activated as standard and others, which must be activated manually. A correctly setup cache is extremely important for good performance.

Page Cache

Pages and page listings are cached internally, so that an API call from a dynamic page will not result in unnecessary database calls. If access to a page does not take place during a 12-hour time period, the page will be removed from the cache. At the next access, it will be read from the database again.

The length of this time period can be changed in web.config via the EpnPageCacheTimeout setting. If this value is changed to "0", the cache will be turned off. This may be useful when searching for errors, but is not recommended for operation. The performance is considerably affected if this cache is turned off.

Locking Management

If several users request the same page information at the same time, and this information is not already in the page cache, there may be several parallel reads from the database whilst the cache is being populated. This can negatively affect performance, if there are a lot of pages to be read, e.g. listings and tree structures. Parts or all of the cache are repopulated when changes occur, or if the application has just started.

To avoid this happening, EPiServer CMS uses optimistic locking management. This means that if a page is already being read to the cache, the next request for the same page will wait for the previous read to be completed. Two configurable parameters in web.config are used for the wait function: EPnCacheSpinlockCount and EPnCacheSpinlockTimeout. If nothing is stated in web.config, SpinlockCount will be 10 and SpinlockTimeout 1000 — timeout is stated in milliseconds — which is optimal in most cases.

An indication that these parameters may need trimming is if you listen to the traffic to the database server and see a large amount of calls to stored procedures netPageDataLoad and/or netPageListLoad with exactly the same ID parameters. Note that this may also be a sign that the cache is turned off. If this is not the case, try increasing SpinlockCount and decreasing SpinlockTimeout. Make sure that SpinlockCount * SpinlockTimeout is not more than 10 seconds, as the product of this is the maximum time for reading to the cache to be completed.

Output Cache (HTML Cache)

A dynamic page can be cached as a static HTML file on the server. These functions in EPiServer CMS are built around the output caching concept in ASP.NET. Output caching is only suitable for Web sites with many anonymous visitors, and is not standard for this reason. EPiServer CMS has its own functions that ensure that output cache is not activated for users that are logged on, as different users see different content depending on access rights and personalized information. Output cache is only activated by EPiServer CMS for common page requests of type "GET", and not for postings ("POST").

A page is normally built up with information from several other pages in EPiServer CMS, e.g. news listings and tree structures. All changes (publications) from Edit mode will, for that reason, delete all the information that EPiServer CMS has placed in the output cache. That is to say that the cache will be reloaded the next time a page is accessed. If templates contain data that vary over time, e.g. a server-generated clock, you must state how long the page can be cached as HTML, so that the information, in this case the time, will not be incorrect.

Set EPnCachePolicyTimeout in web.config to activate output cache. This states how many seconds a caching is valid. To achieve the best performance, you should have, on average, more than one hit per unique page during the period of time (EPnCachePolicyTimeout). Otherwise it is just an unnecessary load for the server, as the cached variant will probably never be read. The recommended setting is at least 3600 seconds or 1 hour.

The output cache varies based on the Web browser type and the page ID. These values can, however, be customised in EPsCacheVaryByCustom and EPsCacheVaryByParams. If an installation has, for example, a query string parameter "print" that controls how the page is adapted for printout, EPsCacheVaryByParams must be changed to "id,print".

User Cache

Information concerning the roles that a user belongs to, along with personalized information, is read when a user logs on. This data is cached, so that the information does not need to be re-read for each new page viewing. User information that is not read for 5 minutes is removed from the cache. The length of this period of time can be changed in web.config via the EPnUserCacheTimeout setting. If this value is changed to "0", the cache will be turned off. This may be useful for troubleshooting, but is not recommended for operation. The main advantage of this cache, from a performance point of view, is obtained when the group membership is read from Active Directory, or another external source that requires more resources than a local database lookup.

Shared Hosting

Shared hosting is when several EPiServer CMS installations or other ASP.NET applications are operated for several customers on the same server.

Roles and Users

In order to cut down on administration, we recommend that each installation/site only has one superuser account created in Windows, and that the customers themselves set up EPiServer CMS users for editors and administrators. The superuser account can then be used for, e.g. FTP access.

The disadvantage of using Windows users, and therefore Windows groups, for role membership is that these apply to the entire server and all sites. That is to say that if two sites use the same groups or roles by mistake, the users can access each other's sites. If you use EPiServer CMS users and EPiServer CMS groups, these will only work per site.

A simple rule of thumb is that, in a hotel environment, the standard groups WebEditors and WebAdmins should never exist in the Windows account database. If the general groups exist, you cannot add users to them. Only operators, for example, who need to access several sites can add users.

It is possible to remove the Write access rights for the ASP.NET account and only allow the superuser account to write to the web.config file. This will result in only the superuser account being able to save new System settings and not common EPiServer CMS users.

Limitations in Windows 2000

ASP.NET uses a general account that the ASP.NET processes run under. This cannot be changed per site in Windows 2000. This causes a security problem, as a site could, code-wise, be able to access information from another site. Unfortunately there is no good solution for this, as it depends on Windows 2000 architecture. Microsoft Windows 2003 Server, which has a new process model in Internet Information Server 6.0, solves this problem. Windows 2003 Server is, therefore, recommended for all types of ASP.NET shared hosting. Make sure first that your EPiServer CMS version supports this platform.

EPiServer CMS Configuration Tool

The installation program automatically applies a configuration template at first time installation. This, among other things, sets file access rights and certain settings in IIS. There is a tool that is used to be able to run this template and other templates manually. A template is defined in XML format, which contains file access rights, IIS settings and web.config settings. This template can then be run by EPiServer CMS Configuration Tool to apply its access rights and settings on an EPiServer CMS installation. There is currently a base template, which is used at installation. It is, of course, possible to customize this template or build your own templates according to the organization's wishes and security requirements.

Template Syntax


The template with settings for a configuration is built up as an XML file containing 3 main parts: file access rights (XML tag acl), Internet Information Server settings (XML tag metabase), and ASP.NET configuration (XML tag web.config). Each main part is placed under the respective location in the structure, when the settings are to be applied (XML tag location). This chapter describes these parts in further detail.

<?xml version="1.0" encoding="iso-8859-1"?>

<configpackage version="1.0">

       <name>Test config</name>

       <description>Test only</description>


              <location path="admin”>







The example above states the path to the admin directory. If you do not state a path by removing the path attribute, the configuration will apply to the root directory. State a new location element for each part that needs to be configured.


The section modifies settings in web.config. There is no limitation to the elements that can be entered here. All elements will be transferred to web.config under the location in question. This function has been tested with the authentication and authorization elements, but should work with all elements.


This section sets access rights (ACL or Access Control List) on files and directories. See the example below:


       <add name="System" value="Write"/>

       <add name="{Administrators}" value="All"/>

       <add name="{IUSR}" value="Change"/>

       <remove name="{Everyone}"/>



This section modifies Internet Information Server's underlying database metabase, which is built up of properties. Four different elements can be stated under this section: add, remove, set and collection. "Add" only adds properties if they do not already exist. "Set" that always allots the values. See the example with syntax below:

<metabase inherit="true">

<collection name="HttpErrors">

       <set name="404" value="*,URL,{RootDir}Util/NotFound.aspx"/>


<set name="AuthAnonymous"  value="True"/>

<add name="AuthAnonymous"  value="True"/>

<remove name="AuthAnonymous"/>


The inherit attribute above defines whether settings from the parent in the directory structure should be included and write over any existing settings on this level. To learn more about which properties IIS saves, we recommend the MetaEdit program, which is available on Microsoft's support site, (see Microsoft KB Q232068).


There are certain constants that are automatically translated to the correct values, depending on language and settings.




The application's root directory, e.g. / or /MyDirectory/.


The name of the local administrator group.


The name of the account used by IIS for the application, if it is run in-process.


The name of the account used by IIS for the application, if it is run pooled.


The name of the local group for anonymous users.


The latest version of EPiServer CMS Configuration Tool can be downloaded from See the Links and References chapter.

Load Balancing

This chapter is an introduction to EPiServer CMS load balancing.


Directories that editors upload files to should be on a central file server. This requires that the account that an application runs under has network access to this server.


In order for all servers to be notified about cache updates in EPiServer CMS, each server must recognize all the other servers within the respective application. In web.config you configure a comma-separated list of site names under EPsCacheListeners.

State and Sessions

EPiServer CMS does not require sessions, but different applications built on EPiServer CMS may do. ASP.NET can either use a state server or a database to save sessions. These settings are done directly in web.config for the installation.


In order for authentication and view state to work in a load-balanced environment, all the servers must have a common machine key. This is configured in machine.config, which contains the main configuration for .NET on a machine. See Microsoft KB Q323744 for further information.

Performance and Load Measurements

EPiServer CMS has good scalability and performance properties, but it is up to administrators and developers to be able to make full use of these. This chapter describes how you can easily check how much an EPiServer CMS application stresses the system, and find any "bottlenecks", which can be fixed in due time. The first step is to simulate workload.

Simulating Workload

Workload is simulated, for example, by using tools provided by Microsoft. Use either Application Center Test (ACT), which is included in Microsoft Visual Studio Enterprise Edition, or the free tool Web Application Stress (WAS). See Microsoft KB Q313559 for information on download and configuration.

As the results from a stress test differ greatly depending on, e.g. how you configure the test, the different hardware, complexity in the tree and listings, and personalization, the best solution is trial and error. The aim of the test is mainly to get an idea of whether the installation will be able to handle the predefined requirements.

It is suitable to start by only loading the first page, as this will take the majority of all the incoming requests, and it is often this page that is most complex.

You can then continue and record a more complex scenario, where you simulate a typical user's interaction with the Web site.

The following chapter describes the parts that should be monitored during workload.

Performance Monitor

The easiest way to see if the system is being loaded to its maximum is to monitor the CPU workload on both the Web server and database server. The Web server's CPU will normally increase to 100% before the database server, as there are several cache functions in EPiServer CMS that reduce the amount of database requests.

EPiServer CMS has several built-in performance counters. See the table below.



Data Factory Reads/Sec

The amount of page data reads per second that EPiServer CMS delivers. A complex template can display data from several different pages in the EPiServer CMS structure, which is why this value can vary between different templates.

Data Factory Listings/Sec

The amount of page data listings per second that EPiServer delivers. A complex template can display listings from several different pages in the EPiServer CMS structure, which is why this value can vary between different templates. Tree controls use listings, which is why this value varies depending on how the tree navigation is implemented.

Data Factory Cache Hit Ratio

Indicates in percent how many of the reads and listings were delivered from the cache object. This value should be close to 100% during heavy workload. Otherwise you may have a problem somewhere, either because the cache is turned off or because a template goes past the cache for some reason.

Authentication Requests/Sec

The amount of authentication requests that are made per second. If you do not use users that are logged on, this value will constantly be zero.

Database Connections/Sec

The amount of database connections EPiServer CMS opens per second. This slightly depends on the type of functions you use in EPiServer CMS. If all the information is cached, this will constantly be zero. Certain functions, like searches in the entire database, are not cached.

SQL Profiles

If the database is very heavily loaded, e.g. CPU workload rises to 100% for several seconds, you can monitor exactly which traffic goes to the database. Your priority should be to check the most common calls. Most stored procedures in EPiServer CMS begin with the prefix "net" and are followed by the type of action, which is often obvious without needing detailed knowledge about the database, e.g. netPageList, which does a page listing. If you are unsure of what a database call really does and cannot trace it to a function in a template, contact the developer or EPiServer Support.


A Page Has Suddenly Started Requesting Login

Check that the role in question has Read access rights for the page in question, and also all the pages that this refers to, e.g. news listings. Note that if a user does not have access rights to a page that is included in a news listing, this will not be displayed. The user must, however, have access to the source, which in this case is the parent to the news. Apart from the access rights on the pages, EPiServer CMS can require higher access rights than those configured, so that a user cannot see information that is protected for other reasons. These reasons could be:

  1. The page has been moved to the Recycle Bin.
  2. The page's publication date has passed.

Error Message: Could Not Load Type 'development.Global'

The first thing that happens when ASP.NET loads an application is that it loads global.asax and the class behind this file that, as standard, is called "Global". That is to say that if there is an error in the .dll file that belongs to the templates, this is the first error message that appears. This error normally occurs, because the Web site's .dll file does not exist in the bin directory or does   not contain the class development.Global.