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.
8/13/2008 - Update to this issue here: http://www.spyordie007.com/blog/index.php?mode=viewid&post_id=27