Well, every time I try writing some thing different than IIS and for some reason I come back to it 🙂
Here is a quick troubleshooting tip for a scenario where World Wide Web service on my test IIS 6.0 box went down for no apparent reason. Here is what I started seeing when we tried to start all IIS related services. IIS ADMIN service came up fine but I wasn’t lucky enough with WWW
From the Services console I got this error message when tried to start WWW service:
Now this was weird, I remember everything was fine just few minutes ago. I wondered how we could resolve the issue.
Event log showed the following:
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7023
Time: 6:59:50 AM
The World Wide Web Publishing Service service terminated with the following error:
Access is denied.
Now, this started making some sense. It was quite apparent that there was a permission issue. But then I was a local admin on the box and I had not changed any file permission recently, at least not in the last few minutes for sure.
I tried running Process Monitor from www.sysinternals.com. It is a handy tool to troubleshoot permission issues. Unfortunately I couldn’t see any ACCESS DENIED anywhere in the log collected via this tool. Now if there was no access denied anywhere what else could have led to such an error message!!!
I ran DebugView while reproducing the WWW startup issue.
It showed the following:
I noticed this in the above log:
Now it was clear that there were no issues as far as accessing this metabase file was concerned. Had there been a permission issue to access this file it should have been captured by the Process Monitor utility. Also since IISADMIN was up and running it was sure that metabase was fine and was accessible. I wondered if there was something within this file, maybe some key/property etc. which was giving the problem.
I went ahead with Metabase Explorer (also called as MBExplorer, part of IIS 6.0 Resource kit) and tried to read through the various hierarchy in the metabase. The moment I tried to launch MBExplorer it gave the following error:
This was getting interesting now :-). I clicked on Yes and launched the utility anyway.
While scanning through the various structures within MBExplorer I got another similar alert when I reached the following location:
I knew now that this subkey was having the permission issue for sure. However I could not even import this setting from any other machine since I could not even rename the key !!
Looked like even administrator account had no permission on this key. It could not even be inherited from its parent level using MBExplorer.
So, after some thought this is what I did. Stopped IISADMIN service and opened metabase.xml file in a notepad.
Found the section which described the Filters subkey properties as shown below:
The only way to change the ACL on this key was to remove the AdminACL attribute such that it would inherit the same from its parent level, i.e. W3SVC level in the above MBExplorer window. I deleted the above AdminACL attribute completely, saved the file and gave a restart with my fingers crossed ;-). I had a backup.
Hurray!!! this is what I got finally.
Later on, found that while playing with permissions for compression filter, accidentally the ACL permissions for Administrators and IIS_WPG was removed, and I was a member of both these two groups 🙁
Finally all that ends well is well, I am a happy man now .
Hope this helps someone stuck in a similar situation…