64 bit IIS manager,32 bit worker process and root web.config settings

The IIS 7 manager provides a UI for almost all sections for the web.config. It does simplify things for administrators but I have seen a couple of cases where this has lead to interesting problems.

Let us consider the Machine Key feature that the IIS 7 manager provides. It is well known that when you deploy your web application across a web farm you have to hard-code the machineKey section of the web.config on all servers so that they carry the same keys that are used for encryption/decryption. The IIS 7 manager also has a useful option to generate random keys.

If the keys are not synchronized across all the web servers you can expect authentication or viewstate issues. One of our customers was well aware of this and had hardcoded the machineKeys using the IIS 7 manager. Yet he was facing all the issues related to the machineKeys not being in sync’.

After a lot of troubleshooting the issue came down to the bitness of the worker process.

Here is what was going on. The customer had set the machine keys at the root level in the IIS manager on all of the servers in the farm. When you do that IIS usually makes the changes to the root web.config file (the one in the framework folder). The status bar in the IIS manager will show you the config file location that will get updated. In the screenshot below, it says Configuration: ‘localhost’ root web.config indicating the web.config in the framework folder. If you check the properties at the website level the values are inherited from the root web.config.

 

Why does the bitness of the worker process matter ?

The IIS manager is a 64 bit process and when it has to modify the root web.config it edits the web.config in the x64 framework folder. If it has to pick a value from the root web.config it will also look for the one in the x64 bit folder.

Suppose you have a web application that needs to run in 32 bit. You would need to set “Enable 32-bit applications” to true. When this worker process starts up it will read values from the web.config in the x86 framework folder and not reference the web.config in the x64 framework folder. IIS manager on the other hand is reading the values from the web.config in the x64 folder.

So you can run into a situation where the IIS manager (reading values from the x64 folder) will show that you have changed certain web.config values but the worker process would not be honoring those values because it is a 32 bit process and reading those values form the web.config in the x86 framework folder.

This issue is not limited to just the machineKey section but any attribute that gets modified in the root web.config.

It is always a good practice to keep an eye on the status bar of the IIS manager while making changes… It will tell you the location of the config file that IIS is modifying.

Comments

• Anonymous
  December 16, 2009
  Thanks for the post! It helped me solve an out-of-sync problem caused by editing the wrong machine.config. I edited the one under the 'Framework' folder, and couldn't figure out why I still had problems until your post alerted me to the existence of the 'Framework64' folder. Perhaps you can clear up the relationship between the root web.config and machine.config. As I said, I edited machine.config and my keys show up in the IIS 7 Manager UI, only it says they are coming from the root web.config, as in your screenshot. Thanks again!

• Anonymous
  April 02, 2010
  Can anyone speak to whether or not the machineKey settings should be in the machine.config in both branches, Framework and Framework64?