In most cases you will not capture the initial FolderSync request that includes the response where these folders are added to the device. This FolderSync response will provide the name of the folder and corresponding CollectionId value.

So how do you determine which folder the device is attempting a request against if all you have is a numeric ID. The answer is using a tool like MfcMapi to open the mailbox and locate these hidden folders. The following steps show how to use MfcMapi to accomplish this task:

1. Open MfcMapi
2. Go to the Session menu and Logon to the Outlook profile for the mailbox

 
3. Double-click on the mailbox to open (should be the email address of the mailbox
4. Expand the Root Container and ExchangeSyncData

5. Here you will find a list of associated ActiveSync devices for this mailbox. Expand the device experiencing the issue and you will see containers for each CollectionId
6. Select the CollectionId number you identified in the ActiveSync log (The CollectionID of 2 will be used in this example) and highlight the property 0x7C030102

7. Go to the Property menu, select Selected property, and select Open as entry ID or object
8. Modify the selected value by removing the first and last bytes. Example: 2E00000000757F911EB748EA45B7F28E4A640430C601006209883B90F0E246B480218E131EAA1E000000000010000003

 
9. The folder associated with the ID should open and in this example it is the Contacts folder 

Now when you troubleshoot and ActiveSync issue can begin searching/parsing the logs for a specific CollectionID value which should improve your efficiency. It is also important to note that when you are parsing the IIS logs the request includes the type of folder being synchronized. Most mailboxes only have a single Calendar and Contacts folder which would allow you to use this type element to quickly determine the CollectionId/Fid value. Here is an example where Fid:2 is of type Contacts:

Update 12/4/2013 - Glen wrote a Powershell script using the EWS API to retrieve this information for all devices associated with a mailbox. Check out his blog to download the script and get this information even quicker.

We know Outlook 2007 and later utilizes EWS to retrieve these settings and that Outlook requires Autodiscover to obtain the URL values for EWS. So with that knowledge the first step in troubleshooting this issue is to verify that Autodiscover works for this user. You can generate an Outlook Autodiscover log when you enable Outlook logging (File menu, Options, Advanced, Enable troubleshooting logginging). The resulting olkdisc log is located under the %Temp% directory. Open this file and you will find something similar to the following:

4044 0x13713D85 04/04/12 08:25:56 +++++++++++++++++++++++++++++++
4044 0x13713D85 04/04/12 08:25:56 AUTODISCOVER GET SETTINGS BEGIN
4044 0x13713D85 04/04/12 08:25:56   SMTP=someone@fabrikam.com
4044 0x13713DD4 04/04/12 08:25:57 Attempting URL https://CAS1.fabrikam.com/Autodiscover/Autodiscover.xml found through SCP
4044 0x13713DE3 04/04/12 08:25:57 Autodiscover to https://CAS1.fabrikam.com/Autodiscover/Autodiscover.xml starting
4044 0x13713E02 04/04/12 08:25:57 GetLastError=12175; httpStatus=0.
4044 0x13714304 04/04/12 08:25:58 GetLastError=0; httpStatus=401.
4044 0x13714304 04/04/12 08:25:58 AutoDiscover supported auth schemes:
4044 0x13714304 04/04/12 08:25:58   Negotiate
4044 0x13714304 04/04/12 08:25:58   NTLM
4044 0x13714304 04/04/12 08:25:58   Basic
4044 0x13714304 04/04/12 08:25:58 AutoDiscover attempting Auto-Negotiate with Desktop Credentials.
4044 0x13714304 04/04/12 08:25:58 AutoDiscover USING pcreds->dwAuthScheme:
4044 0x13714313 04/04/12 08:25:58   Negotiate
4044 0x13714333 04/04/12 08:25:58 GetLastError=0; httpStatus=200.
4044 0x13714342 04/04/12 08:25:58 Autodiscover XML Received
4044  ---BEGIN XML---
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response>
    <Error Time="08:26:00.0807880" Id="423565919">
      <ErrorCode>500</ErrorCode>
      <Message>The e-mail address cannot be found.</Message>
      <DebugData />
    </Error>
  </Response>
</Autodiscover>
4044  ----END XML----
4044 0x13714352 04/04/12 08:25:58 Autodiscover to https://FABRIKAM-SRV.fabrikam.com/Autodiscover/Autodiscover.xml Failed (0x800C8203)

Here we can see the email address sent within the request, the URL used by the client and the error returned by the CAS. In this example the error was "The e-mail address cannot be found." We can see earlier in the log the SMTP address used in the Autodiscover request and query Active Directory for the e-mail address. You may also want to know where Outlook pulled that e-mail address for the request. Let's first look at how the Outlook profile is first created and then everything will come together.

Autodiscover is a feature that was introduced in Exchange 2007 to automatically create Outlook profiles and retrieve mailbox settings. When you create a new Outlook profile it starts with the Auto Account Setup tab that displays your email address.

Where does the wizard get this information? Capture a network trace from the client while running the wizard and add a filter for Tcp.Port==389. Within the results you will find a frame similar to the following where you will find the proxyAddresses listed. The wizard pulls the primary SMTP address from the LDAP query and populates it with this value.

 FCN=Fabrikam User,OU=2007,OU=Exchange,OU=Enterprise,DC=fabrikam,DC=com0?..2?0?...<..objectClass1?...)..top..person..organizationalPerson..user0?......cn1?......Fabrikam User0?......sn1?......User0?......givenName1?......Fabrikam0?...a..distinguishedName1?...H.FCN=Fabrikam User,OU=2007,OU=Exchange,OU=Enterprise,DC=fabrikam,DC=com0?......instanceType1?......40?...&..whenCreated1?......20110806105919.0Z0?...&..whenChanged1?......20120401180659.0Z0?......displayName1?......Fabrikam User0?......uSNCreated1?......206930?...J..memberOf1?...:.8CN=Group1,OU=Users,OU=Enterprise,DC=fabrikam,DC=com0?......uSNChanged1?......3977280?......proxyAddresses1?...ý..SMTP:fabrikam@fabrikam.com.$smtp:user@service.fabrikam.com.?...?x500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=fabrikam.onmicrosoft.com-55785-FabrikamUser6.1X400:c=US;a= ;p=EXCHORG;o=Exchange;s=User;g=Fabrikam;0?......name1?......Fabrikam User0?...$..objectGUID1?......ʶäÝL¢0L?×hÖÝUc0?...!..userAccountControl1?......660480?......codePage1?......00?......countryCode1?......00?...%..lastLogon1?......1297777722202151170?...&..pwdLastSet1?......1295710195946748000?......primaryGroupID1?......5130?.../..objectSid1?...................ÖØõÇ<éâ].X...0?...+..accountExpires1?......92233720368547758070?......logonCount1?......440?......sAMAccountName1?......user0?...!..sAMAccountType1?......8053063680?...b..showInAddressBoo

