Our Blog

where we write about the things we love



Deploying and load balancing EPiServer 5.2

Over the last couple of weeks I’ve been helping out on a website replacement project and one of my tasks was to install and configure the various servers - development, staging, UAT and production - and it has given me a few things to think about and talk about.


Normally EPiServer installation is performed manually using the EPiServer setup and Deployment Centre tools. However, for this project we attempted to script the entire process using PowerShell scripts. We have created a deployment tool with PowerShell - aptly named SuperDeploy - that we use for SharePoint installation and database creation. This is very useful for creating fully automated installations that we can use during development and when we need to install on the clients environment. So, it seemed natural that we should extend this to work with EPiServer. SuperDeploy uses a simple XML file to define what to install and where - the how is hard coded into PowerShell functions in the script.

Anyway, SuperDeploy works very well and provided a nice repeatable installation for all servers - up to a point. With a bit more work it could do everything but time is of the essence, so some manual steps were needed to finish off the production server.

The final production installation had two web servers identically configured. The EPiServer site files were installed to a folder on F:\ and this folder was mirrored between the two servers using Windows DFS - so changes to files on one server were automatically and instantly copied to the other server - essentially meaning we had a single set of files for both servers. We could have had the files on an external drive array of some sort but this would mean a single point of failure. Replicating the files between servers provides an extra level of redundancy. The EPiServer virtual file system (VPP) was also replicated using the same DFS mechanism. The SQL 2005 database was on a third server and this was mirrored using log shipping to a forth server.

Load Balancing

I’ve come to notice over recent years than when something looks hard and not very well documented – it turns out to be obvious and simple. Such is the case with the configuration of EPiServer load balancing.

Documentation of the setup of EPiServer load balancing is hard to find. In fact the only documentation I could find was a single blog post. This worried me somewhat as there isn’t a lot of detail in this post and it wasn’t an official EPiServer document. But I needn’t have worried - five of the six steps were correct but step four is applicable to IIS 6, not IIS 7 which we were using. For IIS 7, httpModules must be specified in the <system.webserver> section of the web.config – not in <system.web>.  You can also configure these in IIS Manager.

The setup of Microsoft NLB was already done for us and the tool linked to in the above post proved that the network was indeed setup correctly.

The hardest part was testing that the servers were actually load balanced.  Fortunately - a mistake by me editing the IIS config meant that one of the sites would not run. Browsing from a test client machine gave me an HTTP 500 error from IIS. It was impossible to know which server was failing so we disabled one of the servers from the load balancing by turning off the NLB agent. When the client browser was able to see the site correctly we knew a) which server was broken and b) NLB was working. Crude? Yes, but good enough. Some better testing is still required, of course, but that's another story.

Even the smoothest installation can have surprises. When we ran the site, we were prompted to log in to view the home page - which is strange as it’s a public website with anonymous access enabled. We compared the production server configuration of IIS and web.config to the other servers and these were identical - we thought. In the end, we configured the IIS anonymous access user to be the application pool account rather than IUSR and the setup was done.

Morals of the Story

EPiServer installation is easy - even for multiple load balanced servers. If you do have multiple servers then ensure they are identically configured - Virtual Machines are a life saver! Mirroring or sharing the site installation folder will help with this (but it also means a mistake on one server will potentially be a mistake on all servers - instantly!).

Script your installation as much as possible. It makes repeating your installation simple.

Install often and early - preferably as part of your development cycle. Don’t wait till the end of the development to test your deployment - YOU WILL REGRET IT - trust me! If you can, have your automated build cycle run your deployment script every night.

Be pragmatic. Perfect is great if you can afford it but customers and bosses are rarely willing to pay for this. Good enough is usually good enough!

Posted by: Peter Jones, Developer | 23 October 2009

Tags: EPiServer, Load Balancing, SuperDeploy

Top Rated Posts

Blog archive

Stay up to date with all insights from the Intergen blog