Language file for CMO

Currently CMO only ships with an English language file. So, if you run the EPiServer UI in another language you have to copy the original English language file and replace the language attributes to use it with your UI locale.

Simply make a copy of the original CMO_EN.xml language file…

…and set the language name and id attributes to whichever language you’re using (Swedish in this case):

Validate CMO permissions

If the CMO tab isn’t visible to a user you need to verify that the user belongs to a group with CMO permissions.

You can change which these groups are in the Security section:

Note that the user might have to log out and log in again in order for changes to take effect if you change these settings.

Allow thumbnail service to authenticate

This is required to get page variation thumbnails when using LPO (Landing Page Optimizer).

Go to Settings under the EPiServer CMO tab. Make sure to check the Authenticate thumbnail service option and enter the username and password of a valid EPiServer user which will give the thumbnail service read access to unpublished page versions.

The thumbnail service uses the credentials to login to the site (it does this by creating a login cookie, essentially “faking” a login through the standard EPiServer authentication form). Once these settings are set you’ll see thumbnails of the page variations, instead of just a login form screenshot:

CMO Live Monitor WCF service fails

If you add the CMO Live Monitor gadget to Online Center you may encounter an error saying “Failed to load root node!”:

This is most likely caused by a server error occuring in the WCF service used by Live Monitor. If you use Fiddler or some other debugging HTTP proxy you may see requests for http://site/Trace/services/TraceService.svc?campaignid=x failing.

Looking at the service using WCFStorm revealed the problem in my case: the WSDL document for the Live Monitor service included links where the domain name was replaced by the local computer name like: http://[SERVERNAME]/CMO/Trace/services/TraceService.svc. Obviously this fails when the request comes from the internet. :)

This has to do with how the WSDL is generated and is normally fixed by setting host headers in IIS (as opposed to a “catch all” where the site responds to all requests on port 80 and/or 443). However, because of how the production environment was set up in this case I had to do the following in web.config (the 111.222.333.444 IP address is the public IP of the web server):