So I just installed RU1 on my brand new Exchange 2010 server and then I issue a Get-Exchangeserver -Identity MyExchangeServer and get the following output for AdminsDisplayVersion and ExchangeVersion:

Ok that looks a little familiar for some reason. I go to my Exchange 2010 RTM server and issue the same cmdlet and get:

...The same result! But one server has RU 1 installed and the other is RTM. Shouldn't I get a different version number back?

Well... no. Exchange 2007 and forward do not reflect the version number either in the value for AdminDisplayVersion, ExchangeVersion, or at this registry key HKLM\SOFTWARE\Microsoft\v8.0\<Role>\ConfiguredVersion as influenced by roll ups. This is a common misconception.

The most conclusive way to get the version of your exchange server, rollup and all, is to check the file version of ExSetup.exe in the BIN folder.

Here is Exchange 2010 RU1 version:

And here is Exchange 2010 RTM:

Another way of getting this information is to run the following PowerShell one-liner:

GCM exsetup |%{$_.Fileversioninfo}

The below output is from an exchange 2010 server running RU1:

Here is an exchange 2010 RTM server:

You can then correlate the 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.

Hope this post reduces some confusion out there!

Tom Kern

Not applicable
I understand that this is the way things are, but is there any advantage to the way this was done?  Seems like it blocks a lot of the advantages to do something like get-exchangeserver and see across the organization what rollups have been applied.
Not applicable
I wish I could pipe get-exchangeserver to GCM exsetup - Any easy powershell for 3+ servers to make sure you patched them all?
Not applicable
Also - RU2 was just released..   the Product Version and File Version for that are 14.00.0689.000.
Not applicable
Here is a list of Product Version Numbers (actually Update Rollup version) on TechNet Wiki
Exchange Server and Update Rollups Builds Numbers

(Updates regular)

Also exist lot of "homemade" powershell scripts to get UR for 3+ servers

But questions is why there no built-int script to get UR (version number) across whole exchange organization.


Not applicable
You can also check the version from the Exchange Management Console by going to Help --> About Exchange Server 2010...  as shown here:

Not applicable
Well, not supplying it anywhere in AD leaves some room for improvements in the future. Think positive, folks.
OK - for orgs with 3+ servers all over the world you have to make sure all lines are up prior to running the "home-made-script".
Which indeed happens almost once a year...
Not applicable
I'm keeping a list of versions, dates and builds here
Not applicable
@KB and @Klaus historically Exchange has never updated the version number in AD based on RU or hot fix.
Recall in Exchange 2000/2003 the serialNumber attribute did not increment after installing a hot fix and thus ESM did not reflect a different build number as well.
You still had to check the version of store.exe or excdo.dll etc to find what build you were really on.
With Exchange 2007 and PS this information is decidedly easier to obtain.
Not applicable
Another method I've used with great success (though perhaps overly complex) is the method Paul talks about in his blog:

I think this version is simplier though, so I may have to swtich. =)
Not applicable
Seems to me that a simple reg update with the updated version numbers tacked onto the install wouldn't take all that much time to implement???
Not applicable
I just thinking why exchange not provides its version number via WMI. This is not AD-related, so it not must be replicated (it eliminates all replication argument) and can be unavailable if xch is offline or not installed (i think).
Not applicable
It certainly would be nice if you could see the list of versions in the GUI. That way you could check to make sure that all servers in an organization are up to date at a glance.
Having to check each one, one at a time is a disservice to Exchange Admins.
After all, what does the Server Version do for me?
Not applicable
In my mind the idea of the Blogs are share a bit deeper information for readers. So Where was the point on here?
Why you did not clarify the reasons to not show the version on the normal GUI. Perhaps the hotfixes does not need to update the number, but RUs atleast should do it.

Simple things makes life easier.
Not applicable
Played with the registry keys for the installed versions without successfully having it show the correct info in the Exchange Management Console. Curious as to where the EMC is pulling the displayed (GUI) info from?
Not applicable
While I agree that not updating the values in AD can seem cumbersome to some admins the purpose of this post was not to give a history of the decision making process that went into not updating Active Directory each time a RU is installed but rather to clear up some misconceptions about the version numbers displayed in EMC/EMS and the registry in relation to roll ups as well as a quick and dirty method of getting the "true" value.
That said we are proactively listening to all your concerns with the RU process and working on addressing them.
Thanks for reading!
Not applicable
Tom - we appreciate these entries and also appreciate that you are actually filtering the feedback out of our replies here.
Not applicable
I'll be honest - the fact that you can't find out something as simple as a version / service pack level from the GUI just goes to show how far out of touch the MS development teams have become.

There is simply no way to defend the choice to leave out something as obvious as making it easy to see the version / service pack level of some installed software.
Not applicable
I have written a script that accomodates both Exchange 2007 and Exchange 2010. The script will check all 2007 and 2010 servers excluding Edge and Porivsioned servers.

More details: http://bit.ly/7teCtQ
Script Direct Download: http://bit.ly/9RFhyC