One of my current projects is to help a large multinational move from Exchange 2007 to a dedicated instance of Microsoft BPOS running Exchange 2010. BPOS is having some woes of its own with yet another outage causing disruption to customers around the world. Let’s hope that Office 365 provides a better level of service as it takes over from BPOS. Assuming that Microsoft will solve the problems, we can turn our attention to migration and figuring out how to make sure that users don’t notice the switch of underlying platform.

In this scenario, the vast bulk of the clients run Outlook 2007 with a scattering of Outlook 2010 thrown into the mix. All clients are configured in cached Exchange mode. Migration is a process best taken slowly and with care, especially when you deal with tens of thousands of clients, and a great amount of testing and validation has been done to ensure that the cloud platform can provide the required service.

Part of the testing involves moving “volunteer” (also known as victim) mailboxes over to BPOS to identify any interoperability or other problems as email flows between the on-premises and cloud servers. One step during the movement process cleans out client-side nickname caches to remove the possibility that users will attempt to address messages with invalid routing addresses that Outlook has cached (see Microsoft KB article 287623 for details).

So good so far… but then we run into OAB problems. Or rather, severely outdated OABs in some of the on-premises mailboxes. The issue manifests itself when people attempt to address messages to users who have moved to BPOS using the information held in the OAB. Of course, if the OAB was kept up-to-date by Outlook downloading the OAB update files that Exchange generates daily, then there would be a reasonable chance that the correct address would be provided. Because of the mechanism used to generate and distribute OAB updates to clients, there’s always going to be some mail-enabled objects that have been added, changed, or deleted since the last update files were generated, but that’s understandable and acceptable. Most companies find that their directory stabilizes after the initial deployment of Exchange and that only a small number of updates occur thereafter. Of course, there will be exceptions to the rule, such as when a company is acquired, splits off, or joins another entity, but in general the mechanism of generating and distributing daily updates works very well to provide Outlook clients with an accurate offline copy of the directory.

Things become a tad more difficult during the main phase of the migration period when lots of mailboxes are being moved. Apart from the obvious scope for more users to run into the “invalid address” problem, there’s also the fact that Outlook will be forced to perform full OAB downloads when the total size of the OAB differential files on the server is more than one-eighth of the size of the OAB. Simply put, once more than an eighth of the directory has changed, Outlook assumes that it is easier to download a full copy of the OAB from Exchange than to attempt to patch so much of the directory using update files. You can modify the threshold for directory changes using the instructions in KB841273 but in most cases you’re simply putting off the day when clients need to refresh the OAB completely with a full download. The problem here is that full downloads steal processing cycles and bandwidth…

It is possible to force Outlook to ignore the OAB and connect to a GC each time it wants some directory information (see KB823580). However, while this ensures that Outlook clients get the most accurate and up-to-date information that the GC can provide, it removes a major benefit of using clients in cached Exchange mode and can impose a very large network and performance load on the GCs.

One approach that works well seems to be to:

1. Make sure that OAB updates are being generated and distributed to client pick-up points. You won’t be able to check this on BPOS or Office 365 as Microsoft runs the servers but you can check that the OAB files on a client connected to these platforms is being updated daily (assuming that there are some updates).
2. Make sure that clients are downloading the OAB updates. This should happen automatically as Outlook’s default behavior is to check daily (Outlook 2003 checks the system public folder holding the OAB updates; Outlook 2007 can use either public folders or the web distribution point introduced in Exchange 2007; Outlook 2010 can’t use public folders) but sometimes the checks don’t work and the OAB is a little aged and a manual download might be necessary. Dave Goldman’s blog contains a good post about the OAB update process.
3. Follow the age-old practice of migrating users who naturally correspond with each other to the new platform together. There’s lots of ways of doing this – moving complete departments, groups, or offices at one time; moving managers and their administrative assistants; moving project teams, and so on. The idea is to limit communications between the two platforms as much as possible.

For all of its apparent simplicity, the OAB remains one of the darker corners of Exchange. Few care about it until problems arise… and then they find out just how essential the OAB is to many Exchange organizations.