Slipstreaming issues beginning with SharePoint August 2012 CU (Part 2)

Standard

In my last post, I described the installation errors that I experienced when attempting to do a slipstreamed install of SharePoint 2010 with SP1 + August 2012 CU, and a workaround that I’d implemented in AutoSPInstaller to allow the script to proceed beyond the error. It seems however that I was a tad hasty… subsequent testing revealed that the errors were not just benign & safely ignore-able – you’d basically be left with a half-patched SP2010 installation afterwards. This was evidenced on two fronts: the version info on certain files were still showing the SP1 build, and the fact that I was able to re-run the August 2012 CU after the supposed successful slipstreamed install and could see it was actually doing stuff (instead of just quickly exiting with an “…already applied” type of message.

In discussing this problem with the usual suspects, we discovered that the August 2012 CU does indeed behave differently. Although SharePoint 2010 Service Pack 1 was nearly always listed as a prerequisite for CUs released after it, up until recently it seems it didn’t actually matter whether SP1 was installed before or after the CU. However, with the release of the August 2012 CU, this has apparently changed – the CU won’t even install on an existing farm if it fails to detect the presence of SP1.

Though we have a support case open with Microsoft about this issue, at the moment we don’t have a real solution. One viable workaround though would involve simply using a slipstreamed source containing SP1 (optionally with the June 2012 CU – the most recent one that worked for full slipstreaming), then afterwards applying the August (or October) 2012 CU. Yes, a pain in the butt… You could even go one step further and run the CU with unattended switches to ease the manual pain – probably the best approach if you’re looking for the latest & greatest SharePoint 2010 build with minimum steps & effort.

I’ll update this post as soon as I confirm any new details, either from the open support case or from the general Interwebz/Twitterz.

Update (Jan 14/2013): Trevor has posted this update based on the support case he opened with Microsoft. Let’s cross our fingers that we see a fix before (heck, or even with) SP2.

Slipstreaming issues beginning with SharePoint August 2012 CU (and a fix)

Standard

Ever since the release of the August 2012 SharePoint 2010 Cumulative Update (CU), I (and several others) noticed that, during the SharePoint binary file installation portion of AutoSPInstaller, it would fail with a PatchApplicationFailure error in the SharePoint installation log, if we integrated Service Pack 1 + the August 2012 CU in the SP2010 install media. Since this did not happen with any prior CU up to and including June 2012, those of us affected basically thought we’d found a bug in the CU. Famous SharePoint admin dude Todd Klindt even included it on his Bugs & Regressions page.

Feeling smug & confident that I’d been part of discovering a sneaky bug, I waited patiently for the latest October 2012 CU to be released, hoping it would provide a fix. Wellll imagine my surprise when I ran into the very SAME issue with the slipstreamed October 2012 CU media… Hang on, I thought. This couldn’t still be an issue with this latest CU. I turned to a good ol’ search of the Interwebz and found a shockingly low number of hits for the problem. Surely, if it were truly a bug then lots more folks would be experiencing it. But the top search hits actually came back to my AutoSPInstaller discussions on the issue. Hmm.

Time to try a manual (non-scripted) install of SharePoint then. Let’s see if it fails, gives a warning, or otherwise indicates a corruption of the install media. What I found was a familiar dialog box, but with a message I’d never seen before:

SP2010UpdatesNotInstalled

Note the text – “Some updates were not installed”. Well, we know that during our scripted install, some updates were indeed not installed – and this caused AutoSPInstaller to blow up & exit. However, the dialog box above simply notes it as an FYI, and allows us to proceed with the usual Config Wizard. Huh?

I did a comparison of the SharePoint installation log files – the log produced when AutoSPInstaller errored out, and the one associated with the apparently successful manual installation above. To my (repeated) surprise, both logs included the PatchApplicationFailure error. But, although this may be a new thing starting with the August 2012 CU, it apparently isn’t considered something critical enough to cause the installation to fail. Further, I noticed that both logs contained the message: “Successfully installed package: oserver” – which I take to be an indication that the setup process as a whole was a net success.

It soon became clear to me why AutoSPInstaller was bombing out. After the setup of the SharePoint binaries, the script would simply parse the log for the string “Error:” If it found at least one instance of it, it would consider the binary installation a failure and throw an error. This worked fine for every type of slipstreamed installation until the August 2012 CU. For reasons as-yet unknown, this update (and presumably all CUs going forward) does things differently to the effect that a successful installation can still actually contain errors in the log…

Luckily the fix was simple. In addition to parsing the log for the string “Error:”, I now needed to search for the string “Successfully installed package: oserver”, and modify the If statement to look for both the presence of “Error:” and the absence of “Successfully installed package: oserver” – in other words, if there was an error in the log but no message indicating overall success, then AutoSPInstaller should throw an error.

The updated AutoSPInstaller changeset that fixes this problem can be obtained as always from http://autospinstaller.codeplex.com/SourceControl/list/changesets and will eventually make its way into the default recommended AutoSPInstaller download package.

Note: At the time of writing this I realized this is seemingly not all there is to this issue. Part 2 of this post will delve deeper – stay tuned!

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

Powershell-based SP2010 install fails to create Version registry value?

Standard

 

As first pointed out in a discussion on my AutoSPInstaller discussion area on Codeplex, and seemingly confirmed in at least one post (that I could find so far), there appears to be an issue with one of the Powershell cmdlets that, when run with a series of other cmdlets, is the equivalent of the SharePoint Products and Technologies Configuration Wizard (AKA psconfigui.exe). The problem can be summed up as follows:

In a regular GUI-based manual installation and configuration, a registry string value called Version gets created at:

HKLM:SOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0

Click to enlarge

However, if you use the SharePoint 2010 Powershell cmdlets (not sure about legacy stsadm-based configs though), the Version string doesn’t get created for some reason! This causes problems with at least one product – Data Protection Manager 2010 (see links above to relevant posts) – as well as some confusion not only as to why this would happen, but what other issues this missing registry entry might cause.

In the meantime, and to set things straight for now, I’m considering just setting the missing registry string value (currently 14.0.0.4762 for the RTM build) by adding a New-ItemProperty command in the AutoSPInstaller. However I’m left feeling that this is kinda less than ideal…

Can anyone else confirm this issue? Have you found any fixes, or are you just using a workaround like the one I’ve suggested?

Cheers
Brian