Troubleshooting the Exchange 2007 Autodiscover Service Among Multiple Forests


The Microsoft Exchange Server 2007 Autodiscover service provides the URLs for each Exchange Web service to Microsoft Office Outlook 2007 clients. The Autodiscover service also provides automatic profile configuration for Outlook 2007 clients in an Microsoft Exchange-based messaging environment.

When you install the Client Access Server role on a computer that is running Microsoft Exchange, a new virtual directory is created under the Default Web site in Internet Information Services (IIS). In the Active Directory directory service, a Service Connection Point object is created. This object allows all domain-connected clients that are running Outlook 2007 to query Active Directory, and to configure the Outlook profile automatically.

Many organizations have complex topologies that have the following conditions:

  • The organization has multiple forests in which Exchange is running in a resource forest.

  • The organization’s user accounts exist in a separate accounts forest or user forest.

In this kind of multiple trusted forest scenario, some Microsoft Exchange features rely on the Autodiscover service to access user accounts among the forests. Among such features are the Availability service, the Offline Address Book, Out of Office responses, and Unified Messaging. In this scenario, the Autodiscover service must be available to users across multiple trusted forests.

The purpose of this topic is not to explain how the Autodiscover service works. Instead, this topic explains how to implement the Autodiscover service in a multiple-forest topology. This topic also provides troubleshooting information for the Autodiscover service when it runs in typical multiple-forest environments. You can use this topic as a practical checklist of some common examples and methods for the Autodiscover service deployment. Use the checklist to resolve issues that you may experience in a multiple-forest environment.

For more information about how the Microsoft Exchange Autodiscover service works, and for deployment considerations, see the following white papers:

Troubleshooting Information

Step 1: Verify DNS name resolution

In Active Directory, the domain controller that holds the PDC Emulator role controls the trust relationship between domains. Therefore, verify that the domain controller that holds the PDC Emulator role in each forest can communicate with the opposite forest. To do this, use the Packet Internet Groper (Ping) tool to ping the domain name from the opposite forest.

Exchange 2007 multiple-forest organization

Exchange 2007 resource forest and accounts forest

In this scenario, use Ping.exe to verify communication with the following:

  • From the primary domain controller (PDC) in, ping

  • From the PDC in, ping (the Microsoft Exchange resource forest).

  • From an Outlook 2007 client in, ping

If any of these ping commands are unsuccessful, you must review the DNS name resolution in each forest. For example, review all the following items:

  • DNS client configuration

  • DNS server primary zones, secondary zones, and stub zones

  • DNS forwarding options and root hints options

Step 2: Test the trust relationship between the two forests

Verify the trust relationship between the resource forest and the user forest. A one-way outgoing trust is required between the Exchange resource forest and the user accounts forest. For detailed information about how to configure a trust, see Create a one-way, outgoing, forest trust for both sides of the trust.

To validate the domain trust between domains across the forests, run the Domain.msc snap-in on a domain controller in each forest. Or, you can run the following Netdom.exe command:

netdom trust <trusted_domain_name> /domain: <trusting_domain_name> /verify

If the trust is validated successfully, you receive the following results:

The trust between and has been successfully verified.

If you have to re-create the trust relationship between the account forest (user forest) domain and the resource forest (Exchange forest) domain, follow these steps.


For the purpose of these steps, is in the accounts forest, and is in the resource forest.

  1. Log on to a domain controller in the accounts forest. Then, start the Active Directory Domains and Trusts MMC snap-in.

  2. Under Active Directory Domains and Trusts, right-click the accounts forest, and then click Properties.

  3. Click the Trusts tab, and then click New Trust.

  4. In the New Trust Wizard, click Next.

  5. In the Name box, type the name of the resource forest. In this example, type, and then click Next.

  6. Click One-way incoming, and then click Next.

  7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next.

  8. On the User Name and Password page, type the credentials of an account that has administrative rights in the accounts domain. For example, type the credentials of an Administrator account in the domain. Then, click Next.

  9. Click Domain-wide authentication, and then click Next.

  10. On the Trust Selections Complete page, review the trust settings, and then click Next.

  11. On the Trust Creation Complete page, click Next.

  12. On the Confirm Incoming Trust page, click Yes, confirm incoming trust, click Next, and then click Finish.

  13. Verify that the new trust appears under Domains that trust this domain (incoming trusts) in the Properties dialog box.

