• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2098
  • Last Modified:

Getting MSExchangeAL 8355 event

We are using Exchange 2003 SP2.  We are using RPC over HTTP for internal mail as well as using it for external access.

The event in question is below:

The description for Event ID ( 8355 ) in Source ( MSExchangeAL ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: DC.domain.com,  .


I first thought the issue was related to a different issue we had, which was where EVERY Exchange based Event was in the same format as the above.  That just turned out to be some missing DLL files.  But when I fixed that problem, this ONE stayed this way.  I then noticed that it was happening every 30 minutes, and always included our Domain Controller FQDN at the end of the event.  That DC has all the FSMO roles, and is our Primary DNS server as well.

The catagory of the above Event is LDAP operations, and I don't really know where to go with this.  Maybe its nothing, but an event that Exchange doesn't recognize throws up red flags in my opinion.  Thanks!
0
sysadmin-inq
Asked:
sysadmin-inq
  • 11
  • 11
1 Solution
 
SteveH_UKCommented:
I'm not sure I'll be able to help solve this one, but here are a few things to try:

1)  Are your computer clocks in sync (using Windows Time Service and NTP servers)?  If not, Kerberos may have issues.
2)  Is the server in question a Global Catalog server?
3)  Do "netdiag" and "dcdiag" report errors (in the Support Tools)
4)  Do your address list LDAP queries work, i.e. without errors?!
0
 
SteveH_UKCommented:
Note that you can turn on more diagnostic logging at the Exchange server level using Exchange System Manager.

Navigate to the server and right-click and select Properties.  On the Diagnostics Logging, navigate to the AL (Address List) option and adjust the logging level.  These logs go into the computer Event Logs.

You may need to restart Exchange services for the changes to complete.  You should then be able to see more informative error messages.
0
 
sysadmin-inqAuthor Commented:
netdiag and dcdiag both come back fine.

I turned up event logging for LDAP last week (or the week before), and the queries were going through just fine.  I then turned it off so I don't fill up the log too fast.  We get a couple Warnings on the Offline Address List Generation, but it doesn't appear to be related in any way.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
sysadmin-inqAuthor Commented:
Oh yeah, the server is not a GC.

The netdiag does fail the WINS test, but we aren't running a WINS server anyway, since we were under the impression that everything uses DNS anyway.
0
 
SteveH_UKCommented:
Do you have a GC?  It may be worth setting the PDC up as one if you only have one.
0
 
sysadmin-inqAuthor Commented:
We have 2.  The DC in question (mentioned in the first post) and one of our other DC's is a GC as well.
0
 
SteveH_UKCommented:
Have you checked that the Recipient Update Services points to your current DCs.  Look in Exchange System Manager under Recipients and then Recipient Update Services (I think it is called that).

Even if it looks correct, try pointing it at a different server.
0
 
sysadmin-inqAuthor Commented:
It was pointed to the PDC.  I just changed it to the second DC that is also a GC.  Now its a short (7 minute) wait to see if I get the event again.
0
 
SteveH_UKCommented:
Good luck!
0
 
sysadmin-inqAuthor Commented:
Well its 10 minutes past when the event was supposed to go off and it hasn't yet.  So the event went away, but I'm still confused as to what the problem actually was.

If tommorrow morning, after the OAL generator is finished, The error is still gone, I'll mark the Recipient Update Services Change as the solution.

That being said, could you shed any light on what was going on?
0
 
SteveH_UKCommented:
I can only presume that either the particular AD server wasn't performing the lookups correctly, or that its configuration was somehow corrupted in ESM.

Changing it may have fixed it by rewriting the configuration data and resetting any stored state.  You may want to change it back to the original server to see if the problem is fully resolved, or server-specific.

Glad it worked, for now at least, anyway!
0
 
SteveH_UKCommented:
You can certainly read from this that there is not a major configuration or running issue, otherwise changing the server wouldn't fix it.

It is of course possible that it is a bug in Exchange...
0
 
sysadmin-inqAuthor Commented:
Well, nix that idea.  The error just showed up again, 25 minutes out of its 'normal' 30 cycle.  It still gives the PDC FQDN as part of the error information, but I have to wait to see if it will stick to the 30 minute cycle it used previously.
0
 
sysadmin-inqAuthor Commented:
Well it looks like that it is back to its 30 minute Cycle.  Any other ideas?
0
 
sysadmin-inqAuthor Commented:
Anyone?
0
 
SteveH_UKCommented:
The following EE article describes the same problem:
http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_22523974.html

But as you can see, it was never answered.  You may want to try Microsoft Product Support if you have any incidents available.

What I can offer is some explanation of the process:

RUS runs every 30 minutes to rebuild the Address Lists and Global Address Lists and to apply Recipient Policies to new Exchange-enabled AD objects.  It is these queries that cause Exchange to access the LDAP server.

Why they should fail is difficult to diagnose.  You may see events on a domain controller that will provide more assistance.

Check out this as well:
http://forums.techarena.in/showthread.php?t=456858

So you may be able to get  more info on the DC in question.
0
 
sysadmin-inqAuthor Commented:
Thanks.  Yeah, I've read both of those links (multiple times).  Ok, I'll check with my boss and see if we can go to Microsoft with this one.
0
 
SteveH_UKCommented:
Sorry I can't be more help.

You could try temporarily removing address lists, or replacing them with standard ones.  If you do this, remember to keep a copy of the LDAP filter settings, so you can rebuild them.

This will tell you if there is a problem with an(/a global) address list and you can then take it from there.
0
 
sysadmin-inqAuthor Commented:
Well after getting a subscription to eventid.net I was able to track down the following two links from Microsoft that seems to be following the problem we have quite closely.  I'm still looking at it, but I figured I'd at least post it for others to see.

http://support.microsoft.com/default.aspx?scid=kb;en-us;818190

http://support.microsoft.com/default.aspx?scid=kb;en-us;822794
0
 
SteveH_UKCommented:
The second article looks helpful for understanding the RUS event logs, pretty much as I understood it to work, but definitely helpful when you have maximum logging on.

I still think that you should consider adjusting the (Global/Offline/) Address Lists, but using maximum logging you should be able to see which operations occur before and after the error message.
0
 
sysadmin-inqAuthor Commented:
I set up a fresh install in a test lab, and found that the issue happens in that as well, which leads me to believe that it may be an exchange issue, and one that MIGHT be of no consequence, though I'd have to go to Microsoft to be sure.
0
 
SteveH_UKCommented:
Fair enough, good test.
0
 
ee_autoCommented:
Question PAQ'd, 500 points refunded, and stored in the solution database.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 11
  • 11
Tackle projects and never again get stuck behind a technical roadblock.
Join Now