Since PowerShell became part of the SharePoint admin’s tool belt in 2010 I’ve been cobbling together crappy PowerShell scripts. When SharePoint 2013 came out I was pleasantly surprised how well most of my crappy SharePoint 2010 scripts worked with it. That’s a testament to both the SharePoint and PowerShell teams and how well each of their products are designed. There were a couple of minor tweaks that had to be made, like to Search creation, but for the most part, they just worked. Because of that I didn’t take any time to have my scripts check to see which version they were running on, 2010 or 2013. I just knew there were a couple of places where I had to run one script over the other. Life was easy and I was lazy. (I still am.)
Then SharePoint 2016 started happening. Now I have three versions of SharePoint to contend with. And while SharePoint 2010 is six years old, it’s still out there in full force. People download and run my scripts against 2010 all the time. There are even some great blogs hosted on it. Because of that, a week ago I put pencil to paper (or at least pixels to ISE) to write the framework I’ll be using in my scripts to make sure they run correctly on 2010, 2013, and 2016. I had a couple of PowerShell folks eyeball it and they said it wasn’t horrible. Then I thought, “I bet my Internet friends would like this.” And here we are.
To make a script that works on all three versions of SharePoint there are actually two separate pieces. The first is determining which version of SharePoint is running. The second is making a decision based on that. The first bit seems easy, right? We have Get-SPFarm, for goodness sake, that gives you the exact build version of SharePoint. Except it only works if your server is part of a farm. Unfortunately, the first script I needed to tweak for SharePoint 2016 was my farm creation script. The New-SPConfigurationDatabase cmdlet in SharePoint 2016 requires a –LocalServerRole parameter to assign the first server’s Minrole. If my createfarm script is going to work with 2010, 2013, and 2016 it has to know whether to provide the –LocalServerRole parameter or not.
The first thing I needed to do was figure out which version of SharePoint was installed, without relying on Get-SPFarm. I could have looked around the file system and pulled version of files or something, but I decided to rely on Registry keys instead. The location HKLM\SOFTWARE\Microsoft\Office Server\ has a key that matches the version of SharePoint that’s installed, and it is created at install. The first part, the detection part, looks like this:
$SP_VERSION = $null
if (Test-Path 'HKLM:\SOFTWARE\Microsoft\Office Server\14.0') { # SharePoint 2010
$SP_VERSION = "14"
Write-Output 'Found SharePoint 2010'
}
if (Test-Path 'HKLM:\SOFTWARE\Microsoft\Office Server\15.0') { # SharePoint 2013
$SP_VERSION = "15"
Write-Output 'Found SharePoint 2013'
}
if (Test-Path 'HKLM:\SOFTWARE\Microsoft\Office Server\16.0') { # SharePoint 2016
$SP_VERSION = "16"
Write-Output 'Found SharePoint 2016'
}
if ($SP_VERSION -eq $null) { # In case we can't figure out which version is installed
Write-Output 'Could not find SharePoint'
break
}
This walks through the versions it knows about, 14, 15, and 16, tells you what it found, and assigns it to the $SP_VERSION variable for easy use later. If it does not find a key it knows about, it tells you so and exits out of the script.
With that out of the way, we just need to use the $SP_VERSION variable whenever we want to make a decision based on the installed version. The two main ways to handle that are with IF and SWITCH. You can find out more about them by running help about_if and help about_switch. It’s mostly straightforward. In the case of my Createfarm script, it was a little more complicated. When I call the New-SPConfigurationDatabase for 2010 and 2013 it’s the same, no –LocalServerRole parameter. 2016 is the oddball. I didn’t want a bunch of nested Ifs, and I didn’t want two identical Switch conditions, if I could avoid it. While in this situation it’s not much duplicated code, but that might not always be the case. That required me to do some research, and ultimately ask the Internet how to do what I needed. Turns out you can put some logic into the Switch condition, so I was able to have two conditions, one for 2010 and 2013, and a second one for 2016. It looks like this:
switch ($SP_VERSION) {
{($_ -eq "14") -or ($_ -eq "15")} {Write-Out ‘Old, stale, SharePoint 2010 and 2013 code goes here’}
"16" {Write-Output ‘Fancy new SharePoint 2016 code goes here’}
}
We’re able to use a –or comparison in the Switch condition so that we can have one set of code run for both 2010 and 2013. We could use the same technique if we had something we wanted to run on both 2013 and 2016.
I have tested this on SharePoint Server 2010, SharePoint Server 2013, SharePoint 2016 (on and off of a farm), Windows 8.1, and Windows 10 and it behaves exactly how I would expect it should. I do not know if it will work with 2010 or 2013 Foundation. I don’t have any Foundation VMs laying around to test against.
I hope this helps you all as you adapt your existing PowerShell scripts and snippets to support SharePoint 2016. I have been putting some scripts up in Github. When I get brave enough I’ll post the link and let you all see how bad my scripts really are. 
tk
ShortURL: http://www.toddklindt.com/POSHFindVersion