Exchange 2007 SP2 Rollup 3


Microsoft released Rollup 3 for Exchange Server 2007 Service Pack 2 (KB979784). This update raises Exchange 2007 version number to 8.2.247.2.

Here’s the list of changes included in this rollup (KB979784):

  1. 976108 “451 4.4.0 DNS Query Failed” status message in an Exchange Server 2007 Edge Transport server
  2. 976460 Later updates do not match a calendar item that an Exchange Server 2007 user updates by using Exchange ActiveSync on a mobile device
  3. 977179 You receive an “0x800423f0” error message when you perform system state backups on the passive node of Windows Server 2008-based Exchange Server 2007 CCR clusters
  4. 977531 An external recipient misses the last occurrence of a recurring meeting request or a recurring appointment that is sent from an Exchange Server 2007 user
  5. 977923 The Edgetransport.exe process crash when it process meeting requests in Exchange Server 2007
  6. 978137 The subject of a confirmation message is garbled for certain languages when a remote device wipe operation is performed in Exchange Server 2007
  7. 978200 The sender address of a forwarded meeting request does not include “on behalf of” as expected in an Exchange Server 2003 organization and an Exchange Server 2007 organization mixed environment
  8. 978253 A SSL certificate validation error is generated on an Exchange Server 2007 server when you run any test commands after you run the Test-SystemHealth command
  9. 978469 A mailbox that was moved from an Exchange Server 2007 server to an Exchange Server 2010 server cannot be accessed by using Outlook
  10. 978517 The Microsoft Exchange Information Store service stops responding on an Exchange Server 2007 server
  11. 978521 The synchronization and the reconciliation between Microsoft Office Outlook and a BlackBerry mobile device fails when a mailbox is moved around between two Exchange Server 2007
  12. 978528 The Microsoft Exchange Information Store service crashes on a Microsoft Exchange Server 2007 server when a user tries to access a specific calendar item
  13. 978832 Read items are marked incorrectly as unread items in an Exchange Server 2007 public folder
  14. 979055 A delegate cannot save three settings of Resource Settings for an Exchange Server 2007 resource mailbox in OWA
  15. 979170 You receive an error message when you use ExBPA to schedule a scan on an Exchange Server 2007 SP2 server
  16. 979219 The store.exe process hangs on an Exchange Server 2007 server

To download the x64 or x86 version of Exchange 2007 rollup 3, click here. The Exchange versions, builds and dates table has been updated accordingly and can be found here.

Exchange 2010 Mailbox Role Calculator 6.1


Again the Microsoft Exchange Team worked hard to improve the Exchange Mailbox Role Calculator even more with the release of version 6.1,  1 month after the 4.5 update. This version includes the following enhancements since 4.5:

  • Option to select requested storage design, also to prevent logic issues with the calculator suggesting 0 (zero) disks. You have the option to select the storage design As Calculated, Entirely on RAID or Entirely on JBOD;
  • Simplified messaging profiles (e.g. “100 messages” instead of “20 sent/80 received”) as it doesn’t influence the IO and capacity calculations;
  • Some improvements and additions in layout and information displayed (e.g. Environment Configuration, Role Requirements Results).

For an extensive overview of the changes and fixes (e.g. zero disk issue), consult the Exchange Team’s changeblog here.

You can download the calculator here. Instructions on usage can be found here.

Exchange Scalability Limits Worksheet


Last Friday, the Exchange team published the initial version of an Excel worksheet describing the scalability limits and recommendations of Exchange 2007 SP2 versus Exchange 2010. It shows to which Exchange version the limit applies, the area, the limitation itself, a description of the underlying issue and where possible mitigations to increase (or lower if you want) the (default) limit. Note that it not only describes the Exchange Server software, but also limitations caused by the underlying Operating System, off- and on-premise usage and running in large organizations. Great info for sizing large scale implementations and deployments!

You can download the Exchange Scalability Limits Worksheet here. The Exchange team welcomes comments and feedback.

DAG & Lagged Replication


With Exchange 2007 a new concept was introduced, that of lagged replication (or database copies if you want). This means that besides “immediate” replication (Cluster Continuous Replication or CCR) you could delay replaying logs on target databases (Standby Continuous Replication or SCR). This enabled creating solutions for resilience since targets could be several hours off. Also, and contrary to CCR that have a 1:1 relationship, SCR targets could have 1:N or N:1 relationships (one to many, many to one).