Step 3: Verify master account permissions to a linked mailbox

A linked mailbox for each user in the accounts forest ( must be created in the resource forest ( Verify that the Master account has full access to the linked mailbox and to the SMTP address. To do this, use the Get-Mailbox and Get-MailboxPermission cmdlets.

For more information, see How to Create a Linked Mailbox.

When you run the cmdlets, you should receive results that resemble the following:

Get-Mailbox <mailbox_user> | fl










Get-MailboxPermission <mailbox_user> | fl


{FullAccess, ExternalAccount}






To use the Exchange Management Console to create a linked mailbox in the resource forest, follow these steps:

  1. In the Exchange Management Console, click Mailbox under Recipient Configuration, and then click New Mailbox in the Actions pane.

  2. In the New Mailbox dialog box, click Linked Mailbox, and then click Next.

  3. Click New user, and then click Next.

  4. On the User Information page, type the resource domain ( user information. For example, specify the following user information.

    1. Field

    1. Value

    1. Organizational unit


    1. First name

    1. Vandy

    1. Name


    1. User logon name

    1. Vandy

    1. Password

    1. <password>

    1. Confirm password

    1. <password>

    Then, click Next.

  5. In the Alias box, type a user alias. For example, type vandy. Then, click Next.

  6. On the Master Account page, type the account information for the accounts forest. For example, specify the following user information.

    1. Field

    1. Value

    1. Trusted forest or domain


    1. User name

    1. Northwindtraders\administrator

    1. Password

    1. <password>

    1. Linked domain controller


    1. Linked master account

    1. Northwindtraders\vandy

  7. Click Next.

  8. Under Configuration Summary, verify that the linked mailbox configuration is correct, click Next, and then click Finish.

The new linked mailbox appears in the Mailbox - details pane.

Step 4: Verify the Keywords and ServiceBindingInformationService attributes of the Service Connection Point

When you run the Export-AutoDiscoverConfig cmdlet, a new Service Connection Point (SCP) object is created in the account forest. This SCP object points to the URL for the Autodiscover service in the resource forest. For an Outlook 2007 client to locate an SCP to respond to the Autodiscover request, the following two attributes are required:

  • Keywords

  • ServiceBindingInformationService

In the resource forest, these attributes serve the following purposes:

  • The Keywords attribute contains the site name in which the Client Access Server (CAS) resides. The Keywords attribute controls site affinity to help an Outlook 2007 client find the best CAS to respond to Outlook requests.

  • The ServiceBindingInformation attribute contains the Autodiscover URL. For example, https://<cas_server>

In the accounts forest, these attributes serve the following purposes:

  • The Keywords attribute contains all the authoritative, accepted SMTP domains. In the Exchange Management Console, this information appears under Organization Configuration\Hub Transport\Accepted Domains.

  • The ServiceBindingInformation attribute contains an LDAP URL (for example, ldap:// for the Microsoft Exchange resource forest.

To review the Keywords and ServiceBindingInformationService attributes in the SCP object for each Microsoft Exchange Client Access Server, you can use the ldifde.exe command, Adsiedit.msc, or the Get-ClientAccessServer cmdlet. For example, you can use the following commands.

Ldifde command

Ldifde -f scp_account.txt -d ",CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Nwtraders,DC=com"


dn:,CN=MicrosoftExchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com

distinguishedName:,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com







Get-ClientAccessServer cmdlet

Get-ClientAccessServer | fl *Auto*











Step 5: Verify SCP discoverability from an Outlook 2007 client

If the SCP Keywords and ServiceBindingInformationService objects exist and are configured correctly, verify that an Outlook 2007 client can locate the objects. To do this, follow these steps:

  1. Modify the Default Domain Controllers Group Policy Object in the resource forest to enable auditing.

  2. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then expand Audit Policy.

  3. In the details pane, double-click Audit directory service access, click to select the Success check box, and then click OK.

  4. Enable Success auditing for the following policies:

    • Audit account logon events

    • Audit account management

    • Audit directory service access

    • Audit logon events

    • Audit policy change

    • Audit system events

  5. Start the ADSIEdit.msc snap-in on a domain controller in the accounts forest to enable auditing of the SCP object.

  6. In ADSI Edit, expand the Configuration container, and then expand the following path:,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com

  7. Right-click the Microsoft Exchange Autodiscover object, and then click Properties.

  8. Click the Security tab, click Advanced, and then click the Auditing tab.

  9. In the Auditing entries list, add the Everyone group.

  10. In the Access list, click to select the Read All Properties check box in the Successful column.

  11. Click OK three times to save the changes to the object.

  12. Create an Outlook 2007 profile, or use the Test E-mail Autoconfiguration feature to generate auditing events. Either method generates the following events in the System log and in the Security log.

System log events

Event ID 540 is logged in the System log for each successful logon.

  1. Event Source: Security

  2. Category: Logon/Logoff

  3. Event ID: 540

  4. User: NORTHWINDTRADERS\<UserName>

  5. Description:

  6. Successful Network Logon:

  7. User Name: <UserName>


  9. Logon ID: <ID>

  10. Logon Type: 3

  11. Logon Process: Kerberos

  12. Authentication Package: Kerberos

  13. Workstation Name:

  14. Logon GUID: <GUID>

Security log events

The following event is logged in the Security log if the user was able to query the SCP object. In this event description, the object name is the SCP in the Account forest.

Event Source: Security

Category: Directory Service Access

Event ID: 566



Object Operation

Object Server: DS

Operation Type: Object Access

Object Type: serviceConnectionPoint

Object Name:,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=northwindtraders,DC=com

Handle ID: -

Primary User Name: <UserName>


Step 6: Review certificate settings

By default, when you install the Client Access Server role, a self-signed certificate is installed. This certificate has a common name that is mapped to the NetBIOS name of the server. The self-signed certificate also includes the internal FQDN of the server as an additional DNS name that is stored in the certificate's Subject Alternative Name (SAN) field. This enables domain-connected clients to successfully connect to the Autodiscover service without receiving any certificate warnings, if the certificate has not expired. For more information, see the Autodiscover and Certificates section of the White Paper: Exchange 2007 Autodiscover Service white paper.


Typically, the self-signed certificate will be replaced by another certificate that is generated by using Windows Certificate Services or that is obtained from a third-party Certification Authority. The new certificate usually includes DNS names that differ from or that are in addition to those that are included in the original self-signed certificate. The examples in this section are based on a certificate that has been generated from an internal CA.

Use the Get-ExchangeCertificate cmdlet to review the Exchange certificate on the Client Access server. When you run this cmdlet, verify the following attributes:

  • CertificateDomains

  • Services

  • Status

  • IsSelfSigned

  • Issuer

  • Subject

Get-ExchangeCertificates cmdlet

Get-ExchangeCertificates | fl


CertificateDomains : {, TX136711-MS1,,, }

HasPrivateKey : True

IsSelfSigned : False

Issuer : CN=Fourthcoffee, DC=Fourthcoffee, DC=com

Services : IMAP, POP, IIS

Status : Valid

Subject :

Step 7: Run the Export-AutodiscoverConfig cmdlet

Every time that you create a new authoritative accepted domain under Organization Configuration\Hub Transport\Accepted Domains in the Exchange Management Console, you must run the Export-AutodiscoverConfig cmdlet. This action updates the keyword attribute in the accounts forest.


The keyword attribute is not automatically updated in the accounts forest when you create a new authoritative accepted domain.

Before you run the Export-AutodiscoverConfig cmdlet, the keywords information resembles the following:

dn:,CN=MicrosoftExchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com

distinguishedName:,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com







On an Exchange CAS server in the source forest, run the following command to retrieve the credentials that are required to run the Export-AutodiscoverConfig cmdlet:

$a = Get-Credential

Then, run the following Export-AutodiscoverConfig command:

Export-AutoDiscoverConfig -DomainController <FQDN> -TargetForestDomainController <String> -TargetForestCredentials $a -MultipleExchangeDeployments $true

Step 8: Run the Exchange 2007 Extra.exe tool

Use the Microsoft Exchange Troubleshooting Assistant (Extra.exe) to trace the Autodiscover service.

  1. Click Start, click Run, type extra.exe, and then click OK.

  2. Click Go to the Welcome Screen, and then click Select a Task.

  3. Click Trace Control, and then click OK if you receive a message that states that Exchange does not have a module to interpret traces.

  4. Click Set manual trace tags, and then click to select the following trace type check boxes:

    • PFD

    • Fatal

    • Error

    • Warning

    • Info

    • Performance

    • Function

  5. In the Components to trace list, click to select the following check boxes:

    • ADProvider

    • MSExchangeAutodiscover

  6. Click Start Tracing


The following trace results show an Outlook 2007 profile that was created successfully. To follow the trace results, determine the user account that you want to troubleshoot together with the corresponding UserID. In this example, the user account is

577502E94268MSExchangeAutodiscoverFramework[Provider.base()] Timestamp="16:53:55.5388560";CompterNameHash="1359685320";EmailAddress="";LegacyDN="";UserSID="S-1-5-21-1704072791-1889598559-3047533862-1110";

57870ADProviderLdapFilterBuilderLdapFilterBuilder::LdapFilterFromQueryFilter - forming LDAP Filter for (&((&((|((Sid Equal S-1-5-21-1704072791-1889598559-3047533862-1110)(MasterAccountSid Equal S-1-5-21-1704072791-1889598559-3047533862-1110)))(ObjectClass NotEqual foreignSecurityPrincipal)))(|((ObjectCategory Equal person)(ObjectCategory Equal msExchDynamicDistributionList)(ObjectCategory Equal group)(ObjectCategory Equal publicFolder)(ObjectCategory Equal msExchPublicMDB)(ObjectCategory Equal msExchSystemMailbox)(ObjectCategory Equal msExchExchangeServerRecipient)(ObjectCategory Equal exchangeAdminService)))(!((&((ExchangeVersion GreaterThanOrEqual 1.0 (

57880ADProviderLdapFilterBuilderLdapFilterBuilder::LdapFilterFromQueryFilter - Ldap filter = (&(|(objectSid=S-1-5-21-1704072791-1889598559-3047533862-1110)(msExchMasterAccountSid=S-1-5-21-1704072791-1889598559-3047533862-1110))(!(objectClass=foreignSecurityPrincipal))(|(objectCategory=person)(objectCategory=msExchDynamicDistributionList)(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchPublicMDB)(objectCategory=msExchSystemMailbox)(objectCategory=msExchExchangeServerRecipient)(objectCategory=exchangeAdminService))(!(&(msExchVersion>=1125899906842624)(msExchVersion=*)))).

5799013965FAADProviderADFindADSession::Find using - LDAP search from , scope 2, filter (&(|(objectSid=S-1-5-21-1704072791-1889598559-3047533862-1110)(msExchMasterAccountSid=S-1-5-21-1704072791-1889598559-3047533862-1110))(!(objectClass=foreignSecurityPrincipal))(|(objectCategory=person)(objectCategory=msExchDynamicDistributionList)(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchPublicMDB)(objectCategory=msExchSystemMailbox)(objectCategory=msExchExchangeServerRecipient)(objectCategory=exchangeAdminService))(!(&(msExchVersion>=1125899906842624)(msExchVersion=*)))), sizeLimit 2, timeout 00:00:30

66130MSExchangeAutodiscoverFramework[LoadProvider()] 'provider "Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider, Microsoft.Exchange.Autodiscover, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is loaded'

661702E94268MSExchangeAutodiscoverFramework[base.GenerateResponseXml()] 'redirectOrError=false; 'Calling provider's WriteConfigXml()'

668003B97E22MSExchangeAutodiscoverFramework[OnLoad()] 'Request is successfully processed'

For More Information

For more information, see the following documents: