Repairing IIS

Configuring and running IIS is a continuous hassle - not because of any problems with IIS, but because of other issues. The worst other is a security update - There is nothing worse than uncontrolled software updates "to protect you" (more like - to sabotage your system). Updates that change system settings and stop things from working are, in my opinion, worse than viruses (at least with viruses, there is software to remove the pest).

Unfortunately, the exact steps to repair this monster depend on the operating system and IIS version - hopefully, the instructions below are close enough that you can figure out the rest.

Testing IIS | Required Services | Restarting a Disabled Service | File Permissions

Testing IIS

To verify that IIS is running, I typically enter in a browser's address. If everything is ok, then the default web page is displayed.

I originally started this page because this simple test quit working - it had been working for over a year, and then, one day it didn't. What I discovered was that the 2 required services had been disabled. Since I do not know exactly how that happened, I am assuming a Windows update did it ... but it is possible that the company I work for pushed some kind of security update.

To debug and fix IIS problems, launch the IIS management program via

This program should allow you In my case, it was immediately obvious that none of the features could be started. After a few hours, I discovered that the services that implement IIS were disabled.

If IIS is not able to connect to any computer, then start IIS Admin Service.

If the Default Web Site is Stopped, right click and try to start it. If that fails, then start World Wide Web Publishing Service and try again.

Once both services are running (and IIS is properly configured), then should work.

Required Services

Under Windows, a service is a program that loads when the computer boots. The services available to your system are visible via The following are important for IIS and sometimes disabled by security patches. I have included names for both 2000 and XP. Notice that inetinfo.exe implements all of these services. On my system, these were all disabled.

Restarting a Disabled Service

On my system, all of the services listed above were disabled - though I believe the both FTP and SMTP had always been disabled (since I never used them).

Normally, to start a service, you right click the service and select Start. Unfortunately, Start is grayed out when the service is disabled. Instead,

Note: Once the Startup type is Automatic, you can also right click the service to start it.

(Hey, if this was obvious to me - I wouldn't bother writing this page!)

After setting both IIS Admin and World Wide Web Publishing to Automatic, and starting them, they are both automatically reset to disabled within about a day. And this is without rebooting the system.

File Permissions

Once I got IIS running locally, I tried to access it from another system ... of course, it prompted me for a user ID and password. When I canceled the dialog box, the browser displayed

For anonymous access, the following 2 accounts need access to your system

On most systems, both accounts are members of the guests group. On my system, the IP Security Policy (pushed via the domain controller) denied this group network access to the computer.

The "working" system I used to debug this denied network access from only the guest account, not the guests group. (Notice the 's')

This fix (kludge) worked

Security Issue

If you stop there, your system will be open to various security problems. Please be sure to lock down the write / modify permissions. (This is very important - this was missing on my system.)

Locate your web directories

Right click and check the security settings - on the security tab, click Advanced, then select each account and press Edit (or View/Edit - system dependent). Both accounts should deny access to the following permissions for This folder, subfolders and files.

It is interesting that it is not necessary to explicitly allow any permissions. Therefore, I assume that either the Users or System group defines the allowed permissions,

Testing Remote Access

In order to back these changes out (for test purposes), you must restart IIS. After adding both accounts back to the guests group (and restarting IIS), I was able to verify that users logged onto the domain had access ... only systems with local logons were denied. I wasn't able to verify it, but it appears that logged on users have way too many permissions ... none of the 7 permissions (shown above) appear to be denied. Thus, in my opinion, by "locking down" the system, the security people actually made the system more vulnerable. (Please let me know if this is not true.)

Author: Robert Clemenzi -
URL: http:// / user / clemenzi / technical / Databases / IIS / Repairing_IIS.html