Web Application Proxy Service Not Starting Due to Malformed Configuration File


The below Web Application Proxy (WAP) server had an unexpected issue.  When the machine came back up, it had lost the configuration to allow it to communicate to the AD FS farm.  This is not specifically an VM/Hyper-V/Azure issue, it is more of a WAP issue.

Fixing the issue is straight forward, though let’s take a look at the symptoms first.

WAP Server Errors

On the affected WAP server the AD FS service would not start.  The below was logged into the system event log indicating that there is an issue:

“The Active Directory Federation Services service terminated with the following error:
An exception occurred in the service when handling the control request”

The Active Directory Federation Services service terminated with the following error

There is not much to go on the that generic service control manager event so the next step is to review the AD FS specific log.  This is contained under the Application and Services node in event viewer.

Opening AD FS Admin Log In Event Viewer

As expected there were events listed in the AD FS Admin log.  They provided more detail as to what the issue was.  The below EventID 383 provides a succinct description of the issue.  Namely that the configuration file is malformed.

WAP The Web request failed because the web.config file is malformed

For the benefit of search engines:

The Web request failed because the web.config file is malformed.

User Action:
Fix the malformed data in the web.config file.

Exception details:
Root element is missing. (C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config)
Root element is missing.

EventID 199 also stated that the AD FS proxy service could not be loaded, which is related to the above configuration issue.

The federation server proxy could not be started

The federation server proxy could not be started.
Reason: Error retrieving proxy configuration from the Federation Service.

Additional Data
Exception details:
An error occurred when attempting to load the proxy configuration.

Reviewing the content on disk we can see that there is indeed a file called microsoft.identityServer.proxyservice.exe.config in the C:\Windows\ADFS\Config folder.

image

However, when we open up this file there is no content within it.    Bummer.

image

Correcting the Issue

In order to get this WAP server back up and running, the process is straight forward.

Follow the steps in the ADFS 2012 R2 Web Application Proxy – Re-Establish Proxy Trust post.

After you have done that, the WAP should be happy and report the below:

The federation server proxy successfully retrieved its configuration from the Federation Service

Bootnote

One thing that you might be tempted to do is to copy a configuration file over from another WAP server in the farm to try and get this working again.  That will most likely end in tears as the certificate used to authenticate the WAP server to AD FS is different.    If you try this, the below message will greet you on the WAP server:

The Web Application Proxy Service service terminated with the following error A certificate is required to complete client authentication

And this is also reflected on the AD FS server to which the WAP server communicates:

The federation server proxy was not able to authenticate to the Federation Service

The AD FS server will log the below:

The federation server proxy was not able to authenticate to the Federation Service.

User Action
Ensure that the proxy is trusted by the Federation Service. To do this, log on to the proxy computer with the host name that is identified in the certificate subject name and re-establish trust between the proxy and the Federation Service using the Install-WebApplicationProxy cmdlet.

The contents of the microsoft.identityServer.proxyservice.exe.config file from different WAP servers in the same farm is below.  Note the difference in the highlighted line.  The certificate used to authenticate each WAP is different.

WAP1 Configuration File

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<configSections>
<section name=”microsoft.identityServer.proxyservice” type=”Microsoft.IdentityServer.Management.Proxy.Configuration.ProxyConfiguration, Microsoft.IdentityServer.Management.Proxy, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL” />
</configSections>

<microsoft.identityServer.proxyservice>
<congestionControl latencyThresholdInMSec=”2000″ minCongestionWindowSize=”16″
enabled=”true” connectionTimeoutInSec=”60″ />
<connectionPool connectionPoolSize=”200″ scavengeInterval=”5″ />
<diagnostics eventLogLevel=”15″ />
<host tlsClientPort=”49443″ httpPort=”80″ httpsPort=”443″ name=”adfs.Tailspintoys.ca” />
<proxy address=”” />
<trust thumbprint=”7690514DDBBA8BA8191CA3D266C4DA8E23EA4682
proxyTrustRenewPeriod=”21600″ />
</microsoft.identityServer.proxyservice>
<!– <system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage=”true”
logMessagesAtServiceLevel=”true”
logMessagesAtTransportLevel=”true”>
</messageLogging>
</diagnostics>
</system.serviceModel> –>
</configuration>

 

WAP2 Configuration File

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<configSections>
<section name=”microsoft.identityServer.proxyservice” type=”Microsoft.IdentityServer.Management.Proxy.Configuration.ProxyConfiguration, Microsoft.IdentityServer.Management.Proxy, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL” />
</configSections>

<microsoft.identityServer.proxyservice>
<congestionControl latencyThresholdInMSec=”2000″ minCongestionWindowSize=”16″
enabled=”true” connectionTimeoutInSec=”60″ />
<connectionPool connectionPoolSize=”200″ scavengeInterval=”5″ />
<diagnostics eventLogLevel=”15″ />
<host tlsClientPort=”49443″ httpPort=”80″ httpsPort=”443″ name=”adfs.Tailspintoys.ca” />
<proxy address=”” />
<trust thumbprint=”91917A08F5578DC6437B57C04740106ADD0B36DD”
      proxyTrustRenewPeriod=”21600″ />
</microsoft.identityServer.proxyservice>
<!– <system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage=”true”
logMessagesAtServiceLevel=”true”
logMessagesAtTransportLevel=”true”>
</messageLogging>
</diagnostics>
</system.serviceModel> –>
</configuration>

 

Cheers,

Rhoderick

Comments (1)

  1. turbomcp says:

    thanks

Skip to main content