Automated SharePoint Installations: Step-by-step
This post is part of a series covering how to configure and run AutoSPInstaller, a set of scripts that can be used to automatically install SharePoint.
AutoSPInstaller is a CodePlex project started by Brian Lalancette. The aim of the project is to provide a set of unified scripts to install SharePoint by following best practices.
I have been using automated installations of SharePoint farms for years now and am a big fan of AutoSPInstaller, the open source script library from CodePlex. This blog post started out as a quick guide on how to run the script. It has now evolved into a sectioned step-by-step guide. This is due to the large amount of support request that I get on the matter. I hope you find the information helpful.
- Prepare Server Hardware, Software and System Accounts
- Preparing the Base Media
- Prepare for Unattended Installation
- Prepare the Scripts
- Executing the Scripts and Post-Execution Tasks
Scripted Installations: The USP and Business Case
Scripted installations creates repeatability and consistency and is very useful when creating separate environments for test, QA and production. You must be sure that the setup in your environment that is used for load testing and acceptance testing is as identical as possible.
The scripts also help when using horizontal farm scaling, the technique used to add a new server node to a farm that spreads the workload over the machines. If we use virtualized environments, we can start up a Windows Server instance, run the scripts and have the new farm node up in less than an hour and be sure that the new server is set up correctly.
When using the standard, GUI-based installer, we get automatic naming of databases, All system databases are named using a random GUID string. The scripted installation will control the database names and make it easier to locate the correct database for your installation.
Last, but not least, this will save you an enormous amount of time. In my cases, I will install a test farm with 1 WFE, 1 Admin server, a QA environment with 2 WFE and 2 Admin servers and a production environment with 2 WFE and 2 Admin servers. Now, I can prepare the base media and three versions of the AutoSPInstaller scripts, one for each farm configuration, and run the installations of all servers simultaneously.
Features by Version
The scripts will (in short) perform the following tasks:
- Re-launch itself in an elevated process to deal with User Access Control
- Validate data, connectivity and security prior to installation
- Install the SharePoint binaries, pre-requisites, language packs, Office Web Apps, Forefront for SharePoint agent
- Discover other target servers in your farm and remote into each of them to perform the installation process
- Configure shared farm services
- Provision web applications and apply site templates
- Log all activity to a file on the current user's desktop, and pop open the log file for review when finished
New in v3
- Centralized, remote install of every SharePoint server in your farm using PowerShell remoting
- Support for parallel binary installations, whether remote install is enabled or not (useful for speeding up multi-server farm installs)
- Ability to specify a different SQL server for each web application and service application, plus support for creating an alias for each (except Search, currently)
- Screen output and log both now display the elapsed time to install SharePoint and Office Web App binaries
- Specify an arbitrary XML input file by passing the XML file name as an argument, or just dragging it onto AutoSPInstallerLaunch.bat
New in v2.5
The ability to use a single AutoSPInstallerInput.XML file for your entire farm, and simply include the names of servers (comma-delimited) on which you want particular service instances or service applications installed.
<ManagedMetadataServiceApp Provision="SPAPPSRV1, SPAPPSRV2"
New in v2
- Portal super user and super reader accounts can now be configured per best practices
- MAJOR code and XML schema refactoring
- Enterprise Search now properly sets both the service account and the crawl (content access) account
- Much better multi-server farm support