During a regular day at work, while working at an Umbraco 7 instance, a client asked me for an easier way to move content from development to production and vice versa. Any Umbraco user knows that any changes you make in development need to be replicated in production, unless you use a tool to do it for you. When it comes to tools, you have options: build your own tool (Umbraco gives you all the resources you need to build your own), you can use a third-party one, or you can use Umbraco Courier. I elected to use Umbraco Courier—it’s simple, £99 per site, really cost-effective, and if you meet their partner standards you get it for free.
Setting up your Umbraco Courier is pretty straightforward IF you don’t have a complicated setup for your servers. Login to Umbraco > Developer > Packages > Umbraco package Repository > Lookup for Courier > Install; answer a few questions; go to the new Courier section and login to download your license and get going. But, in this case, the configuration was not that straightforward.
Courier wasn’t accurately replicating the content that we employed it to replicate. The content wasn’t successfully transitioning through the URL rewrite rule and Courier wasn’t logging real information about the problems it was encountering. It took me working with three of their developers just to pinpoint the issue. Fixing it with our system would prove to be another challenge entirely.
Let me walk you through this client’s infrastructure setup and explain the problems I faced that required long hours and serious headaches to correct. With an understanding of that framework it will be much easier to understand how I corrected the issue.
The Root of the Issue
After installing Courier on our dev server and configuring the courier.config with my three environments (localhost, dev and prod), the first error we got was:
The stack for this instance might look like this:
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object parameters) at Umbraco.Courier.RepositoryProviders.WebServiceProvider.RepositoryWebservice.OpenSession(String sessionKey, String username, String password)
This was really frustrating. The logs don’t provide any real information about the problem as Courier is, apparently, very convoluted regarding licensing errors.
The client setup contained an ELB, which was hosting the SSL, in front of the EC2 instances for both dev and prod, and it incorporated URL Rewrite rules to enforce the http protocol.
How We Solved the Problem
To address this Courier problem check for the following in your Umbraco code:
- Client in AWS with load balancer
- Server where site is hosted
- Site has an HTTP to HTTPS rewrite rule which forces client to go from an open connection to a secure one
Once you’ve confirmed this is the issue you’re dealing with, you can address it easily. First, ensure all servers that will have Courier installed are up and running. If your production server is not ready yet, then only include the servers that ARE ready to be tested in the Courier Config file. Next, modify the rewrite rule to ignore all the Umbraco routes.
Once you’ve done this, Courier should be able to replicate your content accurately across instances and you can start taking full advantage of the software’s functionality such as large uninterrupted deployments to remote instances, custom automated deployment functions, and free open-source software.
To Address Your Own Umbraco Issues
While this step-by-step should help you correct this particular issue with Umbraco, we’re always eager to hear what other problems you may be encountering. Feel free to respond via email or in the comments section to highlight the Umbraco issues you’re currently struggling to remedy.