Upgrading to E2k3 SP2 cluster

  • Article

There are a couple of important things I wanted to point out about the upgrade to E2k3 Sp2 on a cluster:

  • Same process as the upgrade to E2k3 Sp1
  • Fixes broken virtual directories and other upgrade snafus
  • IMF still not supported for use on cluster

Ok, more detail on these three, as I’m sure the one-sentence-explanation is not helpful…

Same process as the upgrade to E2k3 Sp1 – Here I am referring to KB.867624. This KB was written for the upgrade from E2k3 RTM -> E2k3 SP1, and it applies just the same for the upgrade from E2k3 RTM -> E2k3 SP2 or the upgrade from E2k3 SP1 -> E2k3 SP2. You’ll need to do the “Upgrade Exchange Virtual Server” bit again, ensuring you’re executing it from the upgraded node and with the EVS partially-online also on the upgraded node. It’s a bit complicated, but the steps should work just fine if you follow them carefully.

Fixes broken virtual directories and other upgrade snafus – Here I’m talking about the Outlook Mobile Access (OMA) and Recovery Storage Group (RSG) problems that some of you may have run into (and perhaps not even realized). These “new to E2k3” functions will be unavailable in E2k3 Sp1 if the upgrade wasn’t done correctly to E2k3 Sp1. Sp2 upgrade closes all the loopholes and ensures that this part of the upgrade is finally done and the functionality becomes available.

Here’s some more detail. The correct way to do the upgrade from E2k SP3 -> E2k3 SP1 is this high-level set of steps:

  1. Upgrade the node(s) to E2k3 RTM
  2. Do the “Upgrade Exchange Virtual Server” step at E2k3 RTM
  3. Upgrade the node(s) to E2k3 SP1
  4. Do the “Upgrade Exchange Virtual Server” step at E2k3 SP1

In that case, the server goes E2k SP3–>E2k3 RTM->E2k3 SP1

However, if you skip step #2 (ie - apply the E2k3 RTM binaries, then the E2k3 SP1 binaries, and only THEN do the Upgrade Exchange Virtual Server step), some of this “new to E2k3 RTM” functionality will be inaccessible.

Whew, that was a mouthful explanation. Anyways, the end summary is that E2k3 Sp2 “Upgrade Exchange Virtual Server” step goes back and ensures that in all cases the E2k3 RTM “Upgrade Exchange Virtual Server” actions were done, fixing anyone who did the abbreviated upgrade steps (skipping step #2).

IMF still not supported for use on cluster – Yes, it’s included as an integral part of E2k3 Sp2. But the “transport” portion of IMF (the thing you used to have to manually install on the SMTP gateway servers) is still not designed for clustered back-end servers. Store action behavior (moving stuff to the Junk E-mail folder automatically based on SCL) is still supported there, of course, as it’s a back-end server function. But the “stamping an SCL onto the message” part is not. This still makes sense though — do you really want to directly expose your “high availability email cluster” to the Internet? Any high-availability installation of Exchange should definitely have separated Internet gateway functionality, where the IMF will work just fine.