AutoSPSourceBuilder heads to the PowerShell Gallery!


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.


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!


Using AutoSPInstaller to Run Specific Configuration Changes


-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:


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:


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!

(Tricks For Successfully) Creating AD Service Connection Points for SharePoint 2010


A few days ago Jie Li posted instructions on how to track SharePoint 2010 installations in an organization by using AD Service Connection points. This sounded really promising, as it could (for example) allow admins to track ‘rogue’ SharePoint installs, or at a minimum just be able to quickly determine where SharePoint’s been installed.

However, I (for one) could not get the GUID sub-container that Jie mentions in his article to be created. I initially thought the problem was that I wasn’t actually using PSConfig (or PSConfigUI), but rather PowerShell commands (through my AutoSPInstaller process). So I ran some tests using SharePoint Foundation (for speed & simplicity) via the GUI, and got some disappointing results:

  • Using the instructions exactly as outlined in the article, no service connection point got created
  • An error was logged in the Application log of the SharePoint server, stating that it had a problem with the ContainerDistinguishedName (as we were instructed to create it in the registry)

Fair enough, I thought. Guided by the error in the event log (which I should have captured for this post – my bad), I then changed the ContainerDistinguishedName value in the registry to something that actually looked like a DistinguishedName:

CN=Microsoft SharePoint Products,CN=System

[click to enlarge]

Click to enlarge

Now, I began to get different errors on subsequent PSConfig attempts – along the lines of “General access denied”. I correlated these to failure audit events on the domain controller, which indicated that, contrary to Jie’s instructions, Write permissions to the Microsoft SharePoint Products container wasn’t enough; we needed something more…

Long story short, it appears that you don’t even need Write permission to the container; it’s sufficient (but necessary) to have the “Create serviceConnectionPoint Objects” permissions (defined on the container object only):

As you can see I’ve gone ahead and granted Authenticated Users the required privileges. Why? Because in order for this feature to be useful (and track as many SharePoint installs as possible), we need installations performed by anyone with a domain account (not just super-users) to register themselves in AD. Further, the super-granular permissions “Create serviceConnectionPoint Objects” (instead of full Write, as initially thought) should mitigate any risk of granting such broad access.

Once I performed these few steps, I ran the SharePoint Products and Technologies Configuration Wizard, and when it finished I could see the new Service Connection Point in Active Directory:

And finally, back to the question about PSConfig being required for all this to work (as opposed to Powershell cmdlets): it appears that yes, only PSConfig does the trick. There’s still something ‘missing’ in the series of Powershell cmdlets that serve to emulate the PSConfig-like activities. Not sure why but stay tuned.

Hope this helps anyone who’s run into similar issues.


High-level steps to SP2010 Demo VHD boot joy


This is sure to raise more questions than it answers… but here goes: how I managed to get the downloadable Information Worker Demo VM to boot straight from VHD (i.e. no host OS). This assumes a fair level of comfort and proficiency in virtual hardware environments, specifically managing virtual hard disks, the Windows registry, commands, etc. Also note that incorrectly performing some of these steps could potentially render your original host OS unbootable, so beware!!

Part I:

  1. Download and extract VHD (duh).
  2. Make sure the target computer/laptop/server is already running either Windows 2008 R2 or Windows 7. VHD booting requires the new boot loader from either OS to mount a VHD during boot.
  3. Mount the VHD in your fave x64-guest-compatible virtualization platform (other than Hyper-V, I’ve also had success with VirtualBox, others have gotten VMWare to work too after VHD conversion).
  4. Boot the demo VM as you normally would. Once up, you can optionally disable the demo services for faster boot & operation until the VHD is in its final self-booting state.
  5. Upgrade the OS of the IW Demo VM from Win2008 to Win2008 R2 – this is required for VHD boot. Note that you’ll need to run a few adprep commands first, since the demo VM is a domain controller.
  6. Modify your original (physical) boot configuration (using BCDEDIT.exe) to include the path to your newly-upgraded VHD. Sample steps for doing so can be found here and here.

If you’re still with me, at this point you’ll have a freshly-upgraded VM and VHD file, almost ready for VHD boot. Now we’ll need to make sure it actually boots (as opposed to blue-screening). You can definitely try it out now – if it works great! If not (more likely), then read on for Part II.

Part II:

  1. You’ll most likely need to download and ‘inject’ the driver for the hard disk controller for your target hardware. Why? Because apparently the OS that’s booting from the VHD needs to communicate with the hardware the same way your current OS does, and if it can’t do so during boot, it just fails. For example, for most Intel-based chipsets/controllers, you’ll need the Matrix Storage driver. Further, you’ll need to modify the registry so that the VM knows to load this driver at boot. This is probably the trickiest part of this whole process. The steps outlined here are a good starting point, of course you’ll need to modify them to include the registry entries for your own hardware… Here are some basic steps that worked for me:
    1. Download the controller driver, extract it, and copy the extracted files to both C:Windowsinf and C:Windowssystem32drivers on the VM image (I know this is overdoing it, but it works)
    2. Export the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCriticalDeviceDatabase on your original (host) OS subtree to a file, like reg1.reg – again, we probably don’t need the whole thing but in a rush it will get us what we need in terms of boot driver config
    3. Export the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices<drivername> registry subtree on the original (host) OS to reg2.reg. In my case <drivername> was iaStor for the Intel RAID Controller.
    4. Import the two exported registry file into your demo VM. Note that after doing this, you may only be able to do VHD boot going forward, and that booting again while in a VM may not work!
  2. Try (re-try) booting your VHD
  3. If it still fails, you might want to check that:
    1. You have enough free space on your host disk for the VHD to expand to its full capacity when booting (default is ~127GB for the demo VM)
    2. Your VHD isn’t on a compressed or encrypted volume
    3. You’ve actually applied the right hard disk controller driver to the VHD image (hit ‘F8’ during boot to enable troubleshooting options)

Assuming you haven’t given up by this point, and you’ve actually managed to get the VHD to boot, you can now install all the rest of the required drivers (video, LAN, peripherals etc.), just as you would for a regular OS running on the bare metal – because after all, it is running on the bare metal (except for the virtualized boot hard disk). Also, you can re-enable all of your services (if you disabled them in step 4.), but disable the Hyper-V guest services (since we’re no longer running in Hyper-V). Finally, you’ll want to apply the SharePoint 2010 pre-requisite hotfix for Win2008 R2 to your demo machine – since it was upgraded from plain Win2008, it would only have the hotfix for that particular OS applied.

Good luck!!