W2K3 SP1 IIS6 Service Unavailable NOT fixed with latest patch

I just got hit with this today, and a bit of googling shows that lots of folks have been running into problems with IIS6 application pools after installing SP1. My lab box is a W2K3 domain controller.

While I've been running SP1 for awhile in the lab, my app pools were running as Network Service and everything was swell. But when I switched to a custom user account, I started seeing some incredibly odd behavior.

First of all, the user account has all the right privileges - it's a member of IIS_WPG, for example. And running FILEMON shows no problems accessing files.

When the AppPool first starts up, keeping a close watch on TaskManager, I can see W3WP.EXE start up, but the user name says which is really odd. And get this - if the user account was recently created, looking at Active Directory shows that the account has *never*  been logged in. IOW, W3WP.EXE is being launched, then its dentity is being changed to the custom identity (maybe that's how IIS works, but it sure feels odd).

Looking at the security event log (I log both success and failed logon events) shows nothing. It doesn't appear as though any attempt is being made to log in the custom user (and later scouring the user account with ADSIEDIT shows that it's never been logged on). The SYSTEM event log shows about five attempts to start the application pool, then the pool is disabled (I'm sure you've seen this before). This is the typical thing you see when you get the dreaded “Service Unavailable“ error. Tip for those new to this - you need to manually restart the application pool once you get this error - refresh the Application Pools folder in IIS manager and you'll see which pools are disabled -  you need to right-click the disabled pool and choose “start“ to reenable it, otherwise you'll continue to get “Service Unavailable“ even if you've fixed the underlying problem.

The user accounts I'm using are initially created using System.DirectoryServices. I will post the steps I'm taking to create these accounts at the end of this entry. Get this - if I use the AD Users & Groups snapin to create the user instead of my own code, the IIS application pool runs just fine. I can also call net user /add to add the user (and then add it to the IIS_WPG group), and that also works just fine.

I compared the programmatically-created user account with the snapin-created account using ADSIEDIT, and only found one very small difference - an esoteric hidden flag on the account (ADS_UF_PASSWD_NOTREQD) was set on the account I created in code, but not in the snapin-created account. So I tweaked my code to turn off this switch, created a new account, and I'm still having the same problem.

As I'm writing this blog entry, I'm also installing the October security patches for W2K3 (there are oh, about 8 of them). I'm hoping that one of these patches will fix the problem.

UPDATE: After letting the bits in my VPC cool a bit after installing the patches, sure enough, the problem reappeared. And now it's not just with my programmatically created user accounts - it's happening even with user accounts I create via AD Users & Groups. Looks like it's back to the googleboard for me :(

AND SURE ENOUGH... after installing the latest security patches (just came out this week on MS Update), the problem appears to be fixed.

Well, I hope this helps somebody - writing this post gave me something to do while the new patches installed, I guess. I'll update this post if I find that I'm just hallucinating, but it does indeed look as though the problem is fixed now.