Freigeben über

The Elusive 0x81002746 Error

  • Artikel

If you look around for it, you’ll find a lot of posts on a 0x81002746 error that you might get from ConfigureMsgService. But no one seems to know what the error really means or why it happens. I thought I’d fill in some details.

For starters, this error has nothing to do with WSAECONNRESET, which is 0x2746. Some error lookup tools will make this connection, assuming the value was built as a traditional HRESULT and reading the Code from within it. This has lead many people down the wrong path. Actually, the error is MAIL_E_NAMENOTFOUND. Once we know the real name of the error, we can make some sense of when and why it happens.

When you call ConfigureMsgService to configure the Exchange provider, you provide the name of an Exchange server and a mailbox. The Exchange provider uses these to query the GAL to get more information to finish configuring the profile. It talks to the GAL using NSPI. In particular, it binds to the server and issues an NspiGetMatches call, passing a filter built using the mailbox name you gave to ConfigureMsgService. If this call succeeds and returns a record, it parses the results and continues configuring the message service. If it fails, we bubble up some version of the error we got back. But if the call succeeds with no records? Normally, we’d put up a dialog asking the user to check the name. But if we’re running as a service or the client passed flags to disable UI? That’s when we return MAIL_E_NAMENOTFOUND.

Let’s examine the implications of this: We asked the server for any records matching a given name. The server responded with zero matches. This means it didn’t recognize the name. In other words, we looked in the GAL and did not find the mailbox we were looking for! We can now list some common causes:

  1. The mailbox really doesn’t exist.
  2. The mailbox exists, but is hidden from the GAL.
  3. The mailbox exists, isn’t hidden, but strange permissions have been set. Here are a couple examples.

I recently had a customer encounter this error. I was able to eliminate the first two possibilities, but I knew better than to try and personally chase all the whackadoodle permissions that could be set in their Exchange environment. I’m a debugger, not an administrator! So I enlisted Kevin Carker, from our Exchange Admin team, to work with the customer and figure this out. His ace sleuthing uncovered a reason we had not previously considered: the customer had multiple GALs! They must have created them while playing around in the management console, and since nothing broke for their users, didn’t clean them up. But the way they left things configured, the user they were running their application as defaulted to one of the other GALs, which was empty. So NSPIGetMatches looked in that GAL, did not find the mailbox, and we returned MAIL_E_NAMENOTFOUND. Now, the customer could have configured everything so the presence of this empty GAL didn’t cause a problem, but, seeing as it was empty, they chose to delete it instead, at which point their account defaulted back to the regular GAL and could now configure a profile.

Hopefully, now that we understand what this error means and why it happens, no one else will need to rip their hair out trying to troubleshoot it. If you’re getting MAIL_E_NAMENOUTFOUND from ConfigureMsgService, the mailbox you looked up could not be found in the GAL you looked in. By working through the various reasons why this may be, you should be able to resolve this without making a support call.

Enjoy!

Comments

  • Anonymous
    September 05, 2012
    Hi, Even if the mailbox is not hidden from the GAL, its worth a try to hide it and then un-hide it. It worked in my case. Grats for the article. Regards, Akos

  • Anonymous
    September 09, 2013
    Hi Stephen I am not sure if this article is still open for comments, but I have just came across a customer case that was showing the same error, but a different reason (so you can add it to your list). The mailbox was clearly existing, it was not hidden from GAL, no issues with the permissions and I finally figured out (by comparing the differences against a working mailbox) that the issue was the Email field in the user's properties in Active Directory. For whatever reasons, that field was empty (and so was the Mail field when looking at that account's properties with ADSI Edit). Consequently, ConfigureMsgService fails with MAIL_E_NAMENOTFOUND. If checking with PowerShell, the mailbox field that seems to get populated is WindowsEmailAddress: empty causes the CreateMsgService error, populated with the correct info allows the MAPI profile creation/configuration Now, the email addresses were properly set up in Exchange (2010) Console; why does that AD field from the General tab prevents the MAPI profile configuration? Thank you, Dan