How To Check Exchange Rollup Version

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.

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

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 the released builds. Take a look 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 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




Comments (33)
  1. anonymouscommenter says:

    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.

  2. anonymouscommenter says:

    Awesome explanation!!!!

  3. Thanks Atul for the feedback!

  4. 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

  5. anonymouscommenter says:

    When writing Exchange PowerShell scripts it is very useful to target specific machines to either query

  6. anonymouscommenter says:

    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 #.

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


  8. anonymouscommenter says:

    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.

  9. anonymouscommenter says:

    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.

  10. anonymouscommenter says:

    Great and useful post!
    Thank you !

  11. Very useful blog!

  12. anonymouscommenter says:

    Plz anyone help me, how to get my whole organization exchange server details..

  13. anonymouscommenter says:

    Another step backwards… sheesh it just gets worse now we can’t even get a script to work that lists the version is a nice easy way to read without going to a site and finding versions.

  14. anonymouscommenter says:

    After upgrading an Exchange 2013 CU8 lab to CU9, the Set-Mailbox cmdlet did not present the expected

  15. anonymouscommenter says:

    Very useful. but i have question about the version dan rollup.
    I have check on my server and it shows version..14.02.0247.005.
    Is it means SP2 RU 2 ?? is it right ??

  16. That’s correct — 14.2 or 14.02 is SP2.

    You need to upgrade to SP3 ASAP as SP2 is no longer supported:


  17. anonymouscommenter says:

    Ok, Rhoderick,
    Thank for your information & advice.

    Best regrads,
    Aris Suharyono

  18. anonymouscommenter says:

    The year 2015 is almost done, and 2016 is upon us! As in previous years , I thought it would be interesting

  19. anonymouscommenter says:

    Is it possible to use the command "GCM Exsetup.exe | % {$_.FileVersionInfo}" to show only the product version number rather than all 3 columns? I know I can add | ft -hidetableheaders to remove the headers which helps but would like to only output the
    version number once without the path… TIA

  20. Have you tried

    GCM Exsetup.exe | % {$_.FileVersionInfo} | select ProductVersion


  21. Saira Zafar says:

    hi… i know its a bit out of context, but i need a resource who has lotus experience and has Symantec AV, SCCM client along with proficiency in French and English. This is a paris based job. can any one help me on this?

  22. anonymouscommenter says:

    Rhoderick Milne you legend! 🙂 Thank you with the removeheaders that does exactly what I needed thank you! 🙂

  23. Cloud-Ras says:

    Thats a fantastic blog!
    Great work 🙂

  24. Saira – you want to be posting that on some jobs website. Not this blog. I’ll remote future job posting comments, in the same what that I have to remove all of the adverts for cheap hand bags and various potions.


  25. Glad to hear you got what you needed Luke and Cloud-Ras.


  26. Glad to hear you got what you needed Luke and Cloud-Ras.


  27. jchaven says:

    Wow! This is one of the best postings I have ever seen on the Technet blog. Lots of useful take-aways with just enough explanation. I really like how the task was the focus – not Powershell, or *cough* the EMC.

    Thank you!

  28. anonymouscommenter says:

    Worked perfectly – thanks!

  29. Vivek Singh says:

    Hi will it make any difference if we have mixed versions of RU installed on Exchange 2010SP3

  30. Jean-LucCh says:

    Hi Rhoderick,
    If AdminDislpay version & ExSetup version are not same, do you think this is a problem?
    Kind regards

    1. Hi Jean-LucCh – this is normal and expected with Exchange 2010. AdminDisplayVersion will be 14.3.123 and that will not change.


Comments are closed.

Skip to main content