Back with the kickoff few releases of Exchange, product updates were fabricated available via service packs.  This continued into the Exchange 2000 and Substitution 2003 days.  Information technology seems similar an eternity ago, and dinosaurs were still roaming the World, when Exchange 2003 SP2 was released in October of 2005 as a whopping 109 MB download.

Substitution 2007 moved to a dissimilar servicing strategy which added a predictive scheduling chemical element to the underlying Service Pack bike so customers had a vehicle to receive fixes faster than await for the next service pack.  Exchange 2010 does the same.  These updates that nosotros speak of are the Update Rollups, Rollups, URs or RUs.

Update: 4-three-2015 Updated links to new home for Exchange build information.

One result 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 yous look at the below screenshot of an Exchange 2010 arrangement you lot can see that it is running SP2 as the build is fourteen.2 but yous cannot state what RU is currently installed.  If service pack 3 was installed and then the build would start with14.3.

Exchange 2010 Build Information In EMS

And the same information is mirrored in the GUI:

Exchange 2010 Build Information In Exchange Management Console

How can we observe out what RU is currently installed?

The simplest way nosotros tin can check it to look for installed updates in Add/Remove programs (or whatever it's called nowadays)

Exchange 2010 Rollup Updates Shown In Add/Remove Programmes

Or by going aid –> Nearly in the Exchange Management Panel.

Exchange 2010 Help About Build Information

Note that the Aid –> Nearly method does not give you a text based description of the installed RU, and a link to the relevant KB article.  We demand to utilise the techniques described beneath to map the build information to the released products.

Well, that's ok but you can do amend…

Tom Kern originally addressed this back in 2010 with his mail service to the Exchange team blog.  Every bit with Substitution 2003 checking the version of key files is a bang-up style to decide the current build of Exchange.  Every bit an added bonus this tin 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 Become-Command and "%" is an alias to ForEach-Object,  which and so retrieves the FileVersionInfo attribute of the file passed downwards 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 Become-Allonym GCM  and review the output. You also may be thinking about the location of Exsetup.exe and why this is non specified in the above command.  This is because Exchange setup adds the Commutation bin folder to the path environs variable.  To check this out in PowerShell nosotros tin employ:

Get-Item ENV:Path | FL

Taking a sidebar, we can use the aforementioned 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 the released builds. Take a await at Exchange Server and Update Rollups Build Numbers on TechNet.

So looking at the Exsetup.exe version on a lab server:

Checking Exchange 2010 RU Version

We can see that version fourteen.2.309.two is Substitution 2010 SP2 RU3.

Well, that's ameliorate but I desire more

We can at present get a local server's build, just what about remote machines and checking the entire organization?  Scripting to the rescue!  As with nigh things scripting there are a few different ways to attain the same outcome.  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 take WinRM Remoting enabled you can then use the Invoke-Control 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 iii.51, PowerShell 2.0 and Windows Remote Management (WinRM) ii.0.  These prerequisites can exist installed easily by Exchange 2010 setup, using a characteristic introduced by Exchange 2010 SP1.

Sample code to illustrate getting the Commutation version using PowerShell remoting:

Update five-11-2013:  Updated ForEach loop

$ExchangeServers = Get-ExchangeServer  | Sort-Object Name ForEach  ($Server in $ExchangeServers) { Invoke-Command -ComputerName $Server.Proper name -ScriptBlock {Go-Command  Exsetup.exe | ForEach-Object {$_.FileversionInfo}} }

Note that the Invoke-Control is a unmarried line that may be displayed on multiple lines due to give-and-take wrapping.

I other thing that is adept to discuss is a detail around ForEach  and ForEach-Object.  Be sure to avoid disruptive the ForEach keyword with the ForEach-Object cmdlet.   If that is done then the higher up lawmaking will fail to run and you will get this error:

Unexpected token 'in' in expression or statement

Dorsum to Powershell remoting now!

Note that it did say *IF* y'all have WinRM Remoting enabled to a higher place.  If this is not the instance and so you will likely see this lovely error which will no doubt brighten up your solar day!

Connecting to remote server failed with the following fault message : The WinRM client cannot complete   the operation within the time specified. Check if the machine proper name is valid and is reachable over the network and fire wall exception for Windows Remote Direction service is enabled.

For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken

To quickly cheque to see the configuration of WinRM:

Winrm enumerate winrm/config/listener

If enabled y'all should run into something like to this:

Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.0.2.eleven, 127.0.0.1, 169.254.1.65, 192.168.2.eleven, ::1

If there is currently no listener, and then use Enable-PSRemoting  or  the winrm quickconfig control.

Enabling PowerShell Remoting Using Enable-PSRemoting

Annotation that in WinRM ii.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 -send: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, delight see:

Running Remote Commands

about_Remote_Requirements

Well, that'south great just 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, and so you demand help!  For the others who want to save time and ensure a consistent management strategy is applied to all of their servers so we can enable and configure PowerShell remoting using Group Policy.

Leaving on a happy thought, this outcome is resolved in Exchange 2013.  When Cumulative Updates (CUs) are installed on an Exchange 2013 server the version data displayed will exist updated to reverberate the update.

The Exchange 2013 build numbers are also documented on the TechNet wiki.

Exchange 2013 Cumulative Update Version Shown In Management Tools

Thanks,

Rhoderick