Given that so many SBS services are tied to IIS, learning to quickly diagnose and resolve IIS problems will help keep you in the good graces of system users. This section covers several commonly encountered IIS problems and solutions, plus additional steps to help you get the information you need from your users to determine the real source of the problem. This chapter makes no attempt to be a definitive troubleshooting guide for all IIS issues that can arise, but it focuses on items that are either critical to SBS or are commonly found in an SBS environment.
Anatomy of an Error Page
Even though users may not realize it at first, the error page displayed by a web browser when problems are encountered accessing a website contains a wealth of information that can indicate to the system administrator where the source of the problem may be. Unfortunately, each of these error pages looks similar (lots of tiny black text on a white background), so after a while they generally gloss over the information presented and just try again later. When they do finally call in to report the problem, the call is generally phrased as "the Internet is down." Fortunately, you can ask them to read a couple of small lines to get you to the source of the error.
The typical IE error page is divided into three or more basic sections. The top section contains the basic error message"The page cannot be found" or "Service unavailable" or "Bad request"and may have a more detailed description of what the error means. The next section usually contains several options for the user to try and get around the error. The third section generally gives more technical information, or at least an attempt at it, to help better identify the problem.
Figure 6.17 shows a typical "page not found" error that a user may encounter. The middle section of the page lists an HTTP 404 error, which generally indicates that a URL has been incorrectly typed or that a section of the website has become unavailable.
Figure 6.17. "Page cannot be found" error showing a 404 HTTP error.
Figure 6.18 shows a seemingly similar "page not found" error, but this time the page lists an HTTP 400 error instead of a 404 error. This generally indicates that the URL is correct, but there is a problem with the web service. In this example, this error results from the Default Web Site being stopped in IIS.
Figure 6.18. "Page cannot be found" error showing a HTTP 400 error.
The Service Unavailable error in a web browser is pretty straightforward, both from the error page displayed and the troubleshooting steps to resolve it. When a user encounters a Service Unavailable error, that is literally the only information contained on the error page. There are no HTTP codes, no explanatory text, nothing. Only the words "Service Unavailable" in bold at the top of the window.
The key to resolving Service Unavailable errors is finding out what the user was attempting to access. If the user was accessing the Remote Web Workplace interface or one of the other SBS services, such as the Connect Computer Wizard or the ClientHelp directory, the first place to look is the application pools in IIS. If the DefaultAppPool is stopped, the Remote Web Workplace interface generates this error, as well the Backup and Monitoring modules in the Server Management Console. In many cases, the application pool can be started again, and services will be restored. You will still want to review the events listed in both the Application Log and the System Log to determine why the application pool stopped in the first place, if it was not stopped manually.
Service Unavailable errors can also appear related to OWA. When a user gets a Service Unavailable error when trying to access his email or the Exchange Public Folders, there are two places to check. First, check in the Application Pools folder in IIS to see whether the ExchangeApplicationPool is started. If not, starting the application pool should restore access to the OWA interface. If it is started, next check the status of all the Exchange services. See Chapter 12, "Exchange Management," for additional Exchange troubleshooting information.
One common problem that can affect the OWA interface is when some or all of the Exchange virtual directories are removed from the Default Web Site configuration. Although those directories can be re-created manually if you have a known good server configuration to compare against, but this can be a tedious process because it involves more than just changes to IIS to get it back up and working again. Microsoft has a KB article (KB888033, http://support.microsoft.com/?id=888033) that details a way to have IIS rebuild all the Exchange virtual directories automatically.
When looking for the cause of Service Unavailable errors, you may open the IIS Management Console and find that all the application pools are stopped, and you may see a red X in the Web Sites icon. This indicates that the World Wide Web Publishing service is stopped and access should be restored after the service is started. Again, a look at the event logs is warranted when this core service is not running to help determine what might be the cause of the service failure.
IP Address Restrictions
Occasionally you may encounter the "You are not authorized to view this page" error, as shown in Figure 6.19. Looking for the HTTP error code, Figure 6.19 shows a 403.6 error, indicating that the IP address of the workstation accessing the page has been rejected. This error is most often seen when attempting to access the Connect Computer Wizard from a nonlocal domain.
Figure 6.19. The 403.6 error indicates that the workstation IP is not in the allowed range for the site or page.
By default, the Connect to the Internet Wizard sets the IP address restrictions on the ConnectComputer virtual directory in IIS to be the local subnet for the internal NIC of the server. This prevents users from attempting to join workstations to the domain from across the Internet. It also prevents workstations on a different internal but routed network from accessing the page. But the most common cause of this error is if the IP address of the internal NIC on the server is changed without using the Change Server IP Address Wizard. That wizard not only changes the IP address on the NIC but also changes the IIS IP address restrictions for the Connect Computer Wizard, the DHCP scope, and a number of other places where the IP address is specified.
The issue is easy to troubleshoot. Open the properties of the website or virtual directory in the IIS Management Console and look at the IP address restrictions on the Directory Security tab. In the case of the connectComputer virtual directory, shown in Figure 6.20, you see the Denied Access radio button selected and the local subnet as well as 127.0.0.1 listed in the exceptions list. If the subnet does not match the internal NIC, you need to run the Change Server IP Address Wizard and then run the Connect to the Internet Wizard. Alternatively, if you want to restrict access to certain address ranges for other virtual directories, you can add those addresses or address ranges in this dialog box.
Figure 6.20. The ConnectComputer virtual directory restricts access to the localhost adapter and machines on the internal IP subnet.