I installed the roll-up, why does it still say I'm running SP3?!

  • Article

Ok, so that title sort of says it all. You’ll find that installing a roll-up hotfix onto an Exchange 2000 or 2003 server may not update the display in the Exchange System Manager to reflect the new version. So what’s really going on?

For example, an Exchange 2000 SP3 server is going to display itself as 6249.4 in ESM:

If you upgrade it with the latest post-SP3 E2k roll-up (currently the August 2004 “6603” roll-up available at KB.870540), you will find that it still shows as 6249.4 rather than as 6603.1, the updated version.

 

When do we expect the version # to update in ESM?

The only time you’re going to see the version number update in ESM is if it’s a major version update (like going from Exchange 2000 -> 2003) or if it’s a service pack update. The one exception to this is that some of the earlier roll-up hotfixes post-Exchange2000SP3 would update the version number in ESM when applied to Clustered Exchange

Why does it get updated in ESM?

In order for the ESM version number display to be updated, a few things have to happen:

  1. The hotfix has to include the EXSETDATA.DLL file
  2. The hotfix has to be applied on a clustered Exchange 200x machine

If you meet both of those criteria, you’ll see the version number bump up in ESM to whatever version is associated with the EXSETDATA.DLL file. If you fail either of these criteria, the version number in ESM will be untouched.

That begs the question “why does it only happen on clusters? ”:

Exchange clusters undergo a slightly different process than do non-clustered Exchange servers when you do a service pack upgrade. In fact, Exchange 2000 clusters run back through a bunch of the “initial setup” code instead of sticking just to the “upgrade” code.

This will be familiar if you’ve ever done an Exchange 2000 service pack upgrade on cluster. Generally, it’s done in a rolling-upgrade fashion:

  1. Move EVS to active node (let’s call it node1)
  2. Install SP binaries on passive node (call it node2)
  3. Reboot node2 and move EVS over to the upgraded node
  4. <After EVS comes online on upgraded node2, the actual SP upgrade happens to the databases, etc>
  5. If everything comes online on the upgraded node2, you’ve upgraded to the SP successfully!
  6. Complete the process by installing SP binaries on node1 and reboot

Note that moving the EVS to the node with upgraded binaries is where the actual service pack upgrade work takes place behind the scenes. If the upgrade fails at that stage, you’re still able to run the EVS on the non-upgraded binaries of node1. If it succeeds at that stage, you’ll want to finish it off by upgrading the remaining node(s). It’s during the process of upgrading the EVS to match the upgraded binaries on the node that the “setup” code is run to do the upgrade, and this is the code that updates the version number in ESM.

Exchange 2003 is a little different, as the upgrade/setup stuff doesn’t happen automatically when you bring the EVS online any longer (see KB.867624 for more detail on the Ex2003–>Ex2003SP1 upgrade process). In Exchange 2003, you have to tell the cluster (in CluAdmin) to “Upgrade Virtual Server”, at which point just about everything else is the same as in the Exchange 2000 upgrade case.

Perhaps an even better question then is “why DOESN’T it happen on non-clusters!? ”:

Since there is separate “setup” and “upgrade” code — and the setup code touches this version number while the upgrade code does not — hotfix applications on non-clustered Exchange servers will not touch the version number, even if there is an updated EXSETDATA.DLL file in the hotfix. This is a shame, as it makes it a bit harder to tell whether hotfixes have been applied to your Exchange servers.

Well, if it doesn’t always update in ESM, how can you tell if the hotfix has been properly applied?

You can choose from several great ways to tell what version/hotfix you’re running:

  1. Run ExBPA (https://www.microsoft.com/exchange/exbpa/)
  2. Check in Add/Remove programs and/or the registry
  3. Check the actual file versions

Run ExBPA

By far, the easiest way to check if you’ve got the latest Exchange hotfix roll-up is to run the ExBPA “Best Practices Analyzer” program against your server or your whole organization. It’ll check whatever scope of servers you select and will tell you (from its frequently updated ruleset) whether or not you’ve got the latest roll-up on each of your servers. Very cool tool. You want to run it. https://www.microsoft.com/exchange/exbpa/

Add/Remove and/or the registry:

Anytime you add an Exchange 200x hotfix to your server, it’ll be logged in the Add/Remove programs dialog so you can visually inspect that location to see if your particular hotfix is listed. Alternately, all of the hotfixes are also listed in the registry at location by KB number:

HKLM\Software\Microsoft\Updates\Exchange Server 200x\SP#\KB######
(substitute the right Exchange version, service pack #, and KB #)

Check the actual file versions:

It’s a bit arduous, particularly if you want to be thorough and check each and every file in the hotfix. In many cases, you can get away with checking only one or two of the main updated files (say “store.exe” or “mad.exe”) to make sure they have the latest file version.

But if you want to check all the files you can certainly do it. Each hotfix KB article (see KB.870540, for instance) lists all of the updated files along with their respective updated file version. You can find each file on your Exchange server, pull up properties, and then compare the listed version in the KB with the listed version on the file itself. The biggest benefit of this method is that once you’ve gone through and checked each and every file, you know 100% that the hotfix is completely applied to the server. But I certainly don’t envy you the task of checking 150 file versions!

MichaelP actually pointed me to a slightly easier way if you want to scan through all the files manually. Here are the steps:

  1. Open up Windows Explorer
  2. Browse to the folder/directory where the files were installed (i.e., C:\Program Files\Exchsrv\Bin)
  3. Set the Windows Explorer View to “Details” (View > Details)
  4. Right-click anywhere on the existing column headers and choose “More…”
  5. A “Choose Details” dialog window should appear… find “Module Version” and check its box. 
  6. Click the OK button. 

Now all of the binaries should be displayed with their file version in Windows Explorer (sample below).