Cloud to OnPrem free busy Problem

Question

Hi
Free/Busy from onPrem to O365 is working but not from O365 to onPrem

I wasn't able to run the HybridConfigurationWizard successfully (did not work with modern or classic). I did some steps manually

Test-OrganizationRelationship is working from O365. All Steps are successfull (also Step4, Retrieved token for target......)

Results www.testconnectivity.microsoft.com
Outlook Connectivity to onPrem Account: successfull exept last check "Attempting to ping RPC proxy ..." (I'm not sure if this must be successfull)
free/busy O365 to OnPrem(Modern Auth): The Autodiscover service was tested successfully
The Autodiscover service couldn't be contacted by any method
free/busy Lookup failed, https status 504 (Gateway Timeout)

I can see autodiscover requests going through our Firwall and F5 LoadBalancer. In the IIS Log can see a lot of entries and I think the one corresponding to this test has a sc-status of 401 (Unauthorized). cs-username is empty.
Probably an missconfiguration of our F5 but I dont think the Problem is there.

It went through a lot of Troubleshooting Guides without success.
Any help is appreciated.

Answer 1

Hi @Aschwanden Roger, ACA-IT-OPE-CIN ,
What's the version of the on-premises Exchange server?
I noted that you wasn’t able to run the HCW and did some steps manually. What are the steps? Has the hybrid environment been successfully deployed?

1.Have you read this article (Troubleshoot free/busy issues in Exchange hybrid environment )before? If not, please try the troubleshooting methods provided in the article first.

2.About the “Attempting to ping RPC proxy”. According to my test on the test account, the result shows that it is successful. If possible, please share the complete error message with us. But pay attention to covering your personal information. You also could hold the “Ctrl” and right click the outlook icon, then select the “Tesst E-mail AutoConfiguration” to test the Autodisocver service.

3.About the “ https status 504 (Gateway Timeout)”, It fails at EWS request and usually network related issues. Please run the following command to make sure that set the correct external URL and WSSecurity enabled as an authentication method.

Get-WebServicesVirtualDirectory | fl name,server,externalURL,ExternalAuthenticationMethods  

4.According to my research, the Test-OrganizationRelationship cmdlet doesn't include any functional tests of federated sharing features, such as accessing user free/busy information or moving mailboxes between organizations. So please run the following command to check whether the settings of IOC and organizationrelationship are correct:

Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled  
Get-OrganizationRelationship "Exchange Online to on premises Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled  

For the usual settings, you can check at the bottom of this article: Demystifying Hybrid Free/Busy: what are the moving parts?

5.Status 401 indicates that access is denied. Regarding the 401-related error in IIS, you can refer to: HOWTO: Diagnose 401.x HTTP errors on IIS

6.Please run the following command to verify that that the OAuth configuration is correct.

Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List  

---

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.

Answer 2

Hi
thanks a lot for your Feedback.

We have Exchange 2016 onPremise.
Regarding the manual steps we did. We configured connectors and checked all the settings manually.
Unfortunately I don't have a second Environment to verfiy if all the Settings match a working Setup.

1.)
I went through several Troubleshooting Guides, also the one you mentioned where you can verify a lot of settings.

2.)
Result for "Test E-mail Autoconfiguration": Autoconfiguration for https://exchfed.Mydomain.com/autodiscover.xml successfull (0x0000000000)

Outlook Connectivity, Complete Output: 69536-rcatestresult.xml

3.)
Result for Get-WebServicesVirtualDirectory | fl name,server,externalURL,ExternalAuthenticationMethods:
Name : EWS (Default Web Site)
Server : Servername from our onPrem Exchange Server
ExternalUrl : https://exchfed.MyDomain.com/ews/exchange.asmx
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}

4.)
Output OnPrem
TargetAddressDomains : {MyDomain.mail.onmicrosoft.com}
DiscoveryEndpoint : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc
Enabled : True

