Resolve free/busy errors

2025-06-25
Applies to: Outlook for Microsoft 365, Outlook 2021, Outlook 2019, Outlook 2016, Outlook on the web, Outlook for Android, Outlook for iOS, Outlook for Mac

To troubleshoot an error that's related to free/busy information, select the applicable error message from the table of contents (TOC) at the top of this article.

If the troubleshooting steps don't help you resolve the issue, contact Microsoft Support.

An error occurred when verifying security for the message

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Autodiscover failed for email address <smtp address> with error System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message at System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

This error can occur if WSSecurity authentication isn't enabled or has to be reset, or after you renew federation certificates in Exchange Server.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

To refresh metadata in the Microsoft Federation Gateway, run the following command two times in the on-premises Exchange Management Shell (EMS):
```
Get-FederationTrust | Set-FederationTrust -RefreshMetadata
```
For more information, see Free/busy lookups stop working in a cross-premises environment or in an Exchange Server hybrid deployment.
Follow these steps to toggle WSSecurity authentication:
1. Follow the procedure in Users from a federated organization can't see the free/busy information of another Exchange organization to enable—or reset if already enabled—WSSecurity authentication in both the Autodiscover and EWS virtual directories on all on-premises Exchange servers.
  
  Notes
  - Perform this step even if the output of the PowerShell cmdlets Get-AutodiscoverVirtualDirectory and Get-WebServicesVirtualDirectory indicate that WSSecurity authentication is already enabled.
  - The procedure affects only cross-premises free/busy and won't affect other client-server connections.
2. Run the iisreset /noforce command in a PowerShell or Command Prompt window on each on-premises Exchange server to restart IIS.
3. Restart all on-premises Exchange servers.
Check for and resolve any time-skew warnings or errors in the System event log.
Set the TargetSharingEpr parameter value in the organization relationship to the on-premises external Exchange Web Services (EWS) URL by running the following cmdlet in Exchange Online PowerShell:
```
Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
```
After you set the TargetSharingEpr parameter value, the cloud mailbox bypasses Autodiscover and connects directly to the EWS endpoint of the on-premises mailbox.

Note: The default value of the TargetSharingEpr parameter is blank. The Autodiscover parameters TargetAutodiscoverEpr or DiscoveryEndpoint usually contain the on-premises EWS external URL (Autodiscover endpoint). To get the TargetAutodiscoverEpr and DiscoveryEndpoint parameter values, run the following PowerShell cmdlets:
```
Get-OrganizationRelationship | FL TargetAutodiscoverEpr
Get-IntraOrganizationConnector | FL DiscoveryEndpoint
```
Make sure that the TargetApplicationUri parameter value in the organization relationship matches the AccountNamespace parameter value in the federated organization identifier. To find the TargetApplicationUri parameter value, run the Test-OrganizationRelationship PowerShell cmdlet. To find the AccountNamespace parameter value, see Demystifying hybrid free/busy.

Proxy web request failed: Unable to connect to the remote server

Issue

You have cloud user who can't view the free/busy information for an on-premises user, or vice-versa. When you diagnose the issue, you find the following error message:

Proxy web request failed. , inner exception: System.Net.WebException: Unable to connect to the remote server ; System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond CUSTOMER_IP:443 / MICROSOFT_IP:443 at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

This error can occur if network connectivity issues prevent inbound or outbound connections between IP addresses in Exchange Online and endpoints in Exchange Server.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Verify that the firewall on each on-premises Exchange server allows inbound or outbound connections between Exchange Server endpoints and Exchange Online IP addresses. To identify firewall issues, make a free/busy request from Exchange Online and then check the on-premises firewall, reverse proxy, and network logs. For more information about how to configure a firewall, see Firewall considerations for federated delegation and Microsoft 365 URLs and IP address ranges.
Verify that requests from Exchange Online reach the on-premises Client Access servers. Follow these steps on all on-premises Client Access servers:
1. Make a free/busy request from Exchange Online.
2. Check the IIS logs in the W3SVC1 folder for the default website to verify that the free/busy request is logged. The W3SVC1 folder path is %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.
3. Check the HTTP proxy logs in the following folders to verify that the free/busy request is logged:
  - %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover
  - %ExchangeInstallPath%\Logging\HttpProxy\Ews
Test connectivity from Exchange Online to the on-premises Exchange Web Services (EWS) endpoint by running the following cmdlet in Exchange Online PowerShell:
```
Test-MigrationServerAvailability -RemoteServer <on-premises mail server FQDN> -ExchangeRemoteMove -Credentials (Get-Credential)
```
Notes
- This test is useful if you restrict inbound connections from the internet to allow only Exchange Online IP addresses to connect to your on-premises EWS endpoint.
- If only a few cloud users are affected by this issue, and their mailboxes are hosted on the same mail server in Exchange Online, check whether that mail server can connect to on-premises endpoints. It's possible that an on-premises endpoint blocks connections from the outbound external IP address of that mail server.
- When you're prompted for credentials, enter your domain administrator credentials in "domain\administrator" format.

Autodiscover failed for email address: HTTP status 404

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Autodiscover failed for email address <user SMTP address> with error System.Net.WebException: The request failed with HTTP status code 404 Not Found.

This error can occur if Autodiscover endpoints are nonfunctional or misconfigured.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Check whether the Autodiscover endpoint is valid:
1. Run the following commands to get the Autodiscover endpoint URL from the DiscoveryEndpoint or TargetAutodiscoverEpr parameter:
```
Get-IntraOrganizationConnector | FL DiscoveryEndpoint
Get-OrganizationRelationship | FL TargetAutodiscoverEpr
```
2. Navigate to the Autodiscover endpoint URL in a web browser. A valid Autodiscover endpoint won't return HTTP status code 404 Not Found.
Make sure that the domain of the on-premises user is specified in the organization settings (intra-organization connector or organization relationship) of the cloud user:
1. Run the following PowerShell cmdlets in Exchange Online PowerShell:
```
Get-IntraOrganizationConnector | FL TargetAddressDomains
Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
```
  Verify that the domain of the on-premises user is listed in the output of either command. For example, if cloud user user1@contoso.com looks up the free/busy for on-premises user user2@contoso.ro, verify that the on-premises domain contoso.ro is listed.
2. If the domain of the on-premises user doesn't exist in the organization settings of the cloud user, add the domain by running the following PowerShell cmdlet:
```
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
```
Make sure that the SVC handler mapping exists in both the Autodiscover and EWS virtual directories under Default Web Site in IIS Manager. For more information, see FederationInformation couldn't be received and Exception has been thrown by the target.

Note: The AutodiscoverDiscoveryHander mapping (*.svc) isn't used for federation free/busy lookup.

Exception proxy web request failed

LID: 43532

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Exception Proxy web request failed. , inner exception: The request failed with HTTP status 401: Unauthorized diagnostics: 2000005;reason= "The user specified by the user-context in the token is ambiguous." ;error_category="invalid_user"

This error can occur if the UPN, SMTP address, or SIP address of the on-premises user is used by another on-premises mailbox.

Resolution

To fix the issue, follow these steps:

Search for on-premises user objects that have a duplicate UPN, SMTP address, or SIP address by using custom LDAP queries. You can run LDAP queries by using LDP.exe or the Active Directory Users and Computers MMC snap-in.

For example, to show all users that have user@corp.contoso.com as the UPN, user@contoso.com as the SMTP address, or user@contoso.com as the SIP address, use the following LDAP query:
```
(|(userPrincipalName=user@corp.contoso.com)(proxyAddresses=SMTP:user@contoso.com)(proxyAddresses=sip:user@contoso.com))
```
For more information about how to use LDP.exe or Active Directory Users and Computers to find Active Directory objects, see LDP examples.
Change the duplicate address or delete the duplicate user object.

An existing connection was forcibly closed by the remote host

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Proxy web request failed. , inner exception: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host.

This error can occur if an on-premises firewall blocks an inbound connection from an external outbound IP address in Exchange Online.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Check whether free/busy requests from Exchange Online reach IIS on an Exchange server. Make a free/busy request from Exchange Online and search for the following IIS log entries that were made at the time of the free/busy request:
- An Autodiscover entry in the %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover folder that contains "ASAutoDiscover/CrossForest/EmailDomain".
  
  Note: If you manually set the TargetSharingEpr parameter in the organization relationship to the on-premises external Exchange Web Services (EWS) URL, Autodiscover is bypassed, and this entry won't exist.
- An EWS entry in the %ExchangeInstallPath%\Logging\HttpProxy\Ews folder that contains "ASProxy/CrossForest/EmailDomain".
Note: Timestamps in IIS logs use UTC time.
Verify that the firewall on each on-premises Exchange server allows inbound or outbound connections between Exchange Server endpoints and Exchange Online IP addresses. To identify firewall issues, make free/busy requests from Exchange Online, and then check the on-premises firewall, reverse proxy, and network logs. For more information about how to configure a firewall, see Firewall considerations for federated delegation and Microsoft 365 URLs and IP address ranges.
If your organization uses organization relationships to implement free/busy, make sure a federation certificate is installed on each Exchange server. Run the following commands in the Exchange Management Shell (EMS):
```
Test-FederationTrustCertificate
Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
```
If the federation certificate is installed, the command output shouldn't contain any errors or warnings.
Follow these steps to toggle WSSecurity authentication:
1. Follow the procedure in Users from a federated organization can't see the free/busy information of another Exchange organization to enable—or reset if already enabled—WSSecurity authentication in both the Autodiscover and EWS virtual directories on all on-premises Exchange servers. Perform this step even if WSSecurity authentication is already enabled.
2. Recycle the Autodiscover and EWS application pools in IIS Manager.
3. Run the iisreset /noforce command in a PowerShell or Command Prompt window on each on-premises Exchange server to restart IIS.
If only a few cloud users are affected by this issue, and their mailboxes are hosted on the same mail server in Exchange Online, check whether that mail server can connect to on-premises endpoints. It's possible that an on-premises endpoint blocks connections from the outbound IP address of that mail server.

Configuration information for forest/domain could not be found in Active Directory

LID: 47932

Issue

You have a cloud user who can't view the free/busy information for an on-premises user, or vice-versa. When you diagnose the issue, you find the following error message:

Configuration information for forest/domain <domain> could not be found in Active Directory.

This error can occur if organization settings are misconfigured.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Verify that the domain of a user whose free/busy information is requested exists in the organization settings of the user that's trying to view the free/busy information. Select one of the following procedures depending on the free/busy direction.
- Cloud to on-premises
  
  For a cloud user that tries to view the free/busy information for an on-premises user, follow these steps:
  1. Connect to Exchange Online PowerShell, and then run the following PowerShell cmdlets to get the federated domains:
```
Get-IntraOrganizationConnector | FL TargetAddressDomains
Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
```
    Verify that the domain of the on-premises user is listed in the output of either command. For example, if cloud user user1@contoso.com looks up the free/busy for on-premises user user2@contoso.ro, verify that the on-premises domain contoso.ro is listed.
    
    Note
    
    You can also find the domain names by running (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses in Exchange Online PowerShell, or by running (Get-FederatedOrganizationIdentifier).Domains in the on-premises Exchange Management Shell (EMS).
  2. If the domain of the on-premises user doesn't exist in the organization settings of the cloud user, add the domain by running the following PowerShell cmdlet:
```
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
```
- On-premises to cloud
  
  For an on-premises user that tries to view the free/busy information for a cloud user, follow these steps:
  1. In the EMS, run the following PowerShell cmdlets:
```
Get-IntraOrganizationConnector | FL TargetAddressDomains
Get-OrganizationRelationship -Identity <on-premises to cloud ID> | FL DomainNames
```
    Check whether the domain of the cloud user is a match for one of the domains listed in the command output. For example, if on-premises user user1@contoso.ro looks up free/busy information for cloud user user2@contoso.com, verify that the cloud domain contoso.com is present in the output of either command.
  2. If the domain of the cloud user doesn't exist in the organization settings of the on-premises user, add the domain. Run the following command:
```
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<cloud domain>"}
```
Make sure that your hybrid Exchange deployment has a full hybrid configuration. If it's necessary, rerun the Hybrid Configuration Wizard (HCW) and select Full Hybrid Configuration instead of Minimal Hybrid Configuration. A minimal hybrid configuration doesn't create an organization relationship (federation trust) or intra-organization connectors.

Proxy web request failed: HTTP status 401

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find either of the following error messages.

Error message 1

Proxy web request failed. ,inner exception: The request failed with HTTP status 401: Unauthorized.

Error message 2

Autodiscover failed for email address. ,inner exception: The request failed with HTTP status 401: Unauthorized.

This error can occur if a perimeter device in front of Exchange Server is configured to preauthenticate (require username and password) instead of passing requests from Exchange Online directly through to Exchange Server. The Autodiscover and EWS virtual directories in hybrid Exchange deployments don't support preauthentication.

Examples of perimeter devices include reverse proxies, firewalls, and Microsoft Threat Management Gateway (TMG).

Error message 1 indicates that an EWS request failed.

Error message 2 indicates that an Autodiscover request failed.

Troubleshooting steps

To troubleshoot the free/busy issue regardless of which error message you received, use the following steps. After you complete each step, check whether the free/busy issue is fixed.

Check whether preauthentication is enabled. Follow these steps:
1. Run the Free/Busy test in the Remote Connectivity Analyzer to check whether preauthentication is enabled. The cloud mailbox is the Source Mailbox, and the on-premises mailbox is the Target Mailbox. After the test completes, check the pass-through authentication status at the endpoint. If you see a red checkmark, disable preauthentication and retest. If you see a green checkmark, continue to the next step because it could be a false positive.
2. Check whether a free/busy request from Exchange Online reaches IIS. Perform a free/busy query and then search the IIS logs in Exchange Server for any of the following entries at the time of the query:
  - In the %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover folder, search for an Autodiscover entry that has the HTTP status code 401 Unauthorized and contains the text "ASAutoDiscover/CrossForest/EmailDomain".
    
    Note: If the TargetSharingEpr parameter in the organization relationship specifies an on-premises EWS external URL, then Autodiscover is bypassed and this entry won't appear.
  - In the %ExchangeInstallPath%\Logging\HttpProxy\Ews folder, search for an EWS entry that has the HTTP status code 401 Unauthorized and contains the text "ASProxy/CrossForest/EmailDomain".
  Note: Timestamps in IIS logs use UTC time. Some entries that have the HTTP status code 401 Unauthorized are normal.
  
  The specified entries indicate that the free/busy request reached IIS and usually rules out preauthentication issues. If you don't find the specified entries, check your reverse proxy and firewall logs to understand where the free/busy request got stuck.
Make sure that you have enabled WSSecurity (Exchange Server 2010) or OAuth authentication (Exchange Server 2013 and later versions) on the EWS and Autodiscover virtual directories. Also, verify that you have enabled the default authentication settings in IIS for the Autodiscover and EWS virtual directories. For more information, see Default authentication settings for Exchange virtual directories and Default settings for Exchange virtual directories.

Follow the resolution steps in An error occurred when verifying security for the message. If WSSecurity is configured, make sure that you perform the step that toggles WSSecurity. If OAuth authentication is configured instead of WSSecurity, toggle OAuth authentication on the Autodiscover and EWS virtual directories by running the following commands:

Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$False
Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$True 
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$False 
Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$True

Verify that you have an up-to-date federation trust. Run the following command in Exchange Online PowerShell to retrieve the federation trust information for your Exchange organization:
```
Get-FederationTrust
```
The command output should contain the following information:

Name ApplicationIdentifier ApplicationUri

WindowsLiveId 260563 outlook.com

MicrosoftOnline 260563 outlook.com

Note: The WindowsLiveId trust is a consumer instance of the Microsoft Federation Gateway. The MicrosoftOnline trust is a business instance of the Microsoft Federation Gateway.

For an up-to-date federation trust, make sure that the ApplicationIdentifier is 260563 and not 292841, and that the ApplicationUri is outlook.com and not outlook.live.com. If you have an outdated federation trust, contact Microsoft Support.

Name	ApplicationIdentifier	ApplicationUri
WindowsLiveId	260563	outlook.com
MicrosoftOnline	260563	outlook.com

Autodiscover failed for email address: InvalidUser

LID: 33676

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

The response from the Autodiscover service at 'https://Autodiscover/Autodiscover.svc/WSSecurity' failed due to an error in user setting 'ExternalEwsUrl'. Error message: InvalidUser.

The error message might show up when you run the Free/Busy test in the Remote Connectivity Analyzer.

This error can occur if the cloud mailbox or Autodiscover endpoint is misconfigured.

Troubleshooting steps

Verify that the cloud user has a secondary SMTP address that includes the onmicrosoft.com domain by running the following command:
```
Get-Mailbox -Identity <mailbox ID> | FL EmailAddresses
```
For example, a user who has the primary SMTP address user1@contoso.com should have a secondary SMTP address that's similar to user1@contoso.mail.onmicrosoft.com.

If the cloud user is managed from Exchange Server, add the secondary SMTP address to Exchange Server, and then synchronize identity data between your on-premises environment and Microsoft Entra ID.
Run the following commands to set the TargetSharingEpr parameter value in the organization relationship to the on-premises external Exchange Web Services (EWS) URL:
```
Connect-ExchangeOnline
Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
```
After you set the TargetSharingEpr parameter value, the cloud mailbox bypasses Autodiscover and connects directly to the EWS endpoint of the on-premises mailbox.

The caller does not have access to free/busy data

LID: 47652, 44348, 40764

Issue

You have a cloud user who can't view the free/busy information for an on-premises user, or vice-versa. When you diagnose the issue, you find the following error message:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: The caller does not have access to free/busy data.

This error can occur if the mailbox of the user whose free/busy information is requested is misconfigured.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Check the calendar permissions of the user whose free/busy information is requested by running the following command:
```
Get-MailboxFolderPermission -Identity <mailbox ID>:\Calendar
```
The AccessRights value for the Default user in the command output should be AvailabilityOnly or LimitedDetails. If the AccessRights value is None, run the following PowerShell cmdlet to set that value to either AvailabilityOnly or LimitedDetails:
```
Set-MailboxFolderPermission -Identity <mailbox ID>:\Calendar -AccessRights <access rights value>
```
Use the applicable method to check the organization relationship:
- If a cloud user can't view the free/busy information for an on-premises user:
  
  Verify that the on-premises organization relationship specifies the cloud domain that can access the on-premises free/busy information. An example cloud domain is contoso.mail.onmicrosoft.com. For information about how to modify the organization relationship in Exchange Server, see Use PowerShell to modify the organization relationship. Also verify that the From email address of the cloud user has the same cloud domain, for example lucine.homsi@contoso.mail.onmicrosoft.com.
- If an on-premises user can't view the free/busy information for a cloud user:
  
  Verify that the cloud organization relationship specifies the on-premises domain that can access the cloud free/busy information. An example on-premises domain is contoso.com. For information about how to modify the organization relationship in Exchange Online, see Use Exchange Online PowerShell to modify the organization relationship. Also verify that the From email address of the on-premises user has the same on-premises domain, for example lucine.homsi@contoso.com.

An error occurred when processing the security tokens in the message

LID: 59916

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Proxy web request failed. , inner exception: An error occurred when processing the security tokens in the message.

This error can occur if the certificates or metadata in the Microsoft Federation Gateway are invalid.

Troubleshooting steps

Check the expiration date and thumbprints of the on-premises federation trust certificates by running the following PowerShell cmdlets:
```
Get-FederationTrust | FL
Test-FederationTrust
Test-FederationTrustCertificate
```
To refresh metadata in the Microsoft Federation Gateway, run the following command two times in the on-premises Exchange Management Shell (EMS):
```
Get-FederationTrust | Set-FederationTrust -RefreshMetadata
```
For more information, see Free/busy lookups stop working.

The cross-organization request is not allowed because the requester is from a different organization

LID: 39660

Issue

You have a hybrid mesh scenario in which a cloud user in a nonhybrid Exchange Online tenant can't view the free/busy information for a cloud user in another Exchange Online tenant that goes hybrid. When you diagnose the issue, you find the following error message:

The cross-organization request for mailbox <SMTP address> is not allowed because the requester is from a different organization
Recipient: <SMTP address>
Exception Type: CrossOrganizationProxyNotAllowedForExternalOrganization
Exception Message: The cross-organization request for <SMTP address> is not allowed because the requester is from a different organization.

For example, a user lucine@adatum.com in a nonhybrid Exchange Online tenant can't view the free/busy of a cloud user chanok@contoso.com in a hybrid tenant. The cloud user chanok@contoso.com has a proxy email address chanok@contoso.mail.onmicrosoft.com. The nonhybrid tenant has two organization relationships: contoso.com (on-premises) and contoso.mail.onmicrosoft.com (cloud). Autodiscover for contoso.com points to Exchange Server, and Autodiscover for contoso.mail.onmicrosoft.com points to Exchange Online. The user in the nonhybrid tenant receives the error message when querying the free/busy information for chanok@contoso.com, because Autodiscover for contoso.com points doesn't point to Exchange Online.

Note

For the equivalent on-premises hybrid mesh scenario, see Hybrid mesh.

Workaround

To work around this issue, your organization can use one of the following methods:

Users in the nonhybrid Exchange Online tenant should query the free/busy of a cloud user in a hybrid tenant by using the email address for which Autodiscover points to Exchange Online. For example, lucine@adatum.com queries free/busy information for chanok@contoso.mail.onmicrosoft.com. To successfully query free/busy information, users in the nonhybrid Exchange Online tenant must know which users in the hybrid tenant are hosted in the cloud, and for each of those users, the email address for which Autodiscover points to Exchange Online.
An admin of the nonhybrid Exchange Online tenant should set the external email address of each cloud user in the hybrid tenant to the email address for which Autodiscover points to Exchange Online. For example, an admin in the nonhybrid Exchange Online tenant sets the target email address of chanok@contoso.com in the hybrid tenant to chanok@contoso.mail.onmicrosoft.com. To make this change, the admin must know which users in the hybrid tenant are hosted in the cloud, and for each of those users, the email address for which Autodiscover points to Exchange Online. For more information about cross-tenant synchronization of user email addresses, see What is cross-tenant synchronization.

More information

A user might encounter a similar issue in the following scenario:

The user is in a nonhybrid Exchange Server tenant.
The user tries to view the free/busy for an on-premises user in a hybrid tenant.
Autodiscover for the hybrid tenant points to Exchange Online.

For example, a user in a nonhybrid Exchange Server tenant can't view the free/busy information for on-premises user chanok@contoso.com in a hybrid tenant because Autodiscover for contoso.com points to Exchange Online (autodiscover-s.outlook.com).

The request failed with HTTP status 401: Unauthorized (missing signing certificate)

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

If you run the Test-OAuthConnectivity cmdlet, you see the following error message in the command output:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Missing signing certificate.

For example, you run the following command:

Test-OAuthConnectivity -Service AutoD -TargetUri <on-premises Autodiscover URL> -Mailbox <mailbox ID> -Verbose | FL

The TargetUri parameter value is the on-premises Autodiscover service URL. An example of that URL is https://mail.contoso.com/Autodiscover/Autodiscover.svc.

This error can occur if the authentication configuration has an invalid OAuth certificate.

Resolution

To fix the issue, follow these steps:

Run the following PowerShell cmdlet in the Exchange Management Shell (EMS) to get the thumbprint of the OAuth certificate that's used by the authentication configuration:
```
Get-AuthConfig | FL CurrentCertificateThumbprint
```
If the command output doesn't return a certificate thumbprint, go to step 3. Otherwise, continue to the next step.
Run the following PowerShell cmdlet to check whether the certificate that's identified in step 1 exists in Exchange Server:
```
Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
```
If Exchange Server doesn't return any certificate, go to step 3 to create new certificate.

If Exchange Server returns a certificate, but its thumbprint differs from the thumbprint that you obtained in step 1, go to step 4. In step 4, specify the thumbprint of the certificate that Exchange Server returned.
Run the following PowerShell cmdlet to create a new OAuth certificate:
```
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "CN=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName <Domain> -Services SMTP
```
Note

If you're prompted to replace the SMTP certificate, don't accept the prompt.

In step 4, specify the thumbprint of the new certificate that you created in this step.
Run the following PowerShell cmdlets to update the authentication configuration to use the specified certificate:
```
$date=Get-Date 
Set-AuthConfig -NewCertificateThumbprint <certificate thumbprint> -NewCertificateEffectiveDate $date
Set-AuthConfig -PublishCertificate
```
Note

If you're warned that the effective date is less than 48 hours from now, choose to continue.
Run the following PowerShell cmdlet to remove any references to the previous certificate:
```
Set-AuthConfig -ClearPreviousCertificate
```

The application is missing a linked account for RBAC roles, or the linked account has no RBAC role assignments, or the calling users account is logon disabled

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

System.Web.Services.Protocols.SoapException: The application is missing a linked account for RBAC roles, or the linked account has no RBAC role assignments, or the calling users account is logon disabled.

Troubleshooting steps

To troubleshoot the issues that are mentioned in the error message, use the following steps. After you complete steps 1 and 2, check whether the free/busy issue is fixed.

Make sure that the "Exchange Online-ApplicationAccount" entry exists in the list of Exchange Server partner applications. To check, run the following PowerShell cmdlet in the Exchange Management Console (EMS):
```
Get-PartnerApplication | FL LinkedAccount
```
The account entry should appear as <root domain FQDN>/Users/Exchange Online-ApplicationAccount. If the entry is listed, go to step 2.

If the account entry isn't listed, add the account by following these steps:
1. Run the following PowerShell cmdlets to find the account in the on-premises Active Directory:
```
Set-ADServerSettings -ViewEntireForest $true 
Get-User "Exchange Online-ApplicationAccount" 
```
  If the account is listed in Active Directory, go to step 1b.
  
  If the account isn't listed in Active Directory, it might have been deleted. Use ADRestore to check the account status and restore it, if it's deleted. If you restored the account by using ADRestore, go to step 1b.
  
  If you're can't restore the account by using ADRestore, follow the procedure that's discussed in Active Directory and domains for Exchange Server. If that procedure doesn't restore the account, manually create the account in Active Directory, and then continue to step 1b.
2. Run the following PowerShell cmdlet to add the Active Directory account to the list of Exchange Server partner applications:
```
Set-PartnerApplication "Exchange Online" -LinkedAccount "<root domain FQDN>/Users/Exchange Online-ApplicationAccount"
```
3. Restart all on-premises Exchange servers, or restart IIS by running the iisreset /noforce command in a PowerShell or Command Prompt window on each server.
Run the following PowerShell cmdlet in the EMS to check the role-based access control (RBAC) assignments:
```
Get-ManagementRoleAssignment -RoleAssignee "Exchange Online-ApplicationAccount" | FL Name,Role
```
For example, the command output might list the following role assignments:
Search the following logs for the issues that are stated in the error message:
- Exchange Web Services (EWS) logs that are located in the %ExchangeInstallPath%\Logging\Ews folder
- Application event logs
- System event logs
Search the logs that are listed in step 3 for an error message that references AuthzInitializeContextFromSid. If you find that error message, see the following resources:
- Some applications and APIs require access to authorization information on account objects
- Access checks fail because of AuthZ

The entered and stored passwords do not match

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Soap fault exception received. The entered and stored passwords do not match.

You see the same error message when you run the following cmdlet to check whether the cloud user can retrieve a delegation token for the on-premises user mailbox:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Cause

An inconsistency exists in the Azure credentials for specific cloud users.

Resolution

To fix the issue, follow these steps:

Reset the cloud user's password. Choose either the same or a different password.
Update the user principal name (UPN) of the cloud user to use the onmicrosoft.com domain, and then revert the UPN to its former value. For example, if the UPN of the cloud user is user@contoso.com, change it to the temporary UPN, user@contoso.mail.onmicrosoft.com, and then revert the UPN to user@contoso.com. To do this, use either Azure AD PowerShell or the MSOL service.
- Use Azure AD PowerShell
  
  Run the following PowerShell cmdlets:
```
Connect-AzureAD
Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
```
- Use the MSOL service
  
  Run the following PowerShell cmdlets:
```
Connect-MsolService
Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
```
Make sure that the ImmutableId value of the on-premises user object is null. Check the ImmutableId value for the on-premises user object by running the following command in the Exchange Management Shell (EMS):
```
Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
Use one of the following methods, depending on the ImmutableId value.
- ImmutableId value is null
  
  If the ImmutableId value is null, toggle its value:
  1. Set the ImmutableId of the remote mailbox object to the UPN of the cloud user by running the following PowerShell cmdlet in the EMS:
```
Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
```
    For example: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.
  2. Sync the change to the cloud by running the following PowerShell cmdlets in the EMS:
```
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
```
    To verify that the ImmutableId value has been updated, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
  3. Revert the ImmutableId of the remote mailbox object to null by running the following PowerShell cmdlet in the EMS:
```
Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
```
  4. Sync the change to the cloud by running the following PowerShell cmdlet in the EMS:
```
Start-ADSyncSyncCycle -PolicyType Delta
```
    To verify that the ImmutableId value has been updated, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
- ImmutableId value isn't null
  
  If the ImmutableId value isn't null, run the following command in the EMS to set the ImmutableId value to null:
```
Set-RemoteMailbox -Identity <user> -ImmutableId $null
```
  You can verify that the ImmutableId value has been updated by running the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```

The password has to be changed or the password for the account has expired

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find one of the following error messages.

Error message 1

The password for the account has expired

Error message 2

The password has to be changed

You see the same error message when you run the following cmdlet to check whether the cloud user can retrieve a delegation token for the on-premises user mailbox:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

This error might occur if an inconsistency exists in the Azure credentials for specific cloud users.

Resolution

Select the resolution that matches the error message.

Resolution for error message 1

To fix the issue, use either Azure AD PowerShell or the MSOL service.

Use Azure AD PowerShell

Run the following PowerShell cmdlets:

Connect-AzureAD
Set-AzureADUser -ObjectId <account UPN> -PasswordPolicies DisablePasswordExpiration

Use MSOL service

Run the following PowerShell cmdlets:

Connect-MsolService
Set-MsolUser -UserPrincipalName <account UPN> -PasswordNeverExpires $true

Resolution for error message 2

To fix the issue, run the following PowerShell cmdlets:

Connect-MsolService
Set-MsolUserPassword -UserPrincipalName <UPN> -ForceChangePassword $false

For more information, see Can't see free/busy information after migrated from Exchange on-premises.

Provision is needed before federated account can be logged in

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Provision is needed before federated account can be logged in. ErrorWin32InteropError

You also get the same error message when you run the following cmdlet to check whether the cloud user can retrieve a delegation token for the on-premises user mailbox:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

This error can occur if there's an inconsistency in the configuration of federated users in Microsoft Entra ID.

Resolution

Note

If the issue affects most or all cloud users in your organization, contact Microsoft Support.

To fix the issue, update the user principal name (UPN) of the cloud user to use the onmicrosoft.com domain then switch it back to its former value (federated domain). For example, if the UPN of the cloud user is user@contoso.com, switch it to the temporary UPN user@contoso.mail.onmicrosoft.com and then back to user@contoso.com. To do this, use either of the following approaches (Azure AD PowerShell or MSOL service):

Use Azure AD PowerShell

Run the following PowerShell cmdlets:

Connect-AzureAD
Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>

Use the MSOL service

Run the following PowerShell cmdlets:

Connect-MsolService
Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>

The request timed out

LID: 43404

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

The request timed out
Request could not be processed in time. Timeout occurred during 'Waiting-For-Request-Completion'.
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: Request could not be processed in time. Timeout occurred during 'Waiting-For-Request-Completion'.
Name of the server where exception originated: <server name>.

You also get the same error message if you run the following cmdlet to check whether the cloud user can retrieve a delegation token for the on-premises user mailbox:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

This error can occur if there are network or transient issues. The error message is generic.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

To rule out transient issues, verify that the cloud user consistently gets the same error message during repeated attempts to get the free/busy information of the on-premises user.

Check whether you can retrieve a delegation token when you run each of the following cmdlets:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose
Test-FederationTrust -UserIdentity <on-premises mailbox ID> -Verbose
Test-FederationTrustCertificate

Note: Run the Test-FederationTrust cmdlet on all on-premises Exchange servers.

Verify that Exchange Server has outbound internet access to both of the following resources:
- The Microsoft Federation Gateway (or an authorization server, if you use OAuth)
- The availability URL for Microsoft 365: https://outlook.office365.com/ews/exchange.asmx
For more information, see Microsoft 365 URLs and IP address ranges and Firewall Considerations for Federated Delegation.
Make sure that the system account in Exchange Server has internet access to the following URLs. Follow these steps on each Exchange server:
1. Run the following PsExec command to start a PowerShell session that starts a web browser from the system account:
```
PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
```
2. Test browser access (no OAuth) from the system account to the following Microsoft Federation Gateway URLs:
  - https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml
    
    The browser should display an xml page.
  - https://login.microsoftonline.com/extSTS.srf
    
    The browser should prompt you to download the file.
  - https://domains.live.com/service/managedelegation2.asmx
    
    The browser should display a list of operations that are supported by ManageDelegation2.
3. Test browser access (OAuth) from the system account to the following Microsoft authorization server URLs:
  - https://outlook.office365.com/ews/exchange.asmx
    
    The browser should display a sign-in prompt.
  - https://login.windows.net/common/oauth2/authorize
    
    The browser should display the sign-in error, "Sorry, but we're having trouble signing you in."
  - https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2
    
    The browser should display the HTTP status code 400 Bad Request, or the sign-in error message, "Sorry, but we're having trouble signing you in."
Get the details of a free/busy request by checking the Exchange Web Services (EWS) logs:
1. Make a free/busy request from Exchange Online.
2. Find the entry in the EWS logs, and check the value in the time-taken column. The EWS logs are located in the %ExchangeInstallPath%\Logging\Ews folder.
3. Check the IIS logs in the W3SVC1 folder of the default website to verify that the free/busy request is logged. The W3SVC1 folder path is %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

The specified member name is either invalid or empty

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Authentication Failure</S:Text></S:Reason><S:Detail><psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048821</psf:value><psf:internalerror><psf:code>0x80041034</psf:code><psf:text>The specified member name is either invalid or empty. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received. at Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) at Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