Now that we have the SMTP address for the user we can send the Autodiscover request. The client will attempt to locate the Autodiscover URL via the service connection point (SCP) and if that fails it will attempt to use the DNS, HTTP redirect, or SRV record methods. The Autodiscover request will include the primary SMTP address and look similar to the following:

<?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>fabrikam@fabrikam.com</EMailAddress><AcceptableResponseSchema>https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>

What about after the profile is created? Whenever Outlook is launched an Autodiscover request is sent to Exchange to retrieve mailbox settings, and once these settings are retrieved it uses the OOF URL to retrieve the mailbox OOF settings (and
notifies client when it is enabled). Where does the Outlook client obtain the SMTP address for these requests? The primary SMTP address is stored within the Outlook profile settings within the registry under the HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\<YourProfileName>. You need to search underneath this key for 001f6641. Opening this value you will see the primary SMTP address of the user in the syntax SMTP:someone@fabrikam.com.

You can also locate this value by viewing the profile settings with MfcMapi. You can download MfcMapi here. The following steps can be used to locate this profile setting using MfcMapi:

In this example we can see that when the profile was created the primary SMTP address was fabrikam@fabrikam.com, but in the Autodiscover log the request was for someone@fabrikam.com. Then we checked the profile setting using MfcMapi and sure enough the value was someone@fabrikam.com. Outlook refreshes certain profile settings every 24 hours. Here the primary SMTP address for this user was modified and the original SMTP address was removed. Then when the Autodiscover request was sent to the CAS server the LDAP query for that e-mail address failed. Typically when an SMTP address is modified the original address is not removed and this issue will resolve itself within a day. You can also use MfcMapi to modify this value for immediate relief.

To determine what is happening within the RPC Client Access service we need to review the Rpc Client Access logs on the server. While parsing thru this log file I found a high volume of PublicLogon requests coming into this CAS server for a public folder database. These logon attempts are typical behavior as the CAS server will then redirect these requests to the mailbox server hosting the database. But taking a closer look at these requests and I see the database is last mounted on the expected mailbox server, however the client is being redirected to another server. (If you only have one public folder database you will simply see a high volume of requests coming into you CAS server and the CPU will most likely spike to near 100 percent). The log entry looks like the following:

2012-02-15T14:00:51.707Z,6,1,/o=EXCHORG/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Exchange User,,MFCMapi.exe,14.0.6109.5000,Classic,,,ncacn_http,,PublicLogon,1144 (rop::WrongServer),00:00:00.0621272,"Logon: Public,  in database c83d21d5-7228-455e-978d-81d6649863a1 last mounted on MBX1.contoso.com at 1/28/2012 8:01:35 PM, currently Mounted; Redirected: alternate server requested, suggested new server: /o=EXCHORG/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MBX2",RopHandler: Logon:

This issue is caused because the RpcClientAccess service on the mailbox server hosting the public folder database is not responding to client connections. If we take a look at the RPC Client Access logs on this server we should see minimal activity. This is a known issue that is documented in KB 2535105 (Outlook client applications cannot connect to public folders after you install Exchange Server 2010 SP1). The RPC Client Access service acts as a proxy for public folder availability requests and these requests are not completed. Eventually new connections for these EWS calls cannot be made because the connection group limit is reached. The KB article provides a registry key that is available starting with SP1 RU4 that disables these available service calls by the RPC Client Access service.

A .NET hotfix that resolves the underlying issue has been released since the posting of the Exchange KB, KB2497453 (FIX: Application may stop responding after several HTTP requests are aborted if you use the HttpWebRequest class to send requests in the .NET Framework). Install this hotfix on the mailbox server hosting the public folder database and reboot the mailbox server. Once this server is back online we need to restart the Rpc Client Access service on the CAS server to clear the cache. Then when we review the Rpc Client Access logs on the CAS server we should see clients being redirected to the server where the public folder database is mounted.

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

You may also notice that Exchange 2010 provided another cmdlet, Get-MailboxFolder. When I saw this I thought "Wow! I can run the Get-MailboxFolder and pipe the Add-MailboxFolderPermission and I'm done." Did you really think it would be that easy? The Get-MailboxFolder cmdlet only runs against the currently logged in user. Yes, you can't run this cmdlet against another mailbox. Take a look at the management role where this cmdlet is available.

Get-ManagementRole -Cmdlet Get-MailboxFolder

Okay. Then how can we use the Add-MailboxFolderPermission to run against a root folder and all of its subfolders? Looking at all the parameters available for the cmdlet there is no recurse (wouldn't that be nice). I was able to accomplish this task in two steps:

1. Get a list of folders from the mailbox
2. Add the permission to the folder

The first thing we need to obtain is the list of folders that we will apply permissions. We can utilize the Get-MailboxFolderStatistics cmdlet for this purpose. The result we want is the FolderPath value that is returned in the format "/Folderpath".

Get-MailboxFolderStatistics owner | Where { $_.FolderPath.Contains("FolderName") -eq $true }
 

Then we can use the Add-MailboxFolderPermission cmdlet to assign the permissions. The format for the folder name is "Mailbox:FolderPath" so we will need to modify the result from earlier to accomodate the expected value. The following example illustrates the example where Jane's manager John wants her to access his Clients folder and all of its subfolders.

ForEach($f in (Get-MailboxFolderStatistics John | Where { $_.FolderPath.Contains("/Clients") -eq $True } ) ) {
 $fname = "John:" + $f.FolderPath.Replace("/","\");
 Add-MailboxFolderPermission $fname -User Jane -AccessRights Reviewer }
 

Conclusion
This is only an example of how you can accomplish this task. Use this with caution and always test prior to running against a production mailbox. The one known issue is the possible results when using the Get-MailboxFolderStatistics cmdlet. You need to adjust your where clause appropriately so that you don't get unwanted results

$start = Read-Host "Enter the start time"
$subject = Read-Host "Enter the message subject"
$hub = Read-Host "Enter the transport server"
$mbx = Read-Host "Enter the mailbox server"
$mid = Read-Host "Enter the message ID"

$start = [datetime]$start
$end = $start.AddMinutes(10)

$messages = Get-MessageTrackingLog -Server $mbx -Start $start -End $end -MessageSubject $subject -MessageId $mid -ResultSize unlimited | Where { $_.SourceContext.Contains("MessageClass:IPM.Schedule.Meeting.Request") -eq $True -And $_.Server.Hostname -ieq $hub }
foreach($m in $messages)
{ $startChar = $m.SourceContext.IndexOf("Mailbox:") + 8;
$mbx = $m.SourceContext.Substring($startChar,36);
Get-Mailbox $mbx }