Sunday, April 24, 2016

CRM and IIS Machine Keys

When you have multiple CRM web (front-end) servers splitting the load, requests can bounce between servers or they can be set to remain on the same server through the NLB/Firewall settings. The latter option is commonly referred to as “Sticky Sessions” or “Persistence”.

If requests bounce between servers (whether by design or by fault), you may notice issues when accessing certain functionality within CRM. Often it will be accompanied by the following error message in the event viewer:

Event code: 3012 
Event message: An error occurred processing a web or script resource request. The resource identifier failed to decrypt. 

Exception information: 
    Exception type: HttpException 
    Exception message: Unable to validate data.
   at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType, Boolean signData)
   at System.Web.UI.Page.DecryptString(String s, Purpose purpose)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContextBase context, VirtualFileReader fileReader, Action`2 logAction, Boolean validatePath)

Basically what is happening is one server encrypted (validated) some of the traffic with an automatically generated key and another server received it but cannot decrypt it because it has different keys. These keys are known as “machine keys” and are found within IIS. By default, these keys are all set to generate automatically and no two are the same. When you are using multiple web servers, the machine keys need to be set statically and shared amongst them. Here is how to do this, starting on the first web server:

  1. Open IIS, select the Microsoft Dynamics CRM Website, and double-click “Machine Key”

  2. Uncheck the “Automatically generate at runtime” and “Generate a unique key for each application” boxes under both “Validation Key” and “Decryption Key”.

  3. Click “Generate Keys” on the right side of the screen.

  4. This will create new, random keys.

  5. Click apply.

  6. From here, repeat steps 1 and 2 on the remaining web servers. Instead of generating new keys as in step 3, copy and paste the keys generated from earlier into the remaining servers so that all servers have the same set of keys.
  7. Once keys on all servers are set and applied, reset IIS on all the boxes. That should do it.

5 comments:

  1. Thanks for this - very helpful

    ReplyDelete
  2. Hi,
    This is very interesting and the same error that we are seeing on our server. What confuses me, is that we are not using split load, and everything is run on a single server at this point in time.
    Can you see any reason why we would still be seeing this error?
    Many thanks

    ReplyDelete
    Replies
    1. Hmmm... do you have the Machine Keys set in IIS at all on the server or are they just being generated at runtime? Just curious - is that happening with Dynamics CRM or a different application running on ASP.net?

      Delete
    2. Gage,

      Thanks for getting back to me, apologies that I have taken a while to respond.
      I just checked the settings for the MachineKeys and they are all (both validation and encryption) set to be automatically generated at runtime, and to generate a unique key for each Application.
      We are not using the Dynamics CRM, just a proprietary app running on asp.net
      i'm just wondering if somehow we are running multiple instances and the same app and that is causing the problem?
      I guess I could turn of the 'unique for each app' option, or simply force it to use statically assigned key anyway, and see if that fixes it.

      once again many thanks for your input.

      Delete
  3. Those guidelines additionally worked to become a good way to recognize that other people online have the identical fervor like mine to grasp great deal more around this condition.
    Best CRM System

    ReplyDelete