Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OAB Generation: 80040115 (internal ID 500044c)

Status
Not open for further replies.

Stevehewitt

IS-IT--Management
Joined
Jun 7, 2001
Messages
2,075
Location
GB
Hi guys,

Had a fully working Exchange 2007 Enterprise installation since Feb. It's a single installation on a Windows 2003 Server R2 Enterprise x64 box. E.G. All roles are installed on the single box for Exchange. We have 3 DC's in the site, and a remote AD site used for just DR purposes that has a DC there too.

We've had a couple of new starters in the past few weeks and i've noticed that these new mailboxes are not listed in the address book within Outlook 2007. However they appear fine in the address book when using OWA.

After a bit of investigation, I am getting the following error within event viewer application log when the OAB updates (manually or on the schedule):

Source: MSExchangeSA
Category: OAL Generator
Event ID: 9330

OALGen encountered error 80040115 (internal ID 500044c) accessing Active Directory DC01 for ''.
- /o=mycompany/cn=addrlists/cn=oabs/cn=Offline Address Book


From what I gather, this indicates an issue with communicating with AD. I've checked manually on the DC's and they all seem fine. I can see the Offline Address Book object within AD using ADSIEdit.msc, and after running the various troubleshooting tools within Exchange 2007 it's all coming back with a clean bill of health.

There are no other known problems with this Exchange setup.

This is pretty much as far I've got. I've tried creating a new OAB, setting as default etc - but no joy.
I can see NOTHING wrong with our AD. No other issues have been reported with Exchange or the network in general - so i'm at my wits end.

I have NOT got SP1 installed (still in beta I believe) and i've tried the usual reboot too! :-)

Any help appreciated!!!

Cheers,




Steve.

"They have the internet on computers now!" - Homer Simpson
 
FYI:

Process STORE.EXE (PID=2252). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
fileserver.pool.net CDG 1 7 7 1 0 1 1 7 1
DC01.isis.pool.net CDG 1 7 7 1 0 0 1 7 1
rras.pool.net CD- 1 6 6 0 0 1 1 6 1
backoffice.pool.net CD- 1 6 6 0 0 1 1 6 1
Out-of-site:
dr-fileserver.pool.net CDG 1 7 7 1 0 1 1 7 1
dr-isis.isis.pool.net CD- 1 6 6 0 0 0 1 6 1


E.G - AD is working! :-D

Cheers,



Steve.

"They have the internet on computers now!" - Homer Simpson
 
And one more thing, I have enabled 'Expert' logging on the OAL Generator category, but I don't get anything additional in event viewer.

Also, when I created the new OAB I had a look with ADSIEdit - yep, it's there in AD alright.

Finally, I also tried running the update command from the shell with verbose results turned on. Everything came back without a problem...

Stranger and stranger....!

Thanks,



Steve.

"They have the internet on computers now!" - Homer Simpson
 
Bump - can anyone help?!



Steve.

"They have the internet on computers now!" - Homer Simpson
 
Do you have any logs in your Sync Issues folder in Outlook 2007?

BobSchleicher
 
Type this in the RUN area on the start menu:

Outlook /rpcdiag

This will tell you how you are connecting to your Exchange server and what DC also.


BobSchleicher
 
Hi Bob,

Thanks for your reply.

Not getting any sync errors, checked with end users too and nothing there either.

I tried the /rpcdiag switch but nothing that stands out appears. Connects using our only Exchange server (obviously!) and uses the 'better' of our DC's for AD data.

I have noticed one thing. When testing the Email Autoconfiguration (CTRL+content of system tray outlook icon) I see that the OAB URL is
However the GUID used in the URL is not valid - the acutal folder name is something different (a different GUID)

Huh?! :-)

Thanks,




Steve.

"They have the internet on computers now!" - Homer Simpson
 
So if you pound down to that folder in ClientAccess the number is different then the one you see if you were to hold ctrl and test your outlook connection?

Cory
 
Yep - exactly. However that could just be the result of me deleting the old OAB's and re-creating a new one. Obviously i've waited a while, ran manual updates and rebooted the client - but the OAB it's pointing to in the config is different to the UNC/URL that actually exists on the server...!

Cheers,




Steve.

"They have the internet on computers now!" - Homer Simpson
 
I am not sure if this is in any way helpful but could this setting be somewhere in an XML file that is now stale? Something like the autodiscover.xml file or something similar? Have you found anything that maybe helpful in powershell when checking the appropriate get-help for anything CAS related? I am away from the lab at work but come Monday if you cant find a resolution I will be looking into this as well.

I noticed there are a decent few amount of things that I have had to bang my head on the wall for in order to find exactly what I wanted.

Good luck, please keep me posted!

Cory
 
Hey cory,

Thanks for your message. I've tried a few CAS commands in EAS but just can't find anything other than the usual stuff like creating a new OAB, updating it, changing the virtual directory etc.

I'm still plugging away at it, but no joy so far. Starting to hit a brick wall.

I may completely delete the OAB and virtual directory, re-create and try again as I really can't think of anything else I can do!

Thanks again,



Steve.

"They have the internet on computers now!" - Homer Simpson
 
All,

I've deleted both the OAB itself and now the virtual directory, all though EMS to ensure that Exchange knows what is going on.

Create a new virtual directory (again, through EMS) which was generated fine, and finally I created the new OAB with a new name (in case it cached something and the name clashed etc.). All commands ran fine, but still the same problem when I try to update the OAB.

In fact, whilst the new OAB is an object in AD (using ADSIEdit.msc), there is nothing in the \ClientAccess\OAB folder nor the ExchangeOAB folder (also a fileshare). Zip - nothing at all.

I've even edited the permissions to ensure that Exchange Servers have full control over the two OAB folder mentioned above, and also within the AD container for the OAB lists. Still the same error.

I did see this:
which makes me wonder if it could be down to topology. As far as I can see my AD topology is working fine. However I noticed that in most other errors of 80040115, people have the error as "accessing Active Directory DC01 for". I never noticed the "DC01". Is this field in the error actually listing a Domain Controller server name? We have a DC called DC01 within our child domain which does NOT have Exchange on it. (child domain for development reasons only).

Any give me any hints with this? Why would the SA try to access DC01.child.domain.net when Exchange should only be serving domain.net...? Any help really appreciated!

Thanks,




Steve.

"They have the internet on computers now!" - Homer Simpson
 
Bump - anyone more knowledgeable about Exchange AD topology help with this?
Is this error indicating that it's trying to connect to DC01? If so why would SA try to serve a child domain?

Cheers,




Steve.

"They have the internet on computers now!" - Homer Simpson
 
After installing SP1, it appears to be resolved....! :-)

However I do have the error still in the event logs, so maybe SP1 just rebuilt it but Exchange itself still can't update the OAB. Will keep and eye and post back.




Steve.

"They have the internet on computers now!" - Homer Simpson
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top