Link to home
Start Free TrialLog in
Avatar of jeff1946
jeff1946

asked on

OALGen Error Fix Didn't Last

My SBS 2003 Exchange 2003 SP2 server has always had a problem generating the Offline Address List, logging App Events 9330 & 9334 every time the scheduled rebuild occurred or I  attempted a manual rebuild:

Event Type:      Error
Event Source:      MSExchangeSA
Event Category:      OAL Generator
Event ID:      9330
Date:            2/14/2011
Time:            1:42:23 PM
User:            N/A
Computer:      DC
Description:
OALGen encountered error 8004010f (internal ID 5000477) accessing Active Directory  for '/o=First Organization/cn=addrlists/cn=oabs/cn=Default Offline Address List'.
- /o=First Organization/cn=addrlists/cn=oabs/cn=Default Offline Address List

For more information, click http://www.microsoft.com/contentredirect.asp.

Event Type:      Error
Event Source:      MSExchangeSA
Event Category:      OAL Generator
Event ID:      9334
Date:            2/14/2011
Time:            1:42:23 PM
User:            N/A
Computer:      DC
Description:
OALGen encountered error 8004010f while initializing the offline address list generation process. No offline address lists have been generated. Please check the event log for more information.
- /o=First Organization/cn=addrlists/cn=oabs/cn=Default Offline Address List

For more information, click http://www.microsoft.com/contentredirect.asp.

Last week I spent hours and days trying every suggestion I could find on EE and elsewhere to fix this problem. Just as I was getting ready to give up and post a question on EE I repeated what I had tried a half-dozen times before: I removed the value from the 6603001f= line in mapisvc.inf in System 32, restarted the SA (IS, and MTA Stacks) and amazingly, the OALGen started to work. I could rebuild the OAL manually again and again without problems, Outlook clients were successfully downloading the Address Book, life was good.

But the next day, although I made no further changes, it was broken again. It went back to the behavior where attempting a manual rebuild generates the App Log events above. I also see the same pair of events at 7 AM when the daily rebuild occurs.

Needless to say, I've tried stopping the SA, clearing the 6603001f= value, and restarting the SA, but I still get the 9330 & 9334 events when I rebuild.

Can anyone steer me toward a solution? Thanks in advance.
Avatar of jeff1946
jeff1946

ASKER

Experts -- I sure could use some help here. Anybody?
Well, I've discovered some things that might be useful clues. Despite the fact that I had cleared it previously (many times), the oabinteg.exe /t:scanmapisvc test again flagged the 6603001F=DC key in mapisvc.inf:

=====================================================
OABInteg (Offline Address Book Integrity Checker)
Product Version 06.05.7839.2
OABInteg.exe
Microsoft Corporation, Copyright (C) 2006 - 2008
Microsoft and Windows are registered trademarks of Microsoft Corporation.
=====================================================

Command line arguments: oabinteg /s:DC /t:scanmapisvc /v:3 /l

Checking to see if OABInteg is running on an Exchange Server
Checking version of Exchange Server
Exchange 2003 Version: 6.5.6944.00
Exchange 2003 Service Pack Version: 6.5.7638.2.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Setup\ registry key has been closed.
Total registry keys found 1.
Total registry values found 3.
Mapisvc.inf scan started at: 02:54:57 PM
Running OABInteg on: DC Unable to obtain username.
Attempting to scan the mapisvc.inf file for invalid entries.
NOTE: This is only a server side test.

MAPISvc.inf file found. Location is C:\WINDOWS\system32\mapisvc.inf

WARNING: The 6603001F key was found in your MAPISVC.inf file.
Key 6603001F, Value = DC

This can cause several problems. See below:

1. Can cause OAB Generation to fail with an Event ID: 9330 and 9334.
2. Can cause logon problems with the MSExchange SA profile.

Please follow the below steps to resolve this problem:

1. Stop the MSExchangeIS.
2. Stop the MSExchangeSA.
3. Clear out the application log.
4. Open UystemRoot\system32\mapisvc.inf
5. Search for the [MSEMS_DSA_ADMIN] section.
6. Look for the following attrubite -> 6603001F = Some Servername and delete this entry.
7. Start the MSExchangeSA.
8. Start the MSExchangeIS.

Mapisvc.inf scan finished at: 02:54:57 PM

Following the steps 1-8 above exactly restored OALGen to working order again. I manually rebuilt the OAL repeatedly without problems.

However, this morning at 7:10:35, the App Log shows events 9330 & 9334 again, just like in my original submission. And the 6603001F=DC line has reappeared in mapisvc.inf, which now shows a mod timestamp of 7:08:55.

Apparently something is adding this line just before the daily rebuild.

Can anyone help me figure out what is doing this and why, and most importantly how can I stop it?

I have also come to question the daily OAL rebuild. I see those 9330 & 9334 events every morning a few minutes after 7 AM, and I have always just assumed that that is a scheduled task. But is it? Is that the usual behavior?
I found the rebuild schedule and reset it to 5 AM just to see what happens.
ASKER CERTIFIED SOLUTION
Avatar of Saakar
Saakar
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks, Saakar. Yours is the first response I've gotten in two weeks! I had essentially given up hope of getting any help from this resource.

I disabled virus scanning all of the Exchange Server files & folders when I started troubleshooting this problem. (It's not a big security risk as I also have a standalone gateway anti-malware solution in place that filters all the incoming SMTP traffic.) As a result, I'm afraid your suggestion won't make any difference.

As for the OALGen problem itself, I have determined that the problem is caused by a nightly run of EXMERGE that I set up as a Scheduled Task to do a "brick level" backup of individual mailboxes. I do not know how or why, but EXMERGE creates the  6603001F=DC line in mapisvc.inf. I have worked around the problem by suspending the EXMERGE jobs.

The EXMERGE backups are an old habit. I don't really need them anymore, as I can restore individual mailboxes using the Exchange Recovery Storage Group mechanism.

Thanks for sharing the information Jeff I really appreciate it, this information will be of great help to individuals who look forward to EE for there issues.
Moreover I did see some issues wherein the OAB Generation was fixed by following the steps that I have suggested, but yours might be a different scenario..

All is well that end well :-)