Pre-Populating SharePoint Farm Details for ULSViewer

Standard

The new ULSViewer for SharePoint introduces the capability to monitor all the ULS logs in your SharePoint farm at once, in real time. While this is a fantastic enhancement to an already near-perfect piece of software, I found one tiny little pain point with it. When configuring ULSViewer to monitor an entire farm, you need to manually specify all the servers in your farm as well as the common ULS log path.

image

As a seasoned (crusty) SharePoint IT pro, I thought to myself, “hey ULSViewer, you seem smart… figure it out yourself!” After all, this isn’t top-secret information, it’s all right there within the farm configuration. And being the type of person who hates doing anything manually (especially more than once), I wanted some sort of automated fix.

So I set upon writing a fairly simple PowerShell script that would query the farm to grab all the SharePoint servers in the farm, plus the diagnostic (ULS) logging path. These pieces of information are available via two SharePoint PowerShell cmdlets: Get-SPFarm and Get-SPDiagnosticConfig. The rest was just reading and if necessary adding to ULSViewer’s Settings.XML file.

Head on over to the TechNet Gallery to grab the PowerShell script for yourself… heck it could even save you seconds of your precious time!

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.

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

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

Standard

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.

Brian

High-level steps to SP2010 Demo VHD boot joy

Standard

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

References: