This is very important to setup if you have more than one web server or an enterprise site with several start pages because if it does not invalidate cache, the other web sites can potentially return old versions of a page!

Pitfall – Default configuration is using Multicast UDP!

If you read Configuring EPiServer CMS 5 R2 SP2 Enterprise you will learn that all you have to do is to set enableRemoteEvents="true" in web.config.

It is only mentioned briefly that it is using UDP and you may have to change your firewall settings. Too be more specific the default configuration is using multicast UDP broadcast! Tell this to your network guys and watch their reaction…

If you look around you will also find a tech note about the Event Management System Specification and a FAQ about setting up a server to use TCP protocol but not all clues needed are found there – you have to dig with the reflector to find out the rest.

Scenario: 4 start pages, 8 Front-end servers IN DMZ and 2 in LAN

You can change how the Event Management System communicates by changing WCF settings in web.config. It is possible to use TCP instead of UDP and also specify ports to use.

First, the current release (5 R2 SP2) does not support WCF Port Sharing so we need one port opened in the firewall for each start page (that is when you have several siteSettings-tags in web.config).

In our case we need to get four ports (for example port 13000-13003) opened in the firewall for TCP traffic between servers in DMZ and LAN.

Use the sample configuration below as a template to get it to work. In production I suggest using configSource-attribute in web.config to keep the WCF-settings in separate files.

Web.Config

<system.serviceModel>
  <services configSource="system.serviceModel.services.config" />
  <client configSource="system.serviceModel.client.config" />
  <behaviors>
    <serviceBehaviors>
      <behavior name="DebugServiceBehaviour">
        <!--TODO: the option should be only in test environment true in the production should be false-->
        <serviceDebug includeExceptionDetailInFaults="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
  <bindings>
    <netTcpBinding>
      <binding name="RemoteEventsBinding">
        <security mode="None" />
      </binding>
    </netTcpBinding>
  </bindings>
</system.serviceModel>

system.serviceModel.services.config

Use this to configure WCF Services (listens to incoming messages). Setup one service for each EPiServer site-tag.

• Name should be unique.
• Name must be the value of episerver/sites[siteid] plus "/EPiServer.Events.Remote.EventReplication", i.e. if siteId is “sss.se” then name should be “sss.se/EPiServer.Events.Remote.EventReplication”.
• Each site must use a diffrent port in services/service/endpoint[address].
• Use "localhost" in the address attribute to bind to all NIC on the machine.

<services>
  <service name="sss.se/EPiServer.Events.Remote.EventReplication" behaviorConfiguration="DebugServiceBehaviour">
    <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13000/RemoteEventService" binding="netTcpBinding" />
  </service>
  <service name="sss.no/EPiServer.Events.Remote.EventReplication" behaviorConfiguration="DebugServiceBehaviour">
    <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13001/RemoteEventService" binding="netTcpBinding" />
  </service>
  <service name="sss.dk/EPiServer.Events.Remote.EventReplication" behaviorConfiguration="DebugServiceBehaviour">
    <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13002/RemoteEventService" binding="netTcpBinding" />
  </service>
  <service name="sss.com/EPiServer.Events.Remote.EventReplication" behaviorConfiguration="DebugServiceBehaviour">
    <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13003/RemoteEventService" binding="netTcpBinding" />
  </service>
</services>

system.serviceModel.client.config

And each server that changes the content must also be aware of where to send notifications so we must list all servers and websites.

• Name should be unique.
• It is better if address contains IP-addresses than hostnames.
• There should be one endpoint for each website on a server where port number matches the ports used in the services/service/endpoint[address].

<client>
  <!-- SERVER1 -->
  <endpoint name="sss.se-SERVER1" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER1:13000/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.no-SERVER1" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER1:13001/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.dk-SERVER1" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER1:13002/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.com-SERVER1" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER1:13003/RemoteEventService" binding="netTcpBinding" />
  <!-- SERVER2 -->
  <endpoint name="sss.se-SERVER2" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER2:13000/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.no-SERVER2" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER2:13001/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.dk-SERVER2" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER2:13002/RemoteEventService" binding="netTcpBinding" />
  <endpoint name="sss.com-SERVER2" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="net.tcp://SERVER2:13003/RemoteEventService" binding="netTcpBinding" />
  <!-- Repeat pattern above for all other servers and sites -->
</client>

Good luck! And let me know if this helps you or if you get stuck…

