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.
To verify that IIS is running, I typically enter http://127.0.0.1 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
Control Panel / Administrative Tools / Internet Services ManagerThis program should allow you
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 http://127.0.0.1 should work.
Control Panel / Administrative Tools / ServicesThe following are important for IIS and sometimes disabled by security patches. I have included names for both 2000 and XP.
|IIS Admin Service
|This is the primary service for using IIS
|World Wide Web Publishing Service
|This actually displays web pages
|World Wide Web Publishing
|FTP Publishing Service
|Transfer files from one machine to another
|Simple Mail Transport Protocol (SMTP)
|Send mail to another server
|Simple Mail Transfer Protocol (SMTP)
Restarting a Disabled Service
Normally, to start a service, you right click the service and select Start. Unfortunately, Start is grayed out when the service is disabled. Instead,
(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.
You are not authorized to view this page
For anonymous access, the following 2 accounts need access to your system
|Internet Guest Account
|Launch IIS Process Account
Control Panel / Administrative Tools / Local Security Policy / Local Policies / User Rights Assignment Deny access to this computer from the network .... Guests
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
Locate your web directories
default - C:\Inetpub\wwwrootRight 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.)