AutoSPSourceBuilder heads to the PowerShell Gallery!

Standard

File under “why didn’t I do this years ago??”

You can now easily install AutoSPSourceBuilder (my PowerShell-based utility for downloading SharePoint updates and integrating them into the installation media) from the PowerShell Gallery.

TL;DR:

Install-Module -Name AutoSPSourceBuilder

No more need to browse to the GitHub repo, download the zip, extract it, etc. The simple one-liner above will (on any modern Windows machine with installed-by-default PowerShellGet etc.) automatically download and install AutoSPSourceBuilder.ps1 to your default Scripts directory, and make it available to directly run in any PowerShell sessions you launch.

What’s more, the AutoSPInstaller.xml update inventory file, updated on a (roughly) monthly basis and previously bundled with the script, is now by default automatically downloaded at script run-time to ensure you have the latest set of SharePoint updates to choose from. If however for any reason you want to use your own XML inventory, you can opt to skip the xml download and use a local copy of the inventory file by including the new -UseExistingLocalXML switch parameter.

Now that I finally realized just how ridiculously easy it is to publish a script to the Gallery, you can expect to see some more of my stuff make its way there in the near future.

Hopefully this latest batch of changes makes it easier to keep the AutoSPSourceBuilder SharePoint update management tool… updated!

Cheers
Brian

The First SharePoint 2016 Post-RTM Update Has Been Released

Standard

SharePoint 2016 is seeing its first post-go-live update – KB2920721 – available for download here: https://www.microsoft.com/en-us/download/details.aspx?id=51701. You may notice that it doesn’t follow the typical CU naming convention of ubersrv* – that’s because it’s not a cumulative update, but rather just a specific update that contains a single patch sts-x-none.msp.

Things to know about this patch:

  • It does not increment the farm’s configuration database version. Your previously RTM SP2016 farm (as shown in Central Administration) remains at 16.0.4327.1000 after installing this patch, so you’ll need somewhere else like Control Panel –> Programs and Features –> Installed Updates to confirm it’s installed.
  • As with most other SharePoint updates, you must run the SharePoint Products Configuration Wizard after installing the package itself in order to fully commit the patch installation.
  • Also as with most other SharePoint updates, you should be able to extract the .msp patch file to <DriveLetter>:\<SharePointBinaryLocation>\updates (a process called slipstreaming) and use this source when building a new farm from scratch, in order to automatically patch the new farm as it’s being built.
  • The KB article describing what changes are included in the patch is available at http://support.microsoft.com/kb/2920721.

Cheers
Brian

Installing SharePoint 2016 Release Candidate Directly (i.e. Without Manual Patching)

Standard

When SharePoint 2016’s Release Candidate was announced, you may have wondered why (and at the same time been a little sad that) there was no monolithic ISO or executable made available that would allow you to install straight to RC without first having to install the previous public release (Beta 2) first. Well, it turns out there’s a fairly simple way to accomplish a direct-to-RC installation, and it uses a tried & true methodology – slipstreaming!

Here are the high-level steps to go from zero to RC (in your non-Production environments, right?):

  1. Download the SharePoint 2016 Beta 2 bits if you don’t already have them.
  2. (optional) Download any Beta 2 language packs you might require.
  3. Extract/copy the Beta 2 bits to a suitable local or network folder (e.g. C:\SP\2016\SharePoint).
  4. (optional) Extract the language pack(s) to a folder relative to the path above (e.g. C:\SP\2016\LanguagePacks\xx-xx (where xx-xx represents a culture ID, such as de-de)).
  5. Download the SharePoint 2016 RC patch – and don’t forget to select/include the prerequisite installer patch that matches the language of SharePoint 2016 you’re installing.
  6. Download the RC language pack that matches the language of SharePoint 2016 you’re installing (in my case, English). You need this in order to update the built-in language pack.
  7. (optional) Download the corresponding patch for any other language packs you downloaded/extracted previously.
  8. Extract the RC patch to (using the convention above) C:\SP\2016\SharePoint\Updates:

SP2016 Slipstreamed Updates

Note that the wssmui.msp shown above is actually the English language pack patch, which you would have obtained from Step 6. above.

9. Extract the prerequisite installer patch files (downloaded as part of step 5) to C:\SP\2016\SharePoint, overwriting any existing files:

SP2016 Slipstreamed Prerequisiteinstaller

10. (optional) Extract respective RC language patch files to C:\SP\2016\LanguagePacks\xx-xx\Updates:

SP2016 Slipstreamed LangugePack

Careful! All the language pack RC patch files are called wssmui.msp regardless of language, with no quick way to tell them apart. I therefore recommend you extract/copy them one at a time – but again this step only applies if you’re actually installing packs for different languages.

