Web Application Proxy Post-Install Configuration fails with Timeout Exception


We’ve recently resolved a couple of instances of a very specific Web Application Proxy post-install configuration failure. The conditions under which you would see this are quite specific but if you do encounter this it’s not a particularly easy problem to either identify or resolve so we wanted to share our findings to hopefully save some of you some time and pain.


Following on from this article we have released a fix to address the DRS discovery issue detailed in this blog. This is included in the December 2014 rollup patch - http://support.microsoft.com/kb/3013769 - and is detailed in the following KB article:-

AD FS Proxy could not be configured error in WAP post-installation configuration wizard in Windows Server 2012 R2

There is also another known issue which can lead to the same symptoms which is addressed in the folowing fix released in Janaury 2015:-

Time-out failures after initial deployment of Device Registration service in Windows Server 2012 R2

We would recommend installing both the December 2014 rollup (KB.3013769) and the hotfix KB.3020773 on your ADFS servers if you are encountering the timeout issues detailed in this blog.

What are the Symptoms of the Issue?

After installing the Web Application Proxy feature you then need to run through the Web Application Proxy post-installation configuration wizard. After completing all the necessary details the post-install configuration tasks will then run.

Under certain conditions which will come to a bit later, retrieving the ADFS Proxy configuration may fail with the error:-

“AD FS Proxy could not be configured. Unable to retrieve proxy configuration data from the Federation Server.”

WAP Error_635418471643343423 (2)

You will also see the following logged in the AD FS event log on the Web Application Proxy server:-

Log Name: AD FS/Admin
Source: AD FS
Date: 7/20/2014 2:09:22 PM
Event ID: 422
Task Category: None
Level: Error
Keywords: AD FS
User: S-1-5-21-2461873363-3247490994-1217893606-500
Computer: wap.contoso.com

Unable to retrieve proxy configuration data from the Federation Service.
Additional Data

Trust Certificate Thumbprint:

Status Code:
Exception details:
System.Net.WebException: The operation has timed out
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()


What’s going on in the Background to cause this?

As part of responding to the AD FS Proxy configuration request the AD FS server has to determine if Device Registration has been initialized and enabled. This is so the AD FS Proxy service on the Web Application Proxy server knows whether it needs to enable the Device Registration endpoints and certificate bindings,and for which UPN suffixes.

As part of the DRS discovery logic, if the DRS configuration objects which are stored in Active Directory, cannot be found in the local domain, the AD FS 2012 R2 server will try to connect a DC in the root domain to enumerate all GCs under the CN=Sites container and that host the root domain. From this list, it iterates over each GC until it finds a reachable GC to try to locate the DRS configuration.

In a complex, segregated network environment the AD FS server may not have network access to many of these Global Catalog servers which leads to delays while the TCP connection attempts to these GC servers time out.

The Web Application proxy server call to retrieve the AD FS Proxy configuration has a 100 second timeout so if the cumulative delays due to the GC network timeouts exceeds this timeout the post-install configuration will fail. Web Application Proxy will retry the configuration call a number of times but, if you are seeing this issue, each call will be subject to the same delays and will fail.

We are aware that this behavior may cause issues in complex network environments and we are working with the AD FS Product Group to review this and look at how we can modify this behavior moving forward but that’s not going to help you if you’re hitting this issue now.


How can I check if I am hitting this issue?

The first thing to check for is the presence of the “System.Net.WebException: The operation has timed out” Event ID 422 error in the AD FS event logs on the Web Application Proxy server. This is the primary indicator that you may be hitting this problem.

If you believe you may be hitting this issue you can also run a Network Monitor trace (or your network capture tool of choice) trace on the ADFS 2012 R2 server while attempting to run the Web Application Proxy post installation configuration.

Network Monitor 3.4 can be downloaded from the following link - http://www.microsoft.com/en-us/download/details.aspx?id=4865

You can then apply the following display filter in Network Monitor - property.TCPSynRetransmit


This filter will show re-transmitted TCP SYN packets.

A TCP SYN is the first packet used to establish a TCP connection. Re-transmitted SYN’s means that the expected SYN ACK response was not received so the OS retries the SYN packet. You can think of this a bit like trying to phone someone, not getting an answer, waiting a few minutes and then trying again.

We’re specifically interested in unanswered SYN packets to port 139 and 445 which are the ports that will be used to talk to the Global Catalog server.

If you hitting this issue you would see something like the following with the above filter applied.


