Internet Information Services

 

Internet Information Services (IIS) is an integral part of every server running Exchange 2003 Server. IIS hosts essential components that Exchange Server 2003 must have to function as a messaging system. The Internet Server Application Programming Interface (ISAPI) applications, which Exchange Server 2003 adds to the Web service, for example Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync, provide users with access to Exchange over a variety of HTTP-based protocols. The Web service is also responsible for RPC over HTTP communication, if your users use this communication mechanism to access their mailboxes over the Internet without a virtual private network (VPN) connection. IIS hosts the SMTP service, which implements the central transport engine of Exchange 2003. IIS also hosts the NNTP, IMAP4, and POP3 protocol engines that provide Internet users with access to messaging data over most Internet access protocols. The File Transfer Protocol (FTP) service is the only IIS protocol service that is not relevant for Exchange 2003, because FTP is not a messaging protocol.

The following figure illustrates how SMTP, NNTP, IMAP4, POP3, Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync are integrated into the architecture of IIS 6.0.

Exchange Server 2003 components in the IIS 6.0 architecture

a38725fa-3a9e-424a-bae7-f0649065f150

Exchange Server 2003 relies on the following key components in IIS 6.0:

  • Inetinfo.exe   Inetinfo.exe is a user-mode component that runs the main IIS process and hosts most of the protocol engines of IIS 6.0. These components include FTP, SMTP, NNTP, IMAP4, and POP3. The Admin service also runs in the context of the Inetinfo.exe process. It is important to understand, however, that the World Wide Web Publishing service does not run in Inetinfo.exe. The architecture of IIS 6.0 is redesigned to run the Web service in its own processing context for fault-tolerance, performance, and security reasons.

  • Metabase   The metabase is a data store that holds IIS configuration data. The metabase is a plain-text .xml file that can be edited manually or programmatically. You can find the metabase.xml file in the \Windows\System32\Inetsrv directory. For more information on the metabase, see Protocol Virtual Servers in Exchange Server 2003.

  • IIS Admin service   The IIS Admin service (IIS Admin) manages the IIS metabase and updates the registry for the Web service, FTP service, SMTP service, POP3 service, IMAP4 service, and NNTP service. IIS Admin also provides access to the IIS configuration information to other applications, such as to the metabase update service, which is an internal component of System Attendant. For more information on the metabase update service, see Exchange Server 2003 and Active Directory.

    The registry key for the IIS Admin service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin. IIS Admin depends on Remote Procedure Call (RPC) service and Security Accounts Manager service. All other IIS services depend on the IIS Admin service. IIS Admin is implemented in Iisadmin.dll, which resides by default in the \Windows\System32\Inetsrv directory.

    Note

    The IIS Admin service must be running on every server running Exchange Server 2003.

  • SMTP Service   The SMTP service runs the SMTP protocol engine that accepts incoming SMTP messages on TCP port 25 by default and sends messages to other hosts using SMTP. On a server running Exchange Server 2003, the SMTP service also controls the core transport engine. The SMTP service is included with Windows Server 2003 and is extended by Exchange Server 2003. For more information about the SMTP transport architecture, see SMTP Transport Architecture.

    The registry key for the SMTP service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSvc. The SMTP service runs in the context of the Inetinfo.exe process and depends on the Event Log service and IIS Admin service. The SMTP service is implemented in Smtpsvc.dll, which resides by default in the \Windows\System32\Inetsrv directory.

    Note

    Although no other services depend on the SMTP service, the SMTP service must be running on every Exchange Server 2003, because the entire Exchange Server 2003 messaging system depends on it.

  • POP3 Service   The POP3 service is included with Exchange Server 2003 and provides Internet users with access to their mailboxes through Post Office Protocol version 3. Clients, such as Outlook Express, can download messages through POP3 when the user has the required permissions and when the POP3 service is running on the server running Exchange Server. The POP3 service provides access only to the Inbox folder. Other mailbox folders or public folders are not accessible.

    The registry key for the POP3 service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc. The POP3 service runs in the context of the Inetinfo.exe process and depends on the IIS Admin service so that it can be controlled in IIS. The POP3 service is implemented in Pop3svc.dll, which resides by default in the \Program Files\Exchsrvr\Bin directory. The POP3 service is disabled by default.

    Note

    Because no other Exchange services depend on the POP3 service, the POP3 service is not required to be running if users do not use POP3 clients to access their mailboxes.

  • NNTP Service   The NNTP service enables an Exchange Server 2003 server to host NNTP newsgroups (such as discussion groups) based on public folders. Because this feature complies fully with the NNTP protocol, users can use any newsreader client to participate in newsgroup discussions. If the NNTP service runs on a server running Exchange Server 2003, the NNTP service can also be used to replicate newsgroups with other NNTP hosts through newsfeeds. The NNTP service is included with Windows Server 2003 and is extended by Exchange Server 2003.

    The registry key for the NNTP service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NNTPSvc. The NNTP service runs in the context of the Inetinfo.exe process and depends on the Event Log service and the IIS Admin service. The NNTP service is implemented in Nntpsvc.dll, which resides by default in the \Windows\System32\Inetsrv directory. The NNTP service is disabled by default.

    Note

    Because no other Exchange services depend on the NNTP service, the NNTP service is not required to be running if you do not replicate newsgroups with other NNTP hosts and if users do not use newsreader clients to access public folders.

  • IMAP4 Service   The IMAP4 service ships with Exchange Server 2003 and enables Internet users to access their mailboxes and public folders through the Internet Mail Access Protocol version 4. Clients, such as Outlook Express, can download messages through IMAP4 when the user has the required permissions and when the IMAP4 service is running on the server running Exchange Server. IMAP4 users can also work with messages directly on the server.

    The registry key for the IMAP4 service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc. The IMAP4 service runs in the context of the Inetinfo.exe process and depends on the IIS Admin service. The IMAP4 service is implemented in IMAP4svc.dll, which resides by default in the \Program Files\Exchsrvr\Bin directory. The IMAP4 service is disabled by default.

    Note

    Because no other Exchange services depend on the IMAP4 service, the IMAP4 service is not required to be running if users do not use IMAP4 clients to access their mailboxes.

  • World Wide Web Publishing Service   The World Wide Web Publishing service, included with Windows Server 2003, is a user-mode configuration and process manager, which manages the IIS components that process HTTP requests and run Web applications, such as Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. The Web service is also a monitoring component, which periodically checks the Web applications to determine if these applications are running or have stopped unexpectedly. The Web service comes with Windows Server 2003. Exchange Server 2003 extends this service with ISAPI components for Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync.

    The registry key for the World Wide Web service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc. Unlike all other IIS services, the Web service does not run in the context of the Inetinfo.exe process. If you check the ImagePath parameter under the W3Svc registry key, you see that the Web service runs in the context of the Svchost.exe process, which is a generic host process for services that are implemented in DLLs. The Web service is implemented in Iisw3adm.dll.

    The Web service runs in an Svchost.exe service group called IISSvcs. Svchost.exe uses service groups to run separate services together in a single instance of Svchost.exe. Multiple instances of Svchost.exe can run on a server and each Svchost.exe session can contain a separate group of services. Svchost groups are listed in the following registry key:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost.

    Each entry under this key is a REG_MULTI_SZ parameter that represents a separate Svchost group. Each value contains the service names that run together in a service group. If you check the value of the IISSvcs entry, you see that the Web service is the only service in the IISSvcs group.

  • **World Wide Web Worker Process   **All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a World Wide Web worker process. The worker process executable is called w3wp.exe. Each worker process provides complete isolation from system components and other Web applications, and receives requests directly from the HTTP.sys kernel-mode driver.

  • Application Pool   An application pool is a request queue within HTTP.sys that is used by one or more worker processes. In other words, an application pool can serve requests for one or more unique Web applications. These Web applications are assigned to the application pool based on their URL. Each application pool is separated from other application pools by process boundaries. An application that is assigned to one application pool is not affected by other application pools, and that application cannot be routed to another application pool while being serviced by the current application pool.

    All necessary HTTP application run-time services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning Web application or Web site from disrupting other Web applications (or other Web sites) served from other worker processes on that server. It is now possible to unload in-process components without having to stop the entire Web service. The host worker process can be paused temporarily without affecting other worker processes that are communicating with Web browsers or other Web applications. An application pool can also leverage other operating system services that are available at the process level (for example, CPU throttling).

    Note

    Applications can be assigned to another application pool in the IIS Manager snap-in while the server is running. IIS supports up to 20,000 application pools per server.

  • HTTP.sys   This is the kernel-mode component for HTTP listening, routing, queuing, and caching. HTTP.sys is a single point of contact for all incoming HTTP requests. It provides high-performance connectivity for HTTP server applications. The driver sits on top of TCP/IP and registers itself for all Windows sockets (IP/port combinations) on which incoming connection requests are received. HTTP.sys is also responsible for overall connection management, bandwidth throttling, and Web server logging.

    HTTP.sys maintains a queue for each application pool so that the individual HTTP requests are routed to the correct user-mode worker processes serving an application pool. If a user-mode worker process quits unexpectedly, HTTP.sys continues to accept and queue requests, provided the Web service is still running. HTTP.sys continues to accept requests and queues them on the appropriate queue until there are no queues available, there is no space left on the queues, or the Web service has been shut down. Once the Web service notices the failed worker process, it starts a new worker process, if there are outstanding requests waiting to be serviced for the worker process's application pool. Thus, while there might be a temporary disruption in user-mode request processing, the user does not experience the failure because requests continue to be accepted and queued.