Office 365 SAML idp and Outlook 2016 solution?

Hi Kevin, good to hear you found a solution. Could you help me and try something out for me. I have also deployed the F5 APM to fully replace ADFS and everything seems to be working fine. There is only one issue with shared licenses in a non persistent VDI environment and I'm not sure if the problem is within my F5 APM configuration or within Office 365/Azure. I'm trying to validate my setup using the Microsoft connectivity test, but I'm not sure if this test is reliable. Could you run a test on your setup and share your results?

What I do is:

• Go to https://testconnectivity.microsoft.com
• Go to tab 'Office 365'.
• From 'Office 365 General Tests' run the 'Office 365 Single Sign-on Test'.

In my setup it fails with the following messages:

An error was found in the domain registration.
Additional Details
The Metadata Exchange URL in the domain registration isn't valid. URL:
Elapsed Time: 1 ms.

We have set the metadataexchangeuri, so I wonder if I can ignore this error. I would like to know if your setup shows the similar error messages.

I am unable to do this as we had to revert to ADFS. Another script we use to map drives to sharepoint is heavily dependant on ADFS.. it actually scrapes information from ADFS webpages! So I am adapting that at the moment, only 3000 lines of powershell 8-|

But I recall the metadata exchange URL didn't change for us as well. The federation command does not seem to affect this URL at all. I believe you have to manually set this yourself using ...

Set-MsolDomainFederationsettings -DomainName  -MetadataExchangeUri 

Please note i have updated the comment above, the MetadataExhangeUri has nothing to do with SAML exported meta data. It is not needed in a SAML environment so you can delete it. Try setting it to "" to clear it.

Too bad you had to revert to ADFS, but thanks for your help. I too think the MetadataExchangeUri is not applicable to the SAML setup. In the connectivity check Azure is not sending the MetadataExchangeUri at all (while it is set). In the traces you can see . So I suspect we better ignore the Microsoft connectivity check.

Good luck with the 3000 lines of powershell :-)