ADFS 2016 – Cannot add/update Relying Parties from the GUI from metadata files “Method not found”

UPDATE: The following update is fixing this issue:

  • Cumulative Update for Windows 10 Version 1607 and Windows Server 2016: December 9, 2016

If you are currently using the October release of Windows Server 2016 (build: 10.0.14393 N/A Build 14393) you might experience a weird error message when you try to add a relying party trust or update a relying party trust with the metadata files. Whether it is from an HTTPs source or even a local XML files that you previously saved, you have the following message:


It seems that adding or updating a relying party from the console currently does not work as expected. If you don’t know what version of Windows you are running, you can run the command “systeminfo” in command prompt and look at the build line.

But no worry, you can still do the job thanks to our good old friend PowerShell.

Adding a relying party trust from an online metadata file:

Add-AdfsRelyingPartyTrust -Name "My App" -MetadataUrl ""

Adding a relying party trust from a metadata saved on the your ADFS server:

Add-AdfsRelyingPartyTrust -Name "My App" -MetadataFile "C:\Temp\FederationMetadata.xml"

Updating the relying party trust from the metadata file already set on the properties of the trust:

Update-AdfsRelyingPartyTrust -TargetName "My App" 

This will probably be fixed very soon!


Comments (7)

  1. Jean-Philippe says:

    Thanks Pie, that just worked.
    PS1 rocks.

  2. sergeNG says:

    Thank you sir!
    implementing a complete windows infrastructure is truly overwhelming!

  3. Crapitouille says:

    I also have a bug, on server 2016, i cannot update the text of the default tile “Active Directory”. have you the same issue ?

    1. Not aware of that one. Please post a message here: the community will look into it 🙂

  4. Michel Zehnder says:

    And by “very soon” you mean it’s not fixed yet after 2 months 🙂
    Well done, Microsoft!

  5. Thomas Roper says:

    I can confirm this issue is now resolved by installing KB3201845.

    Many Thanks

  6. Brian Walsh says:

    Turns out that Microsoft pulled the update 3201845 on December 12th, mentioned as resolving this issue on December 9th.

    3206632 was released on December 13th, and this page:
    says that it replaces 3201845

Skip to main content