Credits to Petter Klang at EPiServer Support and Shahram Shahinzadeh on the backend dev team that has been helping us out.

I guess you have already checked that the path is correct several times and that you have deployed all DLL’s and ASP.NET files. What is wrong?

LoadControl() parses and compiles your markup

A quick look with reflection reveals the LoadControl() is called to verify that the web part really exists. When you ask ASP.NET for a user control it will parse the ASCX-file, generate code and then compile it.

So there is a lot that can go wrong and all exceptions from this process is swallowed by the user interface and replaced with virtual path could not be loaded.

A good way to actually see the exception is to create a dummy aspx file and register all user controls and reference them from markup. When you try to view the aspx file any compilation error from the user controls will surface.

Examine compile and pages tag in your web.config

The most common reason markup works fine on one machine but not another is differences in web.config. Check the compilation and pages tag and compare them for differences between the machines.

In EPiServer CMS 5 you will always get a read-only PagaData instance and if you want to modify it you have to call CurrentPage.CreateWritableClone() to get an instance that you can modify.

Read Dynamic Propety value returns null

On the read-only version you can always write CurrentPage["MyDynamicProperty"] or CurrentPage.Property["MyDynamicProperty"] to easily get hold of the inherited value. But if you try to do that on a writable PageData instance it will not work and you will always get null back.

In my case when I want the value of a dynamic property in a custom property controller it always returned null because in when you are editing the page your PageData instace is writable.

Using DynamicPropertyTree to FindDynamicProperty

You can retreive the value of a Dynamic Property with the same method that a read-only PageData use if you need it while modifying a page. 

PageReference locationRef = DynamicPropertyTree.Instance.FindDynamicProperty(“MyDynamicProperty”, CurrentPage.Property).Value as PageReference;

Change a Dynamic Property from code

If you need to change a Dynamic Property from code use the class EPiServer.DataAbstraction.DynamicProperty:

DynamicProperty myDynProp = DynamicProperty.Load(CurrentPage.PageLink, "MyDynamicProperty");
myDynProp.LanguageBranch = "sv"; //Only if you have unique values per languge
myDynProp.PropertyValue.Value = "My Value";
myDynProp.Save();

You will also find method like ListForPage(PageReference pageLink) that returns a list of all Dynamic Properties for a given page. DO NOT USE that method in when you just want to read a value! Use you PageData class instead for faster access.

StarCommunity does not work EPiServer Friendly URL Rewriter

I had this issue with StarCommunity 2.4 from NetStar (now bought by EPiServer) and you could get the most strange side effects in the admin interface with tabs not working, layout issues and navigational problems. All issues disappear if you disabled EPiServer Url Rewriting.

So how can you keep EPiServer Url Rewriting on but disable it for a folder or file? This is how I solved it by adding a few lines in Global.asax.cs:

private void UrlRewriteModule_HttpRewriteInit(objectsender, UrlRewriteEventArgs e)
{
    UrlRewriteModuleBase module = sender asUrlRewriteModuleBase;
    if (module != null)
    {
        module.HtmlAddingRewriteToExternalFilter += module_HtmlAddingRewriteToExternalFilter;
    }
}
private void module_HtmlAddingRewriteToExternalFilter(objectsender, UrlRewriteEventArgs e)
{
    string path = e.Url.Path.ToLowerInvariant();
    e.Cancel = path.StartsWith("/netstar") || path.EndsWith("trace.axd");
}
protected void Application_Start(Object sender, EventArgs e)
{
    EPiServer.Web.UrlRewriteModule.HttpRewriteInit += UrlRewriteModule_HttpRewriteInit;
}

As you can see when the application starts it hooks into an event that hooks into another event that has the possibility to prevent Rewrite. Here we check if the requested URL is either starting with “/netstar” disabling rewrite for everything in the StarCommunity admin folder. It also cancels if it is a call to the trace utility.

Change EPiServer.SchedulerSvc.exe.config FILE

You need to add the following to the service’s config-file to get detailed call stacks for exceptions that occur in you web application:

<system.runtime.remoting>
  <customErrors mode="Off"/>
</system.runtime.remoting>

Update EPiServer.SchedulerSvc Registry

Prepare a folder for the log file and make sure the account running the service has write access. I’m usually lazy and give everyone full access since this logging usually is not left on forever.

User RegEdit and change the ImagePath value for the EPiServer Scheduler Service to include a parameter with the log-filename.

