IIS configuration problems with Search Server Express 2010
After Search Server Express 2010 was released yesterday as part of the global SharePoint 2010 launch, I decided to switch the small standalone deployment I use from its predecessor, Search Sever Express 2008, to the new 2010 version. Since I only had a very small deployment, and I wanted some experience of a fresh install for a later SharePoint 2010 deployment, I decided against an upgrade. I backed up the data I needed to keep, uninstalled the old version, and installed the new.
Unfortunately, I ran into a problem almost immediately. After running the configuration tool at the end of setup and trying to load the site for the first time, I was greeted with the spartan and uninformative message, “HTTP Error 503. The service is unavailable.” A quick check of the event logs on the server in question revealed the following cryptic message:
Log Name: System
Date: 13/05/2010 14:15:47
Event ID: 5139
Task Category: None
A listener channel for protocol 'HTTP' in worker process '5116' serving application pool 'SharePoint - 80' reported a listener channel failure. The data field contains the error number.
The error number in this case was 800700C1 (“Not a valid Win32 application”). Searching online for that code very quickly led me to an archived IIS newsgroup post here, and to the circumstances at the root of my problem.
It came down to the particular configuration I was running:
- The server in question is running Windows Server 2008 R2, which is 64-bit.
- Search Server Express 2010 also only comes in 64-bit flavour.
- My old Search Server 2008 install was 32-bit (I have no idea why I didn’t go 64-bit last time).
Unfortunately, the uninstaller for 2008 had left its 32-bit Application Pools lying around in IIS. The installer for 2010 found those pools, saw they were the same names as the ones it wanted, and reused them. This meant IIS was trying to run a 64-bit application in a 32-bit pool; hence, “not a valid Win32 application”.
The solution was simple: in the IIS Manager console on the server, right-click each of the relevant Application Pools (in my case SecurityTokenServiceApplicationPool, SharePoint – 80, SharePoint Central Administration v4, and SharePoint Web Services Root, and a couple if pools with only GUIDs for names), click Advanced Settings, and set Enable 32-bit Applications to False, as shown below.
Note that the other settings here may not match yours, so don’t try to duplicate them. Only the 32-bit setting is pertinent.
In short, my ‘fresh install’ wasn’t as fresh as I’d hoped. I’m not sure whether I would see the same problem if I had done an upgrade, but I almost certainly wouldn’t have seen it on a truly fresh server. In any case, it’s one more thing to watch out for in future.
UPDATE: Edited to add SecurityTokenServiceApplicationPool to the list of Application Pools.