SharePoint is an extremely flexible platform but it doesn't do everything, nor does it come with a full suite of management tools covering all scenarios - that's why the third-party vendor ecosystem exists. As I've worked with SharePoint focused on the Infrastructure side of things, there are a number of third-party tools that I keep coming back to time and again; I consider them invaluable for the specific need they are meant to address. The first of these tools is AutoSPInstaller, and I'll cover additional tools in future posts.
There are a few ways to install and configure SharePoint, including:
- Point + click your way through the wizard, resulting in GUIDs for database names
- Manually run PSConfig and then create/run numerous PowerShell commandlets and scripts
- Use AutoSPInstaller and stand on the shoulders of giants
Having performed installations using each of the methods above, I can say without hesitation that I'll take AutoSPInstaller every time (as you may have gathered).
Now, I'm not going to run through the step-by-step process of using AutoSPInstaller as there exist many good tutorials already, rather I'll focus on why I think AutoSPInstaller is the way to go.
As the configuration is contained in an XML file, we've some documentation of our farm without any extra effort. No need to ask what was provisioned, on which server instance or what particular configuration - it's all captured in the file. Additionally, changes made to the configuration file can be tracked over time in source control, especially when coupled with the post-installation changes as outlined below (Scriptable).
Admittedly, there are often a number of post-installation configuration steps that must be captured in a separate document - many of these will be performed in Central Administration - but this does give us a good start. Coupled with the XML file, a post-installation configuration document may be created that is manageable in size and only needs to cover the last 20% of the steps undertaken.
Part and parcel with the self-documenting aspect of the configuration is the ability to repeat the process exactly. When building multiple SharePoint farms (you are building DEV, TEST and DR farms right?) having the same configuration is critical. Since we're using a configuration-driven process to install binaries and configure the farm we can be assured that the farms are the same.
Creating the configuration for the additional farms can be as simple as changing server names, usernames and passwords in the XML configuration file. In the event that we need to scale-down from multiple server instances we simply remove one or more of the servers in the configuration file - search/replace is our friend here. Run AutoSPInstaller again and rest assured the farm will be configured in the same way. Done.
I have found that this is even more useful when clients will ask me to build out the PROD farm, and then the internal IT staff will build out the additional environments. Being able to hand them a set of configuration files and simple instructions affords confidence that they'll get through the installation successfully.
Since AutoSPInstaller is based on XML and PowerShell, one can script the installation as well as post-installation configuration tasks. This could include automation of items such as server names, URLs, or the like in an environment where many SharePoint farms are spun up/down repeatedly, as an example. Or, based on the values contained in the input file, custom PowerShell scripts can be run to set BackConnectionHostNames the right way.
Additionally, we can make configuration changes such as adding a service application after the initial installation, all driven from the same XML input file. There's a great walk-through on Brian Lalancette's Blog - he's the creator of AutoSPInstaller - that goes through this process in detail. What's nice about this approach is that it can save you a bunch of time and effort when compared to running the equivalent PowerShell manually.
AutoSPInstaller is a great tool and has certainly saved me countless hours installing SharePoint farms. If you're not using it today I'd suggest giving it a look, especially for the reasons outlined above.
Lastly, there are some knock-on projects around AutoSPInstaller, including AutoSPInstaller Online which was previously AutoSPInstaller GUI. It's updated and now runs online (as the name suggests) rather than something that you download and run locally; however, the functionality is basically the same - create an AutoSPInstaller XML configuration file using a GUI. For those that eschew the joys of editing XML manually, this is for you.