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 } }