While performing the install I ran into issues I had not seen before and found solutions that may not be as obvious as they seem on your first read through of the article.
Issue One
First. Having the wrong Operating System makes the process of Federation that much harder. The OS I started with was Windows 2012. This leaves us with ADFS 2.1. My design was for Windows 2012 R2 and ADFS 3.0. The OS version was not noticed until ADFS was installed on both internal ADFS servers. Once this was corrected and the servers we were working with were Windows 2012 R2, a new ADFS install was begun. Added the Role and began the configuration of the role on the server. Selected the user in AD, added the certificate, etc. Then when the configure button was pressed, an error popped up on the screen:

Eh? Well (and no consultant ever says this….) I’ve never seen that error before in an ADFS install. So you research the error…. What is Cryptographic Next Generation (CNG)? CNG allows for the use of a newer suite of public key providers that are unsupported in ADFS 3.0. Why would this certificate be any different from previous ones I’ve used. We called up the CA provider (Comodo) and they confirmed that they have no way to issue a certificate with a Legacy Private Key. Well, that did not help. We had them revoke the certificate and requested a new one. Then on the same server, we completed the process once we had the new certificate. After installing the new certificate, I exported it with the private key.

The ADFS install went flawless this time. What? Same provider and same process to request the certificate… except it wasn’t. During the rebuild of the server, we had not exported the certificate and only had what was originally provided for by the vendor…. So the moral of the story and the solution to this issue is simple:
- On one server, request the certificate, complete the request and THEN export the certificate.
- Save the files to secure location OFF the originating server to be referenced by other nodes.
That’s it.
Issue Two
During some trial and error in the install, a Windows Internal Database (WID) is installed on the Windows 2012 R2 server. This is used by the Federation service for many internal functions. However, what we fund out is that when we had certificate issues, we also generated issues with the WID upon trying to configure the ADFS server. The configuration wizard will attempt to install WID and if WID is present, it tries to configure the WID for ADFS. Unfortunately the botched install (because of the CNG certificate error) left the WID in a strange state.
To correct the issue, I uninstalled ADFS, reinstalled ADFS and attempted a new configuration. Again an error with the WID. The problem was that the WID was not being uninstalled with the uninstall process for ADFS. I then uninstalled ADFS and WID. Rebooted the server as required and then attempted to reinstall ADFS. Same results. Again, the uninstall process left much to be desired. The WID uninstall had left behind files in the Windows\WID directory.
Uninstall WID. Uninstall ADFS. Reboot. Rename WID directory. Install ADFS. Configure ADFS with the new certificate and !?! it worked.
So the solution here is if you need to redo ADFS, remove it and the WID, reboot, rename WID directory and reinstall.
Further Reading
How To Install ADFS 2012 R2 For Office 365
ADFS Configuration Wizard Fails with Error “The certificates with the CNG private key are not supported”
Relaying Trust
Hi, i have the same problem with the uninstall and install of the wid, but, it occurs after every patchday and only in our test enviroment. Do you have a clue, why this hapens?
Off the top of my head, no. What version of ADFS?