Learn about Windows PowerShell
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.”
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:
-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):
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:
-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:
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:
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:
· SharePoint Foundation User Code Service
· Search Query and Site Settings Service
· 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
Next (not necessarily in this order), we’ll create the main portal Web application and site collection, using the application pool, managed account, and template specified in SetInputs.xml. After we’ve created Central Admin, My Sites, and our portal, the script will conveniently open Internet Explorer with respective tabs opened to those three sites!
The Payoff: A Repeatable, Controlled, Standard Process
So what’s the benefit of all this, aside from the reduction in documentation, the high degree of automation, the time savings, and the lowered risk of human error in the process of installing SharePoint? If you’re like me and you (re)build virtual test, development, or evaluation environments, you could leverage the same SetInputs.xml over and over for quick subsequent installs. Some folks like to clone or ghost their machines to achieve the same result, but the AutoSPInstaller can work nearly as quickly, but with a guarantee of uniqueness (each server will be a fresh build).
Finally, there’s what I like to call the “SQL DBA nightmare” that even the promising new SharePoint 2010 Configuration Wizard leaves behind when it’s done creating your service apps:
And here’s what things could look like when SharePoint databases have been created via script instead:
So if you’ve ever wondered or been asked, “How do we get rid of the GUIDs?” or “How do I know which database belongs to which SharePoint server?” then something like AutoSPInstaller can avoid this mess in the first place.
The AutoSPInstaller script and process is still evolving. I’d like to incorporate Enterprise Search provisioning (using Gary Lapointe’s existing Windows PowerShell work in this area); create other service applications such as PowerPivot, Web Analytics, and Performance Point; and overall make the XML input file more user friendly to edit. But even if the remaining few services do have to be manual or even wizard driven, we can still reap the benefits of a mostly automated installation.
I hope this helps others who are looking to evaluate SharePoint 2010, but would rather focus on learning everything about this great platform other than the gory installation details. Please check out http://autospinstaller.codeplex.com to get the script and also discuss any issues, questions, and features.
I have created a GUI configuration tool for AutoSPInstaller, check it out at autospinstallergui.codeplex.com