Note – as the Web Proxy Application server will make a number of attempts to retrieve the configuration you will see multiple cycles of attempts. For the purposes of solving this issue we just need to bring one cycle under the 100 second timeout so we’re interested in unique Global Catalog servers and not how many times we try to connect to them.


A Short Diversion into TCP/IP SYN Re-transmissions

The TCP/IP SYN re-transmission behavior is very specific and worth a short discussion on as tuning this does provide a possible workaround for the issue.

As noted above if a TCP SYN connection attempt does not receive a response it will re-transmit the SYN attempt and there are a couple of key parameters that control the behavior here:-

- TcpMaxConnectRetransmissions – default value 2 – this controls how may times the TCP stack will retry the initial SYN packet if a SYN ACK response is not received. The following KB talks in more details about this setting - http://support.microsoft.com/kb/2786464

- InitialRTO – default value 3000 msec – this is the initial retransmit timeout period and gets doubled between each successive retry. The following KB talks in more details about this setting - http://support.microsoft.com/kb/2472264

For example, with default settings you will see the following behavior:-

Syn Attempt

Timeout Period

Cumulative Time

Initial SYN

3 seconds

3 seconds

1st SYN re-transmit

6 seconds

9 seconds

2nd SYN re-transmit

12 seconds

21 seconds


These settings are relevant as it gives us a means to control how long the timeout takes for each unavailable Global Catalog server.


Potential Workarounds

Now that we know what’s causing the timeout let’s look at potential workarounds for this.

1) Allow the Network Traffic to one of the Global Catalog servers

It’s easy for me to sit here and write this but I’m not the one who has to go and talk to the network/Firewall guys and convince them 🙂

Seriously though, if you are able to open either TCP port 139 or 445 to one of the first Global Catalog servers that AD FS can’t reach this should resolve the issue as the AD FS server would stop at the point it successfully connects to a GC. Hopefully this blog will help explain the issue to your network team.

As mentioned above you can use Network Monitor to identify which Global Catalog servers the AD FS server is trying to connect to and then look at allowing Network Access to the first of the IP addresses you find.

2) Initialize Device Registration

Initializing Device Registration would create the DRS configuration containers in Active Directory and should avoid the Global Catalog discovery steps that lead to the delay.

Device Registration can be initialized using the following PowerShell script on one of the AD FS 2012 R2 servers:-


Note – this needs to be run with Enterprise Administrator credentials and requires that the Windows 2012 R2 AD schema update has been deployed. For further details on this cmdlet please see the following article - http://technet.microsoft.com/en-us/library/dn479332.aspx

This cmdlet does *not* enable the device authentication nor the device registration service in the ADFS servers. Enabling Device Registration is a second step in the DRS set-up process.

3) Tune the TCP SYN Retransmit behavior

If you are unable to implement either of the above resolutions then tuning the TCP SYN retransmit behavior can also be used to workaround the problem.

As discussed previously, we will incur a 21 second delay for each Global Catalog server we try to connect to that we cannot reach. If we can tune the timeout down to that the cumulative delay brings this under 100 seconds (let’s say 80 seconds to give some time for other required activities) then the AD FS server should respond to the configuration request within the 100 second timeout.

- The default setting for TcpMaxConnectRetransmissions is 2 and this is also the minimum value so we cannot tune this further down.

- This leaves us with tuning InitialRTO down from its default value of 3000 msecs. The valid range is 300-3000 msec. This can be tuned using the following netsh command:-

netsh interface tcp set global initialRto=3000

It’s hard to give a precise value to set this to as it how low you will need to go will depend on how many Global Catalog servers the AD FS server is trying to reach. You can use the following table to get an idea of the timeout per server you will get for various initialRto settings:-

initialRTO setting
(in milliseconds)
Total Timeout Period (per failed GC connection)
3000 (default) 21 seconds
1000 7 seconds
500 3.5 seconds

This would only be a viable option for up to around 20 unreachable Global Catalog servers. Anything above this number is going to start to reach the 100 second overall timeout even with a 3.5 second total timeout per server.

Note – lowering the initialRTO could potentially cause the AD FS server connectivity issues in high latency environments and while we would not expect this to be the case for the majority of deployments please just keep this in mind. This is also a global OS level setting so affects any outbound TCP connections made by the AD FS server. It has no impact on inbound connections.

