Hybrid Configuration Wizard bugs

Daniel Brase 196 Reputation points
2020-10-26T09:56:27.557+00:00

Hi,

We have a hybrid configuration in place: Exchange 2016 CU18, no other Exchange Server versions present.

I created this post because I cannot access the migrated one (http 404): migrated-from-msdn-exchange-devoutlook-mobile-auto.html (Thanks to @KyleXu-MSFT for pointing me to the right forum and migrating my post, anyway).

After running the HCW in version 17.0.5494, we had issues with free/busy from on premise to Exchange Online. To narrow down the issue I removed the AuthServers (ACS, EvoSTS) from our configuration and created them manually as stated in the manual configuration of Hybrid Modern Authentication. Since this did the trick for free/busy I wanted to run the HCW to be supported again. Unfortunately, the HCW couldn't configure/create/edit the AuthServers I had created (well known HCW8064 error, in this case the EvoSTS couldn't be created because it already existed. Creating ACS was successful because ist was removed by the HCW prior to creation). Anyway, after removing the AuthServers and let them created by the HCW from scratch, the HCW finished without any errors. After that free/busy wasn't functional again and in addition we had issues with AutoDetect in Outlook mobile (automatic configuation based on email address). The AutoDetect issues went more and more worse until no configuration was possible at all, verified with Test-HMAEAS.ps1. It seems it takes some time until the configuration is recognized by the AutoDetect servers. Because of that issues we checked the AuthServer configuration. OAuth is working but there was no DefaultAuthorizationEndpoint configured by the HCW. We configured the EvoSTS AuthServer to be the default one. Even though it took some time until the Outlook App configuration worked again it's ok now. Now there was still the problem with the free/busy if the AuthServers are configured/created by the HCW. I digged in the HCW logs and found the new (undocumented as time of writing) parameter named DomainName. This parameter was used ith a value of our AutoDiscover domain and therefore the AuthServer wasn't responsible for our mail domains. After setting the AuthServer with -DomainName $null free/busy worked again (tested with test-oauthconnectivity).

The HCW in version 17.0.5494 has in my opinion two bugs:

  1. When no AuthServers are configured, then the HCW creates them but does not enable the EvoSTS one as Default Authorization Endpoint. -> Outlook Mobile AutoDetect will not work! (Test-HMAEAS.ps1 or Remote Connectitivity Analyzer)
  2. The ACS AuthServer is configured by the HCW with a parameter named -DomainName. This resulted in an issue where Free/Busy only worked for the domain set in the DomainName parameter. In our case that was only our Autodiscover domain for all our other email domains. Anyway, "Set-AuthServer -Identity <ACS server entry> -DomainName $null" did the trick. Maybe the parameter must contain all accepted domains configured in the HCW?

Maybe one of the HCW guys may have a look.

Thanks, Daniel.

Microsoft Exchange Hybrid Management
Microsoft Exchange Hybrid Management
Microsoft Exchange: Microsoft messaging and collaboration software.Hybrid Management: Organizing, handling, directing or controlling hybrid deployments.
1,896 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,562 questions
{count} vote

Accepted answer
  1. Daniel Brase 196 Reputation points
    2020-12-18T10:29:44.053+00:00

    It seems that with HCW Version 17.0.5785.0 and Exchange 2016 CU19 the DomainName Property is still configured with our autodiscover domain but after running HCW the Test-OAuthConnectivity is still successful. Free/Busy in Outlook and OWA are fine when accessing calendar information of an Exchange Online user with an on premise user.

    The issue with no DefaultAuthorizationEndpoint still exists but in our case it is not a big problem because there should be no need to delete the AuthServers again so they won't be created from scratch by the HCW. As long as the AuthServers exists, no change to the DefaultAuthorizationEndpoint will be made.

    Please remember: If the EvoSts Authserver on premises is not the DefaultAuthorizationEndpoint the Bearer Token will not contain the authorization_uri and therefore Outlook Mobile Hybrid Modern Authentication will not work! Maybe someday this issue will be solved...

    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. KyleXu-MSFT 26,211 Reputation points
    2020-10-27T02:29:57.723+00:00

    @Daniel Brase
    I saw you said in the original post that the problem was solved, so I deleted this migrated thread.

    Thank you for your feedback on HCW, you can also post it from the end of the Hybrid Configuration wizard article:
    35272-qa-kyle-1027100936.png

    I will also observe for a period of time to see if other users encounter this phenomenon. If many people encounter this phenomenon, I will give further feedback to Microsoft.


    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments