Databases - Repairing IIS

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 -

Everything was working fine yesterday
Today, nothing works
Nothing on the system changed ... except Microsoft applied a few patches

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 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 Manager

This program should allow you

To stop and start various parts of IIS
To configure a default web page

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 http://127.0.0.1 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

Control Panel / Administrative Tools / Services

The following are important for IIS and sometimes disabled by security patches. I have included names for both 2000 and XP.

OS	Service Name	exe	Comment
2000	IIS Admin Service	inetinfo.exe	This is the primary service for using IIS
XP	IIS Admin	inetinfo.exe	This is the primary service for using IIS
2000	World Wide Web Publishing Service	inetinfo.exe	This actually displays web pages
XP	World Wide Web Publishing	inetinfo.exe	This actually displays web pages
2000	FTP Publishing Service	inetinfo.exe	Transfer files from one machine to another
XP		inetinfo.exe	Transfer files from one machine to another
2000	Simple Mail Transport Protocol (SMTP)	inetinfo.exe	Send mail to another server
XP	Simple Mail Transfer Protocol (SMTP)	inetinfo.exe	Send mail to another server

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,

Right click
Select Properties
Change Startup type to Automatic
Press the Apply button
Press the Start button (grayed out until Apply was pressed)

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

You are not authorized to view this page

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

ComputerName\IUSR_ComputerName	Internet Guest Account
ComputerName\IWAM_ComputerName	Launch IIS Process Account

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.

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

Remove both accounts from the guests group

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

default - C:\Inetpub\wwwroot

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.

Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Delete
Change Permissions
Take Ownership

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 - clemenzi@cpcug.org