Introduction
| Internet Information Services (IIS) is not only a popular platform for hosting web sites, it's also a required component for a number of Windows Server System (WSS) products, including Content Management Server, Exchange Server, Virtual Server, and Systems Management Server. Because these products rely on IIS for many of their core functions, understanding how IIS works is essential if you need to deploy, administer, or troubleshoot such products. IIS 6.0 has been rewritten almost from scratch for Windows Server 2003, and its improved architecture supports a wide range of new features including application pools, health monitoring, worker process recycling, and web gardens. Security has also been improved in several ways; for example, IIS is no longer installed by default during a Windows Server 2003 installation (except for Windows Server 2003 Web Edition), and when you do install IIS, the default settings allow only static content to be served. In order to configure IIS to deliver dynamic content such as ASP or ASP.NET applications, you must selectively enable these features using the new Web Service Extensions node in IIS Manager. This chapter provides recipes for the most common tasks an IIS administrator faces on a day-to-day basis.
Application IsolationIIS 4 first introduced the idea of an out-of-process application, that is, ISAPI or ASP code that runs in a separate memory space from inetinfo.exe, the core web server process associated with the IISAdmin and World Wide Web (WWW) services. The advantage of using out-of-process applications was that they could be stopped and started independently from one another, and if one of them crashed it didn't bring down the entire web server. There were disadvantages, however, out-of-process applications couldn't communicate with each other, ran slowly, and consumed large amounts of memory. As a result, running applications out of process was usually used only during the development phase for troubleshooting unstable applications, and once an application was debugged, it was moved in process with inetinfo.exe. And then if any bugs still lingered, the server crashed and had to be manually restarted. IIS 5 added a new type of application protection called pooled process, which let you run several applications together in a COM+ host process called dllhost.exe that was separate from the core inetinfo.exe process where the WWW service resides. The advantages of running applications in a pooled process include improved performance and better resource usage over isolated processes. Plus, if one application in the pool dies, it brings down only the other pooled applications and not the entire server. Additionally, IIS 5 could automatically restart pooled applications if they failed, reducing the number of manual reboots required on your computers. IIS 5 ran all applications as pooled processes by default, but they could also be moved out of process for troubleshooting purposes or in process for top performance. One limitation, however, was that IIS 5 only had one pool for lumping applications together. The architecture of IIS has been completely revamped in IIS 6 (see Figure 12-1 for a comparison of architectures for different IIS versions). There is now only one kind of application isolation available: application pools. These pools are similar to pooled processes in IIS 5, but now you can create as many pools as you like and group your applications accordingly. Figure 12-1. Comparison of architectures for different versions of IIS These pools are completely isolated from each other and thus combine the benefits of out of process and pooled process as in IIS 5. And in IIS 6, you can no longer run web-application code in process with inetinfo.exe, though this process still encapsulates all FTP, SMTP, or NNTP sites running on the server. Instead, a new service called the Web Administration Service (WAS) replaces IISAdmin as the user-mode component of the WWW service. This new IIS 6 architecture is named "worker process isolation mode," because any user-developed application code must now run within a worker process (w3wp.exe) as its host process instead of the dllhost.exe process used by IIS 5. There are several advantages of this new architecture. For example, one worker process can service several applications within a pool, providing isolation between applications running within other pools. One pool can also be serviced by several worker processes in a configuration known as a web garden. This increases availability on a single computer the way web farms do using multiple computers. WAS also monitors the health of worker processes and can terminate blocked processes and create new ones to take their place, further improving performance. And on a multiprocessor computer, a new feature called processor affinity lets you assign individual worker processes to specific CPUs to fine-tune performance. But what happens if you move your existing IIS 5 applications to IIS 6 and they have trouble running on the new architecture? Simply switch your server from worker process isolation mode to IIS 5 isolation mode (see Figure 12-2) and suddenly there are no more application pools, worker processes, WAS, or processor affinityyou've got IIS 5 instead. Or at least something that's similar to it in architecture, which should keep your legacy apps running until you can recode them to take advantage of the new features of worker process isolation mode. Figure 12-2. Switching from worker process isolation mode to IIS 5 isolation mode HTTP Request HandlingIn previous versions of IIS, the core inetinfo.exe process was hooked into the TCP/IP stack to pull out incoming HTTP requests and pass them to the WWW service (w3svc.dll) or a dllhost.exe helper process as appropriate. In IIS 6, however, the WWW service has been moved out of inetinfo.exe into the WAS, and inetinfo.exe no longer fields HTTP requests from the stack. Instead, this activity is done by the new kernel mode HTTP listener (http.sys). It resides within the TCP/IP stack, listening for incoming HTTP requests and routing them to the appropriate worker process. This architectural change (within both IIS and the networking subsystem) has several significant results. Responsiveness is improved because http.sys can queue HTTP requests if the worker process that services them is blocked or busy. Performance is improved because http.sys is a kernel-mode process, in comparison with inetinfo.exe, which was a pageable user-mode process. And reliability is improved because http.sys cannot encapsulate any user-developed code the way inetinfo.exe could in IIS 5. Http.sys also caches HTTP responses for both static and dynamic content, generates IIS log entries, and manages establishing and tearing down TCP sessions for HTTP communications. Note that while http.sys means big performance gains for applications running on IIS, it can cause compatibility problems for third-party HTTP applications you have running on your server. Fortunately, there's a workaround using a command-line tool called httpcfg.exe, found in the \Support\Tools folder on Windows Server 2003 CD. See MS KB 813368 for more information on how to use it. XML MetabaseThe final major change in IIS 6 I'll discuss here pertains to the metabase, the memory-resident database used in place of the registry for storing most IIS configuration settings. The biggest change is from the proprietary binary format used in the IIS 5 metabase to a text-based XML format used in IIS 6. This change makes it easier to edit and customize the metabase to meet your needs. In fact, IIS 6 lets you edit the metabase even while IIS services are running on your computer, something you couldn't do in earlier versions. (Note that you have to enable this first; see Recipe 12.15.) IIS 6 also makes it easier to back up and restore the metabase, even to a different computer, opening the way for you to create a master IIS computer, clone its settings, and copy them to other computers. The new metabase history feature even generates backups automatically whenever changes are made to the metabase.
Using a graphical user interfaceThe standard graphical tool for administering IIS is Internet Information Services (IIS) Manager, or IIS Manger for short. This tool is standard on Windows Server 2003 platforms and a version of this tool that runs on Windows XP Professional can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=f9c1fb79-c903-4842-9f6c-9db93643fdb7. Using a command-line interfaceIIS 6 includes a number of command scripts written in VBScript that can be used for common tasks such as creating web sites, backing up the metabase, and so on. In addition, there is the adsutil.vbs script that came with IIS 5, which uses ADSI to manipulate the IIS configuration, the iisreset command, and the net commands, and a couple of useful tools from the IIS 6.0 Resource Kit (you can download the Resource Kit tools from http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499). All of the tools used in this chapter are listed in Table 12-1.
Using VBScriptIIS is one of Microsoft's most programmable Windows components. And unlike most other components, you have your choice between ADSI and WMI as a programmatic interface. Historically, ADSI was the only interface available to script against IIS, but with Windows Server 2003 and IIS 6, Microsoft added WMI support. In this chapter, I've used ADSI solely because of its legacy support in older versions of IIS and the fact that a lot of people still use ADSI when scripting IIS. Many of the examples you'll find in other books and on the Web use the ADSI provider. However, depending upon your specific requirements, you may find that WMI provides capabilities that are not present in the ADSI interfaces.
|
EAN: 2147483647
Pages: 380