AD FS 2012 R2 Web Application Proxy – Re-Establish Proxy Trust

In the Tailspintoys environment, the administrator (moi) was a bit slack.  They let the AD FS 2012 R2 proxy get into a bad state.  The AD FS Proxy was not contacting the AD FS server on the internal network, and this allowed the short lived authentication certificate to expire.  At this point the AD FS Proxy was “dead to me” as far as the AD FS server was concerned.  The internal AD FS server was OK, the issue was just with the proxy.


How do we fix this?  Actually before we dive into that, lets see what was going on first.  Please note that this post is specific for AD FS 2012 R2.  It does not aim to cover AD FS 2.0 or 2.1 at all.

Starting Point – What The AD FS Proxy Saw

On the WAP server, the Remote Access Management Console was not happy.   It was reporting error code 0x8007520C.

ADFS 2012 R2 ADFS Proxy - Error 0x8007520C

On the WAP server, EventID 422 was logged into the AD FS Admin log stating that it was unable to retrieve proxy configuration data from the Federation Service.  The details in the event stated: System.Net.WebException: The remote server returned an error: (401) Unauthorized.

ADFS 2012 R2 EventID 422 - ADFS Proxy Unable To Retrieve Its Configuration Data from The Federation Service

Starting Point – What AD FS Saw

On the AD FS server EventID 394 indicated what the AD FS server really though about the AD FS proxy:

The proxy trust certificate specified by thumpbrint {0} has expired.

ADFS 2012 R2 EventID 394 - The Federation Server Could Not Renew ITs Trust With The Federation Service

Since the federation server proxy could not renew its trust with the Federation Service, the recommended user action was:  To ensure that the federation server proxy is trusted by the Federation Service. If the trust does not exist or has been revoked, establish a trust between the proxy and the Federation Service using the Federation Service Proxy Configuration Wizard by logging on to the proxy computer.   This is detailed in EventID 276, which is again logged on the AD FS server.

ADFS 2012 R2 EventID 276 - Federation Proxy Was Not Able To Authenticate To the Federation Service

OK – so we need to re-establish the trust between the AD FS proxy and AD FS server.  How do we go about doing that?

Re-Establish AD FS Proxy Trust Using Remote Access Management Console

Interestingly enough there is no option presented initially in the GUI to re-configure the AD FS proxy.

WAP 2012 R2 Remote Access Management Console Does Not Show Configuration Wizard

Currently it knows that the wizard was previously executed, and this fact is stored in the registry.  As Georg discussed at MEC last year to allow the Remote Access GUI to re-run the wizard again, we need to edit the registry.  The registry value that we need to change is:


We need to set the ProxyConfigurationStatus REG_DWORD to a value of 1 (meaning “not configured”) instead of 2 (“configured”). Once that change is made, re-open the GUI.  No reboot is required.

The Remote Access Manager should now allow you to re-run the configuration wizard.

WAP 2012 R2 Remote Access Management Console Now Shows Configuration Wizard

For full details on this process, please see this post.  As a brief recap, we need to ensure that the federation service name is the AD FS endpoint that we defined when initially building the environment.

Re-Running WAP 2012 R2 Remote Access Configuration Wizard

Since there may have been certificate replacement/renewal since the initial server was deployed, be careful to select the correct certificate:

Re-Running WAP 2012 R2 Remote Access Configuration Wizard - Ensure Correct Certificate Is Selected

The summary screen indicates the PowerShell code that will be executed.  This is also captured later in the post for reference.

Re-Running WAP 2012 R2 Remote Access Configuration Wizard - Summary

And when complete, the trust is now re-established.

Now restart the AD FS service on the Proxy server, and check the AD FS event logs to ensure that they are all green ticky ticky!

Re-Running WAP 2012 R2 Remote Access Configuration Wizard - Completed

Alternatively, this can be done from PowerShell, this is shown below.

Re-Establish AD FS Proxy Trust Using PowerShell

EventID 276 shown above, notes that we can run the Install-WebApplicationProxy cmdlet to re-establish trust between the AD FS server and the WAP.  TechNet discusses this in the Install and Configure the Web Application Proxy Server section.  The certificate we want to use is already installed onto the server.  In my case it has the thumbprint of 3EFF626CD4CAECDB6F84DB5FB4FCF580ACF629E2 – note that yours *WILL* be different.  To obtain your certificate thumbprint you can look at the certificate MMC or alternatively run:


In this lab, the command executed was:

 Install-WebApplicationProxy –CertificateThumbprint 3EFF626CD4CAECDB6F84DB5FB4FCF580ACF629E2 -FederationServiceName adfs.tailspintoys.ca


Note that the username and password were not specified, since the cmdlet knows it needs an account that has permission on the AD FS server and it prompts for this required information.  This is the Tailspintoysadministrator account as shown below:

Using Install-WebApplicationProxy Cmdlet To Re-Establish Trust Wth 2012 R2 ADFS Server

After providing the credentials, the cmdlet does it’s thang:

Install-WebApplicationProxy Cmdlet Is Doing Its Magic

Finally finishing up with a Deployment Succeeded message.

Install-WebApplicationProxy Cmdlet -- Deployment Succeeded

Checking For Success

After the restarting the AD FS service on the proxy, success messages were then logged on both the AD FS server and the proxy.

On the AD FS proxy EventID 245 noted that the proxy was able to successfully retrieve its configuration:

ADFS Proxy 2012 R2 - Now Able To Successfully Retrieve Configuration From ADFS Server

And on the AD FS server EventID 396 was logged stating that the trust between the proxy and AD FS server was renewed.

ADFS 2012 R2 - The Trust between The Federation Server Proxy And The Federation Service Was renewed Successfully

Clients were now able to successfully authenticate through the AD FS proxy from the Internet.

Good job.  Time to go home for tea and medals!



Rhoderick Milne [MSFT]


  1. Hello Rhoderick,
    Thank you for this post.
    Do you know if another parameter exists for ADFS external authentication, if primary ADFS is missing?
    I can see WAP servers need to contact primary ADFS. If not, authentication failed.
    Can you see the same issue?

  2. We recently had a situation where new WAP servers would fail to connect to ADFS and the log was full of ID 224 errors (The federation server proxy configuration could not be updated with the latest configuration on the federation service.), with a few 394 errors too.
    After about a day and a half scratching our heads and reading lots of articles like yours, we finally found the reason: our new WAP servers did not have the "SchUseStrongCrypto" setting enabled and like all good .Net4 applications, were defaulting to TLS1.1 to which our ADFS servers were sticking two fingers up (and rightly so).
    Set this, reboot and hey presto - all working.
    Whilst your article was not able to help us, thanks - and hopefully someone else in our predicament will read this comment and be able to fix it, without wasting too much time

    • Thank you John!!! This was our issue too. We'd done a system update, and after restarting for that - this connection issue appeared. But actually the issue wasn't because of the update as we thought (and tried to rollback from - where the issue persisted). The event log had been giving the errors for a while, but the issue only triggered after the reboot when trying to re-establish the connection again... Then after setting the SchUseStrongCrypto stuff, "hey presto" indeed. Thanks

      --hopefully this too will draw attention to your solution for anyone else out there looking.

    • Hosts in that environment on the WAP would point to either the internal AD FS VIP or to one of the AD FS servers.


Leave a Reply

Your email address will not be published. Required fields are marked *