![Rhoderick Milne [MSFT]}](http://i1.social.s-msft.com/profile/u/avatar.jpg?displayname=rhoderick+milne+%5bmsft%5d&size=large){kind=avatar}
Back with the first few releases of Exchange, product updates were made available via service packs. This continued into the Exchange 2000 and Exchange 2003 days. It seems like an eternity ago, and dinosaurs were still roaming the Earth, when Exchange 2003 SP2 was released in October of 2005 as a whopping 109 MB download.
Exchange 2007 moved to a different servicing strategy which added a predictive scheduling element to the underlying Service Pack cycle so customers had a vehicle to receive fixes faster than wait for the next service pack. Exchange 2010 does the same. These updates that we speak of are the Update Rollups, Rollups, URs or RUs.
One issue with this though is that Exchange 2007/2010 tools show the currently installed Service Pack version, as they did in Exchange 2003, and not what RU is currently installed. So when you look at the below screenshot of an Exchange 2010 organisation you can see that it is running SP2 as the build is 14.2 but you cannot state what RU is currently installed. If service pack 3 was installed then the build would start with14.3.
And the same information is mirrored in the GUI:
How can we find out what RU is currently installed?
The simplest way we can check it to look for installed updates in Add/Remove programs (or whatever it’s called nowadays)
Or by going help –> About in the Exchange Management Console.
Note that the Help –> About method does not give you a text based description of the installed RU, and a link to the relevant KB article. We need to use the techniques described below to map the build information to the released products.
Well, that’s ok but you can do better…
Tom Kern originally addressed this back in 2010 with his post to the Exchange team blog. As with Exchange 2003 checking the version of key files is a great way to determine the current build of Exchange. As an added bonus this can be automated and scripted. Party on Wayne!
In its simplest form Tom demonstrates how to check the version of Exsetup.exe locally on a server:
GCM Exsetup.exe | % {$_.FileVersionInfo}
Expanding this out, '”GCM” is an alias of Get-Command and “%” is an alias to ForEach-Object, which then retrieves the FileVersionInfo attribute of the file passed down the pipeline which is Exsetup.exe. So this could be written out fully as follows:
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}
To prove they are aliases run Get-Alias GCM and review the output. You also may be thinking about the location of Exsetup.exe and why this is not specified in the above command. This is because Exchange setup adds the Exchange \bin folder to the path environment variable. To check this out in PowerShell we can use:
Get-Item ENV:Path | FL
Taking a sidebar, we can use the same technique to show the version information of all the .exe files in the C:\Windows folder:
Dir C:\Windows *.exe | GCM | % {$_.FileVersionInfo} | FT -AutoSize
As Tom mentions, you then correlate the exsetup.exe version number you find with those listed in Exchange Server 2007: Platforms, Editions, and Versions, Build numbers and release dates for Exchange Server or on the actual rollup update download pages. The content in that KB is a little stale, and chances are you want to take a look at Exchange Server and Update Rollups Build Numbers on the TechNet Wiki.
So looking at the Exsetup.exe version on a lab server:
We can see that version 14.2.309.2 is Exchange 2010 SP2 RU3.
Well, that’s better but I want more
We can now get a local server’s build, but what about remote machines and checking the entire organisation? Scripting to the rescue! As with most things scripting there are a few different ways to achieve the same result. Bhargav has a script on his blog to determine the build version information using remote registry and also Get-Content.
As an alternative, if you have WinRM Remoting enabled you can then use the Invoke-Command cmdlet to remotely access servers if they have the necessary build of WinRM, PowerShell and .Net Framework. Exchange 2010 servers already have the necessary components installed as the underlying prerequisites to install Exchange 2010 include NET Framework 3.51, PowerShell 2.0 and Windows Remote Management (WinRM) 2.0. These prerequisites can be installed easily by Exchange 2010 setup, using a feature introduced by Exchange 2010 SP1.
Sample code to illustrate getting the Exchange version using PowerShell remoting:
Update 5-11-2013: Updated ForEach loop
$ExchangeServers = Get-ExchangeServer | Sort-Object Name
ForEach ($Server in $ExchangeServers)
{
Invoke-Command -ComputerName $Server.Name -ScriptBlock {Get-Command Exsetup.exe | ForEach-Object {$_.FileversionInfo}}
}
Note that the Invoke-Command is a single line that may be displayed on multiple lines due to word wrapping.
One other thing that is good to discuss is a detail around ForEach and ForEach-Object. Be sure to avoid confusing the ForEach keyword with the ForEach-Object cmdlet. If that is done then the above code will fail to run and you will get this error:
Unexpected token 'in' in expression or statement
Back to Powershell remoting now!
Note that it did say *IF* you have WinRM Remoting enabled above. If this is not the case then you will likely see this lovely error which will no doubt brighten up your day!
Connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and fire wall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
To quickly check to see the configuration of WinRM:
Winrm enumerate winrm/config/listener
If enabled you should see something similar to this:
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.0.2.11, 127.0.0.1, 169.254.1.65, 192.168.2.11, ::1
If there is currently no listener, then use Enable-PSRemoting or the winrm quickconfig command.
Note that in WinRM 2.0 and newer the listener is created on port 5985 TCP for HTTP and HTTPS is port 5986 TCP. To Configure WINRM for HTTPS the winrm command can changed to:
winrm quickconfig -transport:https
To configure a HTTPS listener via PowerShell, specify the –UseSSL parameter on the Set-WSManQuickConfig cmdlet.
For more fun and games that you can have with PowerShell remoting, please see:
Well, that’s great but I want it all
Chances are that you don’t fancy logging on to each server and running Enable-PSRemoting. If that does excite you, then you need help! For the others who want to save time and ensure a consistent management strategy is applied to all of their servers then we can enable and configure PowerShell remoting using Group Policy.
Leaving on a happy thought, this issue is resolved in Exchange 2013. When Cumulative Updates (CUs) are installed on an Exchange 2013 server the version information displayed will be updated to reflect the update.
The Exchange 2013 build numbers are also documented on the TechNet wiki.
Cheers,
Rhoderick
>>>
