Hey, Scripting Guy! The AutoSPInstaller Windows PowerShell Script

  About the author: Brian Lalancette is a consultant at Navantis, Inc. He is MCTS certified with more than 10 years’ experience in various Microsoft platforms, including SharePoint, ISA Server, and Live Communications, and has just recently caught Windows PowerShell fever. You can follow his blog on SharePoint, virtualization, and infrastructure automation at http://spinsiders.com/brianlala/.

 

Last year, being in the position of a SharePoint administrator/consultant who is often tasked with performing Microsoft Office SharePoint Server (MOSS) 2007 installations and being blessed (cursed?) with a desire to automate everything, I set out on the journey of scripting the MOSS installation. What was the point, I thought, of producing pages of screen captures and quickly obsolete documentation for error-prone manual MOSS installations, when that amount of effort could be applied to a process that nearly eliminates both the documentation and the probability of error? A few months of evenings/weekends/in-between-project work later, the AutoMOSSInstaller was born. This is great for nearly hands-free installation of MOSS 2007. It was never really Windows PowerShell-y enough for my liking though; it did invoke a .ps1 script that disabled some Windows services, but the project was still mainly a DOS-style batch script.

With the news of the SharePoint 2010 command-line story being focused on Windows PowerShell, my challenge now was to automate as much of the installation and configuration as possible, this time with Windows PowerShell and the new cmdlets that the latest SharePoint version comes with. Luckily, there’s already a great deal of documentation and samples (both official and community-authored) for Windows PowerShell and SharePoint 2010, so this made my job a lot easier.

This article will walk through the AutoSPInstaller script, its advantages, and what remains in terms of “nice-to-haves.”

Gathering Input

For the end user of this script, the biggest piece in terms of effort is a bit of planning to enumerate things such as service accounts and database names, and editing the corresponding input file (SetInputs.xml). If this sounds daunting, keep in mind that in a proper deployment, you’d want to carry out this planning anyway in one way or another. Gather values such as your farm account, SQL server name, TCP port for central admin, which service apps you’d like configured, and so on. The SetInputs.xml file comes prepopulated with a lot of the values, so have a look. Also, if you understandably don’t feel comfortable potentially exposing passwords in SetInputs.xml, just leave them blank and the script will prompt you for them.

Also, there’s a config.xml file that’s used by the SharePoint installer in unattended mode. There isn’t much to modify here, except maybe the PIDKEY (Product ID–currently public knowledge for the beta and release candidate) and the value for OFFICESERVERPREMIUM (1 for Enterprise and 0 for Standard).

Prep and Prerequisites

After it has launched (yes, with a .bat file – to enable logging and a check of the version of Windows PowerShell), the script will check whether it’s being run with the same farm account credentials you specified in SetInputs.xml. It will warn you and stop, if not. Why? In the beta at least, SharePoint 2010 seems pretty finicky about accounts (user profile sync issues, etc.). Plus it’s probably a good idea to install under a managed service account rather than as an individual user (whose account is more subject to things such as expiry, deletion, and password changes). Next are sections within the script that will gather an process all of the input we specified in SetInputs.xml, as well as sections for installing the SharePoint 2010 prerequisites. Thankfully, the latter is now handled by PrerequisiteInstaller.exe; all we need to do is execute it in unattended mode:

      Start-Process “$bitsPrerequisiteInstaller.exe”`

-ArgumentList “/unattended”`

-WindowStyle Minimized -Wait

$bits is the path to the installation root. In addition to running PrerequisiteInstaller.exe, we also need to install a Windows 2008 hotfix separately for SharePoint 2010 Beta 2 as per KB971831 for Win2008 and KB976462 for Win2008 R2. The script takes care of this by first identifying the version of the operating system, and then running the required hotfix ($WCFHotfix):

 

      Start-Process “$dp0Hotfixes$WCFHotfix”`

-ArgumentList “/quiet`

/promptrestart” -Wait

 

Here, $dp0 is just a variable representing the path to the root where the script was launched. Note that if any of the prerequisites requires a reboot, you can do so, and then just rerun the script again. It should effectively pick up where it left off.

 

SharePoint 2010 Installation

Given that you’ve extracted the SharePoint Server 2010 installation files, the script will perform an unattended installation of SharePoint 2010:

      Start-Process “$bitssetup.exe”`

-ArgumentList “/config $config”`

-WindowStyle Minimized –Wait

 

Here, $config is a variable containing the full path to the config.xml file mentioned earlier. In my experience, the entire binary file installation could take 8-15 minutes. Go grab a coffee, unless you happen to be mesmerized by progress bars and blinking hard drive lights (like I am).

 

You should get back just in time to see the installation GUI disappear, and not be replaced with the SharePoint Products and Technologies Configuration Wizard. What happened? We got rid of it, and we’re going to reproduce what the wizard used to walk us through with some Windows PowerShell.

 

SharePoint Farm Creation and Configuration

Now that SharePoint Server 2010 is installed, we need to run the equivalent of the Products and Technologies Configuration Wizard (also known as PSConfigUI.exe) to create our farm. Because we’re going to use the new SharePoint 2010 PowerShell cmdlets to do this, we first need to load them:

      Add-PsSnapin Microsoft.SharePoint.PowerShell

You’ll get an informational message about the farm not being accessible; this is normal because we obviously haven’t created our farm yet. The next series of steps draws from examples by Jos Verlinde and Eric Kraus for creating a farm. I won’t go into detail here, but here are the seven cmdlets that will replace the Configuration Wizard and create our farm:

      New-SPConfigurationDatabase

New-SPCentralAdministration

      Install-SPHelpCollection -All

      Install-SPApplicationContent

      Initialize-SPResourceSecurity

      Install-SPService

Install-SPFeature

 

Here’s a glimpse of what the command window might look like at this point:

 

After this is done, we not only have our farm, but a browseable Central Administration site that is ready for further configuration. But that’s where it gets interesting. The script isn’t done yet, so leave that wizard alone and sit back while we register our managed accounts. Then we’ll create some service applications, Web applications, and site collections.

 

Registering Managed Accounts and Starting Some Services

Because we’re using specific accounts to run different services and Web applications in our farm, the script will now register any accounts we’ve specified in SetInputs.xml as managed accounts in SharePoint. Pretty straightforward, using the New-SPManagedAccount cmdlet.

 

Next we can start some service instances and create service applications. Some of these can be toggled (with a 1 or 0) in SetInputs.xml; have a look to decide which ones apply to your particular deployment. At this time, the script can create, configure, and start the following:

 

Service Instances:

·         SharePoint Foundation User Code Service

·         Search Query and Site Settings Service

 

Service Applications:

·         Managed Metadata Service (full credit to Zach Rosenfield for the script snippets)

·         User Profile Service (including Web application and site collection for My Sites)

·         State Service

·         WSS Usage Application

·         Secure Store Service

 

Again I won’t go into detail here, except to say that each instance/application above has its own Windows PowerShell function.

 

Create Web Applications