Under x64 Windows certain paths are designated as 64-bit paths, and a 32-bit process, like Visual Studio, is being redirected by Windows to the 32-bit path at C:\windows\SysWOW64 whenever C:\windows\system32 is referenced. The 32-bit process thinks it is looking at C:\windows\system32\inetsrv\config when it has been given C:\windows\SysWOW64\inetsrv\config; which indeed contain none of those configuration files we are after.
To solve (credit to Robert McMurray):
Open a 64-bit command prompt and execute the following commands:
cd /d "%systemdrive%\windows\syswow64\inetsrv"
move config configx86
MKLINK /d Config "%systemdrive%\windows\system32\inetsrv\Config"
It should report
symbolic link created for Config <<===>> C:\windows\system32\inetsrv\Config
This effectively renames the 32-bit config directory so a symbolic link of that name can take its place to redirect back to the 64-bit path which we are really interested in.
If you just need a copy of the content of that file (for Windows Vista), I copied the XML text from a clean Vista installation and put a ZIP file you can download here. I guess you'll have to stop the IIS service before you access the file.
No, changing the file itself doesn't cause an AppDomain recycle like editing web.config or machine.config does.
However, some settings, like application pool defaults, global settings or http modules will cause an AppDomain recycle.
Just adding settings in location tags to the bottom or doing general settings won't cause an AppDomain recycle. All site specific changes will, at the most, impact the one site only.
Best Answer
Paraphrased from icelava.net forums:
Under x64 Windows certain paths are designated as 64-bit paths, and a 32-bit process, like Visual Studio, is being redirected by Windows to the 32-bit path at C:\windows\SysWOW64 whenever C:\windows\system32 is referenced. The 32-bit process thinks it is looking at C:\windows\system32\inetsrv\config when it has been given C:\windows\SysWOW64\inetsrv\config; which indeed contain none of those configuration files we are after.
To solve (credit to Robert McMurray):
Open a 64-bit command prompt and execute the following commands:
It should report
This effectively renames the 32-bit config directory so a symbolic link of that name can take its place to redirect back to the 64-bit path which we are really interested in.