Exchange HCW Detects “Wrong” Version

When running Exchange setup or the Exchange Hybrid Configuration Wizard (HCW), I always recommend looking at the version information that is shown on screen. This is part of the gross error check to make sure that the correct version is being used.

This habit is one of the recommendations made in the Mistakes to Avoid Installing Exchange CU post.

Sometime you still may see something that surprises you and is unexpected.  This is one of those cases.


Running Exchange 2010 HCW

The below was on an Exchange 2010 Server.  Yes Exchange 2010 has exited out of extended support; the below was captured in September 2020.

There is also an Exchange 2016 one further down in this post.

In the highlighted section, note that the version of Exchange which was detected in Exchange 14.3 - this is the service pack three branch of Exchange 2010.  The version information is 496 which is reported as RU25.


Exchange Hybrid Configuration Wizard Showing Wrong Version

At the time of taking this screenshot RU30 was the latest released version of Exchange 2010 SP3 and it was also installed.

Looking at Add/Remove programs we can see that RU30 was installed when it was released back in February 2020.

Exchange 2020 SP3 RU30 Is Installed

There is a year's difference between SP3 Ru25 being released and RU30.  You can see that with "Installed On" date in the image above.


One of the useful tools in the current HCW is the ability to press  F12 to show the Diagnostic Options along the bottom of the HCW.

Press F12 to Show the Diagnostics Pane in The Exchange HCW

From there we can easily click to open the log file.  No more having to remember which version of the HCW stores logs in what folder.

Searching the log file for version information, we can see the table below.  Note that it does NOT list all the Exchange RU versions, only version information up to RU25 is included.


2020.09.02 15:55:49.297         10449 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Thread=11]
(E14) Exchange Server Installed Locally
Name                             | Exch-2010
AdminDisplayVersion | Version 14.3 (Build 123.4)
Install Version              | Version 14.3 (Build 496.0)


2020.09.02 15:45:59.740         10019 [Client=UX, Thread=1]
Supported Releases:
Exchange Server 2019 "E19" RTM Version 15.2 (Build 221.12)
Exchange Server 2016 "E16" CU11 Version 15.1 (Build 1591.1)
Exchange Server 2016 "E16" CU10 Version 15.1 (Build 1531.3)
Exchange Server 2013 "E15" CU21 Version 15.0 (Build 1395.4)
Exchange Server 2013 "E15" CU20 Version 15.0 (Build 1367.3)
Exchange Server 2010 "E14" SP3/RU25 Version 14.3 (Build 435.0)
Exchange Server 2010 "E14" SP3/RU24 Version 14.3 (Build 419.0)


Exchange 2016 CU18

This is an example from the 8th October 2020.  This is a brand new Exchange installation and is running on a newly built Exchange 2016 server that was installed directly from the CU18 media.

Exchange 2016 CU18 Showing Wring Exchange Server Version


If we look at the log file, there are a couple of things worth pointing out.

Exchange 2010 SP3 RU30 is now included, but we are still missing the latest Exchange 2016 versions.


2020.10.09 00:09:19.854         10019 [Client=UX, Thread=1]
Supported Releases:
Exchange Server 2019 "E19" CU5 Version 15.2 (Build 595.3)
Exchange Server 2019 "E19" CU4 Version 15.2 (Build 529.5)
Exchange Server 2016 "E16" CU16 Version 15.1 (Build 1979.3)
Exchange Server 2016 "E16" CU15 Version 15.1 (Build 1913.5)
Exchange Server 2013 "E15" CU23 Version 15.0 (Build 1497.2)
Exchange Server 2013 "E15" CU22 Version 15.0 (Build 1473.3)
Exchange Server 2010 "E14" SP3/RU30 Version 14.3 (Build 496.0)
Exchange Server 2010 "E14" SP3/RU29 Version 14.3 (Build 468.0)



It would appear that N and N-1 are listed in the second log file for Exchange 2010, but this is not the case for Exchange 2016.  CU17 and CU18 were available for those products at the time of writing.

If the intent was to define a minimum version, would only one version be sufficient? That would allow you to define the minimum build required.


On a side note: there is no way that you should still be running Exchange 2013 CU22. More on that in a separate post.




Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *