Autodiscover fails for one or more users
Recently I have come across an issue where a few users are not able to use Outlook 2007
to view free/busy information or set automatic replies. The Test E-mail AutoConfiguration
tool fails to retrieve the settings for this user with the following error: Autodiscover
to https://cas.contoso.com/autodiscover/autodiscover.xml FAILED
(0x800C8203) . Users with mailboxes on the same mailbox database have no issues
with Autodiscover and can use the Exchange Web Services. In fact, another user
can login to the same workstation and have no issues while this user can go to
another workstation and still have problems. This led me to believe that the
issue was related to the user account and not the Exchange configuration. I
decided to begin troubleshooting by running a web debugging tool on the client which
allows me to capture the HTTP traffic generated by Outlook. I found the following
Autodiscover response within this trace:
<ErrorCode>603</ErrorCode>
<Message>The Active Directory user wasn't found.</Message>
<DebugData />
</Error>
</Response>
</Autodiscover>
At first I was confused since this user has no issues with login or mailbox access
using either Outlook or Outlook Web App. Then I realized that Exchange 2010 SP1
introduced a new feature called Automapping where Outlook will automatically
add mailboxes to your Outlook profile where an administrator has granted full
access. (See the following article for more details https://technet.microsoft.com/en-us/library/ff459252.aspx)
How do we know that this new feature is causing our issue? Well let’s look at how
this AutoMap feature works and see if we can answer that question.
The AutoMap feature starts when an administrator grants a user full access to
another mailbox using either the Exchange Management Console (EMC) or Exchange
Management Shell (EMS). While the permissions are being applied against the
object, the delegate user object is also added to the msExchDelegateListLink
attribute for the owner mailbox. The delegate’s user object also has an Active
Directory attribute modified. The msExchDelegateListBL is updated to include
the new mailbox owner’s user object DN. Now that the user has been granted
access to the mailbox we will look at what happens on the client side.
An Autodiscover request is always initiated when the Outlook client is launched to
determine the mailbox settings for the user. This Autodiscover request queries
Active Directory and retrieves the msExchDelegateListBL for the user as part of
the process. These results are then included in the Autodiscover response XML
as an alternative mailbox. The following is an example taken from a working
client:
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Jim Martin</DisplayName>
<LegacyDN>/o=ExchOrg/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=Jim Martin7a7</LegacyDN>
<Server>mail.contoso.com</Server>
</AlternativeMailbox>
Take a look at the response and you will notice the Type tag is populated with
Delegate. This is how we know the mailbox was pulled from the
msExchDelegateListBL. The other value you may see here is Archive which
obviously is the archive mailbox for the user. The other tags we are interested
in are the LegacyDN and Server tags. These two tell us the location and name of
the mailbox which we need to connect.
What do you think happens when Active Directory returns this msExchDelegateListBL
and there is a user object within the list that no longer has a mailbox? If you
answered Autodiscover returns a 603 error, then you are correct. Once this list
is retrieved, the server and legacyExchangeDN for the mailboxes must be
retrieved. These attributes are no longer present on a user object after the
mailbox has been removed. Therefore Active Directory cannot find the mailbox
and returns the user not found error.
So how do identify these mailboxes? Windows 2008 R2 includes the Active Directory
Module for Windows Powershell which you can use to read the
msExchDelegateListBL attribute. You can run the following commands from the
Exchange Management Shell:
Import-Module ActiveDirectory
Get-ADUser <username> -Properties msExchDelegateListBL
The result will look similar to the following:
As you can see from the results this user has been granted full access to my
mailbox. Since this is the only mailbox listed in the backlink there must be an
issue with this mailbox. You can run the Get-Mailbox cmdlet against the names
in this attribute when there are multiple to determine which is missing.
Now that we have identified the missing mailbox causing our issue we need to remove
it from this backlink. A backlink attribute is read-only so we cannot modify it
directly on this user object. Instead we must modify the msExchDelegateListLink
for the object identified within the backlink or the original mailbox owner. We
can do this from the same Powershell session using the following (we can use
the clear switch since the mailbox no longer exists and this will resolve the
issue for all users that were granted permissions):
Set-ADUser <user> -Clear msExchDelegateListLink
Once Active Directory replication completes in your environment you can run the
previous Get-ADUser cmdlet again to verify that the name has been removed from
the msExchDelegateListBL. Then at this point Autodiscover should be successful
for our user account and our automatic replies and free/busy information
visible.
You can also run a query to determine which users have this msExchDelegateListBL
attribute populated with a missing mailbox by running the following:
Get-ADUser -Properties msExchDelegateListBL -LDAPFilter "(msExchDelegateListBL=*)" | ForEach-Object { Write-Host $_.Name -ForegroundColor Green; ForEach ($m in $_.msExchDelegateListBL) { Get-Mailbox $m } }
Comments
Anonymous
January 01, 2003
I have identified the mailbox and that mailbox doesnt exist. How should i go about get it off the Delegate listAnonymous
January 01, 2003
Thanks for this post we also faced similar issue with one user account but we didn't find any mailboxes that doesn't exist instead some mailboxes for which auto discover was not working. I have documented this in my blog as well.
http://msexchange.me/2014/05/18/auto-discover-failing-for-particular-user/Anonymous
January 01, 2003
Thanks a lot jim, wonderful article. can you please tell us which webtool you use to capture HTTP traffic.i have used netmon tool but very diffficult to analyse the netmon capture. if you can share the step by step procedure to analyse Netmon capture it would be of great help for us.Anonymous
January 01, 2003
I have identified the mailbox and that mailbox doesnt exist. How should i go about get it off the Delegate listAnonymous
January 01, 2003
Nice one!Anonymous
January 01, 2003
A slight modification below that can be used to check a single user. Get-ADUser -Identity <Name> -Properties msExchDelegateListBL | ForEach-Object { Write-Host $.Name -ForegroundColor Green; ForEach ($m in $.msExchDelegateListBL) { Get-Mailbox $m }}Anonymous
January 01, 2003
I have this same issue however running on Exchange 2007 so auto discover is not in use. Certain mailboxes have this issue not all mailboxes. Tested the prob mailbox with Outlook 2013 and OOF works OK but using Outlook 2007 gives that errorAnonymous
January 11, 2012
I like the way you approached the problem and solved itAnonymous
February 06, 2013
Very helpful!Anonymous
March 08, 2013
There are no words to describe this solution, but I'll try one - AWESOME!!! Jim, thank you very much!Anonymous
April 15, 2013
This is just a brilliant solution. Big Thankyou JimAnonymous
September 12, 2013
This is Awesome !!! Helped me out. In my case it was a terminated user, i had to connect the mailbox from disconnected mailboxes to fix this.Anonymous
October 29, 2013
Thanks a lot Jim! :-) This issue affecting a small number of Users had been bugging me for some time!Anonymous
February 13, 2014
Thanks a lot ... it was very helpful..Anonymous
May 05, 2015
Sorry for keeping the blog so Dull and not updating the same.
I would try to keep it as active asAnonymous
March 13, 2016
The comment has been removed