Administration of an IIS 7.0 Web Server • Chapter 16 847 Frequently Asked Questions Q: There seem to be differences in several tools when comparing the version that is part of Windows Vista versus the one that is part of Windows Server Codenamed “Longhorn”. How does one determine how to choose? A: This is a common question and it’s easy to address. Microsoft released Windows Vista and IIS 7.0 as a ready product for the developer audience and optimized for that scenario. The features built for administration in production environments will be part of “Longhorn” Server and Windows Vista Service Pack 1. The nice thing is that Microsoft is building the products simultaneously and will release them at identical points, thus bringing Windows Vista RTM users up to the IIS 7.0 server level. Q: Can remote administration in IIS Manager be used in Windows Vista? A: No. Unfortunately, it can’t and is only supported in “Longhorn” Server and Windows Vista Service Pack 1. Q: Can AppCmd.exe be used from client workstations connecting to IIS 7.0 servers? A: No, unfortunately it does not have any remote capabilities and is only available on the server you want to manage. To provide remote support, use WMI or MWA. Q: Why did Microsoft rebuild the WMI provider when they had one in IIS 6.0? A: The new provider provided users the ability to manage IIS 7.0 in a familiar environment (WMI) while not interfering with current scripts aimed at managing IIS 6.0. In fact, the WMI provider that is part of IIS 6.0 is completely available to be used in IIS 7.0 alongside the new provider. Q: If I am not familiar with managed code development is there any reason to learn MWA? A: No. IIS 7.0 offers a plethora of options for managing its confi guration, server objects, and runtime data for this very reason. The toolsets as a whole should have very close feature capabilities, minus IIS Manager, which obviously can’t expose everything to users and still maintain usability. This page intentionally left blank 849 Chapter 17 Solutions in this chapter: ■ Using IIS 7.0’s Custom Detailed Errors ■ Inside IIS 7.0’s Failed Request Tracing ■ Breakpoints: Extending IIS 7.0’s Tracing ■ Reality: Inside What Tracing Can’t Do in IIS 7.0 ˛ Summary ˛ Solutions Fast Track ˛ Frequently Asked Questions Troubleshooting 101: Diagnostics in IIS 7.0 850 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 Introduction No area in IIS 6.0 is more in need of improvement than diagnostics. Many users referred to IIS as a “black box” into which requests went, yet never came out. To complicate the matter further, administrators and developers were often left without any avenue to reproduce and hence correct IIS because there were no means to access request-based information at the point of failure. In contrast, it has never been so easy to detect and isolate an error than in IIS 7.0, which offers detailed error messages that outline step-by-step instructions on what to try if a request fails. In the event that the error messages don’t help, you can use IIS 7.0’s new Failed Request Tracing. This new instrumentation offers a step-by-step output as requests, one by one, enter and exit the IIS request pipeline. This detailed tracing can be enabled based on HTTP error messages or by time taken, two of the most common troubleshooting starting points. Beyond that, developers can build on IIS 7.0’s tracing to include their individual code “eventing” that allows administrators to see their status alongside IIS 7.0’s status. This makes debugging failures of IIS and custom code a reality without attaching a debugger. As great as IIS 7.0’s diagnostics are, there are still areas where it can’t help. It is important to understand these areas and ensure that you tackle them with the right tools to succeed. Using IIS 7.0’s Custom Detailed Errors IIS 6.0 and previous versions included custom yet not very detailed errors. Unlike previous versions, IIS 7.0 includes Custom Detailed Errors that offer administrators console access to the most detailed error messages, such as the module processor and request state, and some steps to resolve the problems. It is important to understand the default behavior to show only custom detailed errors for console (127.0.0.1) requests. However, it is possible to enable detailed error messages for nonconsole requests; we will outline how to accomplish this goal effectively. Confi guring Custom Error Messages Custom errors are a powerful method for creating customized, styled, yet useful error messages for your users. HTTP errors are a rather unpleasant side effect of the Web experience, but custom error messages can improve this typically unpleasant experience. There is a wide array of confi gurable settings for custom errors, such as using a specifi c fi le, redirection to another URL, or executing another URL. We will help simplify how each works and furthermore tell you how you can confi gure IIS7.0 to use custom error pages other than the default shipped by Microsoft. First, let’s start by taking a look at a custom error message. As you can see in Figure 17.1, the custom error message is pretty simple. Troubleshooting 101: Diagnostics in IIS 7.0 • Chapter 17 851 Figure 17.1 IIS 7.0 Standard HTTP Custom Error Message The custom error page is pretty basic and really only a placeholder until a developer can create an error page, or better yet handle the errors, that fi ts with the user experience and navigation that fi ts the rest of their application. Now let’s take a look at a detailed error message based on navigating to the same page from the IIS7 server console (see Figure 17.2). As you can see, there is quite a bit of information available that can help a developer or administrator work toward fi nding the root issue. As interesting as this information is for a developer or administrator, it’s equally interesting for a malicious user or hacker. As a best practice, you should not expose this information to end users unless you are in a development and testing phase. There are a number of options to suppress this generic custom error and provide our own custom error page. As an administrator or developer, you’ll have the ability to override the default error handling in IIS 7.0 using a redirection to a URL, custom static error page, or custom dynamic error page. The following section will explain how to defi ne these by server, site, and/or application. . choose? A: This is a common question and it’s easy to address. Microsoft released Windows Vista and IIS 7.0 as a ready product for the developer audience and optimized for that scenario. The. IIS and custom code a reality without attaching a debugger. As great as IIS 7.0’s diagnostics are, there are still areas where it can’t help. It is important to understand these areas and ensure. detailed error messages, such as the module processor and request state, and some steps to resolve the problems. It is important to understand the default behavior to show only custom detailed