It's been a while since I posted a troubleshooting article, however spending a Sunday morning fixing ADFS with a college inspired me to write the following post.
Occasionally we are forced asked to do things which are against best practices or even common sense, such as multi-rolling an existing ADFS server as an Exchange 2016 Administration server in order to manage recipients in an Office 365 tenant.
Based on the customer's insistence, Exchange was installed on an ADFS instance hosted on Windows 2012R2. After rebooting, Outlook authentication died for the entire user base. Un-installing Exchange 2016 was not cited as an acceptable option.
The logical troubleshooting path started with Outlook performing an Autodiscover test, which revealed a 401 Unauthorised error. We know the customer was federated, which meant the next troubleshooting logical step was examining ADFS.
https://sts.contoso.com/adfs/ls/idpinitiatedsignon showed the customised sign-on page which was expected with XML metadata on logon.
EXRCA AKA the Microsoft Remote Connectivity Analyser | Office 365 | Office 365 Single Sign-On Test revealed that the https://sts.contoso.com/adfs/services/trust/mex services endpoint returned HTTP Error: 503. The service is unavailable.
We knew that we had a conflict between two applications on the same servers, Exchange 2016 and of course ADFS. ADFS and Exchange administration consoles both fired up and on the face appeared to be working, with exception to the adfs/services/trust/mex services endpoint returning an error.
Recycling the ADFS service created an application log entry detailing a conflict on port 808. A quick search on ADFS conflicts on port 808 revealed a CRM and ADFS multi-role configuration detailed here.
The fix then was quite trivial:
- Using PowerShell "Set-ADFSProperties –nettcpport 809"
- Restart the ADFS service
Following these steps, browsing to https://sts.contoso.com/adfs/services/trust/mex services endpoint returned the correct XML. The Office 365 Single Sign-On Test returned without errors and the Outlook autodiscover test also ran successfully.
Outlook authentication was fixed for all users. While interesting troubleshooting the entire configuration flies against best practice. There is no documentation that I could find that said this configuration was either unsupported or supported, however common sense dictates that servers are single rolled for a reason unless massive budget constraints force otherwise.
Sadly, what appears to achieve an initial saving is often reduced with troubleshooting costs, or in this case a company-wide outage. Domain Controllers, ADFS servers, Exchange servers and more should not be mixed in order to reduce costs.