Sitecore Installer Re-visited

Hard to believe, but it was close to a year ago that I released my Sitecore PowerShell Installer script. Since then I've continued to refine and improve upon it. Now seems like as good a time as any to take stock of the script.

Enhancements 

Installs 8.1 or 8.0

I've added a version checker in the script that uses Reflection to examine the version of the Sitecore.Kernel.dll assembly. This check then forces some behavioral differences during the script's runtime.

Robust Pre-Install Sanity Checking

Roughly 1/4 of the script is dedicated to validating configuration input and environmental health before any changes are made to the server. If I had a time machine, I would go back in time to the day I started the script and add a install counter. It's hard to pin down an accurate estimate of how many times I've used the script to install Sitecore, but I know I would need at least three digits! :)

More Sitecore Roles

Originally, the script was intended for CM/CD installs. Since then I have added more specialized roles like a Preview CD and a Publishing server.

Optionally Disable All Database Operations

Do you have to deal with intransigent DBAs? If, for some reason, you simply cannot allow the script to connect to SQL and write changes, then you can still use the script to automate everything else.

Full Compliance with MongoDB's Connection String Specification

If Mongo allows for it, then so does the script. You can review the specification here.

Multiple Bindings in IIS

This is useful if you are running a multi-site instance or use load-balanced servers and wish to provide dedicated host names/IPs in addition to the load-balanced binding.

Change Default Admin Password

I worked very hard to ensure that servers were properly hardened during install. Yet, somehow, overlooked this basic but necessary change! Of course you could make this change manually, but if you wish to automate the installation of entire server environments this is a simple but important addition to the script.

Role-Based Config File Examples

The installer script's run-time is governed by a .config file that contains all the information needed to install Sitecore. To help people get started using the script, I've created a number of example configuration files according to Sitecore role.

Philosophy of Use

My general approach to managing and customizing Sitecore is through package deployment -- typically .update package. This, in turn, informs how I think about installing Sitecore. As a general rule of thumb, I want to make any system change that I cannot (easily) do through an .update package. I want to configure the server into a standard role that is suitable for smoke testing, but I don't want to turn an installer into an application management solution. This is same basic position I've maintained since I wrote the original version.

What doe this mean in a practical sense? As much as possible, I try to avoid modifying stock .config files. There are a handful of exceptions, some of which I wouldn't have predicted back when I wrote my original blog post. Here are the list of files I do modify depending upon the specifics of the install:

• web.config
• DataFolder.config
• Sitecore.analytics.tracker.config
• Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config.example
• ScalabilitySettings.config
• Sitecore.Publishing.Parallel.config

In addition, I will enable/disable any number of files depending upon the server role specified. For example, a CD server will have the SwitchMasterToWeb.config file enabled. Furthermore, I will place that file in an appropriate folder (e.g. zzzMustBeLast or Z.SwitchMasterToWeb).

So what are some examples of what I won't do? My script will not 'turn on' Solr. Doing so depends upon having a Solr environment ready to go. I have provided a script to switch between search providers however. I won't create new indexes or new indexing strategies if you provision a Preview CD server, nor will I ensure your indexing strategies are appropriately configured on a CD vs. a CM server. In my opinion, that is the job of some other process such as deploying an .update package that contains the appropriate .config file patches. The job of the install script is to ensure that each server is in a state ready to receive those packages and to eliminate the need to make any system changes outside the domain of an .update package.

Installer Configuration Tour

Future Enhancements

One idea I have is to isolate all sitecore config changes made by the installer to a single patch file. While the list of files that I make changes to today is fairly small, it would be an improvement if I made no modifications at all.

How else could I improve the script? Actually, I'd like to ask you that, dear reader. What would you like to see done, if anything?