Summary: Guest blogger, Brian Lalancette, talks about how AutoSpInstaller and AutoSpSourceBuilder work together.
Microsoft Scripting Guy, Ed Wilson, is here. After nearly four years, guest blogger, Brian Lalancette, is back to give us an update. Brian, take it away…
Unbelievably, it’s coming up on nearly four years since my last post on the Hey, Scripting Guy! Blog. A lot has improved in AutoSPInstaller since I discussed its introduction in my post, The AutoSPInstaller Windows PowerShell Script.
Now there is SharePoint 2013 support, of course. But there is also the ability to provision pretty much every service application, and most recently, the ability to deploy Project Server 2013—and all leveraging the awesomeness of Windows PowerShell. I’ve published a companion script of sorts called AutoSPSourceBuilder that can help you assemble the required installation files for SharePoint, along with a specified set of updates (which may or may not be the latest available—depending on what you’re after). This set of binaries can be used on their own for a manual installation or in conjunction with AutoSPInstaller. The latter scenario is what we’re interested in here.
History and rationale
Anyone who’s installed SharePoint 2010 or SharePoint 2013 knows that very early in the process, the installer will attempt to download all the software components it depends on for SharePoint to install and run. And many of you who have used and followed AutoSPInstaller through the years will recall a handy little script that I created, Download SharePoint 2010 Prerequisites, which in essence, allows you to download all of these SharePoint prerequisites at once.
There are a couple of reasons why you might want to do this:
- Your target servers don’t have access to the Internet. This is particularly common in locked-down production environments that want to absolutely minimize the possibility of their servers being compromised. (After all, who hasn’t tried to browse shady websites from their production servers, right?)
- You’re faced with a multiserver farm installation, and you aren’t crazy about the thought of downloading the same set of prerequisites over and over on 18 servers.
- You want speed up the installation. Period.
With the prerequisites downloaded to a known location, you could then, as part of your SharePoint installation process, run the PreRequisiteIntaller.exe with some special switches and simply point to that location as the source, avoiding the download. But alternately, you could use AutoSPInstaller (sense a theme here?), which has full built-in support for what I call the offline installation. Fantastic! End of post, right? Not quite…
Although the prerequisite predownload script got some traction (~6000 downloads) and much community love, it hadn’t quite reached its full potential. First, it only worked for SharePoint 2010 prerequisites—SharePoint 2013 has its own set of required software to be preinstalled. Second, what about the endless slew of updates to SharePoint, not to mention related products like Office Web Apps? These gaps led me to ponder the creation of a new tool that would have broader applications, and remove even more of the tedious manual steps typically involved in a SharePoint installation.
A new approach
Enter AutoSPSourceBuilder, a script with some lofty goals:
- Provide robust, automatic downloading of SharePoint and Office Web Apps 201x prerequisites, cumulative updates, service packs, and language packs
- Organize and extract the downloaded packages into a consistent folder structure
- Where applicable, slipstream updates into the installation folder structure (slipstreaming is an approach that is used to preintegrate updates so that they can be applied simultaneously with the product being installed)
- Overall, prepare all the required files to install SharePoint 201x plus Office Web Apps 201x plus language packs at the desired build level (service pack or cumulative update)
Prior to this script, it seemed the only approach was a manual one, involving not only downloading all the stuff yourself (after painstakingly searching for all the correct links), but then extracting, arranging, and if you dared, slipstreaming it. Mind you, there were some good resources outlining this process, but in the end you had to do the grunt work yourself.
Using a similar approach to AutoSPInstaller, I opted to keep all of the data external to Windows PowerShell in an accompanying XML file, which would be subject to regular incremental updates (naturally, at roughly same frequency as the SharePoint update cycle). A nice side-effect of this is that AutoSPSourceBuilder.xml provides a nice structured breakdown of all the recent updates to SharePoint products, including name, build, and URL.
Here’s a snapshot of AutoSPSourceBuilder in action:
As a net new Windows PowerShell project, AutoSPSourceBuilder strives to follow good scripting practices, like including built-in Help via a Synopsis block, with parameter descriptions and examples, and lots of region nodes to make the script collapsible in supported editors. It also does some cool stuff like checking to see if you’re running under an elevated command prompt. Plus it automatically attempts to resume an interrupted download (thanks to the magic of the BitsTransfer PowerShell module). And when it’s all done, it writes a nice little .txt file in the destination folder that summarized what exactly has been done, so you can quickly determine the state of your SharePoint binary source.
Better together
Because AutoSPInstaller is designed to make the SharePoint installation as hands-off as possible, I’ve always recommended slipstreaming updates into your SharePoint source for the best unattended experience. And as noted previously, AutoSPSourceBuilder was designed to do this slipstreaming for you, in advance. This worked great with SharePoint 2010 and SharePoint 2013, up to a certain point (for more information, see Slipstreaming issues beginning with SharePoint August 2012 CU and a fix). After that, slipstreaming seemed to become a challenge unto itself. But more on this later.
If you’ve worked with AutoSPSourceBuilder, you may have noticed that the default paths look familiar. Indeed, it was designed to work in conjunction with our old friend AutoSPInstaller to not only get your farm built quickly and (mostly) automatically, but also with your chosen SharePoint build and language pack(s).
Like AutoSPInstaller, it defaults to C:\SP\<version> as the root folder, where <version> represents the SharePoint year (currently, either 2010 or 2013). The interesting stuff goes in the …\Updates subfolder. After successfully running AutoSPSourceBuilder, you should see descriptive subfolders for each update downloaded, for example, 15.0.4551.1511 (December 2013). This makes it easy to maintain a library of all the SharePoint updates (if you’re into that sort of thing).
Further, when AutoSPInstaller runs, it will actually search (by using Get-ChildItem -Recurse) this \Updates\ folder and all its subfolders, looking one-by-one for updates to install. Want to avoid a particular update without moving or deleting it from your library? No problem! Simply mark the subfolder as “hidden.” By default, Get-ChildItem won’t uncover hidden files and folders. This is a great approach for developers, testers, and other SharePoint nerds who frequently install different versions of farms.
I mentioned earlier that slipstreaming has its own issues (for more information, see Slipstreaming the August 2012 Cumulative Update or higher with SharePoint 2010 Service Pack 1). If you’ve decided to go the slipstreaming route, you can still include the monolithic updates to be installed to “fill in the gaps” if the slipstreaming attempt wasn’t 100% kosher. Installing the entire package of updates at the end of the binary install, regardless, is my preferred route.
A work in progress
Microsoft has done a good job of keeping me on my toes with the AutoSPSourceBuilder project. The current update cycle is around two months, so the XML file needs to be kept current with the new download URLs as they are made available. In addition, it seems that every few months, there’s a change in the way SharePoint updates are delivered, packaged, extracted, or installed. Although this has made maintaining the project a bit of a challenge, it’s certainly helped keep my Windows PowerShell skills sharp. And that’s never a bad thing, I suppose.
Thank you, Brian, for taking the time to stop by and share your knowledge.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy