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

 

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

This entry was posted in Bugs, Hacks & Workarounds. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.