DomainNames : {MyDomain.com, MyDomain.mail.onmicrosoft.com, MyDomain.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
TargetApplicationUri : outlook.com
TargetSharingEpr :
TargetOwaURL :
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
Enabled : True

Output O365
TargetAddressDomains : {MyDomain.com}
DiscoveryEndpoint : https://exchfed.MyDomain.com/autodiscover/autodiscover.svc
Enabled : True

DomainNames : {MyDomain.mail.onmicrosoft.com, MyDomain.com, MyDomain.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
TargetApplicationUri : FYDIBOHF25SPDLT.MyDomain.com
TargetSharingEpr :
TargetOwaURL :
TargetAutodiscoverEpr : https://autodiscover.MyDomain.com/autodiscover/autodiscover.svc/WSSecurity
Enabled : True

I also went through your mentioned Article.

5.)

SubStatus Code is 0 -> no Additional Information.

6.)
O365 where MyUser is an OnPrem Mailbox
Test-OAuthConnectivity -Service EWS -TargetUri https://exchfed.MyDomain.com/ews/exchange.asmx -Mailbox MyUser@MyDomain.com -Verbose | fl

OnPrem where MyUser in an O365 Mailbox
Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.com/owa/accarda.onmicrosoft.com -Mailbox MyUser@MyDomain.com -Verbose | fl

Both command ResultType : Success

Can you see someting and point me to the right Direction?

Best Regards,
Roger

Answer 3

Hi
Sorry for the Delay, as mentioned I was on Holiday. Thank you again for the suggestions.

Yes, I tried to bypass the F5 by making a NAT Rule for the IP Address 13.74.35.9 which is used during the free/busy test.
The Problem ist that the answer from our onprem exchange going through our Proxy and results in an "Connection was reset by Server".
(Direct Connetion from Exchange to Internet is not allowed so far).

We have our "internal Server Certificates" configured in the IIS binding settings with our "internal domain".
If I change it to our "external domain wildcard Certficate" the internal client receive a "Certificate Warning" during Outlook startup.

You said that it's recommended to have direct connections from O365 to Exchange Onprem without any Server in between.
Should we place an additional CAS Server in our DMZ Zone acting as Proxy?
I didn't find Documentations about such a szenario. I think it's a normal setup to have the exchange server in the internal Zone accessed through a Load Balancer.

I have also another Question. When I try to check free/busy information from an Outlook client in our internal Network with an O365 Mailbox for an OnPrem Account i should see a Request to autodiscover.mydomain.com in our Firewall from Micosoft O365 Network.
But in don't see such a Request. As mentioned I can see Requests when testing with https://testconnectivity.microsoft.com/ but not whith the outlook Client itself.
The Outlook Client with aO365 Mailbox is in our internal network but if I understand it correct the free/busy check is done from the cloud and the request should be visible.
Or did I misunderstand something?

Best Regards,
Roger

Answer 4

Hi @Aschwanden Roger, ACA-IT-OPE-CIN ,
1.I want to confirm with you, according to the information you provided, after bypassing F5 LB, can Free and Busy work normally?

2.For the certificate. Based on the research of the error information you provided before, in order to ensure that your certificate is correct, let you confirm it. If the information contained in the internal certificate is correct, there is no need to replace it.

3.Because after the deployment of the mixed environment is completed, for Exchange online and on-premises Exchange server. Mail sent to each other is equivalent to internal delivery. Although Microsoft has not officially released related articles, in some articles describing mail flow, we know that Microsoft does not recommend placing any servers, services and equipment that handle or modify SMTP communication between the on-premises Exchange server and Exchange online. So as mentioned above, in order to eliminate the problem caused by F5 LB, we need to confirm whether F5 LB can be turned off or bypassed.

4.Can you share the results and logs of running Test E-mail AutoConfiguration with us? I want to confirm whether the result returned by your auto-discovery service is correct, and check the auto-discovery process. But please noted that covering your personal information. Through this process, we can also confirm the request process of the autodiscover service. For your test using ExRCA, this is usually a choice for us to troubleshoot, but in reality it is done through simulated mailboxes.

In addition, have you ever tried to use OWA to log in to your mailbox to view Free/Busy information?

---

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.

Answer 5

Hi
1.)
It doesn't work either when bypassing F5 with the single IP 13.74.35.9 (testconnectivity.microsoft.com). Our exchange is going through our Proxy (I whitelisted the exchange IP's that no rules take place)

3.)
F5 cannot be turned off.
F5 can be bypassed for testing if I know the source(s).
As mentioned I bypassed it for 13.74.35.9 (testconnectivity.microsoft.com) but I cannot give access from Internet to our Exchange without an Application FW in between.
Should I allow bypassing the IP's mentioned by Microsoft?
https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide
But the 13.74.35.9 isn't mentioned there. So I don't know what I have to bypass.

4.) Yes, we teste with owa and have the same behavior.

Test E-mail AutoConfiguration when I specified an o365 and OnPrem mailaddress