11. Now install SharePoint as you normally would. Patches placed in the correct locations will be automatically picked up and applied during the installation. Note that by this point, the process should look familiar if you’ve ever done slipstreaming in previous versions of SharePoint.

12. Once the installation is complete, verify that the patches were successfully applied in <CentralAdminUrl>/_admin/PatchStatus.aspx. You should see entries for “Update for Microsoft Office 2016 (KB2345678) (wssmui_<cultureID>.msp 16.0.4336.1000)” under each language pack (if applicable):

SP2016 Slipstreamed RC Language Pack

And also “Update for Microsoft Office 2016 (KB2345678) (sts.msp 16.0.4336.1000)” under SharePoint 2016 Preview itself:

SP2016 Slipstreamed Updates

Oh, and the contents of that “readme.txt” file shown in the screen caps above? “Any patches placed in this folder will be applied during initial install.” As though the product was, you know, designed for this 🙂

Cheers
Brian

Using AutoSPInstaller to Run Specific Configuration Changes

Standard

-UPDATED May 2019-

While AutoSPInstaller (my open-source project for installing SharePoint 2010-2019) is designed so it can be run and re-run as often as required to complete or tweak the installation and initial configuration of a SharePoint farm, there admittedly are times when executing the entire scripted process might seem like overkill.

For example, you might want to provision a service application that you accidentally had left set to “false” the first time around. Or, you might want to rewire which servers in your farm are running the Distributed Cache service (maybe to create a dedicated Cache cluster). Alternately, maybe several months (and changes) have passed since your farm was built, and your level of confidence that something hasn’t diverged from your original XML configuration (to the point of conflicting with it) isn’t rock-solid.

Luckily, since the included file AutoSPInstallerModule.psm1 is, as the filename suggests, now an actual module with a collection of PowerShell functions, you can actually isolate and run these chunks of script code individually. The advantages are twofold: First, you can continue to leverage the consistent and automated approach that helped get your farm built quickly in the first place. Second, you can completely bypass all the redundant steps in the process (such as checking for and creating web apps, adding managed accounts, etc.) and can be assured that only the net-new changes you need will be executed.

To do this, you’ll obviously need the AutoSPInstaller script files themselves, as well as the AutoSPInstallerInput*.xml file you used to originally build the farm (with your new modifications included of course). For the steps below, you’ll want to be logged in as the SharePoint installer account (you did use a dedicated account to install SharePoint, right?)

First, we want to grab the full path to your XML, so we can easily paste it below. A quick shortcut to do this is to shift-right-click the XML file itself and select Copy as path:

image

Now, launch a SharePoint Management Console (as Administrator), and enter the following in order to assign the content of our input file to an XML object:

[xml]$xmlinput = (Get-Content "<path to your XML file which you can just paste here>") -replace "localhost", $env:COMPUTERNAME

Note that you can simply paste the path to your XML in the designated space above (by the way, the line above was basically pulled straight from AutoSPInstallerMain.ps1).

Now that our entire XML input file is loaded and available as $xmlinput, we can use it to pass parameters to many of the functions found in AutoSPInstallerModule.psm1. First however we’ll need to make those functions available to us in this console – this is accomplished by simply importing the module. Here we have another one-liner, and if we use the same technique to copy the path to our AutoSPInstallerModule.psm1 as we did above, we can just type something like the following:

Import-Module -Name "C:\SP\Automation\AutoSPInstallerModule.psm1" -Verbose

(TIP: including the -Verbose switch above will output all the available functions for easy reference)

Finally, we’re ready to call nearly any of the functions in AutoSPInstaller (in fact we can use familiar tab-based autocomplete to get their names, too) since they’re loaded in memory for the current PowerShell console.

Let’s say for example we want to provision Business Connectivity Services on this particular server (the one we’re logged on to, that is). We would simply enter:

CreateBusinessDataConnectivityServiceApp $xmlinput

At this point, the BCS service app should get provisioned based on the details in our XML input file:

image

Note, if nothing happens, it’s likely because you forgot to change the XML Provision attribute from “false” to either “true” or the name of your target server.

That’s really about all there is to it. Hopefully this helps folks who are leery of running the entire monolithic AutoSPInstaller process just to make small changes to their existing farms.

(Oh I realize the current layout & structure of AutoSPInstaller may not be optimal – namely, much of this should probably have been implemented as one or more PowerShell modules… it’s in the queue of future enhancements!)

Update- the entire post above was updated to reflect the fact that the AutoSPInstaller functions file has been converted to a PowerShell module!