In this article, an issue is described where a single cluster is incapable of updating the OAB. Work-arounds include a manual copy and/or another mailbox server for this process - both of which are not good options. Does anyone at MSFT or otherwise have any updates to this problem? Using clustered-mailboxes on 2008 is becoming increasingly popular, and the norm, why is there not more attention drawn to this issue? http://blogs.msdn.com/dgoldman/archive/2008/06/19/oab-generation-on-a-ccr-cluster-will-fail-with-error-1021.aspx Here's another article also describing this problem: http://www.spyordie007.com/blog/index.php?mode=viewid&post_id=25 It's not just CCR, it applies to SCC as well.

Hi Mike, Looks like CCR bug is already resolved but didnt include in SP1 UR4. You can check comments from Dave in below article. http://blogs.msdn.com/dgoldman/archive/2008/10/01/understanding-why-error-code-0x8004010f-is-thrown-when-trying-to-download-an-oab.aspx#comments Additionally, Scotts comment to Benoit + Michael in below article. http://msexchangeteam.com/archive/2008/10/07/449931.aspx So we may expect some news soon

Good to see it's not forgotten, but does this mean we need to wait for sp1 rollup-5? Also, they mention CCR and even SCR explicitly, but I'm having this issue with SCC. Do you think 1 fix will resolve all? The comments section you point out make me think otherwise.

We may need to wait for UR5 or moderators or MSFT guys can give more update on that if they have I think that supposed to be SCC and not SCR as it is not a clustering technology.

Aha, good point. Thanks for the help. I'm gonna leave this as unanswered however until we get a true fix.

Hi Mike, Actually, there are two issues currently related to Exchange 2007 OAB on Windows Server 2008. 1. On CCR cluster, the OAB file cannot be copied from the mailbox server to the CAS server due to a new file share concept in Windows Server 2008. 2. On SCC cluster, the OAB file cannot be generated The product issue on CCR cluster has been identified. Our dev team are still working on the OAB generate issue on SCC cluster. Mike

Thanks Mike Shen. Can you please update this thread when the issue has been resolved? or even a beta fix?

I see the issue for CCR is resolved in Rollup 5. Any update on SCC?

Looks like rollup 5 may also address SCC. http://support.microsoft.com/kb/957978I'll test and post back.-Yep, fixed it...

I've applied rollup update 5 for Exchange 2007 SP1 and it appears that it didn't fix the OAB issue that I'm having. My setup is as follows, all systems are running on Windows 2008, 2 hub/cas servers, 2 mailbox servers configured as CCR. I recreated the OAB using Web-based distribution and still same problem.Log Name: ApplicationSource: MSExchangeFDSDate: 11/24/2008 1:51:52 PMEvent ID: 1021Task Category: GeneralLevel: WarningKeywords: ClassicUser: N/AComputer: hubserverDescription: Process MSExchangeFDS.exe (PID=2600). Could not find directory \\CCR\ExchangeOAB\4fe15af2-b486-46f6-8171-51362c564e90. This is normal if the directory has never been generated. Otherwise, make sure this directory and share has read permission for the "Exchange Servers" group.

You put the update on all 4 servers? is "ccr" the name of your CMS?Also, did you create a folder earlier and manually copy the oab? If so, could the permissions be preventing this function? Try to put the oab there yourself and see if RU5 fixes it going forward.If none of that helps, your issue is dead on the nose for what RU5 is supposed to address, specifically kb/954197. I'd call pss.

HI mike, Can you please advise is RU5 solved the OAB generation on SCC ? The KB state only the CCR. Thanks Regards

Rony, please see my post above. I listed the KB article...

It appears that the CCR OAB issue has been resolved. Initially, I created the OAB on the CCR and the CAS server failed to pull the data. I waited a few days and just happened to check it again and now the CAS server has the OAB. So, I guess a little patience did the trick. Thanks Mike for the help.Dan

dano008 said:It appears that the CCR OAB issue has been resolved. Initially, I created the OAB on the CCR and the CAS server failed to pull the data. I waited a few days and just happened to check it again and now the CAS server has the OAB. So, I guess a little patience did the trick. Thanks Mike for the help.DanDan, How many days did it take? I've got another deployment (using SCC) with RU5 and its been over a week with your above mentioned eventID still showing and the ExchangeOAB directory still empty. I'm thinking of copying the data myself initially to see if it "kick-starts" the process.Mike Shen, can you comment as well?Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator

Before I copy the data manually, I tried updating the OAB to see if that would force the file creation. When I tried this I got the following errors in my App log: Log Name: Application Source: MSExchangeSA Date: 1/30/2009 10:30:54 AM Event ID: 9109 Task Category: OAL Generator Level: Warning Keywords: Classic User: N/A Computer: OITPMXMB01.AD.xxx.EDU Description: OALGen encountered an error ffffffff (internal ID 50506a8) while generating address list '/o=xxx Exchange/cn=addrlists/cn=oabs/cn=Default Offline Address List'. Check other logged events to see if this is a serious error. - Default Offline Address List Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSExchangeSA" /> <EventID Qualifiers="32768">9109</EventID> <Level>3</Level> <Task>13</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-01-30T15:30:54.000Z" /> <EventRecordID>42051</EventRecordID> <Channel>Application</Channel> <Computer>OITPMXMB01.AD.xxx.EDU</Computer> <Security /> </System> <EventData> <Data>ffffffff</Data> <Data>50506a8</Data> <Data>/o=xxx Exchange/cn=addrlists/cn=oabs/cn=Default Offline Address List</Data> <Data>Default Offline Address List</Data> </EventData> </Event> Log Name: Application Source: MSExchangeSA Date: 1/30/2009 10:30:54 AM Event ID: 9334 Task Category: OAL Generator Level: Error Keywords: Classic User: N/A Computer: OITPMXMB01.AD.xxx.EDU Description: OALGen encountered error ffffffff while initializing the offline address list generation process. No offline address lists have been generated. Please check the event log for more information. - Default Offline Address List Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSExchangeSA" /> <EventID Qualifiers="49152">9334</EventID> <Level>2</Level> <Task>13</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-01-30T15:30:54.000Z" /> <EventRecordID>42052</EventRecordID> <Channel>Application</Channel> <Computer>OITPMXMB01.AD.xxx.EDU</Computer> <Security /> </System> <EventData> <Data>ffffffff</Data> <Data>Default Offline Address List</Data> </EventData> </Event> xxx-represents scrubbed infoI found this article discussing the above error and it suggests permissions adjustments. I have verified this was already set as recommended:1. Make sure there is an ACE for - Allow for Authenticated Users on =Default GAL with "List Contents" and "Open Address List".2. Being that the OAB Generation process runs as local-system on the =exchange server you also need to make sure there is an ACE for the =rights to open the default GAL.Another post on this issue. Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator

Ok, so Im up and running now. Ive been on the trail for half of the day now and finally found the solution. SP1+RU5 resolves this issue but look at this text from kb 957978: IMPORTANT To enable the change in this hotfix, you must apply the hotfix that is described in Microsoft Knowledge Base article 955733. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 955733 (http://support.microsoft.com/kb/955733/ ) Incorrect status codes that are returned in failover clusters may cause operations to fail on a Windows Server 2008-based computer This is funny. To enable the functionality of one hotfix I need to install another?!? Anyway, I saw the 955733 article earlier today, but didnt install at it at first because the description talks about resolving error reporting issues. Its close in some of the terminology, but nothing says it actually fixes anything. Anyway, fortunately I was able to stumble across this article that tied all of the pieces together.Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator