Exchange 2013 and RMS on Windows 2012 R2 getting UnsupportedCryptographicSetException error

Well, I never really considered myself an RMS guy, but I guess this month has changed things some.  After my last article, I was running through a test plan, when I came to find that the Test-IRMConfiguration was failing on one server (the entire time of this project, I had only really focused on the Exchange servers in the same datacenter.  The exact failure seen below is identical to the error you would expect to see on an older OS, or an unpatched Exchange 2010 server.  It also was documented here.  We did use Cryptographic Mode 2, but since we are on Windows 2012 R2 and Exchange 2013, the error was not expected here.  Also, the permissions that the error tells you to set are already in place.  Keep in mind that I already had two Exchange 2013 servers working correctly, just this other one didn't.

Acquiring Rights Account Certificate (RAC) and Client Licensor Certificate (CLC) ...

    - FAIL: Failed to acquire a Rights Account Certificate (RAC) and/or a Client Licensor Certificate (CLC).

This failure may cause features such as Transport Decryption, Transport Protection Rules, Journal Report Decryption, IRM in Outlook Web App, IRM in Exchange ActiveSync, and IRM Search to not work. Make sure that the Exchange Servers Group is granted "Read" and "Read & Execute" rights on the ServerCertification.asmx and Publish.asmx pipelines on your AD RMS server. For details, see "Set Permissions on the AD RMS Certification Pipeline" at  http://go.microsoft.com/fwlink/?LinkId=186951.

----------------------------------------

Microsoft.Exchange.Security.RightsManagement.RightsManagementException: Failed to acquire server box RAC from

https://adrms.contoso.com/_wmcs/certification/servercertification.asmx.

---> System.Web.Services.

Protocols.SoapException: System.Web.Services.Protocols.SoapException: Exception of type 'System.Web.Services.

Protocols.SoapException' was thrown. ---> Microsoft.DigitalRightsManagement.Cryptography.UnsupportedCryptographicSetException: Exception of type 'Microsoft.DigitalRightsManagement.Cryptography.UnsupportedCryptographicSetException' was thrown.

   --- End of inner exception stack trace ---

   at Microsoft.DigitalRightsManagement.Certification.BaseCertificationWebService.Certify(CAType caType, CertifyParams requestParameters)

   at Microsoft.DigitalRightsManagement.Certification.ServerCertificationWebService.Certify(CertifyParams requestParams)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.Net.WsAsyncProxyWrapper.EndInvoke(IAsyncResult result)

   at Microsoft.Exchange.Security.RightsManagement.SOAP.ServerCertification.ServerCertificationWS.EndCertify(IAsyncResult asyncResult)

   at Microsoft.Exchange.Security.RightsManagement.ServerCertificationWSManager.EndAcquireRac(IAsyncResult asyncResult)

Exchange server was 2013 and patched on a Windows 2012 R2 server

Resolution:
This issue was because the environment had an RMS server in the past that had been decommissioned.  The Exchange server that was failing to use RMS was doing so because it already had machine certificates.  The fix was to backup these cache files, and reboot the Exchange server, then the command passed and it rebuilt the cached files using the new RMS instance.  Of course, the old instance was Type 1 Cryptographic mode, hence the mismatch error.

1. On the impacted Exchange server, go to c:\ProgramData\Microsoft\DRM\Server (Server is a hidden folder, so you need to specify it)
2. You will see SID's like below in there.  I just moved both into a new subfolder for now.  You can see an example of the content of these folders below as well.
3. Reboot the Exchange server
4. Re-test the Test-IRMConfiguration