In addition to the replay lag time in Exchange 2007, you can also specify the truncation lag time which determines when log files will be truncated. This period starts after replaying the log files. Both parameters are limited to 7 days in Exchange 2007; the default values for SCR’s ReplayLagTime is 1 day and TruncationLagTime is 0.

With Exchange 2010 DAG, which is the successor to CCR/SCR, the maximum for ReplayLagTime and TruncationLagTime have been increased to 14 days. The default value for ReplayLagTime is 0, which mimics the behaviour of CCR.

Needless to say that you should have sufficient space to host the replication log files when you set it to to a value greater than 0, also depending on the transations within that time frame. In Exchange 2010 these lag times can be configured using the cmdlets Add-MailboxDatabaseCopy or Set-MailboxDatabaseCopy, e.g. to set the ReplayLagTime to 7 days for  (format Days.Hours:Minutes:Seconds) use:

Set-MailboxDatabaseCopy -identity DAG2\MBX1 -ReplayLagTime  7.0:0:0

Note that in Exchange 2010 these values can be configured on-the-fly; in Exchange 2007 you need to disable and re-enable SCR.

JBOD versus RAID


After the arrival of Exchange 2010 and its DAG feature many people suggested – Microsoft included – the option to run Exchange on low-cost SATA disks in JBOD (Just Bunch Of Disks) configuration, provided you have at least 3 database copies. As you probably know, DAGs enable you to have multiple copies of mailbox databases running on multiple servers with a configurable lag per copy.

This suggestion to use JBOD, as well as the discussion of going backupless or not, isn’t without controversy. For many years people have learned to put their (critical) data on redundant storage. With Exchange 2010 this dogma is said to have changed, because contrary to its predecessors, Exchange 2010 can happily run fully supported on low-cost SATA storage in JBOD configuration. The argument used is that because you have at least 3 copies on 3 different physical servers you can survive a single failed mailbox server (likely) but also two failed mailbox servers (unlikely?).

The first problem is underestimating the limits of relying on 3+ copies. Nobody expects the Spanish inquisition 3 failures, right? But what if your hardware (e.g. disks) are from a faulty batch or contain buggy firmware, and you equipped all three of your physical servers with those parts (something burn-in tests should bring to light, but who does that these days?). I know of several occassions where drives died in pairs within hours from each other; you better make haste recovering your mailbox then. Is this perhaps a reason to look at different vendors, different parts? After all, this is more or less the same reason many businesses require multi-vendor products when reliability & security is concerned, e.g. anti-virus products from different vendors. The idea is to spread the risk.

Also, being able to use JBOD (and go backupless) looks interesting on paper, but don’t forget that – as suggested – you need to get yourself at least 3 physical servers (and no, don’t run them virtually on the same host). So, in the end this may lead to less servers (with RAID) being the most cost-effective alternative when looking at the total picture, e.g. hardware, licenses (OS, Exchange, AS/AV agents, management software, etc.) and operational costs. Why run (and maintain) many servers when the additional costs don’t outweigh the benefits?

A third element of the JBOD versus RAID discussion is the time to recover the original situation. When one of the servers fails, you should rebuild the server (hope you have some spare parts lying around or a decent replacement service contract). And after rebuilding (or restoring) the server, you need to reseed the database copies. This step may take a long time, depending on the size of the databases. Replacing a harddisk and rebuilding RAID sets is much quicker and much easier (and less prone to error).

In the end – as always – the choice should be based on business requirements. Perhaps your business can do a few hours without e-mail while IT is recovering services (can’t imagine, but you never know). In that case it’s nice to have a supported low-cost JBOD/SATA option. In my opinion, the benefits of having proper RAID setup outweighs the trouble you have to go through when repairing your JBOD based solution. Depending on these requirements, and how deep your pockets are, I’d go for a combination of RAID and DAG, where RAID is used for availability and DAG for availability (same data center) or resilience (multi data center, i.e. disaster recovery).

Oh and one other thing: when you must, use proper “Enterprise class” SATA disks; they’re made to run 24×7.