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:
- 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.