In the
Academy's .NET classes, we usually create a separate application pool and run the web site under account that has access to MS SQL database. There are a few caveats to get it all running and I am so used to them that it takes a few seconds for me to resolve that kind problems.
Today I had a problem that was new to me.
After creating the new pool, adding the user to the IIS_WPG group and accessing a page for the first time I got the error
“Service Unavailable”. Typically the reason that you will get this error message is when you forget to add the application pool user to IIS_WPG group as described in
KB 823552. You may also get this error message when you have incorrectly entered the account password in the Identity tab of Application pool properties, or when the account is disabled or require password change.
There is another catch if you use a blank password for the account as described in
this post in MSDN Forums.
Since none of these resolved my problem, I opened the Event Viewer and saw event log warnings like the one below:
A process serving application pool 'SQLAppPool' terminated unexpectedly. The process id was '4048'. The process exit code was '0xffffffff'.Surprisingly this warning was repeated few times before the pool is actually disabled. Usually when there is a problem with the account identity, you will only get this error once. So I tried to watch out for access denied messages in the indispensable
Sysinternals File Monitor and for Failure Audit event log messages, but they did not show anything.
It turns out that
Keith Brown also
blogged about this Service Unavailable problem more than a year before but I did not find resolution there.
So I decided to check out the permissions in IIS metabase using the
Metabase Explorer tool in IIS 6.0 Resource Kit. IIS Metabase is the configuration store of IIS and you should not touch anything there unless you are pretty sure what you are doing. A lot of IIS configuration options that are not shown in the IIS Manager UI, are stored in the metabase and most important – the permissions that each account has to an option. I compared current permissions on my web server with the default ACL list as described in
KB 326902. It turns out that IIS_WPG group was not resolved properly as a security object so I reapplied the security permissions for IIS_WPG and run iisreset.exe to restart the IIS.
Volla! The web site was up and running again.
Labels: Tools and Tips
# posted by Martin Kulov @ 12:22 PM
