Microsoft Outlook Web Access and Outlook Mobile Access are essential technologies for enabling users to access Microsoft Exchange anywhere at any time. As you know from previous discussions, Outlook Web Access lets users access Exchange over the Internet or over a wireless network using a standard Web browser, and Outlook Mobile Access lets users access Exchange through a wireless carrier using mobile devices, such as smart phones and Pocket PCs. When users access Exchange mail and public folders over the Internet or a wireless network, Hypertext Transfer Protocol (HTTP) virtual servers hosted by Microsoft Exchange Server 2003 are working behind the scenes to grant access and transfer files. As you’ll learn in this chapter, managing HTTP virtual servers is a bit different from other tasks you’ll perform as an Exchange administrator—and not only because you’ll use the Internet Information Services (IIS) Manager snap-in to perform many of the management tasks.
When you install Exchange Server 2003, Outlook Web Access and Outlook Mobile Access are automatically configured for use. This makes them fairly easy to manage, but there are some essential concepts you need to know to manage these implementations more effectively. This section explains these concepts.
Outlook Web Access, Outlook Mobile Access, and a default HTTP virtual server are installed automatically when you install Exchange Server 2003. In most cases you only need to open the appropriate ports on your organization’s firewall to allow users to access Exchange data. Then you simply tell users the Uniform Resource Locator (URL) path that they need to type in their browser’s Address field.
The users can then access Outlook Web Access or Outlook Mobile Access when they’re off-site. The URLs for Outlook Web Access and Outlook Mobile Access are different. Typically, the Outlook Web Access URL is http://yourmicrosoft.com/exchange and the Outlook Mobile Access URL is http://yourmicrosoft.com/oma.
You can configure Outlook Web Access and Outlook Mobile Access for single-server and multiserver environments. In a single-server environment, you use one server for all your messaging needs. Here, the HTTP virtual server used by Outlook Web Access and Outlook Mobile Access is configured directly on the Exchange server and you don’t need to change any configuration options.
In a multiserver environment, such as the one shown in Figure 16-1, you have separate servers for different messaging needs. Here, the HTTP virtual server used by Outlook Web Access and Outlook Mobile Access might reside on a different server than the servers used for Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol 4 (IMAP4), and Post Office Protocol 3 (POP3). To make the best use of Outlook Web Access and Outlook Mobile Access in a multiserver environment, you should designate an Exchange front-end server. The front-end server is the server running the HTTP virtual server and is the one to which users connect when they want to use Outlook Web Access or Outlook Mobile Access.
In multiserver environments, Microsoft recommends that you use a front-end/ back-end deployment scenario for Outlook Mobile Access and Outlook Web Access. In this configuration, front-end servers handle client requests and establish the connections. Once a connection is open, the front-end server uses Lightweight Directory Access Protocol (LDAP) to query Active Directory and determine the back-end server on which the needed mailbox or public folder is located. The front-end server then delivers the request to the appropriate back-end server. When ready, the front-end server passes the back-end server’s response to the client.
Additionally, if Secure Sockets Layer (SSL) is used, the front-end server is responsible for encrypting and decrypting message traffic. This means that the front-end server decrypts a client request before delivering it to a back-end server and then encrypts the back-end server’s response before sending it to the client.
Tip
Although the focus of this chapter is on HTTP virtual servers, front-end servers can handle SMTP, POP3, and IMAP4 as well. To enable handling of these protocols, all you need to do is to configure clients to use a front-end server rather than the back-end server on which these protocols are configured. The front-end server uses Active Directory to determine where to forward requests.
As you might have already realized, a front-end/back-end deployment strategy has several benefits:
You can use a front-end server to handle connections and perform directory lookups, which reduces the load on the back-end servers.
You can use a front-end server to encrypt and decrypt SSL traffic, which again reduces the load on the back-end servers.
You can use a front-end server to direct requests to multiple back-end servers, which makes it easier to configure clients in large enterprises.
Here’s how a typical front-end/back-end deployment works:
You install Exchange Server 2003 on the back-end servers and then configure the information stores and virtual servers that are needed by these servers.
When you create user mailboxes and public folders, you do so in the information stores on the back-end servers.
You install Exchange Server 2003 on the front-end servers. You can place these servers behind the organizational firewall as discussed in the section of this chapter entitled "Using Outlook Web Access and Outlook Mobile Access with Firewalls."
Afterward, you use System Manager to identify the front-end servers. To do that, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to designate as the front-end server, and then select Properties.
On the General Tab, select This Is A Front End Server. Click OK.
Restart the front-end server. Repeat Steps 1 through 3 for other front-end servers.
To complete the deployment, you configure clients to connect to the front-end servers. The front-end servers then act as proxies for the organization.
You can use Outlook Web Access and Outlook Mobile Access with firewalls. If you configure your network to use a perimeter network with firewalls in front of the designated front-end server, you can use a configuration similar to the one shown previously in Figure 16-1. In this setup, you configure Outlook Web Access and Outlook Mobile Access by completing the following steps:
Install the perimeter network and the organizational firewalls. Open ports 80 and 443 to the front-end server’s Internet Protocol (IP) address.
Install Exchange Server 2003 and then configure the server as a front-end server that will provide Outlook Web Access and Outlook Mobile Access services.
The front-end server makes connections to back-end servers and to the organization’s global catalog server, which provides information needed for logon and directory searches.
Note
If SSL is enabled, and you want all Web browsers to use SSL exclusively, you don’t need to open port 80 on the perimeter network firewall. However, you still need to open port 80 on the organizational firewall.
Your perimeter network could also be configured as shown in Figure 16-2. In this configuration, your front-end server is within the perimeter network and there is a firewall in front of and behind it. In this configuration, you would need to configure Outlook Web Access and Outlook Mobile Access by completing the following steps:
Install the perimeter network and the organizational firewalls. On the firewall connected directly to the Internet, open ports 80 and 443 to the front-end server’s IP address.
Install Exchange Server 2003 and then configure the server as a front-end server that will provide Outlook Web Access and Outlook Mobile Access services.
The front-end server makes connections to back-end servers and to the organization’s global catalog server, which provides information needed for logon and directory searches. On the organizational firewall, open port 80 to the IP addresses for the back-end servers. Then open ports 389 and 3268 to the IP address for the global catalog server.
When you install Exchange Server 2003, a default HTTP virtual server is installed and configured for use. The default HTTP virtual server allows authenticated users to access their mailboxes and public folder data. As your organization grows, you might find that you need additional HTTP virtual servers to handle the needs of remote users or that you want to offload HTTP services to separate Exchange servers. You can handle both of these tasks by installing Exchange Server 2003 on new servers and then creating additional HTTP virtual servers as necessary.
You can create additional HTTP virtual servers by completing the following steps:
If you’re installing the virtual server on a new Exchange server, make sure that messaging services have been installed on the server.
If you want the HTTP virtual server to use a new IP address, you must configure the IP address before installing the HTTP virtual server. For details, see "Configuring Static IP Addresses" in Chapter 16 of Microsoft Windows Server 2003 Administrator’s Pocket Consultant (Microsoft Press, 2003).
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click HTTP in the console tree, point to New, and then select HTTP Virtual Server. You should see the Properties dialog box shown in Figure 16-3.
In the Name field, type a descriptive name for the virtual server.
Use the IP Address selection list to select an available IP address. Choose (All Unassigned) to allow HTTP to respond on all unassigned IP addresses that are configured on the server. The Transmission Control Protocol (TCP) port is assigned automatically as port 80 for HTTP and port 443 for SSL.
To set additional identities, click Advanced on the General tab. Use the following options in the Advanced dialog box to modify the server’s identity:
Add. Adds a new identity. Click Add, select the IP address you want to use, and then type a host name, TCP port, and SSL port. Click OK when you’re finished.
Modify. Allows you to modify the currently selected entry in the Identities list box.
Remove. Allows you to remove the currently selected entry from the Identities list box.
Connection limits control the maximum number of simultaneous connections. To set a connection limit, select the Limit Number Of Connections check box and then type a limit.
The Time-Out (Secs) field controls the connection time-out. The default is 900 seconds. As necessary, type a new time-out value.
When you create HTTP virtual servers, you have the option of configuring the server for access to the following:
Mailboxes for SMTP Domain. If you want to provide access to mailboxes, select this option. The current domain is configured as the default. To choose a different SMTP domain, click Modify, and then in the Select SMTP Domains dialog box, choose the SMTP domain to use.
Public Folders. If you want to provide access to public folders, select this option. The All Public Folders Tree is configured as the default. To choose a different public folder tree or a specific public folder within a tree, click Modify and then in the Public Folder Selection dialog box choose the public folder to use.
Click Finish to create the virtual server.
HTTP virtual servers provide the transport services you need to access public folders and mailboxes from the Web. You can also use HTTP virtual servers to publish documents that can be accessed by off-site users or the general public. If you examine the directory structure for HTTP virtual servers, you’ll find several important directories, including:
Exadmin. Exadmin is used for web-based administration of the HTTP virtual server. By default, this directory is configured for integrated authentication only.
Exchange. Exchange is the directory to which users connect to access their mailboxes. By default, this directory is configured for both basic and integrated Windows authentication with the default domain set to the pre-Windows 2000 domain name, such as ADATUM.
ExchWeb. ExchWeb is used with Outlook Web Access and provides calendaring, address book and other important control functions. By default, this directory is configured for anonymous access but the bin directory which provides the controls is restricted and uses both basic and integrated Windows authentication.
OMA. OMA is the directory to which Outlook Mobile Access users connect to access their Exchange data. By default, this directory is configured for basic authentication with the default domain set to .
Public. Public is the directory to which users connect to access the default Public Folders tree. By default, this directory is configured for both basic and integrated Windows authentication with the default domain set to the pre-Windows 2000 domain name, such as ADATUM.
This section examines key tasks that you use to manage HTTP virtual servers and their related directories.
Each HTTP virtual server is identified by a unique TCP port, SSL port, IP address, and host name. The default TCP port is 80. The default SSL port is 443. The default IP address setting is to use any available IP address. The default host name is the Exchange server’s Domain Name System (DNS) name.
When the server is multihomed or when you use it to provide Outlook Web Access or Outlook Mobile Access services for multiple domains, the default configuration isn’t ideal. On a multihomed server, you’ll usually want messaging protocols to respond on a specific IP address, and to do this, you need to change the default setting. On a server that provides Outlook Web Access and Outlook Mobile Access services for multiple domains, you’ll usually want to specify an additional host name for each domain.
To change the identity of an HTTP virtual server, complete the following steps:
If you’re configuring a new Exchange server, ensure that messaging services have been installed on the server.
If you want the HTTP virtual server to use a new IP address, you must configure the IP address before trying to specify the IP address on the HTTP virtual server. For details, see "Configuring Static IP Addresses" in Chapter 16 of Microsoft Windows Server 2003 Administrator’s Pocket Consultant (Microsoft Press, 2003).
Start IIS Manager. Click Start, point to Programs or All Programs as appropriate, point to Administrative Tools, and select Internet Information Services (IIS) Manager.
Note
By default, IIS Manager connects to the services running on the local computer. If you want to connect to a different server, right-click Internet Information Services in the console tree, and then select Connect. In the Connect To Computer dialog box, type the name of the computer to which you want to connect, and then click OK.
In IIS Manager, each HTTP virtual server is represented as a Web site. The Default Web Site represents the default HTTP virtual server. Double-click the entry for the server you want to work with and then double-click Web Sites.
Right-click the Web site that you want to manage, and then select Properties.
On the Web Site tab, click Advanced. As Figure 16-4 shows, you can now use the Advanced Web Site Identification dialog box to configure multiple identities for the virtual server.
Use the Multiple Identities For This Web Site panel to manage TCP port settings:
Add. Adds a new identity. Click Add, select the IP address you want to use, and then type the TCP port and host name. Click OK when you’re finished.
Remove. Allows you to remove the currently selected entry from the Multiple Identities For This Web Site list.
Edit. Allows you to edit the currently selected entry in the Multiple Identities For This Web Site list.
Use the Multiple SSL Identities For This Web Site panel to manage SSL port settings. Click Add to create new entries. Use Edit or Remove to modify or delete existing entries.
More Info
If the SSL options are unavailable, as shown previously in Figure 16-4, you haven’t installed SSL. To enable SSL and the related options, you need to obtain and install an SSL certificate as discussed in the next section of this chapter.
Click OK twice.
SSL is a protocol for encrypting data that is transferred between a client and a server. Without SSL, servers pass data in cleartext to clients, and this could be a security risk in an enterprise environment. With SSL, servers pass data encoded using 40-bit or 128-bit encryption.
Although HTTP virtual servers are configured to use SSL on port 443 automatically, the server won’t use SSL unless you’ve created and installed an X.509 certificate. You can create and install an X.509 certificate for an HTTP virtual server by completing the following steps:
Start IIS Manager. Click Start, point to Programs or All Programs as appropriate, point to Administrative Tools, and then select Internet Information Services (IIS) Manager.
Note
By default, IIS Manager connects to the services running on the local computer. If you want to connect to a different server, right-click Internet Information Services in the console tree, and then select Connect. In the Connect To Computer dialog box, type the name of the computer to which you want to connect, and then click OK.
In IIS Manager, each HTTP virtual server is represented by a Web site. The Default Web Site represents the default HTTP virtual server. Double-click the entry for the server you want to work with, and then right-click the Web site that you want to manage, and choose Properties.
On the Directory Security tab, click Server Certificate. This starts the Web Server Certificate Wizard. Use the wizard to create a new certificate. For additional virtual servers on the same Exchange server, you’ll want to assign an existing certificate.
Send the certificate request to your certification authority (CA). When you receive the certificate back from the CA, access the Web Server Certificate Wizard from the virtual server’s Properties dialog box again. Now you’ll be able to process the pending request and install the certificate.
You control incoming connections to an HTTP virtual server in two ways. You can set a limit on the number of simultaneous connections, and you can set a connection time-out value.
Normally, virtual servers accept an unlimited number of connections, and this is an optimal setting in most environments. However, when you’re trying to prevent a virtual server from becoming overloaded, you might want to limit the number of simultaneous connections. Once the limit is reached, no other clients are permitted to access the server. The clients must wait until the connection load on the server decreases.
The connection time-out value determines when idle user sessions are disconnected. With the default HTTP virtual server, sessions time out after they’ve been idle for 900 seconds (15 minutes). Although 15 minutes might seem to be a short time, it’s sound security policy to disconnect idle sessions and force users to log back on to the server. If you don’t disconnect idle sessions within a reasonable amount of time, unauthorized persons could gain access to your messaging system through a browser window left unattended on a remote terminal.
You can modify connection limits and time-outs by completing the following steps:
Start IIS Manager. Click Start, point to Programs or All Programs as appropriate, point to Administrative Tools, and then select Internet Information Services (IIS) Manager.
Note
By default, IIS Manager connects to the services running on the local computer. If you want to connect to a different server, right-click Internet Information Services in the console tree, and then select Connect. In the Connect To Computer dialog box, type the name of the computer to which you want to connect, and then click OK.
In IIS Manager, each HTTP virtual server is represented by a Web site. The Default Web Site represents the default HTTP virtual server. Double-click the entry for the server you want to work with.
Right-click the Web site that you want to manage, and then select Properties. Click the Performance tab, as shown in Figure 16-5.
To remove connection limits, select Unlimited on the Connections panel. To set a connection limit, select Connections Limited To and then type a limit.
The Connection Timeout field controls how long idle user sessions remain connected to the server. Type a new value to change the current time-out value.
Click OK.
HTTP virtual servers support five authentication methods:
Anonymous authentication. With anonymous authentication, IIS automatically logs users on with an anonymous or guest account. This allows users to access resources without being prompted for user name and password information.
Basic authentication. With basic authentication, users are prompted for logon information. When entered, this information is transmitted unencrypted (cleartext) across the network. If you’ve configured secure communications on the server as described in the section of this chapter entitled "Enabling SSL on HTTP Virtual Servers," you can require that clients use SSL. When you use SSL with basic authentication, the logon information is encrypted before transmission.
Integrated Windows authentication. With integrated Windows authentication, IIS uses standard Windows security to validate the user’s identity. Instead of prompting for a user name and password, clients relay the logon credentials that users supply when they log on to Windows. These credentials are fully encrypted without the need for SSL, and they include the user name and password needed to log on to the network. Only Microsoft Internet Explorer browsers support this feature.
Digest authentication. With digest authentication, user credentials are transmitted securely between clients and servers. Digest authentication is a feature of HTTP 1.1 and uses a technique that can’t be easily intercepted and decrypted. This feature is available only when IIS is configured on a server running Microsoft Windows Server 2003 server and is part of a Microsoft Windows 2000 Server or later Active Directory domain. The client is required to use a domain account and the request made by Internet Explorer 5.0 or later.
.NET Passport authentication. With .NET Passport authentication, the user credentials aren’t checked directly. Instead, the server checks for a Passport Authentication ticket as one of the cookie files on the user’s computer. If the ticket exists and has valid credentials, the server authenticates the client. If the ticket doesn’t exist or the credentials aren’t valid, the user is redirected to the Passport Logon Service. Once the user logs on to the Passport service, the user is directed back to the original URL.
By default, both basic and integrated Windows authentication are enabled on the Exchange and Public directories used by the HTTP virtual server, and you should rarely change this setting. However, if your organization has special needs, you can change the authentication settings at the virtual directory level. A virtual directory is simply a folder path that is accessible by a URL. For example, you could create a virtual directory called Data that is physically located on C:CorpDataData and accessible using the URL http://myserver.microsoft.com/Data.
The default public folder tree and any other public folder trees you’ve created are accessible through basic and integrated Windows authentication. If you want to grant public access to these folder trees or restrict them so that only integrated Windows authentication is allowed, you can do so by editing the individual security settings on the related virtual directory.
Although the mailbox tree is accessible through basic and integrated Windows authentication as well, access to mailboxes is restricted, just as it is from Microsoft Office Outlook 2003. As a result of this security, only William Stanek can access William Stanek’s mailbox—unless you’ve granted special permissions to other users. You should rarely—if ever—change the authentication settings on the Mailbox virtual directory.
The authentication settings on virtual directories are different than authentication settings on the virtual server itself. By default, the virtual server allows anonymous access. This means that anyone can access the server’s home page without authenticating himself or herself. If you disable anonymous access at the server level, users need to authenticate themselves twice: once for the server and once for the virtual directory they want to access.
You can change the authentication settings for an entire site or a particular virtual directory by completing the following steps:
Start IIS Manager. Click Start, point to Programs or All Programs as appropriate, point to Administrative Tools, and then select Internet Information Services (IIS) Manager.
Note
By default, IIS Manager connects to the services running on the local computer. If you want to connect to a different server, right-click Internet Information Services in the console tree, and then select Connect. In the Connect To Computer dialog box, type the name of the computer to which you want to connect, and then click OK.
In IIS Manager each HTTP virtual server is represented by a Web site. The Default Web Site represents the default HTTP virtual server. Double-click the entry for the server you want to work with.
Right-click the site or virtual directory that you want to manage, and then select Properties.
On the Directory Security tab, click Edit on the Anonymous Access And Authentication Control panel. This displays the Authentication Methods dialog box shown in Figure 16-6.
To allow anonymous access, select the Enable Anonymous Access check box. To disable anonymous access, clear this check box.
Note
In most cases the anonymous user account is named IUSR_ServerName, such as IUSR_Mailer1. If you use this account, you don’t need to set a password. Instead, let IIS manage the password. If you want to use a different account, click Browse,s and then use the Select User dialog box to select the anonymous user account.
Configure the authentication methods you want to use. Keep the following in mind:
Disabling basic authentication might prevent some clients from accessing resources remotely. Clients can log on only when you enable an authentication method that they support.
A default domain isn’t set automatically. If you enable basic or .NET Passport authentication, you can choose to set a default domain that should be used when no domain information is supplied during the logon process. Setting the default domain is useful when you want to ensure that clients authenticate properly.
With basic and digest authentication, you can optionally define the realm or realms that can be accessed. Essentially, a realm is a level within the metabase hierarchy. The default realm name is the computer name, which provides access to all levels within the metabase hierarchy. You could limit this by defining specific realms, such as W3SVC (for the Web Site’s root) or W3SVC/1/Root (for the root of the first Web instance).
If you enable .NET Passport authentication, all other authentication settings are ignored. As a result, the server only authenticates using this technique for the specified resource.
Click OK. Before applying changes, IIS checks the existing authentication methods in use for all Web sites and directories within Web sites. If a site or directory node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.
The default HTTP virtual server provides access to mailboxes and public folders in the Exchange server’s local domain. You can also configure additional HTTP virtual servers you’ve created to access mailboxes and public folders in the local domain or other domains.
To provide access to a public folder or public folder tree on a new HTTP virtual server, follow these steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, select HTTP. Right-click the HTTP virtual server that you want to work with and then select Properties.
On the General tab, select Public Folder, and then click Modify.
As shown in Figure 16-7, choose the public folder or public folder tree that you want to make accessible on the virtual server. If the public folder tree is on a different server than the default, click Change Server. Afterward, select the Exchange Server and the public store containing the public folder tree you want to use and then click OK.
Click OK. Users can now access the public folder by typing the server or folder URL in their browser’s Address field.
Note
If the public folder or public folder tree you want to use isn’t displayed, click Change Server and then select the public folder store where the element you want is located. Click OK. You can then choose the element in the list.
To provide access to mailboxes in an SMTP domain, follow these steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, select HTTP. Right-click the HTTP virtual server that you want to work with and then select Properties.
On the General tab, select Mailboxes For, and then click Modify.
As shown in Figure 16-8, select an SMTP domain, and then click OK.
Click OK again. Users can now access mailboxes for the selected domain.
To provide access to additional SMTP domains or public folder trees, you must create additional virtual directories for the server. These virtual directories serve as the root from which users can access additional resources. For example, you could configure an HTTP virtual server with the fully qualified domain name of mail.microsoft.com to access resources in microsoft.com, boston.microsoft.com, and chicago.microsoft.com. To do this, you would follow these steps:
Configure the local SMTP domain (microsoft.com) for access as discussed in the section of this chapter entitled "Configuring Mailbox and Public Folder Access on a Virtual Server." Users can then access mailboxes using the URL http://mail.microsoft.com/Exchange/alias/, where alias is the user’s Exchange alias.
Create a new virtual directory on the HTTP virtual server named boston and set the directory to access boston.microsoft.com as the SMTP domain. Users can then access mailboxes using the URL http://mail.microsoft.com/boston/alias/, where alias is the user’s Exchange alias.
Create a new virtual directory on the HTTP virtual server named chicago and set the directory to access chicago.microsoft.com as the SMTP domain. Users can then access mailboxes using the URL http://mail.microsoft.com/chicago/alias/, where alias is the user’s Exchange alias.
Procedures for creating virtual directories are examined next.
To create a virtual directory for accessing an additional public folder tree, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, select HTTP. Right-click the HTTP virtual server that you want to work with, point to New, and then select Virtual Directory.
Type a name for the virtual directory. This name will be used in the folder path of the URL, so be sure to keep it simple.
Select Public Folder, and then click Modify.
In the Public Folder Selection dialog box, choose the public folder or public folder tree that you want to make accessible on the virtual server.
Click OK. Users can now access the public folder by typing the server or folder URL in their browser’s Address field.
To create a virtual directory for accessing an additional SMTP domain, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, select HTTP. Right-click the HTTP virtual server that you want to work with, point to New, and then select Virtual Directory.
Type a name for the virtual directory. This name will be used in the folder path of the URL, so be sure to keep it simple.
Select Mailboxes For, and then click Modify.
Select an SMTP domain, and then click OK.
Click OK again. Users can now access mailboxes for the selected domain.
HTTP virtual servers run under a server process that you can start, stop, and pause much like other server processes. For example, if you’re changing the configuration of a virtual server or performing other maintenance tasks, you might need to stop the virtual server, make the changes, and then restart it. When a virtual server is stopped, it doesn’t accept connections from users and can’t be used to deliver or retrieve mail.
An alternative to stopping a virtual server is to pause it. Pausing a virtual server prevents new client connections, but it doesn’t disconnect current connections. When you pause an HTTP virtual server, active clients can continue to retrieve documents, messages, and public folder data in their Web browser. No new connections are accepted, however.
The master process for all HTTP virtual servers is the World Wide Web Publishing Service. Stopping this service stops all virtual servers using the process and all connections are disconnected immediately. Starting this service restarts all virtual servers that were running when you stopped the World Wide Web Publishing Service.
You can start, stop, or pause an HTTP virtual server by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the Protocols container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, expand HTTP and then right-click the virtual server you want to manage. You can now do the following:
Select Start to start the virtual server.
Select Stop to stop the virtual server.
Select Pause to pause the virtual server.
You can start, stop, or pause the World Wide Web Publishing service by completing these steps:
Open the Computer Management console.
Right-click the Computer Management entry in the console tree and select Connect To Another Computer from the shortcut menu. You can now choose the Exchange server for which you want to manage services.
Expand the Services And Applications node by clicking the plus sign (+) next to it, and then choose Services.
Right-click World Wide Web Publishing Service, and then select Start, Stop, or Pause as appropriate. You can also choose Restart to have Windows stop and then start the service after a brief pause. Additionally, if you pause a service, you can use the Resume option to resume normal operation.