Having non-static machine keys when hosting on IIS is just one of those things that’s just bound to cause trouble eventually. This holds true equally for single server hosting environments and load balanced web farm environments. Especially if your goal is to shield your users from any knowledge of IIS lifecycle activities (e.g. application pool recycles), the use of static machine keys is to be strongly recommended. The implications of static versus dynamic keys are enumerated for several different hosting situations below:

Virtue of Static IIS Machine Keys

  • Single Machine – Most of the recommendations around machine keys involve synchronizing machine keys across multiple machines. There is, however, value in setting static machine keys for a single machine, single worker process environment. Quite simply, if machine keys are not static, the generation of a dynamic machine key for an IIS reboot or application pool recycle will cause any machine key related elements (e.g. view state) rendered before the event to be invalid. This will likely result in exceptions that will impact normal user processing.
  • Single Machine / Web Garden – The introduction of the Web Garden option to IIS can be viewed as the “poor man’s load balancing”. This option provides for a simple round robin routing across multiple worker processes, usually with each process owing affinity to a particular processor. Due to the simple load balancing approach taken, there is no option for web gardens but to synchronize machine keys. This is of course, unless you’ve managed to make your application completely stateless, in which case (congratulations) none of this advice applies to you.
  • Multiple Machines / Web Farms – The applicability of static machine keys to a web farm environment applies, theoretically, only to web gardens in which the load balancing approach does not guarantee server affinity. Once again, to avoid impacting user processing during load balance machine failover or due to recycles or reboots, I’d always recommend using static machine keys. Even when these areas are not concerns, I’ve found other troubles just seem to arise when you can’t guarantee static machine keys across machines. For web events regarding cryptographic exceptions or viewstate verification issues, I’ve found it best to start troubleshooting with synchronizing machine keys and then working down from there.

The definitive guide to configuring machine keys in ASP.NET 2.0, including .NET code for generating the keys, can be found here. Microsoft has never revisited their ruling that machine key issues can arise outside of web farms. Once again, if you’re observing cryptographic or viewstate errors, I’d advise that you start with static machine keys. If compiling and running Microsoft’s code to generate a machine key is asking too much, this online program will generate a key for you.

Finally, I’ve been asked a couple of times about the downsides of sharing static machine keys across machines. This depends upon what you use the machine key for. In most cases, I wouldn’t advise that you use the machine key for anything more than viewstate encoding. In this case, a machine key compromise will mean that someone can theoretically hack your viewstate. If they got your machine key, it also means that they have access to your web.config file, in which case you usually have bigger concerns than viewstate hacking.

Leave a Reply