Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We just migrated our old Windows 2003 server to Windows 2008 64-bit, so we are trying to get used to the newer IIS.

We have a lot of changes to make concerning things like MIME types, etc and figured that these changes would go a lot quicker if we were to just edit a config file rather than using the IIS manager.

However, we have found two paths for config files:

%WinDir%\System32\Inetsrv\Config\applicationHost.config %WinDir%\SysWOW64\inetsrv\Config\applicationHost.config

Since we are on 64-bit, I would assume we need to be editing the one under the SysWOW64 folder. However, we have been editing settings in IIS all night, yet both files are showing a modification date as of only a few minutes ago...

So, am wondering which one we need to be messing with... And, when we do, does IIS automatically pick up on the changes when we save or do we need to do something in the manager to refresh the settings?


Might be worth mentioning: we use this server to run Coldfusion 9, and aside from a few sites with static HTML that we host, everything runs Coldfusion.


Looked into this, and it appears that I was reading the timestamps on the files wrong. It looks like when I make changes in IIS, the System32 file is altered, and the SysWOW64 is not touched. However, this is weird because the SysWOW64 file was modified last night at 10:44PM, so I can assume this was being used (we started work way before then)? At around 10:45PM last night, I did make a command line call to "iisreset", could that have messed something up?

Something else to note: the app pool our sites are in is set to ASP.NET 2.0, in case that has some sort of affect (maybe need to switch these to 4.0).

share|improve this question
Just to clarify, System32 is actually where 64-bit related files live. SysWOW64 is where the 32-bit related files live. Yes, it's confusing. Blame Microsoft. – Ryan Bolger Jul 3 '12 at 19:57
up vote 1 down vote accepted

What this turned out to be was that, for some reason, we needed to use a 64-bit text editor to edit this config file. This is the first time I have ever ran into this (I use a 32-bit app, Notepad++, to edit text files on a 64-bit system), but this is some kind of "special case" for these IIS config files.

The actual location we should be editing also turned out to be %WinDir%\System32\Inetsrv\Config\applicationHost.config.

I do not know why we have to use a 64-bit app for this file, but I do know that using on fixed our problem. We ended up using Notepad2, as it was the only thing we could really find that was 64-bit; it's been working pretty well though.

share|improve this answer

By default the 64-bit OS will run the app pool in 64-bit mode, but IIS7 can also run 32-bit app pools. I believe that is why you have the two files.

This answer has more detail.

Under a 64 bit OS, a .NET application can either run on a 32 bit CLR in WOW64 mode or natively run under x64 mode. Each .NET framework instance has its own set of config files and ignores all other configuration files.

Check the enable32BitAppOnWin64 attribute to determine if the app pool is running in 32 or 64-bit mode.

share|improve this answer
while i guess comes bundled inm i forgot to mention, we aren't really using it (we run Coldfusion). would this still have an effect on this? – jzimmerman2011 Jul 3 '12 at 15:56
Yes, this applies to IIS and not any particular platform. See this post for more info on app pools and Cold Fusion, it contains some good advice that you'll likely find relevant: – Somantra Jul 3 '12 at 16:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.