250 Hello

Random Musings on Exchange and Virtualization

How To Check Exchange Rollup Version

How To Check Exchange Rollup Version

  • Comments 12
  • Likes

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.

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

Exchange 2010 Rollup Updates Shown In Add/Remove Programmes

Or by going help –> About in the Exchange Management Console.

Exchange 2010 Help About Build Information

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:

Checking Exchange 2010 RU Version

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:

    Address = *
    Transport = HTTP
    Port = 5985
    Enabled = true
    URLPrefix = wsman
    ListeningOn =,,,, ::1

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

Enabling PowerShell Remoting Using Enable-PSRemoting

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:

Running Remote Commands


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.

Exchange 2013 Cumulative Update Version Shown In Management Tools





Can You Help Us?  -- Yes !

If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!

If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!



For all other areas please use the US contact point.

  • Any way of getting this to work in an Office 365-D environment? We only have Remote PowerShell access into the Exchange servers (we have to create a new PS session into the Exchange servers). So we cannot run the cmdlets directly on the Exchange server. Nor can we use Invoke-Command.

  • Awesome explanation!!!!

  • Thanks Atul for the feedback!

  • Hi Stuart - is the Get-ExchangeServer cmdlet exposed to you? You may notice that the versions are a little different as remember with the Exchange 2013 servicing strategy code is validated first in the service and then in on-prem. Are you running into a particular issue that you are checking the versioning ? Cheers, Rhoderick

  • Help About in Exchange Management Console might not be too reliable either.
    A client server shows version 14.02.0387.000 which would be somewhere between SP2 RU 7 and SP2 RU 8.
    Command shell method reports correct build #.

  • Hey Dan,

    I don't have any Exchange 2010 SP2 boxes left as that is no longer supported.


    Just checked a SP3 RU5 box, and the two are correct.


  • Here's a listing of the different build numbers for various versions of Exchange Server:


    It contains a list of all Exchange Server versions, service packs and update rollups and which four-part version number those refer to.

  • Here's a listing of the different build numbers for various versions of Exchange Server:


    It contains a list of all Exchange Server versions, service packs and update rollups and which four-part version number those refer to.

  • Great and useful post!
    Thank you !

  • Very useful blog!

  • thank

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Post Comment Fixer