HKLM\SYSTEM\CurrentControlSet\Services\EPiServer.SchedulerSvc
ImagePath = C:\Program Files\EPiServer.Scheduler\EPiServer.SchedulerSvc.exe D:\Log\EPiServer.SchedulerSvc.log

Be careful when you edit the Registry! I use to export the key to a file before I change anything so I can look at the original configuration.

See also: Auto Restart of EPiServer Scheduler Service

Requirements for Scheduled Jobs in EPiServer

Several things must be true for tasks to be executed:

• The Service must be running
  The service is installed and updated by EPiServer manager but you may have to configure it and setup the in the computers Administrative Tool for Services.
• Each EPiServer Web must be allowed to use the Service
  There is only one instance of the Service but there might be several Web Applications. Each has a setting that controls if they are allowed to connect to the service or not. This often misunderstood setting is displayed on the Capability page in EPiServer Manager.
• Each Job must be active and have a schedule
  You must also for each Web Application go to admin mode and enable each Scheduled Job by checking Active and give it a schedule.

The EPiServer Scheduler Service does not appear to be active

If you have satisfied all requirements above and it suddenly stops working it can be an uncaught exception that halts your service.

My recommendation is always to configure the EPiServer Services to automatically restart if it should stop unexpectedly. This can be done from the Recovery Tab in the Properties for each Service.

Update

See also: Enable debug logging for EPiServer Scheduler

This area of the product is still one of EPiServer weaker areas mainly because the error massages when something goes wrong does not contain enough information.

I want to share the last issue I run into today and also show how I did to find out what was wrong. We could not export and only got this lovely message:

The following errors have occurred: Exception: Object reference not set to an instance of an object.[]

As you can see not much to go on here…

Strategy to resolve issues with EPiServer Export

First thing you should do is to narrow down what is causing our problems and a call stack can often help. 1) We need to attach your debugger to the web server.

2) We must make sure it halts on thrown exceptions even if it outside our code. Open your options dialog and uncheck”Enable Just My Code”.

With default settings the debugger will only break on uncaught exceptions.

3) We need the debugger to break when an exceptions are thrown regardless of they are handled by a try-catch statement.

This can be changed in your Exceptions dialog (Ctrl+Shift+E). You can either set it to catch all managed exceptions as I have in the screen shot or if you know what exception you are looking for you can halt on that one alone.

We are now ready to start the export again to trigger the error. If everything is correctly configured it will break on the exception and show you a call stack.

Analyzing the call stack and Disassembling EPiServer

With a call stack we have more clues to go on. In this case the two methods on top of the call stack gives us valuable clues.

Use Lutz Roeder’s .NET Reflector and click File>Open to load all assemblies in your web applications bin-folder. Search for the class or method and Disassemble the two methods and get more clues.

PropertyCategoryTransform.TransformCategoryForExport
PageTypeTransfer.Export

In this case it is probable that calling split on categoriesAsIds when categoriesAsIds is null is the culprit.

Looking at the calling method we can see that it is calling TransformCategoryForExport for PageDefinitions (a PageDefinition is another name for a property on a page type) if it as a Category. It does so to convert the Default Value for a Category property into a string with names instead of integer ids.

Conclusion and workaround

It is not possible to export a page type if you add a property of type Category selection (in EPiServer CMS 5 RC1 SP1 5.1.422.122). The reason is that default value is null and an easy workaround is to set the default value to “1″ for each added Category property. The value “1″ is the root category.

I have and the reason is of course that I use my developer license file in more than one place.

To workaround this problem you can always restart EPiServer Scheduler Service and recycle your application with an iisreset.

EPiServer appears to use the Scheduler Service for more things than just executing scheduled tasks. It is used when a central communication point is required like when you need to synchronize licenses between web applications…

As you probably know this is configured in Admin Mode on each Page Type. What you probably don’t think about is that these settings can make it impossible to import and export pages.

“Available Page Types”-rules can break import

If your rules change over time or if you use Stop Publish and Archive Page so your pages moves around you can get in trouble with these rules.

In the current version (5.1.422.122 SP1) the import will stop with an error and it can be quite hard to figure out what is wrong.

I created a SQL-statement to help you figure out what is wrong. It will give you a list of all pages breaking the “Available Page Types”-rules. It lists the Parent and Child’s Page Id, Page Name and also Page Type.

