Sitecore 9.1 SIF Distributed Installation Forces Role Per Server
For those excited to run a Sitecore 9.1 SIF Distributed Installation, beyond what was detailed in the “Sitecore 9.1 SIF: Distributed Installation 101… and 1 Gotcha” and “WinRM over HTTPS for a Sitecore 9.1 SIF Distributed Installation” articles, there is another key aspect to consider… and its a big one.
Sitecore 9.1 SIF Distributed Installations force a role per server by default.
How Does it Force This?
Yes, you read correctly. While SIF for the individual roles for 9.1 ties the website bindings of each role to the desired DNS name, the distributed installation JSON by default forces the computer name to be used for the website binding… which will not allow multiple roles per server, as you can’t have two bindings with the same name. Sitecore Support confirmed this was by design.
You can see that for yourself if you open the XP1-Distributed.json. As an example, look at the call for the xConnectCollection role installation section (DNSName and SSLCert is set to ComputerName).
"Collection:ConfigurationParameters": {
"Path": "[JoinPath(variable('RemoteResourceFolder'), SplitPath(Path:variable('CollectionConfig'),Leaf:true))]",
"Package": "[JoinPath(variable('RemoteResourceFolder'), SplitPath(Path:parameter('CollectionPackage'),Leaf:true))]",
"SiteName": "[parameter('CollectionSitename')]",
"XConnectCert": "[parameter('CertificateName')]",
"SqlDbPrefix": "[parameter('Prefix')]",
"SqlServer": "[parameter('SqlServer')]",
"SqlAdminUser": "[parameter('SqlAdminUser')]",
"SqlAdminPassword": "[parameter('SqlAdminPassword')]",
"LicenseFile": "[JoinPath(variable('RemoteResourceFolder'), SplitPath(Path:parameter('LicenseFile'),Leaf:true))]",
"HostMappingName": "",
"DNSName": "[parameter('CollectionComputerName')]",
"SSLCert": "[parameter('CollectionComputerName')]"
Why is This a Problem?
Many that deploy Sitecore 9 will run xConnect roles on one server, or other roles in conjunction with each other, such as the CMS and Reporting roles.
With this force in place, you will be required to have 12 dedicated servers to run a minimal XP1 Scaled Deployment on IaaS. That is 1 for the Identity Server, 5 for the xConnect, 1 for Processing, 1 for Reporting, 2 for Cortex, 1 for CMS, and 1 for CDS (although you should have at least a load balanced CD front end if you are serious about scaling).
If you have development and staging environments to match your Production setup, you can see that this amount gets staggering.
In short, this is non-governable, not cost effective, and widens the attack area for Sitecore…
What Can We Do About It?
Before you get your pitchforks and torches out, this issue has already been raised with Sitecore as it was discovered as part of the Sitecore 9.1 Initial Release. And while it was there by design, it is simply bad design.
The hope is that it will be immediately addressed via Sitecore 9.1 Update 1 instead of going the way of SIF deployment to Azure SQL (still no SIF deployment to Azure SQL).
However, in the meantime you can deploy the individual roles for Sitecore 9.1 via SIF one at a time… or for the brave, attempt to modify the distributed installation scripts and JSON to “unforce” the computer name.
Was this ever fixed. I’m deploying 9.2 this way and I see no separate variable for host header. That would be a winner for me, let me specify a host header variable for each role separately from the machine name.
It has not been. I needed to modify the JSON (distributed file) to change the host name in IIS to not be the server name.
Oh, care to share a little more detail? I did see that recently and wondered if that was all that was required to make it set a different host header value in the IIS bindings? I was worried I’d have to hack up the SIF PS scripts as well.
Its more the JSON files that have to be modified, specifically the distributed json file where it is using computername:
Example
“DNSName”: “[parameter(‘CollectionComputerName’)]”,
“SSLCert”: “[parameter(‘CollectionComputerName’)]”