Calendar synchronization lost between New Teams and classic Outlook

Hi @Damien

Is there any update from you?

If yes, please feel free to let me know.

Hi Michelle, thank you for your feedback.

I haven't been able to clear the New Teams application cache, as there were no Teams folder in Roaming\Microsoft nor in Local\Microsoft.

We are in a RDS environment, and I was not able to access the Windows Credential Manager.

I disabled / enabled the Teams Meeting add-in, with no effect.

I created a new Outlook profile, with no effect.

On Exchange 2019, the UPN matches the primary SMTP address. EWS is explicitly enabled for this mailbox. And the EWS URL is accessible.

What are the steps to take to Audit the OAuth token status and Hybrid Modern Authentication (HMA) configurations for this account?

Regards,

Damien

Hi @Damien

Thank you for the update.

Because the Teams calendar is populated by the Teams cloud service through Exchange Web Services, it is not synchronized through the Outlook client or the Teams Meeting Add-in. Therefore, reinstalling the add-in or recreating the Outlook profile will generally not resolve this particular issue. The add-in is used to create Teams meeting details in Outlook, while Teams retrieves the calendar separately through Exchange integration.

For an on-premises mailbox, Teams requires a supported Exchange hybrid configuration, OAuth connectivity, external Autodiscover/EWS availability, and a correctly synchronized Microsoft Entra ID user. Microsoft also notes that full Teams calendar integration requires Classic Full Hybrid. Modern Hybrid is limited and does not provide Teams-to-on-premises calendar integration. [learn.microsoft.com], [learn.microsoft.com]

Since other users work correctly, I recommend comparing the affected user with a working user rather than changing the organization-wide OAuth configuration immediately.

1. Confirm the type of hybrid deployment

First, verify that the Exchange organization was configured by using the latest Hybrid Configuration Wizard and that it is a Classic Full Hybrid deployment.

The Hybrid Configuration Wizard normally configures OAuth between Exchange Server 2019 and Exchange Online. Avoid manually recreating the OAuth configuration before checking the existing configuration and HCW status.

From the on-premises Exchange Management Shell, collect:

Get-HybridConfiguration | Format-List *
Get-AuthConfig | Format-List CurrentCertificateThumbprint,PreviousCertificateThumbprint,NextCertificateThumbprint,ServiceName,Realm
Get-AuthServer | Format-List Name,Enabled,IssuerIdentifier,AuthorizationEndpoint,TokenIssuingEndpoint
Get-PartnerApplication | Format-List Name,Enabled,ApplicationIdentifier,Realm,UseAuthServer
Get-IntraOrganizationConnector | Format-List Name,Enabled,DiscoveryEndpoint,TargetAddressDomains

Check that:

• Get-AuthServer returns the Microsoft Entra or Azure Access Control authorization server.
• The relevant auth server is enabled.
• Get-AuthConfig has a current certificate thumbprint.
• The certificate exists and is not expired.
• The intra-organization connector is enabled.

You can validate the OAuth certificate with:

$thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
Get-ExchangeCertificate -Thumbprint $thumbprint 
 Format-List Subject,Thumbprint,NotBefore,NotAfter,Status,Services

If Get-AuthServer returns no result, the OAuth relationship may not have been created correctly. In that case, rerunning the latest Hybrid Configuration Wizard is safer than manually creating authentication objects.

2. Test OAuth for the affected mailbox

Run the following from the Exchange Management Shell, replacing the URL and mailbox:

Test-OAuthConnectivity `
 -Service EWS `
 -TargetUri "https://mail.contoso.com/ews/exchange.asmx" `
 -Mailbox "******@contoso.com" `
 -Verbose |
 Format-List

Then run the same test against a working user:

Test-OAuthConnectivity `
    -Service EWS `
    -TargetUri "https://mail.contoso.com/ews/exchange.asmx" `
    -Mailbox "working******@contoso.com" `
    -Verbose |
    Format-List

Test-OAuthConnectivity is specifically intended to test OAuth access to a service such as EWS in the context of a selected mailbox.

If the working user succeeds but the affected user fails, concentrate on the affected user’s on-premises and cloud identity attributes. If both tests fail, investigate the organization-wide OAuth or hybrid configuration.

Hi @Damien

Is there any update from you?

If yes, please feel free to let me know.

Hi Michelle,

The various commands checking the hybrid deployment configuration seems to be OK.

I have run the Test-OAuthConnectivity command on both a user account where the synchronization works and on the user account where it does not work, and in both cases I obtain the following error :

Journal Oauth sortant Exchange : ID de la demande client : xxx Exception : System.Net.WebException: Impossible de se connecter au serveur distant ---> System.Net.Sockets.SocketException: Une tentative de connexion a échoué car le parti connecté n’a pas répondu convenablement au-delà d’une certaine durée ou une connexion établie a échoué car l’hôte de connexion n’a pas répondu xxx à System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) à System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception) --- Fin de la trace de la pile d'exception interne --- à System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) à System.Net.HttpWebRequest.GetRequestStream() à Microsoft.Exchange.Monitoring.TestOAuthConnectivityHelper.SendExchangeOAuthRequest(ADUser user, String orgDomain, Uri targetUri, String& diagnosticMessage, Boolean appOnly, Boolean useCachedToken, Boolean reloadConfig) ResultType : Error Identity : Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid : True

Does this help troubleshooting further?