Here's an interesting note about Windows 2008 running in 64 bit. Today I needed to edit ApplicationHost.config only to not find the damn file anywhere on my machine. It turns out 64 bit Windows uses redirection in the System32 folder and while running with a 32 bit Explorer replacement and a 32 bit editor I was unable to find the file until I switched to the stock tools in Windows which are 64 bit.

This bit me because I needed to make some changes in applicationhost.config. ApplicationHost.config is IIS 7's master configuration file that holds top level configuration settings. In it you can find things like Application Pool and Virtual directory definitions as well as most of the default root level configuration settings for IIS and ASP.NET.

What I wanted to do is change the IIS GZIP compression settings as well as lock down the UrlScan rules to lock out some unwanted DOS style attacks that seem to be plaguing a lot of sites over the last few days. Anyway I needed to open ApplicationHost.config on my newly buffed up Windows 2008 64 bit Server. And this is where it gets weird.

ApplicationHost.config should live in:

c:\windows\system32\inetsvr\config\applicationhost.config

So I navigated there and found - nothing. An empty folder with no files.

I'm running xPlorer2 as my Windows Explorer replacement interface and I installed it on the server as well to facilitate the lengthy process of copying files onto the new machine from the old Web Server. xPlorer2 rocks and beats the crap out of Windows Explorer (no big feat), but it's 32 bit application. One very nice feature of xPlorer2 is that it also has a quick deep search feature so I fired that off to search the entire boot drive for ApplicationHost.config. However, I came up with only history files and one version in some obscure amd64 related folder (most likely from an install path).

In short the freaking file I'm looking for was nowhere to be found on the system! So I searched around and ran into this IIS forums post that talks about a similar problem:

http://forums.iis.net/p/1150832/1875622.aspx

Basically it turns out that when you are running a 32 bit application you cannot see certain files in the 64 bit system32 folder - ApplcationHost.config among them. Files may be split between the system32 folder and system32Since xPlorer2 is 32 bit I get this (contrasted below with classic Explorer which does show the files):

The top app is xPlorer2 the bottom standard old Explorer. Notice that same folder in xPlorer2 above is empty while in classic Explorer the files show. But the issue is not just that files don't 'list' in a directory listing, but they are literally not accessible to 32 bit applications. The machine also has Visual Studio Tools for Applications installed, which is an editor - installed likely with SQL 2008 and meant for editing configuration files. It's essentially just the VS editor that does syntax highlighting (notice the Visual Studio Icon next to the Open button in the Explorer Window).

But it fails to open ApplicationHost.Config because it's a 32 bit app:

My favorite editor - EditPad - that is the default text editor in my configuration also doesn't work for the same reason. In the end, the only way I could actually edit ApplicationHost.config is with Notepad... Oh joy <g>.

I mentioned that I'm new to 64 bit, with this installation on the server being the first and this - this is really something I had no idea about. This is whacky to the max and heck it doesn't even make any sense. I did some searching around trying to find more information on this topic and it looks like there's very little info on this issue or at least it's not easy to find (here is one and another). Both of these describe the x64 FileSystem Redirector which basically routes DLL access to 32 bit or 64 bit specific directories. I suspect what's happening is that even other files are being redirected so trying to access applicationhost.config looks in C:\Windows\SysWOW64\inetsrv\Config but even there applicationhost.config is not found because well IIS is a 64 bit app and doesn't look there.

So using a 64 bit Editor and stock Explorer is the only way for the moment to get at the file. Kinda whacky, eh?