Note – reducing the initialRTO is not something that we would normally recommend so please do remember if you do change this that we’d recommend that you revert to the default settings when we have a fuller resolution for this issue if you have needed to tune this down.



Under certain conditions the Web Application Proxy post-installation configuration task may fail with the following error:-

“AD FS Proxy could not be configured. Unable to retrieve proxy configuration data from the Federation Server.”

The AD FS event log on the Web Application Proxy server will also show an Event ID 422 error with “System.Net.WebException: The operation has timed out” in the error details.

We do not expect the issue we’ve covered here to be a common issue but due to the difficulties in diagnosing this and understand the resolution options we wanted to share our findings.

In the cases we have seen this timeout errors due to the AD FS server trying to locate the Device Registration configuration containers in Active Directory. As part of this discovery the AD FS server may try to connect to GC’s across the local Forest.

If there is a complex, segregated network infrastructure in place these connection attempts may fail incurring a 21 second delay per inaccessible Global Catalog server leading to the Web Application proxy server 100 second timeout being exceeded.

There are a number of workarounds you can consider to alleviate this issue:-

- Allow ADFS connectivity to one of the relevant Global Catalog servers

- Initialize Device Registration

- Tune the TCP SYN retransmit timer (initialRTO) to reduce the time delay per GC server

We are working with the AD FS Product Group on a solution for this issue moving forward and will update this article when we have some updates on this but in the meantime hopefully the above information will help unblock any of you who do hit this issue.


Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team


Thanks also to the following for helping put all the pieces of this jigsaw together:-

Billy Price, Senior Escalation Engineer, Web Application Proxy support team

Rainier Amara, Support Escalation Engineer, Web Application Proxy support team

Comments (11)

  1. Ed (DareDevil57) says:

    Thanks for sharing.

  2. Hi Paul,

    it doesn’t sound likely to be the above issue.

    The first thing in my mind would be whether you’re terminating SSL at the F5 as this will break the proxy trust relationship:-



  3. Marc_Martinez says:

    Really usefull!!


  4. Hey Paul,

    I would definitely have them double check about the SSL termination on the F5 which is Root Cause 6 in the Proxy Trust blog. The fact that it works when this is bypassed keeps me coming back to this and would explain the 401.

    Network traces on the WAP and ADFS server covering a repro of the problem would definitely be worth doing.



  5. paul says:

    I am seeing this issue when I deploy the WAPs and they are pointing to the F5’s VIP. If I point them directly to the backend STSs, I don’t see the problem. Any pointers?

  6. paul says:

    Nope, we are not terminating the SSL at the F5. The strange thing is that clients pointing to the VIP do not have any issues authenticating… Looking at the exception details of EventID 422 I see: "The remote server returned an error: (401) Unauthorized."
    I tested the same configuration in Azure, deployed 4 proxies and 3 of them completed correctly, the 4th one has the same issue (and only when pointing to the ILB). I’ll try to capture a network trace. thanks

  7. paul says:

    To add to the discussion: we are using the same F5 configuration on the old AD FS 2.x farm without any issues.

  8. We had already initialized AD Device Registration once before on our Active Directory. For some reason, after a little more than two years of operational AD FS deployment, this problem started to pop up. So I tried to re-initialize it again from an AD FS server:


    Fixed the problem for us.

    This was so very frustrating to debug. The AD FS server showed no events whatsoever. The WAP server would always timeout when trying to connect. The WAP Event Viewer showed success / failure / success / failure but the commands *never* showed a success. The Proxy Server would also register between 1 and 8 certificates on the AD FS server, despite the AD FS server being *completely silent* in the Event Viewer. Poor logging, poor set of debugging tools available, poor set of documentation. So even though this problem is fixed on our network, I still have an eye to tear down our AD FS installation and throw it out. It has been nothing but a waste of servers, money, resources and time.

    1. momilian2010 says:


      Did you re-initialize ADdeviceregistration even though it was already initialized? Will that break anything if we’re currently doing AzureAD device registration? We got a SAN cert with deviceregistration and enabled that before that was an option in Azure.
      I’ve got 2 ADFS servers and 2 proxies in my farm and we’ve had to disable one of each because of trying to reconfigure the WAP server and running into the above issues. But with mine also, it can’t stop the adfssrv service on the proxy and that kills the wizard. The tech from MS wants me to upgrade those 2 servers to .net 4.7 (we’re at 4.0) and try again, but I don’t know how I feel about that.

Skip to main content