This blog is basically a heads up for those deciding to split up roles across many servers when upgrading from Exchange 2003. One of the processes you need to move over is the OAB generation. While this is pretty straightforward I ran into a minor quirk in the new 2007 environment.
The documentation for this process is pretty sparse and lacking detail but may end up taking some of your valuable time better spent doing other things. Anyway, we had a new 2007 environment with all the bells and whistles (CCR, SCR, UM, ISA, etc) and ran into a little snag when decommissioning the 2003 servers. As part of the transition to 2007 we moved over the OAB generation to our mailbox server (CCR). We also had Public Folders sitting on a couple of servers that were pulling double duty as Hub Transport server. The majority of the clients were still on Outlook 2003 so we couldn’t just use web distribution for OAB. So we configured the OAB for web and public folder distribution.
The problem started when we ran our moveallreplicas script to move all public folders off the 2003 servers. Later the next morning we started seeing 9331/9335 errors in the event log on the mailbox cluster. Those basically meant that the public store was not online. We knew all stores were online though/ That was odd and a little alarming so I researched the events further but everything checked out from what I could see and test. I even looked in ADSI edit and the only thing I found out of place was the siteFolderServer was still pointing to a 2003 server on the Administrative Group for 2007 and on the Offline Address book we published. I contacted MS and they agreed that this should be changed. We stopped and started the stores on all the servers, yet the problem remained. The MS engineer and I tried some different things from recreating the OAB to changes in replcation. On a follow up call the engineer had me move the OAB generation server to another machine, one of our PF servers.
We made some progress doing that and didn’t get the 9331/9335 errors. Now we got two new warnings, 9386/9399. These were similar to the previous errors in that they claimed the public folder for version 2, 3 and 4 were not online. Once again this was not true. Finally the engineer suggested creating a local mailbox store on the PF server. That did it!
So the moral of this story is to ensure you have both a mailbox and public folder store on the same machine running your OAB generation. Since we were running a CCR cluster and wanted some resiliency for PFs we opted not to add that database to the cluster and on the PF server we did not have a mailbox database since we had not planned on homing any users there. So this series of events led us to the conclusion that we needed both databases locally to make OAB happy. I hope this helps someone prevent this from happening in your environment. I’ve been told a KB article may come out about this but one would only hope this type of issue gets published somewhere.
