Project Description
Automated SharePoint 2010/2013 PowerShell-based installation script.
Introducing AutoSPInstaller v3 with numerous enhancements including:
- Granular SQL server assignment and aliasing for (almost) every service/web app (for control freaks)
- Centralized, remote installation to all farm servers
- Ability to specify any XML input file, by passing it as an argument to AutoSPInstallerLaunch.bat
- Several tweaks & fixes
- Experimental support for SharePoint Foundation 2013 (as of 3.98 release)
AutoSPInstaller now works reliably with SharePoint 2013, and of course SharePoint 2010 including Service Pack 1 (and SP2) for SP2010! It takes advantage of some of the cmdlet updates in SharePoint 2010 SP1, while remaining
backward-compatible with non-SP1 deployments.
Newer versions often include updates to the input file XML schema, so make sure you compare any of your existing XML files to the newest AutoSPInstallerInput.XML. See below for highlights of changes in v3.x.
AutoSPInstaller has been used as the go-to SharePoint installation method for hundreds of SharePoint practitioners & partners worldwide! If you or your organization find AutoSPInstaller useful, making a donation (any amount) is a great way to support
the ongoing development & improvement of the project.
![Donate to AutoSPInstaller!]( "Donate to AutoSPInstaller!")
New! Frequently Asked Questions
This project consists of PowerShell scripts, an XML input file, and a standard windows batch file (to kick off the process) which together provide a quick and near-unattended installation and initial configuration (Service Apps, My Sites) of Microsoft SharePoint
Server 2010/2013. Works on Windows 2008 (though I hardly test on that OS these days), 2008 R2 and Windows 2012 (x64 only of course).
Perfect for repeated Virtual Machine-based installs/tear-downs, etc., but also great for production installs where you want to guarantee consistency and minimize data entry glitches. The immediate value is for installing and configuring the first/only server
in a farm, but also supports using either server-specific input files or a single, all-encompassing input file for running the script on all farm servers (with parameters - e.g. for the service apps - set according to your desired topology).
"But doesn't SharePoint 2010 have a nice wizard now that does all this for me??" - Yes, and it's a huge improvement over what was available in MOSS 2007. However if you've ever seen the 'DBA nightmare' left behind on your SQL server after the Farm Configuration
Wizard has completed (GUID'ed databases with inconsistent naming, etc.):
![]()
...then you'll see the value in having consistently-named but automatically-created databases:
![DatabaseList-Clean]( "DatabaseList-Clean")
The scripts (Franken-scripts, really...) leverage previously-available resources (as PowerShell has now taken its place asthe automation platform for SharePoint) such as:
Zach Rosenfield's blog, Jos Verlinde's script for creating a Farm,
Gary Lapointe's Enterprise Search script functions and other miscellaneous tidbits in the wild.
The scripted process will:</form>
- Re-launch itself in an elevated process to deal with User Access Control
- Check whether the target server is running Windows 2008 or 2008 R2
- Prompt you to enter
allmost (in progress) service accounts, passwords and the farm passphrase, unless you opt to just specify them in the AutoSPInstallerInput.xml - Validate connectivity and permissions to your SQL instance/alias
- Validate the farm passphrase (for complexity), as well as the service account/password combinations specified in the input XML file
- Automatically download and install platform-specific pre-requisites (e.g. IIS, .Net Framework) using the SP2010 Prerequisiteinstaller.exe. You can also pre-download all the prerequisites/hotfixes usingthis script, then specify <OfflineInstall>true</OfflineInstall> in your AutoSPInstallerInput.xml instead of having Prerequisiteinstaller try to download fixes at script runtime.
- Optionally disable some unnecessary Windows services, CRL checking and the dreaded IE Enhanced Security Configuration
- Install the SP2010 binaries using an (optionally, server-specific) config.xml for input
- Optionally install the Office Web Applications (OWA) binaries using config-OWA.xml for input
- Create the Farm (Config & Central Admin content databases, Central Admin site, help collections, etc.)
- Optionally configure and start many SharePoint services and service applications; currently the script can provision:
- User Profile Service Application
- User Profile Synchronization Service
- Metadata Service Application
- SharePoint Foundation User Code Service
- State Service Application
- Usage and Health Service Application
- PowerPivot Service Application (removed due to complexity/misunderstandings around order of installation etc.)
- Secure Store Service
- Enterprise Search Service Application
- Web Analytics Service Application
- Outgoing Email
- Business Data Connectivity Service Application
- Excel Service Application
- Access Service Application
- PerformancePoint Service Application
- Visio Graphics Service Application
- Word Automation (Conversion) Service Application
- The Office Web Applications service apps:
- PowerPoint Service Application
- Word Viewing Service Application
- Excel Service Application (if not already provisioned by virtue of having an Enterprise license)
- Create the main Portal web app and site collection (will try to provision and/or assign a certificate, too - all you need is an https://-based URL in the input XML)
- Create/configure your My Sites web app and site collection (will also try to provision and/or assign a certificate if you have an https://-based URL in the Input XML)
- Configure paths and options for both IIS and SharePoint (ULS) logging according to your preferences
- (NEW) Discover other target servers in your farm (based on values in AutoSPInstallerInput.xml) and remote into each of them to perform the installation process (if <RemoteInstall> istrue)
- Configure PDF indexing and icon display within SharePoint – effectively resolving what many consider to be a long-standing omission in the product in just a few seconds
- Optionally install
ForeFront Protection 2010 for SharePoint if the binaries are found in the correct path (see below)
- Launch IE to display Central Administration, Portal and My Sites, and view the results of your hard work (just in time for your return from lunch)
- Log all activity to a file on the current user's desktop, and pop open the log file for review when finished.
There are several input parameters to define in the input XML file (which illustrates how much stuff you really have to plan & gather during a regular SharePoint install). However this is a one-time-per-install effort, and the trade-off includes hours
saved and better spent elsewhere (see lunch above) and an avoidance of the risks involved (typos, missed settings etc.) during manual installations.
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/instance for each web application and service application, plus support for creating an alias for each SQL instance
- 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
The full v3 change log can be found within the
CodePlex source code changesets for the project. Also, see the
post on my blog at spinsiders.com that provides an overview of the new features & fixes.
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. This works by using the Provision=""
and Start="" attributes; for example, to provision the managed metadata service on your 2 app servers, you would specify:
<ManagedMetadataServiceApp Provision="SPAPPSRV1, SPAPPSRV2"
...
Further, the old way of specifying <ManagedMetadataServiceApp Provision="true"... still works, if you want to continue using a different XML input file for each server.
See the release notes associated with the original 2.5 changeset
here for a more complete list of changes.
New in v2:
- MAJOR code and XML schema refactoring effort by
Andrew Woodward of 21apps to enable (among other things) easier editing and extending via a custom functions script file.
- Both the launch batch file and the User Profile Service App creation (as farm account)self-elevate so no more need to right-click, Run as Administrator to successfully run AutoSPInstaller on a server with User Access Control (UAC) enabled!
- Enterprise Search now properly sets both the service account and the crawl (content access) account
- Much better multi-server farm support. Services can be tweaked to start on the servers you wish, and service applications won't be erroneously re-created on subsequent servers, etc.
- Portal super user and super reader accounts can now be configured per best practices
- Overall the install experience and results are more in line with community best practices; as always, this is a community-inspired and driven effort!
In addition to the scripts, you should create an installation source (local or shared) containingthe entire extracted contents of the SP201x install package. The zip package will by default create most of this folder structure when you extract it. When you're done, your folder structure should look something like this (Note: updated for v3):
\SP\AutoSPInstaller\AutoSPInstallerLaunch.bat
\SP\AutoSPInstaller\AutoSPInstallerInput.xml
\SP\AutoSPInstaller\AutoSPInstallerMain.ps1
\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1
\SP\AutoSPInstaller\AutoSPInstallerFunctionsCustom.ps1
\SP\AutoSPInstaller\AutoSPInstallerConfigureRemoteTarget.ps1
\SP\AutoSPInstaller\config.xml
\SP\201x\SharePoint\<installation files & folders>
\SP\201x\SharePoint\PreRequisiteInstallerFiles\
\SP\201x\SharePoint\Updates\ (extract Service Pack + Cumulative Updates here. NOTE not all updates support slipstreaming!)
\SP\2013\ProjectServer\ (optional; copy/extract the contents of the Project Server 2013 DVD/ISO here)
\SP\2013\ProjectServer\Updates (optional, for slipstreaming Service Packs and Public/Cumulative Updates. NOTE not all updates support slipstreaming!)
\SP\201x\LanguagePacks\xx-xx\ (optional)
\SP\201x\LanguagePacks\xx-xx\Updates\ (optional; extract Language Pack Service Pack / Cumulative Updates here)
OR
\SP\201x\LanguagePacks\<ServerLanguagePack_XX-XX.exe> (optional)
\SP\2010\OfficeWebApps\ (optional; only required/supported with SP2010)
\SP\2010\PDF\ (optional; only required/supported with SP2010)
\SP\2010\ForeFront\<ForeFront Protection 2010 for SharePoint install files> (optional, only required/supported with SP2010)
Note that x in the paths above is a0 or a 3 depending on whether you're installing SP2010 or SP2013. Spaces in the path to AutoSPInstallerLaunch.bat will cause the script to blow up, so avoid them.
Useful references:
- Config.xml reference (SharePoint Server)
- List of SharePoint Templates Codes and description
- ULSViewer - best SharePoint log viewer out there, displays events in real-time and super useful for troubleshooting farm, service and service application provisioning issues.
- I also highly recommend slipstreaming SharePoint 2010 service packs, cumulative updates and hotfixes into your installation source too, to further automate the process. Just place extracted patches in the\Updates\ path listed above, and they'll be automatically applied during the SharePoint binary installation process! Todd Klindt provides a great overview of the processhere.
Finally, I highly recommend working on your XML input file using a good editor like Notepad++ or good old Visual Studio - this helps a ton, especially to highlight any errors.Be especially mindful of invalid characters such as $ & " in your passwords etc.! Many script blow-up errors can be attributed to illegal characters or syntax errors in the XML. Finally, once you've populated your XML file with your environment/server
specifics and before you attempt to run the script, pass the XML through a validator likethis.
