This is all great, Brittany! Where do I get started?

First things first, I’m writing based upon my experience while using Umbraco v. 7.2.8. Take note that distributed calls get an upgrade with v. 7.3.

Set up your servers, making sure you have admin privileges. All servers must be on the same network, part of the same domain, and be able to communicate with each other using HTTP protocol. Configure IIS like normal, creating an authoring site on the authoring environment and a delivery site on the delivery environment. Here is a very important tip: For each site, even though they are different sites on different servers, they must have different ID values. Check this by going to the site’s Advanced Settings in IIS and looking for the ID field. If they are the same, like they were in my case, you need to change one of them. Set up publishing profiles in Visual Studio for the new authoring and delivery environments. I’ll call these ProdDelivery and ProdAuthoring. *

* I also set up environments for staging delivery and authoring with their own staging database server. I developed the majority of the site in a local testing environment and towards the end of development when it was time to setup production, I tested everything in the separate staging environment first. Keeping the staging environments for future testing prior to hotfixes and releases is up to the client, but well worth it. Transfer your development database to the production database server. **

** Before transferring the database to the new server, a quick tip is to login to the Umbraco back office and add the ProdAuthoring IIS Domain. You should also add localhost for now, as this will allow you access to Umbraco on each server while setting up and testing.

Transform web.config and insert or replace the new database details for web.ProdDelivery.config and web.ProdAuthoring.config. Transform umbracoSettings.config and now the fun starts! In your ProdDelivery and ProdAuthoring umbracoSettings.config file, you’ll want to add a distributedCall section. It is very important that this section is included on all servers for communication. It will not work if it is only on one server.

<!-- Make sure enable is set to true --> <distributedCall enable="true" xdt:Transform="Insert"> <!-- user 0 is admin --> <user>0</user> <!-- All servers will be listed here --> <servers> <!-- Authoring server always is listed first and is also referred to as the Master server. The serverName is the domain DNS name. The server node's value is the IP address of the server or the hostname of the site. --> <server serverName="WEB-AUTH">IP.ADDRESS.GOES.HERE</server> <!-- This server and any others after this are delivery servers and also referred to as Slave servers. --> <server serverName="WEB-DELIVERY">IP.ADDRESS.GOES.HERE</server> </servers> </distributedCall>

Enable the call and insert or replace the distributedCall section depending on what’s in your base settings file. I tend to remove sections out of my base config file that I’m not using globally for all of my transformed configs and then insert any unique sections in the individual configs. Users is set to 0 which is Umbraco Admin. For the servers section, you’ll need to pay attention to the order in which the servers are listed and the details of each server. The first server listed is considered the Master server and any servers listed below are Slave servers. The Master server is always the Authoring server. The serverName attribute is the domain DNS name. I recommend using the IP address for the value of the server, but the hostname of the site will also work. For example, if my authoring site is http://www.auth.site.com, I would use www.auth.site.com in place of 172.17.1.9. Publish your solution to both ProdAuthoring and ProdDelivery.

Time to test!

Testing your setup is quick assuming everything is perfect, which let’s face it—when is it ever perfect on the first try? Go to the Umbraco back office of the authoring site, publish a change, and verify that change has also happened on the delivery site. You’ll want to disable any caching on the site while testing so you’re not waiting around to check for the changes....Personal experience has made me pull my hair out from 30 minute caching that I failed to disable. Once the separation has been tested thoroughly, disable the Umbraco back office for the delivery site. There are a few ways of achieving this, such as in the delivery server site’s configurations in IIS or in the ProdDelivery web.config file. I’ll direct you to a solution found at the digbyswift blog that directs the Umbraco login page to a 404. See a code example from the blog of this approach below.

<rule name="Restrict umbraco access" stopProcessing="true"> <match url="^umbraco/?.*"/> <action type="CustomResponse" statusCode="404" /> <conditions> <add input="{HTTP_HOST}" pattern="^www.example.co.uk$"/> <add input="{REQUEST_URI}" pattern="^umbraco/Surface/.*" negate="true" ignoreCase="true" /> </conditions> </rule>

This process may not be suitable for every site or client. There will be additional server costs based on how many servers you set up. At a minimum and a good place to start for the majority of sites is with one database server, one authoring server, and one delivery server. The upside of doing this in Umbraco is that unlike other CMSes that have license costs per server or instance, Umbraco licenses are free for one and free for all!