Issues with web OAB gen for Exchange 2007 CMS on Server 2008

 29 May 2008 03:43:19 pm

You and me both. To give you the short answer up front this is something Microsoft is aware of and activity working to fix; however they need your help, if youíre experiencing these issues please contact PSS to have a support case opened. Typically there is no charge for bugs, so make sure you request a refund.

In the meantime there are some workarounds (and Iíll get to that shortly), but before you attempt them you should be aware of the details of the issues so you know what youíre working around and youíre able to support it.

That said what are the problems? There are issues effecting both CCR as well as SCC clusters, the issues are different and the symptoms will affect your environment in different ways.

CCR Clusters: On CCR clusters OAB generation will only occur on a single node, typically thatís the first node that was added to the cluster (more information about OAB generation under CCR here). The problem with CCR clusters is that when OAB generation occurs on the node the ExchangeOAB is created on that node, with Server 2003 that share was accessible by both \nodeExchangeOAB as well as \CMSExchangeOAB. Under Server 2008 the OAB is generated and made available under \nodeExchangeOAB however is not available under \CMSExchangeOAB. On the CAS(es) there is a service that runs, the MSExchangeFDS (File Distribution Service) which reaches out to the mailbox server (standalone or clustered) and copies the OAB(s) up to the web OAB directory; when the mailbox is clustered it goes to the CMS. In turn this fails and generates Event ID 1021 indicating that the \CMSExchangeOAB[OAB GUID] is not available, if you try and pull that path up yourself youíll notice it doesnít exist either.

The net result? Your Outlook clients cannot download a copy of the OAB and get the ever enjoyable 0x8004010F sync errors. If the CAS has an old version of the OAB (i.e. if it was previously generated on a 2003 server) it will not get updated and the clients will continue to download the old version.

SCC Clusters: On SCC clusters the issue is a little harder to spot; as I understand it what happens is that the OAB generation process kicks off and attemps to create the ExchangeOAB share, which is already present, and fails with an error Exchange is not expecting. This causes the OAB generation process to fail however the share and OAB that was generated the first time the process was run which the CAS continues to download. I donít have any current SCC projects on 2008 to confirm further details, there may be additional symptoms/information.

The net result? A stale OAB.

In both cases the only supported workarounds is to move OAB generation off of the 2008 CMS. If you have a standalone mailbox server or 2003 CMS youíre in great shape! Otherwise you would have to build an additional mailbox server for OAB generation.

There are a couple of unsupported workarounds as well:
If CCR you can copy the contents of the OAB to the CAS under ClientAccessServerOAB - the catch is that permissions need to be applied to the OAB properly otherwise the users will get authentication dialogs in Outlook when it attempts to download the OAB and in IIS on the CAS youíll see 401 errors.
As I understand it if SCC you can delete the ExchangeOAB share prior to the OAB generation process starting (by default 5am daily) that way the share creation doesnít cause the process to bomb out.

As I said earlier please contact PSS if/when you experience these issues, the more cases they get (and therefore the more customers that they know are effected) the more forthcoming a supported fix should be.

Erik Szewczyk

8/13/2008 - Update to this issue here:

Category : Exchange | Posted By : Erik | Comments [5] | Trackbacks [0]


The URI to TrackBack this entry is :


Yes Me too!

By : Derek @ Time : 30 May 2008 08:42:49 pm :

yes I have the same problem with my 2008-based CCR cluster. I hope Microsoft fixes this pronto!


By : Thomas @ Time : 02 Jun 2008 03:38:54 pm :

Can you elaborate on the required permission changes if we use the manual copy method on a CCR cluster?

CCR Permissions

By : Erik Szewczyk @ Time : 02 Jun 2008 05:37:21 pm : Home

For the manual copy method the NTFS ACL inherited only allows Exchange Servers and Administrators access to the directory.

Offhand I dont recall what gets stamped by the FDS, but your user accounts will need access to the OAB so Domain Users is probably the best place to start (and what I\'ve tested with).

As I mentioned if you are running into this please be sure to open support cases if you encounter the problems listed.


Useful article

By : Sergey @ Time : 08 Feb 2009 05:33:03 pm : Email : Home

Thank you for info.

FYI this is fixed in RU5 for SP1

By : Erik Szewczyk @ Time : 08 Feb 2009 09:13:24 pm : Home

I have another post about it, but thought I would comment here also. This has been fixed in RU5 for SP1.

Add Your Comment




Email Address (Optional)

Home Page (Optional)

Security Code
Click to display security code
Note:Security Code valid for only 10 minutes!
Need to enable javascript & accept cookies to work
Please enter the security code as displayed :

NOTE: All comments are now moderated and will not immediatly appear.