The error might occur for either of the following reasons:

An inconsistency in the Microsoft Entra ID for users that request a delegation token
An inconsistency in the configuration of federated users in Active Directory Federation Services (AD FS)

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Update the user principal name (UPN) of the cloud user to use the onmicrosoft.com domain, and then revert the UPN to its former value. For example, if the UPN of the cloud user is user@contoso.com, change it to the temporary UPN, user@contoso.mail.onmicrosoft.com; and then revert the UPN to user@contoso.com. To do this, use either of the following methods (Azure AD PowerShell or MSOL service):
- Use Azure AD PowerShell
  
  Run the following PowerShell cmdlets:
```
Connect-AzureAD
Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
```
- Use the MSOL service
  
  Run the following PowerShell cmdlets:
```
Connect-MsolService
Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
```
Check the AD FS rules, endpoints, and logs.
Search for an error that's related to the ImmutableID of the cloud user in the command output of the following PowerShell cmdlet:
```
Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud user ID> -Verbose
```
For example, the command output might contain the following error message:

"The email address "XGuNpVunD0afQeVNfyoUIQ==" isn't correct. Please use this format: user name, the @ sign, followed by the domain name. For example, tonysmith@contoso.com or tony.smith@contoso.com.
+ CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

If you receive a similar error message, use one of the following methods to make sure that the ImmutableId value is null (empty value):
- If the cloud user isn't synced from on-premises, check the ImmutableId value by running the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL ImmutableId
```
  If the ImmutableId value isn't null, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Set-Mailbox -Identity <cloud mailbox> -ImmutableId $null
```
- If the cloud user is synced from on-premises, check the ImmutableId value for the on-premises user object by running the following command in the Exchange Management Shell (EMS):
```
Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
  Use either of the following methods, depending on the ImmutableId value:
  - ImmutableId value is null
    
    If the ImmutableId value is null, toggle its value:
    1. Set the ImmutableId of the remote mailbox object to the UPN of the cloud user by running the following PowerShell cmdlet in the EMS:
```
Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
```
      For example: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.
    2. Sync the change to the cloud by running the following PowerShell cmdlets in the EMS:
```
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
```
      To verify that the ImmutableId value was updated, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
    3. Revert the ImmutableId of the remote mailbox object to null by running the following PowerShell cmdlet in the EMS:
```
Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
```
    4. Sync the change to the cloud by running the following PowerShell cmdlet in the EMS:
```
Start-ADSyncSyncCycle -PolicyType Delta
```
      Verify that the ImmutableId value was updated. To do this, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
  - ImmutableId value isn't null
    
    If the ImmutableId value isn't null, run the following command in the EMS to set the ImmutableId value to null:
```
Set-RemoteMailbox -Identity <user> -ImmutableId $null
```
    To verify that the ImmutableId value was updated, run the following PowerShell cmdlet in Exchange Online PowerShell:
```
Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
```
Check the organization relationship settings. For more information, see Demystifying Hybrid Free/Busy.
If the error message is generated for a cloud user who can't view the free/busy information for an on-premises user, follow these steps:
1. Run the following PowerShell cmdlet:
```
Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
```
2. Re-create the federation trust. For more information, see Remove a federation trust and Configure a federation trust.

The result set contains too many calendar entries

LID: 54796

Issue

You have a cloud user who can't view the free/busy information for another cloud user. When you diagnose the issue, you find the following error message:

Exception: The result set contains too many calendar entries. The allowed size = 1000; the actual size = 5009.

This error occurs if the number of calendar entries in a single timeslot exceeds 1,000 items. A single free/busy request can't retrieve more than 1,000 items.

Resolution

Remove some of the calendar items from the timeslot so as not to exceed the limit of 1,000 items that can be retrieved in a single free/busy request.

For more information, see You can't view free/busy information on another user's Calendar in Exchange Online.

Work hours start time must be less than or equal to end time

Issue

You have a cloud user who can't view the free/busy information for a room list. When you diagnose the issue, you find the following error message:

Exception: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: Work hours start time must be less than or equal to end time.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

This error might occur if one or more of the following calendar settings for a room mailbox in a room list are invalid:

WorkingHoursStartTime
WorkingHoursEndTime
WorkingHoursTimeZone

The work hours start time must be less than or equal to the work hours end time, and the work hours' time zone must be set.

Resolution

To fix the issue, follow these steps:

Run the following PowerShell cmdlet to check the calendar settings of each mailbox in the room list to identify the room mailbox that has invalid settings:
```
Get-DistributionGroupMember -Identity <room list name> | Get-MailboxCalendarConfiguration | FL Identity,WorkingHours* 
```

Run the following PowerShell cmdlet to set the required parameter values for a room mailbox:

Set-MailboxCalendarConfiguration -Identity <room ID> -WorkingHoursStartTime <start time> -WorkingHoursEndTime <end time> -WorkingHoursTimeZone <time zone>

For more information, see Set-MailboxCalendarConfiguration.

The request failed with HTTP status 401: Unauthorized (token has an invalid signature)

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

When you run the following PowerShell cmdlet to test OAuth authentication:

Test-OAuthConnectivity -Service EWS -TargetUri <external EWS URL> -Mailbox <cloud mailbox ID> -Verbose | FL

You receive the following command output:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. Boolean reloadConfig, diagnostics: 2000000; reason="The token has an invalid signature.";error_category="invalid_signature".

Note: The TargetUri parameter value in the Test-OAuthConnectivity command is an external Exchange Web Services (EWS) URL, such as https://mail.contoso.com/ews/exchange.asmx.

This error might occur if the Microsoft authorization server settings are invalid.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Refresh the authorization metadata on the specified Microsoft authorization server that's trusted by Exchange. Run the following PowerShell cmdlet in the EMS (on-premises):
```
Set-AuthServer <name of the authorization server> -RefreshAuthMetadata 
```
Wait about 15 minutes for the command to fully take effect, or restart IIS by running the iisreset /noforce command in a PowerShell or Command Prompt window on each Exchange Server.

Check the Microsoft authorization server settings in your Exchange organization by running the following PowerShell cmdlet in the EMS:

Get-AuthServer | FL Name, IssuerIdentifier, TokenIssuingEndpoint, AuthMetadataUrl, Enabled

The following command output is an example of valid settings:

Name : WindowsAzureACS
IssuerIdentifier : 00000001-0000-0000-c000-000000000000
TokenIssuingEndpoint : https://accounts.accesscontrol.windows.net/XXXXXXXX-5045-4d00-a59a-c7896ef052a1/tokens/OAuth/2
AuthMetadataUrl : https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1
Enabled : True

If the Microsoft authorization server settings aren't valid, try rerunning the Hybrid Configuration Wizard to reset the Microsoft authorization server settings to valid values.

The request failed with HTTP status 401: Unauthorized (key was not found)

Issue

You have an on-premises user who can't view the free/busy information for a cloud user. When you diagnose the issue, you find the following error message:

System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

When you run the following PowerShell cmdlet in the EMS to test OAuth authentication:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <on-premises mailbox ID> -Verbose | FL

You receive the following command output:

System.Net.WebException: The remote server returned an error: (401) Unauthorized.
Error: Unable to get token from Auth Server. Error code: 'invalid_client'. Description: 'AADSTS70002:
Error validating credentials. AADSTS50012: Client assertion contains an invalid signature. [Reason - The key was not found., Thumbprint of key used by client: '<thumbprint>'.

This error can occur if the OAuth certificate in Exchange Server doesn't exist in Exchange Online.

Resolution

To fix the issue, use the following steps:

Determine whether your on-premises Exchange Server OAuth certificate exists in your Exchange Online organization:
1. Run the following PowerShell cmdlet in the Exchange Management Shell (EMS) to get the OAuth certificate in Exchange Server:
```
Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
```
  The command output contains the Thumbprint value.
2. Run the following PowerShell cmdlets to get the Exchange Online OAuth certificate by using the MSOL service:
```
Connect-MsolService
Get-MsolServicePrincipalCredential -ServicePrincipalName "00000002-0000-0ff1-ce00-000000000000" -ReturnKeyValues $true
```
  If the Value parameter value in the command output is empty, an OAuth certificate doesn't exist in Exchange Online. In that case, go to step 3 to upload the on-premises certificate to Exchange Online.
  
  If the Value parameter value isn't empty, save the value to a file that has a ".cer" extension. Open the file in Microsoft Certificate Manager tool to view the Exchange Online OAuth certificate. Compare the Thumbprint value in the Exchange Online certificate to the thumbprint of the on-premises certificate that you obtained in step 1a. If the thumbprint values match, go to step 4. If the thumbprint values don't match, choose one of the following options:
  - Go to step 2 to replace the existing on-premises certificate with the Exchange Online certificate.
  - Go to step 3 to replace the existing Exchange Online certificate with the on-premises certificate.
Replace the existing on-premises certificate with the Exchange Online certificate:
1. Run the following PowerShell cmdlet to update the on-premises certificate thumbprint:
```
Set-AuthConfig -NewCertificateThumbprint <thumbprint of Exchange Online certificate> -NewCertificateEffectiveDate (Get-Date) 
```
  If you're notified that the certificate effective date is less than 48 hours from now, accept the prompt to continue.
2. Run the following PowerShell cmdlet to publish the on-premises certificate:
```
Set-AuthConfig -PublishCertificate  
```
3. Run the following PowerShell cmdlet to remove any references to the previous certificate:
```
Set-AuthConfig -ClearPreviousCertificate 
```
4. Go to step 4.
Export the on-premises authorization certificate, and then upload the certificate to your Exchange Online organization.
Run the following PowerShell cmdlet to check whether the SPN in the on-premises authentication configuration is 00000002-0000-0ff1-ce00-000000000000:
```
Get-AuthConfig | FL ServiceName
```
If the SPN value is different, update the SPN by running the following PowerShell cmdlet:
```
Set-AuthConfig -ServiceName "00000002-0000-0ff1-ce00-000000000000"
```

Proxy web request failed: Response is not well-formed XML

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Proxy web request failed., inner exception: Response is not well-formed XML

If you run the Synchronization, Notification, Availability, and Automatic Replies test for the on-premises user, you receive the following error message:

The response received from the service didn't contain valid XML

These errors can occur for any of the following reasons:

External Exchange Web Services (EWS) issue
Misconfiguration of network devices, such as a reverse proxy or firewall

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Check whether a free/busy request from Exchange Online can reach IIS on an Exchange server. Perform a free/busy query and then search the IIS logs for entries that have HTTP status code 200 OK or 401 Unauthorized at the time of the query. Those entries indicate that the free/busy request reached IIS. Note: Timestamps in IIS logs use UTC time.

If you don't find those entries, check the reverse proxy and firewall logs to determine where the free/busy request got stuck.
Perform a free/busy query, and then search the Exchange Server application log in the Windows Event Viewer for entries that were made at the time of the query to help narrow down the cause of the issue.

Unable to connect to the remote server

Issue

You have an on-premises user who can't view the free/busy information for a cloud user. When you diagnose the issue, you find the following error message:

Failed to communicate with https://login.microsoftonline.com/extSTS.srf., inner exception: Unable to connect to the remote server.

This error might occur if one or more Exchange servers can't connect to a Microsoft Federation Gateway URL.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Run the following PowerShell cmdlets in the Exchange Management Shell (EMS) to check whether you can retrieve a delegation token:

Test-OrganizationRelationship -Identity "On-premises to O365*" -UserIdentity <on-premises user ID> -Verbose
Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
Test-FederationTrustCertificate

Verify that your on-premises Exchange servers have outbound internet access to both of the following resources:
- The Microsoft Federation Gateway, or the Microsoft authorization server if you use OAuth authentication.
- The availability URL for Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.
For more information, see Microsoft 365 URLs and IP address ranges and Firewall considerations for federated delegation.
Verify that the System account in Exchange Server has internet access to the following URLs. Follow these steps on all Exchange Servers in your organization:
1. Run the following PsExec command to start a PowerShell session that launches a web browser from the System account:
```
PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
```
2. Test browser access (no OAuth authentication) from the System account to the following Microsoft Federation Gateway URLs:
  - https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml
    
    The browser should display an xml page.
  - https://login.microsoftonline.com/extSTS.srf
    
    The browser should prompt you to download the file.
  - https://domains.live.com/service/managedelegation2.asmx
    
    The browser should display a list of operations that are supported by ManageDelegation2.
3. Test browser access (OAuth authentication) from the System account to the following Microsoft authorization server URLs:
  - https://outlook.office365.com/ews/exchange.asmx
    
    The browser should display a sign-in prompt.
  - https://login.windows.net/common/oauth2/authorize
    
    The browser should display the sign-in error message, "Sorry, but we're having trouble signing you in."
  - https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2
    
    The browser should display the HTTP status code 400 Bad Request or the sign-in error message, "Sorry, but we're having trouble signing you in."

Autodiscover failed for email address: The remote name could not be resolved

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Autodiscover failed for E-Mail Address <user email address> with error System.Net.WebException: The remote name could not be resolved: '<on-premises host name>'.

This error might occur if the on-premises Autodiscover endpoint URL or the public DNS settings are incorrect.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Run the following PowerShell cmdlets in Exchange Online PowerShell to get the value of the TargetAutodiscoverEpr parameter:
```
Get-IntraOrganizationConnector | FL TargetAutodiscoverEpr
Get-OrganizationRelationship | FL TargetAutodiscoverEpr
```
For example, if the on-premises hostname value in the error message is mail.contoso.com, the Autodiscover endpoint URL is likely to be https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

If the TargetAutodiscoverEpr parameter value is correct, go to step 3. Otherwise, go to step 2.
Update the Autodiscover endpoint URL by using one of the following methods:
- Run the Hybrid Configuration Wizard (HCW) to restore the default Autodiscover endpoint.
- Manually update either the DiscoveryEndpoint parameter or the TargetAutodiscoverEpr parameter by running either of the following PowerShell cmdlets:
  - Set-IntraOrganizationConnector -Identity <cloud connector ID> -DiscoveryEndpoint <Autodiscover endpoint URL>
  - Set-OrganizationRelationship <O365 to On-premises*> -TargetAutodiscoverEpr <Autodiscover endpoint URL>
Make sure that the on-premises host name in the error message (for example: mail.contoso.com) is resolvable in public DNS. The DNS entry for the host name should point to the on-premises Autodiscover service at the Autodiscover endpoint URL.

Note: If you can't fix the issue and you want a temporary workaround, run either of the following PowerShell cmdlets to manually update the TargetSharingEpr parameter value to the external Exchange Web Services (EWS) URL. The external EWS URL should resemble https://<EWS hostname>/ews/exchange.asmx and be resolvable in DNS.
- Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>
- Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>
Note

If you set the TargetSharingEpr parameter value, the cloud mailbox bypasses Autodiscover and connects directly to the EWS endpoint.

Failed to get ASURL. Error 8004010F

Issue

You have an on-premises user who can't view the free/busy information for a cloud user. When you diagnose the issue, you find the following error message:

Failed to get ASURL. Error 8004010F.

This is a general error that's related to the Autodiscover service.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Make sure that Autodiscover for the affected user returns the Exchange Web Services (EWS) URL for the user.
Run the email autoconfiguration test in the affected user's Outlook client to make sure that Autodiscover returns the EWS URL for the user.
Make sure that free/busy works between on-premises users who are hosted on different Exchange servers.
If you have load balancers, check whether the load balancers caused the issue. To do this, modify the Windows Hosts file (on the computer that has the user's Outlook client installed) to bypass the load balancers and point to a specific Client Access server.
If free/busy works between on-premises users, check whether all on-premises Exchange servers have outbound access to Microsoft 365 URLs and IP address ranges.
Check whether each Exchange server can retrieve a delegation token. To do this, run the following PowerShell cmdlet in the EMS on all on-premises Exchange servers:
```
Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
```
If the command fails to retrieve a delegation token, check whether the server can connect to Office 365 at the proxy or firewall level.

Proxy web request failed: Object moved

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Proxy web request failed. , inner exception: System.Net.WebException: The request failed with the error message: Object moved.

This error might occur if the TargetSharingEpr parameter value in the organization settings is set to an incorrect Exchange Web Services (EWS) endpoint URL.

You can run the following PowerShell cmdlets to get the TargetSharingEpr parameter value from the organization settings (intra-organization connector or organization relationship):

Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr

Verify that the TargetSharingEpr parameter value doesn't resolve in public DNS.

Note: The Hybrid Configuration Wizard (HCW) doesn't set a value for the TargetSharingEpr parameter unless you select Use Exchange Modern Hybrid Technology to install a Hybrid Agent. In that scenario, the HCW sets the TargetSharingEpr parameter to an external EWS URL endpoint value that resembles https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. You can also set the TargetSharingEpr parameter value manually. If the TargetSharingEpr value is set to an endpoint, Outlook bypasses Autodiscover and connects directly to that endpoint.

Resolution

To fix the issue, run either of the following commands to manually update the TargetSharingEpr parameter value to an external EWS URL that resolves in DNS:

Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>
Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

The request was aborted: Could not create SSL/TLS secure channel

Issue

You have a cloud user who can't view the free/busy information for an on-premises user, or vice versa. When you diagnose the issue, you find the following error message:

The request was aborted: Could not create SSL/TLS secure channel.

Cause 1: Cloud user can't view the free/busy information for an on-premises user

The issue might occur if TLS 1.2 is misconfigured or disabled in an on-premises endpoint that Microsoft 365 connects to, such as Exchange Server or a firewall.

Cause 2: On-premises user can't view the free/busy information for a cloud user

The issue might also occur for any of the following reasons:

The Microsoft 365 certificate (outlook.office365.com) is missing from the trusted root Certification Authorities (CA) store.
A Cypher suite mismatch exists.
Other SSL/TLS issues.

Troubleshooting steps

Use the following tools to diagnose on-premises TLS 1.2 issues:

Run the SSL server test in the Microsoft Remote Connectivity Analyzer.
Run the HealthChecker script in the Exchange Management Shell (EMS) on each Exchange server.

For information about TLS configuration, see Exchange Server TLS configuration best practices and Preparing for TLS 1.2.

For information about how to check for certificates in the trusted root CA store, see View certificates with the MMC snap-in.

For information about supported TLS cipher suites, see TLS cipher suites supported by Microsoft 365.

The user specified by the user-context in the token does not exist

Issue

You have an on-premises user who can't view the free/busy information for a cloud user. When you diagnose the issue, you find the following error message:

The user specified by the user-context in the token does not exist. error_category="invalid_user". 401: Unauthorized.

You get the same error message if you run the Test-OAuthConnectivity PowerShell cmdlet.

The error might occur if the on-premises user mailbox and the corresponding mail-user object in Microsoft Entra ID aren't synced. Until they're synced, the mail-user object in Microsoft Entra ID might be unprovisioned.

Resolution

To fix the issue, use Microsoft Entra Connect to sync the on-premises user and the corresponding mail-user object in Microsoft Entra ID.

The hostname component of the audience claim value is invalid

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

The hostname component of the audience claim value 'https://<hybrid.domain.com>' is invalid; error_category="invalid_resource"

The error can occur for either of the following reasons.

Cause 1

SSL offloading and OAuth authentication are both enabled. SSL offloading doesn't work if OAuth authentication is enabled.

Cause 2

A network device in front of Exchange Server is blocking free/busy requests.

Solution

Workaround for Cause 1

Select either of the following workarounds:

Disable SSL offloading for both Exchange Web Services (EWS) and Autodiscover in the on-premises environment. For more information, see Configuring SSL offloading for the Autodiscover and Configuring SSL offloading for EWS, and default SSL settings.
Run the following PowerShell cmdlet to disable OAuth authentication by disabling the cloud intra-organization connector:
```
Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
```
When the intra-organization connector is disabled, DAuth authentication is enabled through the organization relationship. To check the organization relationship, run the following PowerShell cmdlet:
```
Get-OrganizationRelationship
```
For more information about the organization relationship settings, see Demystifying Hybrid Free/Busy.

Resolution for Cause 2

Configure the network device in front of Exchange not to block free/busy requests.

Proxy web request failed with HTTP status 503: Service unavailable

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Proxy web request failed, inner exception: System.Net.WebException: The request failed with HTTP status 503: Service Unavailable...

This error might occur if there's a stopped Microsoft Windows service, server component, IIS application pool, or a misconfigured endpoint.

Troubleshooting steps

After you complete each step, check whether the free/busy issue is fixed.

Make sure that the Windows services that Exchange Server requires are running. To check the status of services, run the following PowerShell cmdlet on each Exchange server in your organization:
```
Test-ServiceHealth
```
Use the Services console to start any stopped services that are required by Exchange Server.
Check that the required Exchange Server components are active. To check the status of components, run the following PowerShell cmdlet on each Exchange server in your organization:
```
Get-ServerComponentState <server name>
```
To activate an inactive component, use the Set-ServerComponentState PowerShell cmdlet.
Make sure that the following IIS application pools for Exchange Web Services (EWS) and Autodiscover are started:
- MSExchangeServicesAppPool
- MSExchangeSyncAppPool
- MSExchangeAutodiscoverAppPool
Test whether the Autodiscover endpoint is valid. Follow these steps:
1. Run the following PowerShell cmdlets to get the Autodiscover endpoint URL from the DiscoveryEndpoint or TargetAutodiscoverEpr parameter values:
```
Get-IntraOrganizationConnector | FL DiscoveryEndpoint
Get-OrganizationRelationship | FL TargetAutodiscoverEpr
```
2. Navigate to the Autodiscover endpoint URL in a web browser, or run the Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell cmdlet, to make sure that the URL valid. Preferably, check the URL from an external network.
Test whether the EWS URL is valid by following these steps:
1. Run the following PowerShell cmdlets to get the EWS URL from the TargetSharingEpr parameter value in the organization settings:
```
Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr
```
b. Navigate to the EWS URL in a web browser, or run the Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell cmdlet to make sure that the URL is valid. Preferably, check the URL from an external network.
Check the IIS logs for free/busy requests that return HTTP status code 503 Service Unavailable:
1. Make a free/busy request from Exchange Online.
2. Check for HTTP status code 503 Service Unavailable entries in the IIS logs in the W3SVC1 folder for the default website on each Exchange server. The W3SVC1 folder path is %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Those entries can help identify the server that has the issue.
3. If the free/busy request isn't logged in the W3SVC1 folder, check whether the request is logged in the error logs in the HTTPERR folder on each Exchange server. The HTTPERR folder path is %SystemRoot%\System32\LogFiles\HTTPERR. If the free/busy request is logged in the HTTPERR logs, check for misconfigured IIS settings.
Check the header of the server response that you receive when you connect to the on-premises EWS URL to verify that IIS (not a different web server) sent the response. To do this, run the following commands in a PowerShell session that isn't connected to on-premises EWS (don't run the commands in the Exchange Management Shell):
```
$req = [System.Net.HttpWebRequest]::Create("<EWS URL>") 
$req.UseDefaultCredentials = $false $req.GetResponse()
$ex = $error[0].Exception
$ex.InnerException.Response $resp.Headers["Server"]
```
For example, if you see "Microsoft-HTTPAPI/2.0" in the command output instead of "Microsoft -IIS/10.0", it's likely that a Web Application Proxy (WAP) service (not IIS) responded to the request. Check whether the WAP service is down.

Proxy web request failed with HTTP status 504: Gateway timeout

LID: 43532

Issue

You have a cloud user who can't view the free/busy information for an on-premises user. When you diagnose the issue, you find the following error message:

Proxy web request failed, inner exception: The request failed with HTTP status 504: Gateway Timeout...

This error might occur if a Hybrid Agent in your organization is configured incorrectly.

Resolution

To fix the issue, use the following steps. After you complete each step, check whether the free/busy issue is fixed.

Check the TargetSharingEpr parameter value in the organization settings. The value should resemble https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. To determine the value of the TargetSharingEpr parameter, run the following PowerShell cmdlets:
```
Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr
```
If the TargetSharingEpr parameter value is incorrect:
1. Run the Hybrid Configuration Wizard (HCW), and select Use Exchange Classic Hybrid Topology.
2. Rerun the HCW, and select Use Exchange Modern Hybrid Topology. This procedure forces the HCW to reset the TargetSharingEpr parameter value.
Check the status of the Microsoft Hybrid Service on the server where the Hybrid Agent is installed. If the service is stopped, start it.
Check the status of the Hybrid Agent. If the status is Inactive:
1. Run the Hybrid Configuration Wizard (HCW), and select Use Exchange Classic Hybrid Topology.
2. Rerun the HCW, and select Use Exchange Modern Hybrid Topology. This procedure forces the HCW to reinstall the Hybrid Agent.
3. Install the Hybrid Agent PowerShell module, and then run the Get-HybridApplication PowerShell cmdlet to find the internal URL that the Hybrid Agent points to.
Browse to the internal URL that you found in step 3. Resolve any errors that you find, such as certificate errors.
Configure the Hybrid Agent to direct requests to a load balancer instead of a server that's running Microsoft Exchange Server to rule out issues that might exist on that server.
Verify that the Hybrid Agent supports free/busy requests and mailbox migration.

Share via

Resolve free/busy errors

An error occurred when verifying security for the message

Issue

Troubleshooting steps

Proxy web request failed: Unable to connect to the remote server

Issue

Troubleshooting steps

Autodiscover failed for email address: HTTP status 404

Issue

Troubleshooting steps

Exception proxy web request failed

Issue

Resolution

An existing connection was forcibly closed by the remote host

Issue

Troubleshooting steps

Configuration information for forest/domain could not be found in Active Directory

Issue

Troubleshooting steps

Proxy web request failed: HTTP status 401

Issue

Troubleshooting steps

Autodiscover failed for email address: InvalidUser

Issue

Troubleshooting steps

The caller does not have access to free/busy data

Issue

Troubleshooting steps

An error occurred when processing the security tokens in the message

Issue

Troubleshooting steps

The cross-organization request is not allowed because the requester is from a different organization

Issue

Workaround

More information

The request failed with HTTP status 401: Unauthorized (missing signing certificate)

Issue

Resolution

The application is missing a linked account for RBAC roles, or the linked account has no RBAC role assignments, or the calling users account is logon disabled

Issue

Troubleshooting steps

The entered and stored passwords do not match

Issue

Cause

Resolution

The password has to be changed or the password for the account has expired

Issue

Resolution

Provision is needed before federated account can be logged in

Issue

Resolution

The request timed out

Issue

Troubleshooting steps

The specified member name is either invalid or empty

Issue

Troubleshooting steps

The result set contains too many calendar entries

Issue

Resolution

Work hours start time must be less than or equal to end time

Issue

Resolution

The request failed with HTTP status 401: Unauthorized (token has an invalid signature)

Issue

Troubleshooting steps

The request failed with HTTP status 401: Unauthorized (key was not found)

Issue

Resolution

Proxy web request failed: Response is not well-formed XML

Issue

Troubleshooting steps

Unable to connect to the remote server

Issue

Troubleshooting steps

Autodiscover failed for email address: The remote name could not be resolved

Issue

Troubleshooting steps

Failed to get ASURL. Error 8004010F