While working on upgrading a Windows 2012 R2 ADFS Farm to Window Server 2016 I noticed the worried looks of the systems administrators while looking at a warning in the ADFS event log, which they wanted to trouble shoot. I knew they had a hardware load balancer in place which made me 99.999% sure it wasn’t a real issue. You see, early documentation on configuring load balancing for and ADFS farm was often configured with a health check for the following url: /FederationMetadata/2007-06/FederationMetadata.xml. This leads you to an XML file that should be available on a working ADFS node.
This works fine. The Kemp Loadmaster knows the ADFS nodes are functional or not and can do it’s job. There’s a nagging issue however. The ADFS log on the ADFS farm node keep logging every health check with a warning
Event ID 143 AD FS
The Federation Service was unable to create the federation metadata document as a result of an error.Document Path: /FederationMetadata/2007-06/FederationMetadata.xml
System.Net.HttpListenerException (0x80004005): The specified network name is no longer available at System.Net.HttpResponseStream.Write(Byte buffer, Int32 offset, Int32 size) at Microsoft.IdentityServer.Service.FederationMetadata.SamlMetadataListener.OnGetContext(IAsyncResult result)
As you cans see it just fills the logs every 9 seconds (the frequency of the health check).
This leads to hunting for a “ghost” issue that’s actually only an artefact of checking for .
Kemp has updated their documentation with 2 other values for the health check url to use. The good news is these don’t cause the above artefact of logging warning to the ADFS event log. These 2 options are:
This leads to an XML file as well but it doesn’t cause the warning to be logged.
This leads to the ADFS login page which also doesn’t cause a warning to be logged.
So by changing your health check to any of the above you get a functional health check for your nodes and you don’t have the phantom warning entries in the ADFS event log. That’s a lot better and at least doesn’t cause any unneeded concerns by the initiated accidental ADFS administrator.
Thanks for the post. Found these seemingly never ending errors in my ADFS logs while troubleshooting something else. Now my Kemp is happy and my error log is no longer being spammed.
I found that the ADFS 2019 version doesn’t like the IPDInitiatedSignon.aspx URL, but it worked fine with the /adfs/services/trust/mex URL. It logged exactly one error (1000) and was back to normal after that.