Using AutoSPInstaller to Run Specific Configuration Changes

Standard

While AutoSPInstaller (my open-source project for installing SharePoint 2010/2013) 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 AutoSPInstallerFunctions.ps1 is, as the filename suggests, just a (very) big 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 AutoSPInstallerFunctions.ps1. First however we’ll need to make those functions available to us in this console – this is accomplished by dot-sourcing the script. Here we have another one-liner, and if we use the same technique to copy the path to our AutoSPInstallerFunctions.ps1 as we did above, we can just type a dot “.” followed by a space then paste the path, for example:

. "\\Win2012R2-SP\C$\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1"

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!)

New Add-SPProfileSyncConnection cmdlet seems to ignore NetBIOSDomainNamesEnabled property?

Standard

With the release of Service Pack 1 for SharePoint 2010 came a cmdlet called Add-SPProfileSyncConnection which finally allowed the OOB creation of a User Profile Sync connection with Powershell. Prior to this, one would either have to resort to manual creation of a User Profile Sync connection or write up some fairly eloquent custom Powershell to do the job.

As great as Add-SPProfileSyncConnection promised to be, there were some limitations discovered and not much documentation around it. Further, I think I may have found another issue with this new cmdlet – but it only applies in specific cases.

The User Profile service application has a property called NetBIOSDomainNamesEnabled, which is by default set to False. It can be set to True though if the host portion of your Active Directory domain name (e.g. corporate.local) doesn’t match the NetBIOS name of your domain (e.g. CORP). Otherwise, imported user profiles will incorrectly appear in the format corporate\brianl instead of the actual value CORP\brianl.

I’ve noticed that, on a User Profile service app with NetBIOSDomainNamesEnabled set to True, if a sync connection is created using Add-SPProfileSyncConnection and users are subsequently imported, the username format comes through incorrecty – as though NetBIOSDomainNamesEnabled was still set to False.

In the example below, you can see how, in my test domain lalancette.home, with NetBIOSDomainNamesEnabled set to True, my user profiles show up incorrectly as lalancette\username:

After_Add-SPProfileSyncConnection-Highlight

As this is unacceptable and just plain wrong, I decide to blow away the sync connection that was created by the cmdlet, and create one manually, old skool style – with identical parameters (as far as I can control). The connection gets created successfully (confession: I still get a little giddy when this happens), and I then proceed to Start Full Synchronization from Central Admin.

Monitoring user profiles within the service app page, I can actually see the number of profiles drop down to zero after that first full sync. No problem… I run it again, and presto… my user profiles return, and – most importantly – they display in the correct format!
After_ManualProfileSyncConnectionCreation

I’ve run this through several times, and can only attribute it to the connection having been created with the Add-SPProfileSyncConnection cmdlet.

Finally, I’ve confirmed this in all types of post-SP1 farms: SP1 alone, SP1 with the June 2011 CU, and even SP1 with the August 2011 CU.

Has anyone else run into this? Ping me on Twitter: @brianlala

Cheers