Shared Free/busy between two untrusted forests failing in one or both directions
In a recent case, I found a pretty common mistake many customers make when setting up their free/busy sharing between two untrusted orgs or more appropriately, when they set up their trusted and intermediate certs for their target domains.
Scenario:
Contoso and WingTipToys are two partner companies with no forest trust between them that want to share free/busy information.
Both companies set up the AvailabilityAddressSpace and the AvailabilityConfig as outlined in the following article:
https://technet.microsoft.com/en-us/library/bb125182(v=exchg.150).aspx
Contoso is on Exchange 2013 and WingTipToys is on Exchange 2010. The testing user from WingTipToys was an O365 user. In this particular case, however, the issue could have been between other version of exchange or even the same version on both side. In other words, the version of exchange had nothing to do with the issue.
After setting up the AvailabilityAddressSpace and the AvailabilityConfig, the WingTipToys engineers quickly noticed that they were unable to see the free/busy of the Contoso users. In this particular case the Contoso users were able to see the free/busy of the users in WingTipToys, so it was only broken in one direction.
Troubleshooting:
Since one side worked and the other didn't we began by comparing the settings in get-AvailabilityAddressSpace. It looked as follows:
From the WingTipToys side:
RunspaceId : 7c0543e4-0813-4670-aa8d-1251c9b09936
ForestName : Contoso.com
UserName : Contoso\TestAccount
UseServiceAccount : False
AccessMethod : OrgWideFB
ProxyUrl :
ParentPathId : CN=Availability Configuration
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : Contoso.com
DistinguishedName : CN=Contoso.com,CN=Availability Configuration,CN=WingTipToys,CN=Microsoft Exchange
,CN=Services,CN=Configuration,DC=WingTipToys,DC=com
Identity : Contoso.com
Guid : 7e264c80-75d9-4492-a528-1962c0cd6dee
ObjectCategory : int.wingtiptoys.com/Configuration/Schema/ms-Exch-Availability-Address-Space
ObjectClass : {top, msExchAvailabilityAddressSpace}
WhenChanged : 6/6/2016 4:05:16 PM
WhenCreated : 6/6/2016 4:04:57 PM
WhenChangedUTC : 6/6/2016 8:05:16 PM
WhenCreatedUTC : 6/6/2016 8:04:57 PM
OrganizationId :
OriginatingServer : Server01.WingTipToys.com
IsValid : True
From the Contoso side:
RunspaceId : 7c0543e4-0813-4670-aa8d-1251c9b09936
ForestName : WingTipToys.com
UserName : WingTipToys\TestAccount
UseServiceAccount : False
AccessMethod : OrgWideFB
ProxyUrl :
ParentPathId : CN=Availability Configuration
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : WingTipToys.com
DistinguishedName : CN=WingTipToys.com,CN=Availability Configuration,CN=Contoso,CN=Microsoft Exchange
,CN=Services,CN=Configuration,DC=Contoso,DC=com
Identity : WingTipToys.com
Guid : 8c235d81-55d1-4211-b122-1353cabd1aed
ObjectCategory : int.wingtiptoys.com/Configuration/Schema/ms-Exch-Availability-Address-Space
ObjectClass : {top, msExchAvailabilityAddressSpace}
WhenChanged : 6/8/2016 4:05:16 PM
WhenCreated : 6/8/2016 4:04:57 PM
WhenChangedUTC : 6/8/2016 8:05:16 PM
WhenCreatedUTC : 6/8/2016 8:04:57 PM
OrganizationId :
OriginatingServer : Server01.Contoso.com
IsValid : True
As you can see, there wasn't anything really different here. From all perspectives, this was set up correctly. We then kicked off an Extra trace with the InfoWorker.RequestDispatch tag selected. Instructions can be found here:
After reproducing the issue and a quick analysis of the results, we found several errors:
Unable to find a organization Relationship with domain Contoso.com.
Failed to discover Availability service for mailbox <Dude>SMTP:Dude@Contoso.com because AvailabilityAddressSpace is misconfigured.
Failed to discover Availability Service for user Dude@Contoso.com using both the target address and primary SMTP address.
We also pulled the Free/busy logs from the Outlook client and found the following in it:
Unable to send cross-forest request for mailbox <Dude>SMTP:Dude@Contoso.com because of invalid configuration., inner exception: AvailabilityAddressSpace 'Contoso.com' couldn't be used because the Autodiscover endpoint couldn't be discovered.
At this point we decided to run the Remote Connectivity Analyzer to see if we could figure out why Autodiscover was not working:
https://testconnectivity.microsoft.com/
We chose the Office 365 tab and then the Free/Busy Test since we are testing with an O365 user in a hybrid configuration.
After the test completed, we could see that the FreeBusy Connectivity had succeeded. However, as we scrolled down we found an error in the Performing Free/Busy Test. We followed the test down to the initial failure which was during the Analyzing the certificate chains for compatibility problems with versions of Windows test. Here it was saying Potential compatibility problems were identified with some versions of Windows. We clicked on additional details and it said the following:
Additional Details: The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
At this point I was fairly convinced that the issue was a certificate issue.
Resolution:
We pulled up the MMC console the user had used to add the root and intermediate certificates from the target domain (Contoso.com) and he showed me where he had added all of the certs. A root certificate had been added to the Trusted Root Certification Authorities and the two intermediate certificates were installed to the Intermediate Certification Authorities. I opened the certs and they all appeared valid. I was just about to close it and spin up a different troubleshooting step when I noticed the top line of the MMC console. It said Certificates - Current User.
In a nutshell, the customer had installed the correct certificates but in the incorrect store. When he had set up his Certificates console, he had chosen Current User, not Local Computer. The certs were saved in the wrong store. So I had him close the console and set up a new one:
- From Start, type MMC
- Click on File and select Add or Remove Snap-ins
- Select the Certificates snap-in and click on Add
- Choose Computer Account (this is where he had strayed previously by leaving it at the default of My user account)
- Click Next and then Finish
Now when we look at the certificates console, we see the proper path - Certificates (Local Computer).
We then could see that the certificates were not present in this store. So we added them to the appropriate authorities on all of the WingTipToys CAS servers, and the issue resolved.
Notes:
In order for shared free/busy to work between two untrusted forest, the root certificate of the target domain, at a minimum, need to be installed to the Local Computer store on each CAS server. There are many other requirements, but this is the one that seems to get missed or done incorrectly more than most. Even when you do everything else right with the configuration of shared free/busy, something as simple as installing the certificates to the wrong store can lead to really long and often misdirected troubleshooting. Hopefully this article will help cut down on that mistake.