Imagine the situation. You just finished deploying AD FS 2016 and Web Application Proxy (WAP) servers in a highly available environment with the AD FS namespace load balanced internally and externally. There are multiple AD FS servers and WAP servers. This is an interesting deployment project and all is going well. After verifying that core AD FS and WAP functionality works as expected you then move onto using WAP to publish Exchange to the Internet using pass through authentication.
Unfortunately no plan survives contact with the enemy….
Instead of being able to see your lovely OWA splash screen when at Starbucks you instead are greeted with the below rather sad page:
For make most glorious search engine benefit:
Service Unavailable HTTP Error 503. The service is unavailable.
Hmm. Maybe OWA is not running on the published Exchange server – let's try ECP instead.
Nope same issue.
Internally everything is just fine and all is working as expected. From the WAP servers themselves, DNS resolves to the correct endpoints. OWA and ECP can also be rendered as expected on the WAP server.
The issue is only with the external publishing. Something is wrong with WAP.
Reviewing WAP Configuration
All of the required Exchange CAS namespaces were published using WAP. Below is the Remote Access management console on server WAP-2016-1. The OWA published application is highlighted, and then a zoomed view is shown for OWA.
We can use the Remote Access Management console to open the properties of the published application, or use PowerShell. The PowerShell method is shown below.
Get-WebApplicationProxyApplication "mail.wingtiptoys.ca/owa" | Format-List
All of this looks OK. The correct certificate is selected and the certificate is valid in all respects.
Since that all seems to be fine, let's review the WAP diagnostics to see what is happening
Upon initial inspection it would seem that all is well in the WAP world. There are no errors logged in:
Applications and Services Logs\AD FS\Admin
All of these entries indicate nirvana, and they state:
"The federation server proxy successfully retrieved and updated its configuration from the Federation Service 'sts.wingtiptoys.ca'."
As noted earlier, the idpinitiatedSignon page was working as expected with no issues. In this case the URL used was:
However, WAP logs to a different event log which is:
Applications and Services Logs\Microsoft-Windows-Web Application Proxy\Admin
When this log is reviewed note that there are errors.
Specifically we can see EventID 12019 where there is an error with creating the WAP listener.
The details of the error are:
Web Application Proxy could not create a listener for the following URL: https://mail.wingtiptoys.ca/owa/.
Cause: The filename, directory name, or volume label syntax is incorrect.
Well that would be a problem, no?
Addressing WAP 2016 Application Publishing Error
The name that the error is referring to as invalid is highlighted below.
It is quite common to copy the published URL and then paste it into all of the relevant fields. This is efficient and also prevents making typos.
However, if the URL is pasted into the Name field as shown above you will find yourself in a pickle and probably reading this post…..
The issue is due to the "/" invalid character in the name field. Simply remove the offending special character to address the issue. To do this we can right click the WAP published application, and chose EDIT.
Note in the below example, the Name field was edited and now contains "OWA"
Complete the wizard to save changes. Allow for WAP to save and update its configuration.
This could also be done in PowerShell using the Set-WebApplicationProxyApplication cmdlet. As an example:
Set-WebApplicationProxyApplication -BackendServerUrl "https://mail.wingtiptoys.ca/owa/" -ExternalCertificateThumbprint 'BD4074969105149328DBA6BC8F7F0FFC9509C74F' -ExternalUrl "https://mail.wingtiptoys.ca/owa/" -Name 'OWA' -ID '8D8344E0-52A9-ED1D-692C-81BF039813B5'
This was repeated for all published applications. Note the highlighted Name column – all of the published applications now have simplified names.
Now it is time to test, and you should be back in business!
Note that this issue seems to be specific to WAP 2016, and was not present on WAP 2012 R2.