NI: Free Time Busy on the BT Co Existence Servers not working from Domino/Notes to Outlook/M365 (4321246)

We have an issue where where Notes users cannot see the calendar availability for Outlook users. Outlook users can see Notes calendar availability. I found some BT trouble shooting documentation online and ran the following commands on both the Coex servers. I included the commands and result

Tell BTfreebusy show

BTFreeBusy client: C:\IBM\Domino\nbtfreebusy.EXE version 19.06.0.0, built 6/28/2019 10:42:48 AM
BTFreeBusy client: btexchange.box = https://domain.com/BTAvailability/Availability.asmx
Tell btfreebusy test user@domain.com
BTFreeBusy client: Console command "Test" requesting FreeBusy for user@domain.com

BTFreeBusy client: Server was unable to process request. ---> Call failed to the Exchange Web Services for - GetUserAvailability() ---> The request failed with HTTP status 401: Unauthorized.

BTFreeBusy client: Console command "Test" produced user@domain.com = Server was unable to process request. ---> Call failed to the Exchange Web Services for - GetUserAvailability() ---> The request failed with: Unauthorized.

or
"<Call failed to the Exchange Web Services for - GetUserAvailability()>
   The underlying connection was closed: An unexpected error occurred on a receive."

BTFreeBusy client: Issued 1 requests

When Free Busy (FreeBusy, Free/Busy, FB) stops working suddenly in one direction from Domino to Exchange this usually means something is out of sync in Domino.

The first and most important question is have there been any changes?

Have there been a software update on the Windows COEX servers?

The most plausible cause for a sudden failure, if there were no changes, is a firewall block between O365 and the Windows IIS COEX servers.

Microsoft does update the IP Addresses frequently for O365 and therefore your firewalls need to take this into consideration. If this is urgent we suggest that you contact the Infrastructure team as soon as possible to open the firewall port between O365 and the Windows IIS Coex servers to check. We have included details of where to find the details for the Microsoft IP addresses.

Once the Firewall port is open and there is still a problem please restart the Windows IIS Coex servers and check that they startup properly by checking the event logs.

https://technet.microsoft.com/en-us/library/dn163583
https://technet.microsoft.com/en-us/library/dn163581(v=exchg.150).aspx

We don't keep that documented as the ranges do get added to quite frequently by Microsoft.

Microsoft themselves do publish that information and also any changes they make to that, in fact they even have an RSS feed for it that can be subscribed to.

Check the below URL for all of their required ranges. For Coexistence you would be needing the Exchange portions of the ranges. If the customer does look to implement this then they should plan that for out of hours changes and confirm email and free busy connectivity in both directions.

https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2?ui=en-US&rs=en-US&ad=US

Confirm the btfreebusy@tenant.onmicrosoft.com (btfreebusy@domain.com) account is enabled and the password has not changed. This account must be enabled and contain the correct password which was used when FreeBusy was installed.

Move on to this next section if the account credentials are correct

When troubleshooting Freebusy it's always best to restart all servers (if possible) that interacts with Freebusy (IIS, Domino Coexistence server, Load Balancer/VIP and Exchange [if on-premises])

If you cannot restart the coex servers without scheduling down time, perform the following
Restart IIS servers
From Coex server console

tell btfreebusy quit
tell HTTP quit
load HTTP
load btfreebusy

Note: We recommend performing these steps on a scheduled basis (monthly) should prevent these issues from happening in the future. If they happen again, just perform these steps and test.

If this does not resolve the issue then perform the following:

1. Obtain the version of Freebusy utilized within your environment:
Issue (from the Domino Coexistence Console): tell btfreebusy show

2. Enable Freebusy logging on the IIS server:

On the Windows Coexistence Server got to:

IIS Manger-Sites-Default Web Site-Autodiscover-Application Settings-LogAllRequests-(Double-click) LogAllRequests (note default path for the logs is c:\log\AutoDiscover)-Change ‘Value’ field from False to True and Click OK to save
IIS Manger-Sites-Default Web Site-BTAvailability-Application Settings-LogAllRequests-(Double-click) LogAllRequests (note the default path of the logs is c:\log\BTAvailbility)-Change ‘Value’ field from False to True and Click OK to save
IIS Manger-Sites-Default Web Site-BTRouter-Application Settings-LogAllRequests-(Double-click) LogAllRequests (note path for the logs typically c:\log\BTRouter)-Change ‘Value’ Field from False to True and Click OK to save
Please restart IIS, retest and provide the above and the logs that were indicated in the prior email to us as soon as possible.

3. Enable FreeBusy logging on the Domino Coexistence notes.ini server:

BTCOEX_LOGDATA=15
BTCOEX_SERVER_LOG=6
BTCOEX_CLIENT_LOG=6
BTCOEX_LOG=8

The location of the above logs/output is usually located within the Domino program directory listed under a folder called logs

4. Restart Freebusy by issuing the following (on the Domino Coexistence server console):

tell btfreebusy quit
tell HTTP quit
load HTTP
load btfreebusy

5. Perform more Freebusy lookups and provide those logs to us for further analysis. Please note the approximate time tested along with the users tested with i.e. Freebusy account in Exchange and Freebusy Domino user.

Related article: https://support.quest.com/binary-tree-integration-for-notes/kb/b909172/fb-bt-freebusy-troubleshooting-steps-b909172

6.For EWS calls, if the call is being sent but failing it is probably EWS configuration and it not allowing the FB account to use EWS

Testing for EWS connection issue:

Contact Support if this does not resolve the issue.
Provide the logs above to us, post testing and we will investigate further and provide feedback during our troubleshooting