This (messy) SQL statement for copy paste:

SELECT fkParentID AS ParentPageId, pkID AS ChildPageId, (SELECT Name FROM tblPage AS p2 WHERE (pkID = p.fkParentID)) AS ParentPageName, Name AS ChildPageName, (SELECT fkPageTypeID FROM tblPage AS p2 WHERE (pkID = p.fkParentID)) AS ParentPageTypeId, fkPageTypeID AS ChildPageTypeId FROM tblPage AS p WHERE (NOT EXISTS (SELECT fkPageTypeParentID, fkPageTypeChildID, Access FROM tblPageTypeToPageType AS tt WHERE (fkPageTypeParentID = (SELECT fkPageTypeID FROM tblPage AS p2 WHERE (pkID = p.fkParentID))) AND (fkPageTypeChildID = p.fkPageTypeID))) AND EXISTS (SELECT fkPageTypeParentID, fkPageTypeChildID, Access FROM tblPageTypeToPageType AS tt WHERE (fkPageTypeParentID = (SELECT fkPageTypeID FROM tblPage AS p2 WHERE (pkID = p.fkParentID))))

Use the following script if you want to clear all the value of Archive page on all pages in your source database:

UPDATE tblPageTypeDefault
SET fkArchivePageID = NULL

Remember to do a iisreset to invalidate all cached information after you change in the database.

EPiServer and Memory

First thing to check is that you have enough memory. EPiServer needs a lot of memory to cache the PageData object for each of all active pages on the site. The larger site (more pages) you have, the more memory you will need.

The DataFactory class will first look if the requested page or list of pages is in the cache when you call GetPage() or GetChildren(). If it is not in the cache, the page or list will be loaded from the database and added to the cache. The default implementation (read more about pluggable runtime cache) uses ASP.NET’s built-in public cache to store pages and lists in memory.

The public cache in ASP.NET is also used to store other data in addition to EPiServer PageData and Lists. Periodically ASP.NET will use a Least Recently Used (LRU) algorithm to scavenge the cache for more space. If the memory pressure is very high the lifetime of cached items can be very short or even zero (not added at all). This is not good for EPiServer’s performance.

It is easy to see what’s inside your cache:

protected void Page_Load(object sender, EventArgs e)
{
    foreach (DictionaryEntry d in this.Cache)
    {
        Response.Write(d.Key);
        Response.Write(" - ");
        Response.Write(d.Value);
        Response.Write("<hr>");
    }
}

A very good indicator if Memory is an issue is to look at some statistics from the DataFactory class. You can see the Cache hit rate if you go to admin mode. It should be close to 100% or maybe a few percent below. (It is normal that it drops to zero when you restart the site but it should climb fast.) A constant low value is one indicator that you need more memory because PageData objects are thrown out of the cache and then they must be reloaded from the database.You can also see the Cache Hit Ratio (and some other counters) through Windows Performance Monitor. This is a good value to monitor in a hosting environment and add an alert when the value becomes to low.

ASP.NET Worker Process / Application Pool

The maximum memory ASP.NET allows a worker process to consume before it is recycled is by default 60% of the total system memory. Read more about memoryLimit tag.

<system.web>
<processModel>
<memoryLimit>60</memoryLimit>
</processModel>
</system.web>

Default Application Pool – Do not use it and do NOT delete it (even if you plan to never use it). Create your own pool instead but not create one pool for each site on the web server. Instead consolidate your applications into one pool and only use a separate pool for troublesome web applications. You must have separate pools for ASP.NET 1.1 and 2.0 applications though.

You can also configure the application pool to recycle if it consumes to much memory. If you worker process constantly recycles you need to find out why because EPiServer will always be a little bit sluggish after a restart (before data is cached again). You also loose all in-process session data when the process restarts which is an issue of its own.

Settings: I recommend that you uncheck “Recycle worker process (in minutes)” and use “Recycle worker process at the following times” instead.

You should also uncheck “Shutdown worker process after being idle”. This is very important for EPiServer sites that has a low traffic (for example during the night).

Do not use Web Garden unless you know what you are doing. It will require double memory for the cache and out of process state-handling. If you change the number of worker processes from 1 to 2 it is like having two web servers on the same box with IIS acting like load balancer. (It is a cheap way in a development environment to test how you application will behave in a farm with load balancing.)

MSSQL Server and EPiServer

Its a best practice to have two machines, one for the web server and one for the database. But sometimes you have to run the database on the same machine as the web server. If you do, it is important to remeber that the MSSQL Server competes with the Web Server for resources like memory. You should always limit the amount of memory the database can use because it is better for EPiServer to have data cached in the web application than in the database.

Usually the usage of the database is low (around 5% CPU) in EPiServer scenarios because EPiServer tries to cache what it needs in the web application. If you have a higher usage of the database this can be an indication of that caching does not work as it should in the web application but it could also indicate that you do something else wrong. (More about database issues in a later post.)

Other processes

Finally, do not forget to have use the ordinary task manager to check if you have other processes that compete for the memory on your web server.

You control the name, order and number of starting points in the File Manager for EPiServer CMS 5 by adding or removing Virtual Path Provides in web.config.

<virtualPath customFileSummary="~/FileSummary.config"> 

  <providers>  

    <add showInFileManager="false" virtualName="Page Files" virtualPath="~/PageFiles/" ... />  

    <add showInFileManager="true" virtualName="Global Files" virtualPath="~/Global/" ... />  

    <add showInFileManager="true" virtualName="Documents" virtualPath="~/Documents/"... />  

The virtualName is what you see in the File Manager.

You can hide providers from the File Manager by changeing the showInFileManager attribute to false but these providers will still be available from code. This can be usefull for generated thumbnail and similar.

If you open the File Manager without a page selected the first visible provider in the list will get focus.

There is usually a current page when you open the file manager in edit mode (either in the action window or as a modal dialog) and you will always see the page folder or get a question if you want to create a new page folder if it does not exist. There is currently no way to disable page folders in the current (5.1.422) release as far as I know.

Which Virtual Path Provider that is used to store Page Folders is also controlled in web.config.

<episerver ...> 

  <sites>  

    <site ...>  

      <siteSettings ... pageFolderVirtualPathProvider="SitePageFiles" ... />  

A common mistake is to mix up the Page ID and the Page’s Folder ID. They are two separate number sequences and there is a property on the PageData obeject that stores the folder id for each page.

CurrentPage.Property["PageFolderID"].Value  

Follow this link to see more examples on how to use EpiServers Unified File System.

The property can either be defined directly on a page type or as a dynamic property so the value it can be inherited in a branch of the page tree. It is possible to both define properties as a dynamic and on page types. In this case the value on the page is used first.

This list does not include properties used by the public templates. I’m pretty sure I missed some properties so please, write a comment if you know of anyone I missed!

[EPiServerException: Can't find provider capability information for provider [XYZ].]
EPiServer.Security.ProviderCapabilities.IsSupported(String providerName, Action action) +117
EPiServer.UI.Edit.UserMembership.EnableFields() +418
EPiServer.UI.Edit.UserMembership.OnLoad(EventArgs e) +1201

The reason is because EPiServer only has hardcoded the capabilites for some of the default providers name like this:

static ProviderCapabilities()
{
_providerDictionary = new Dictionary();
_providerDictionary.Add("SqlServerMembershipProvider", new ProviderCapabilitySettings(true, true, true, new object[] { "email", true, "comment", true }));
_providerDictionary.Add("WindowsMembershipProvider", new ProviderCapabilitySettings(false, false, false, new object[] { "email", true, "comment", false }));
_providerDictionary.Add("SqlServerRoleProvider", new ProviderCapabilitySettings(true, true, true));
_providerDictionary.Add("WindowsRoleProvider", new ProviderCapabilitySettings(false, false, false));
}

To get it to work if you have providers with other names you must obviously register them manually (at least until EPiServer provides a better sollution) in Global.asax.cs. This is how I did it:

private void RegisterCapabilitiesOnMembershipProviders()
{
string defaultMembershipProviderName = ProviderFacade.GetDefaultMembershipProviderName();
string defaultRoleProviderName = ProviderFacade.GetDefaultRoleProviderName();ProviderCapabilities.AddProvider(defaultMembershipProviderName, new ProviderCapabilitySettings(false, false, false, new object[] { "email", true, "comment", false }));
ProviderCapabilities.AddProvider(defaultRoleProviderName, new ProviderCapabilitySettings(false, false, false));
}protected void Application_Start(Object sender, EventArgs e)
{
RegisterCapabilitiesOnMembershipProviders();
}

Update: This has changed in SP1 so it uses the class type and not the name. So a rename of a provider does not require registration but you must register capabilities if you write your own.