We have a requirement for setting up a dedicated CM server (CM2) that will handle scheduled publishes. Other publishing jobs the users are doing should be handled on the default CM server (CM1). How can we approach for this?
Sitecore Publishing Instance is nothing but a clone instance of Sitecore CM environment.
On CM server, open \Website\App_Config\Include\Scalability.config file. Update Publish Instance Name as below.
<setting name="Publishing.PublishingInstance"> <patch:attribute name="value">PI-Sitecore</patch:attribute> </setting>
If the value is empty Sitecore will use the instance name by combining the machine name and the IIS Site name. So for the IIS Site Sitecore on the server PI the instance name would become PI-Sitecore.
Just to remember, do not configure above setting on Publish Instance. Note: Sitecore allows to add only one publish instance name in this setting.
Enable EventQueue on both CM and PublishInstance servers. To enable EventQueues, from web.config, find EnableEventQueues setting.
Set its value to true. This setting can also be set from \App_Config\Include\ScalabilitySettings.config, which will be given more precedence over web.config settings.
<setting name="EnableEventQueues"> <patch:attribute name="value">true</patch:attribute> </setting>
Disable any scheduled tasks or agents running if not required.
More information you can find here
If you have setup 2 CM servers, both will be able to publish. So you need to make sure that they only publish their own jobs.
As SitecoreClimber mentioned, you can use the
Publishing.PublishingInstance setting for this.
If you look at the
ScaleabilitySettings.config.example file included in your Sitecore installation it says this:
<!-- PUBLISHING INSTANCE Assigns the instance name of dedicated Sitecore installation for publishing operations. When empty, all publishing operations are performed on the local installation of Sitecore. Default vaue: (empty) --> <setting name="Publishing.PublishingInstance"> <patch:attribute name="value"></patch:attribute> </setting>
So this means that if you only let your content editors log into
CM1, any publish job they run will execute on
Now you can simple setup a scheduled job to run publishes on
CM2. All jobs that run in the scheduled task on
CM2 will execute on
You will need to make sure that only
CM2 is setup to run the scheduled task that kicks off the scheduled publish.
I can confirm that such approach can be really useful from our experiences. We are using a quite huge infrastructure set-up for our solution: like five independent clusters, every cluster contain one CM for editors and another CM for publishing (+ other service jobs). There is even one global admin (CM) from where the contents are regularly distributed into the regional clusters.
Using separate CM instances (publishers) was the only option how we could achieve putting the fresh data into the CD instances relatively fast. Currently, every language is updated 3 times in hour by scheduled publishing jobs. In case we have around 15 languages in one cluster there is no other option than use a separate publishing instance.
Another advantage can be that you can tune-up the publishing instance appropriately (e.g. number of publishing threads, disable analytics, ...).