Lesson 1: Front-EndBack-End Configurations

Front-end/back-end (FE/BE) configurations, as the name implies, rely on front-end (FE) and back-end (BE) servers. An FE server is a computer that receives incoming client connections and proxies them to an appropriate BE server. The BE server, in turn, hosts the actual data (that is, the mailboxes and public folders). Exchange 2000 Server supports FE/BE configurations for Internet protocols, such as Internet Message Access Protocol 4 (IMAP4), Post Office Protocol 3 (POP3), or Hypertext Transfer Protocol (HTTP). Unfortunately, Messaging Application Programming Interface (MAPI)-based clients cannot benefit from this type of configuration.

This lesson addresses the design of FE/BE configurations and the resulting strategies for mailbox and public folder access. You can read about the advantages and disadvantages of the FE/BE approach and how FE servers communicate with BE servers. You can also read about the role that the Active Directory assumes in FE/BE configurations and how to design FE servers for maximum performance.

After this lesson, you will be able to

• Explain the advantages and disadvantages of FE/BE configurations
• Design an FE/BE environment and client access strategy for a centralized organization with a large number of users

Estimated time to complete this lesson: 60 minutes

Understanding FE/BE Configurations

It is remarkably easy to configure an Exchange 2000 server as an FE system for another Exchange 2000 server. In the Exchange System Manager snap-in, click the server’s General tab. In the General tab, select the This Is A Front-End Server check box (see Figure 8.1). To put the changes into effect, you need to restart POP3, IMAP4, and the World Wide Web Publishing Service. This is most conveniently done in the Internet Services Manager console. Right-click the server object and select Restart IIS. In the Stop/Start/Reboot dialog box, make sure Restart Internet Services is selected, and then click OK.

You need to restart the services to activate the FE drivers for IMAP4 and POP3, implemented in IMAP4FE.DLL and POP3FE.DLL. By default, Exchange 2000 loads the BE drivers, IMAP4BE.DLL and POP3BE.DLL, which do not proxy the client communication. Every Exchange 2000 server is a BE server until you activate the FE feature explicitly. The HTTP-based FE component is EXPROX.DLL.

Figure 8.1 - Configuring an FE server

Advantages of FE/BE Configurations

In a typical FE/BE configuration, FE servers, deployed around BE systems, do not hold any mailboxes or public folders. The FE server merely receives the incoming client connections, contacts Active Directory to locate the home servers of the users where the mailboxes actually reside, and then relays the communication to the appropriate BE servers. The protocol between the FE and BE systems corresponds to the protocol used on the connection between the client and the FE server. In other words, FE and BE systems communicate with each other via HTTP, IMAP4, or POP3, depending on the messaging client (that is, Microsoft Outlook Web Access [OWA], IMAP4 client, or POP3 client) of the user. The FE/BE communication process is transparent to the user, so it appears as if all resources reside on the FE server.

FE/BE configurations have the following advantages:

• Encrypted communication without impact on BE servers To protect the client connections, Secure Sockets Layer (SSL) encryption can be enabled on the FE servers. The data encryption and decryption increases the processing overhead, but the FE server allows you to keep this overhead away from your mailbox and public folder servers. You can read more about security in hosted environments in Chapter 9, "Implementing Security for Hosted Services."
• IMAP4-based access to the entire public folder hierarchy IMAP4-based messaging clients are able to access public folders, but if the public folder does not reside on the user’s home server, the client must be redirected. To accomplish this, the home server returns an appropriate IMAP referral to the client, but problems occur if the client does not support IMAP referrals. In an FE/BE configuration, the FE server handles the referral process and redirects the client connection to the appropriate public folder server right away. To the IMAP4 client it appears as if all public folders reside on the FE server and the user has access to the entire public folder hierarchy.
• Increased protection based on firewalls It is possible to place the FE servers—in other words, the access points for your messaging clients—in a demilitarized zone (DMZ) and shield the internal network and BE servers from the Internet by means of firewalls. Firewall deployments are discussed in Chapter 9, "Implementing Security for Hosted Services."
• Multiple FE servers can share the same host name FE/BE configurations allow you to distribute incoming client connections across multiple FE servers to provide load balancing and eliminate single-point failures. Hardware load-balancing solutions are ideal, but it is also possible to use Network Load Balancing (NLB) of Microsoft Windows 2000 or the Microsoft Domain Name System (DNS) round-robin method. Load balancing is discussed in more detail later in this lesson.
• Single point of access to messaging resources Access to all resources in the organization is possible via a single FE server or load-balanced FE server farm. Resources can be spread across numerous BE systems, but the user does not need to know where the resources actually reside. The FE servers can determine the location of each resource in the organization via Active Directory. You can add further BE servers or move the resources from one BE server to another without affecting the client configuration. Users simply continue to access their mailboxes through the FE servers. FE/BE configurations are very scalable and easy to maintain in a dynamically growing environment.

More Info: Redirection of Incoming Client Connections without FE Servers

FE servers enable you to provide a single host name for all users to access their mailboxes or groupware forums. However, for OWA or IMAP4 clients that support referrals, you don’t need to implement an FE server. Users are free to choose any Exchange 2000 server in the organization. If this server does not hold the mailbox or public folder, it instructs the Web browser or IMAP4 client to connect to the correct location via an HTTP redirect request or IMAP4 referral. This redirection requires the client application to establish an explicit connection to the mailbox or public folder server, but this process is transparent to the user. The URL in the browser’s Address bar automatically changes and points to the user’s home server.

Disadvantages of FE/BE Configurations

FE/BE configurations can increase the scalability and resilience of your client access points, but at the cost of servers that do not hold any mailbox or public folder data. The FE servers increase the complexity of the environment and also increase the workload placed on Global Catalog (GC) servers, because whenever an Internet-based client attempts to establish a connection, the FE server must communicate with a GC to determine the correct BE server. Besides, FE servers do not support relaying of MAPI-based client connections. The FE server always redirects MAPI-based clients, such as Microsoft Outlook 2000, directly to the BE server (see Figure 8.2). For this reason, FE/BE configurations are not usually beneficial if your user community relies on Outlook 2000 for messaging and groupware.

Figure 8.2 - FE servers and MAPI-based clients

FE/BE configurations have the following disadvantages and limitations:

• Customized Transmission Control Protocol (TCP) ports are not supported The FE server always contacts the BE server over the default port that corresponds to the client access protocol. For instance, the FE server relays OWA connections to TCP port 80 on the BE server. If the BE server’s HTTP virtual server is listening at TCP port 8080 or any other custom port number, communication cannot take place. For IMAP4- and POP3-based access, you may use custom ports on FE servers; however, avoid using them, if possible, because they complicate system configuration. The benefits of custom port numbers are minimal anyway, because potential intruders can quickly determine customized ports using a port scanner. Table 8.1 lists the default port numbers for the Internet mail access protocols.
• Increased complexity of system configuration To support the relaying of client connections, you have to configure all virtual servers and virtual HTTP directories on the FE and BE servers identically. For instance, if OWA users are supposed to establish a connection to an FE server via a virtual directory called OWA (http://<FE server>/OWA ), then you need to create the same HTTP virtual directory on all BE servers; otherwise, the users might not be able to access their mailboxes. You can read more about protocol virtual servers in Lesson 2.
• MAPI-based clients not supported Because MAPI is not an Internet access protocol, FE servers cannot proxy incoming MAPI connections to BE servers. MAPI-based clients are redirected directly to the BE server that holds their mailboxes, as outlined earlier. If the BE server is not directly accessible for any reason, such as a firewall blocking communication based on remote procedure calls (RPCs), Outlook 2000 users are unable to work with their mailboxes.
• Network traffic and workload on GCs FE servers need to communicate with Active Directory for purposes of authentication and to determine which BE server holds the requested resources. If your FE servers are configured to authenticate users, communication with Active Directory takes place via RPCs. Normal communication with GCs, on the other hand, relies on the Lightweight Directory Access Protocol (LDAP). For security reasons, the GCs should not be located in the network segment of the FE servers, but high-speed connections should exist. You can read more about the deployment of FE servers and GCs in a protected network environment in Chapter 9, "Implementing Security for Hosted Services."

Table 8.1 Default TCP Ports for Internet Mail Protocols

Protocol	Clear-Text Communication	SSL-Encrypted Communication
HTTP (OWA, Web Folders, and others)	80	443
POP3 (Microsoft Outlook Express, Outlook 2000 in Internet Mail configuration, and others)	110	995
IMAP4 (Microsoft Outlook Express, Outlook 2000 in Internet Mail configuration, and others)	143	993

FE Servers and Active Directory

In Active Directory, every mailbox-enabled user object has a homeMDB attribute, which points to the server and mailbox store where the mailbox actually resides. Whenever a user contacts an FE server, a directory lookup via LDAP is performed to obtain this information. Busy FE servers can put a substantial strain on GCs. To mitigate the impact, Exchange 2000 Server stores directory information temporarily in its Directory Service Access (DSAccess) cache. The default time period is 10 minutes and the default cache size is 4 MB. The DSAccess cache can measurably reduce the number of queries sent to Active Directory.

More Info: Adjusting DSAccess Cache Parameters Manually

It is possible to adjust the expiration interval and size of the DSAccess cache by means of Registry parameters. It is also possible to disable the DSAccess cache entirely, which can be useful in troubleshooting situations. All Registry settings are located under the following Registry key:

 HKEY_LOCAL_MACHINE   \System  \CurrentControlSet    \Services  \MSExchangeDSAccess 

To deactivate the DSAccess cache, create a REG_DWORD value called CachingEnabled under the \MSExchangeDSAccess key and set it to 0x2. Deleting this value or setting it to 0x1 enables the DSAccess cache again. To specify an expiration interval or memory size limit, create a new key and call it \Instance0. The settings under the \Instance0 key influence how DSAccess handles information from the configuration naming context (NC). Under this key, you can place a REG_DWORD value named CacheTTL and specify the expiration time in seconds (such as 0x258 for 10 minutes). To customize the size of the DSAccess cache, specify a REG_DWORD value called MaxMemory and specify the size in kilobytes (such as 0x1000 for 4 MB). Alternatively, you can create a REG_DWORD value called MaxEntries and specify the maximum number of entries allowed in the DSAccess cache, but MaxMemory usually gives you more control over the cache size. A MaxEntries value of 0x0 stands for an unlimited number of entries in the DSAccess cache.

The longer you hold information in an FE server’s DSAccess cache, the more you reduce the network traffic and workload on the GC, but this increases the chance of the FE server using outdated directory entries. You also must considerthe increased demand for system memory on the FE server. Nevertheless, increasing the size of the DSAccess cache can help you achieve very high system performance. Remember to carefully test any configuration changes in your computer lab and during the pilot phase.

Note

---

The minimum memory size limit of the DSAccess cache is 2 MB. MaxMemory values of less than 2 MB are ignored.

POP3 and IMAP4-Based Access via FE Servers

Access to mailboxes based on POP3 or IMAP4 via FE servers is straightforward. The user specifies an FE server and mailbox account in the client configuration, and, when the user launches the client, the account information is passed to the FE server. Based on this information, the FE server queries the GC to determine the appropriate BE server to which to relay the client communication. The BE server receives the client request via the FE server, performs the user authentication, determines whether the user is allowed to access the mailbox, and, if this is the case, sends the mailbox data back to the FE server, which in turn delivers the results back to the client. The user can then download or read personal messages.

If an IMAP4 user attempts to access a public folder, the request is relayed to the user’s home server. Access is possible if the public folder resides on this server. Otherwise, the BE system returns an IMAP referral to an appropriate public folder server. This referral is not passed to the IMAP4 client. Instead, the FE server handles the referral process and redirects the client communication to the correct location, as mentioned earlier. POP3 clients are unable to access public folders.

Note

---

POP3- and IMAP4-based clients use the Simple Mail Transfer Protocol (SMTP) to send messages. Your users can specify the FE server or any other Exchange 2000 server as the host for outgoing messages, but the receiving SMTP virtual server is not part of the FE/BE configuration.

HTTP-Based Access via FE Servers

Every item, folder, and message in the Information Store has a Uniform Resource Locator (URL) associated with it. The Web Storage System (WSS) of Exchange 2000 Server makes this possible. You can access mailbox and public folder resources through a Web browser or a specialized client, such as the Exchange Installable File System (ExIFS). You can also use the Windows 2000 Web Folders feature.

By default, every Exchange 2000 Server has three HTTP virtual directories that can be used to access resources: Exadmin, Exchange, and Public (see Figure 8.3). The Exchange System Manager snap-in requires access to the Exadmin virtual directory for the purposes of public folder administration. The two remaining virtual directories give you direct access to mailboxes and public folders (Exchange) or public folders only (Public).

Figure 8.3 - The default HTTP virtual directories of an Exchange 2000 server

Explicit HTTP Connections

To establish an explicit HTTP connection, you need to specify the mailbox you intend to access in the URL, such as, http://Adventure/Exchange/Administrator (see Figure 8.4). The FE server is then able to extract the mailbox name from the URL, attach the SMTP domain name specified in the virtual directory’s configuration to this name, and then perform a directory lookup to find the corresponding mailbox-enabled user account in Active Directory.

For example, let’s say an Administrator account has the SMTP address [e-mail]. If adventure-works.com is also specified as the SMTP domain (in the General tab) of the Exchange virtual directory, the FE server can create the correct SMTP address. Correspondingly, the FE server can find the administrator object in Active Directory, examine its homeMDB attribute to determine the mailbox location, and then proxy the client connection to the HTTP virtual server (Exchange) on the BE server. The FE server is not necessarily required to perform any authentication because the BE system challenges the user for his or her credentials (that is, user name, domain name, and password).

Figure 8.4 - Explicit and implicit HTTP connections to a mailbox

The advantages of explicit HTTP connections are as follows:

• You do not need to enable authentication on the FE servers. This procedure is discussed further in Chapter 9, "Implementing Security for Hosted Services."
• You can specify any mailbox to which you have access rights in the URL.

Implicit HTTP Connections

Explicit connections to mailbox resources are straightforward, but they require mailbox-specific information, which complicates the URLs for e-mail access slightly. To simplify the user environment, Exchange 2000 Server supports implicit HTTP connections in which only the virtual directory is specified (that is, http://<server name>/Exchange ), as shown in Figure 8.4.

The challenge is to find the user’s mailbox. To determine the location, the FE server must authenticate the user, which yields the user’s Windows 2000 account that holds the homeMDB attribute. As soon as it knows the account, the FE server can query the GC via LDAP to obtain the missing pieces of information and then redirect the user to the correct BE server and mailbox. The rest works as with explicit HTTP connections.

Implicit HTTP connections simplify the end-user environment, but they have the following limitations:

• Access is possible only to the mailbox that is directly associated with the user’s Windows 2000 account. If the user wants to access other mailboxes, such as a resource mailbox, an explicit URL must be specified.
• Implicit connections only work with Web browsers and OWA. Alternative HTTP clients, such as the Web Folders feature in Windows 2000 Explorer, cannot use implicit HTTP connections.
• Implicit connections require authentication on the FE server, which in turn requires authentication and RPC-based communication with Active Directory. This might not be possible in a DMZ-oriented deployment, as discussed in Chapter 9, "Implementing Security for Hosted Services."

More Info: Simplifying OWA URLs

Based on implicit HTTP connections and the redirection capabilities of Internet Information Services (IIS), you can greatly simplify the URLs that your users need to know to access their mailboxes.

To access Exchange 2000 Server via a simple URL, such as http://exchange. adventure-works.com , perform the following steps:

1. Register the host name exchange for your FE server or server farm in an A (host) record in the DNS. If you don’t want to use the name exchange, choose whatever name suits you.
2. Launch the Internet Services Manager console, expand the node that corresponds to your FE server, right-click on Default Web Site, and then select Properties. If you have implemented a server farm, you need to repeat these steps on all FE servers.
3. Click the Home Directory tab.
4. Under When Connecting To This Resource, The Content Should Come From, select the A Redirection To A URL option.
5. In the Redirect To box, type /Exchange , which redirects the Web browsers to the URL http://exchange.adventure-works.com/Exchange or whatever host name you specified in step 1.
6. Click OK. You do not need to restart the IIS. The changes take effect immediately.

At this point, your users need only to request the URL http://exchange. adventure-works.com, and IIS forwards the browsers to the default HTTP virtual directory for mailbox access on the Exchange 2000 server. Keep in mind, however, that an implicit HTTP connection is established, requiring the FE server to perform user authentication.

HTTP Connections to MAPI-Based Public Folders

Access to MAPI-based public folders differs for authenticated and nonauthenticated users. For authenticated users, the FE server can determine the mailbox location and the default public store associated with the user’s mailbox store. The default public store is specified in the properties of the user’s private information store database (in the General tab). By default, this public store is on the user’s home server, but you could assign it to a different machine if you want to point users to a dedicated public folder server. Public folder access strategies are discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

The FE server relays the client connection to the BE server that holds the default public folder store to give the user access to the same set of folders that he or she would access using Outlook 2000. However, if the FE server cannot authenticate the user for any reason, it cannot locate the default public store. The user accessing the MAPI-based public folder hierarchy via the Public virtual directory is simply unknown until a BE server performs the authentication. In this scenario, the FE server obtains a list of all public servers that can provide access to the MAPI-based public folder hierarchy and then contacts these servers in a load-balancing way. If the FE server cannot contact the BE system via HTTP for any reason, the BE server is marked as offline and the client connection is relayed to another machine. No further communication attempt is made to the offline BE server. FE servers mark unavailable BE servers as offline for a period of 10 minutes.

The presence of the MAPI-based public folder hierarchy on a BE server does not necessarily mean that the server also has the contents available. The contents might exist on yet another machine. In this case, the contacted BE server returns a list of public folder servers that have the content to the FE server. The FE machine, in turn, transparently picks one server from this list to which to redirect the client connection.

HTTP Connections to Alternate Public Folders

In addition to MAPI-based public folders, Exchange 2000 Server supports alternate hierarchies, as explained in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server." Alternate public folders are unavailable to MAPI-based clients, such as Outlook 2000, but you may find them useful if you plan to implement Web-based groupware solutions.

Although MAPI-based public folders are accessible via the Public HTTP virtual directory, no virtual directory exists for alternate hierarchies by default. After you create the alternate hierarchy and associate it with a public folder store, you need to create an HTTP virtual directory explicitly for it. In the Exchange System Manager snap-in, expand the server object that corresponds to your FE server, expand the Protocols container, expand HTTP, and then expand the Exchange Virtual Server node. Right-click Exchange Virtual Server, point to New, and then select Virtual Directory. Specify a name in the General tab, then under Exchange Path, select Public Folder, click Modify, and then select the desired alternate hierarchy. Do not forget to create the same HTTP virtual directory on all BE servers that hold a public store associated with the hierarchy. The configuration of virtual directories is discussed in more detail in Lesson 2.

Alternate hierarchies are not associated with any mailbox stores. This implies that FE servers cannot determine a preferred or default public server when a user requests access to an alternate public folder. To give the user access to the contents, the FE server always determines the complete list of public servers that hold the alternate hierarchy and distributes the user connections across them in a load-balancing way. This mechanism works exactly the same as it does for unauthenticated access to MAPI-based public folders.

Designing FE Server Configurations

It is very easy to configure an Exchange 2000 server as an FE server, but it is not that straightforward to fine-tune the configuration to meet users’ demand for fast response times and reliable system operation. The This Is A Front-End Server check box does not take care of all substantial configuration issues. Among other things, you might want to specifically optimize the server hardware for relaying network communication. You might also want to stop idle services to free unnecessarily consumed resources.

When designing FE server configurations, the following are important questions:

• How many FE servers do you need to implement to provide reliable access points to Exchange 2000 Server?
• Which hardware is available for FE servers?
• Which services are the FE servers supposed to provide to the end users?

Load-Balancing FE Servers

You can deploy multiple FE servers and connect through any of them to your mailbox or public folder server. All FE servers will be able to determine your home server and relay the connection to the correct BE system. Multiple FE servers allow your users to continue to participate in messaging even if a particular FE server is unavailable for some reason, such as maintenance. Microsoft recommends deploying one FE server for every four BE systems. It is advantageous to have at least two FE servers for fault tolerance through redundancy, if your budget permits the investment.

Multiple FE servers do not require users to specify different host names if you group the systems together by means of a load-balancing solution in a server farm, sometimes called a cluster. Do not confuse a load-balancing cluster with a server cluster. In a load-balancing cluster, you use software or hardware load-balancing mechanisms to randomly distribute the load of incoming TCP connections across all of your FE systems. To the user, it appears as if the client is always accessing the same host (see Figure 8.5). The users do not know which FE server is actually handling their client connections. In a server cluster, on the other hand, you use the Windows 2000 Advanced Server or Datacenter Server Cluster service to group up to four nodes around a shared storage system. Windows 2000 clustering is covered in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Figure 8.5 - Multiple FE servers in a load-balancing environment

Powerful load-balancing solutions, such as NLB of Windows 2000 Advanced Server, are able to increase the resilience of your messaging system. For example, NLB is able to reconfigure the load-balancing environment automatically when an FE server fails or is taken offline. Existing connections to the offline server may be lost, but new client requests are then redirected to one of the remaining computers. When you reboot the offline server, the system joins the load-balancing cluster again.

To configure your FE servers as a load-balanced cluster, use one of the following technologies:

• Hardware load balancing Hardware load-balancing solutions, such as Cisco Local Director content switches, can manage and distribute the client traffic to multiple servers. Hardware load balancing is advantageous if you want to implement a high-performance environment with numerous FE servers.
• Microsoft NLB This load-balancing solution is available at no extra cost in the Windows 2000 Advanced Server and Datacenter Server product packages. NLB is easy to install and supports up to 32 FE servers. If you need more servers, use a hardware solution. NLB supports the mapping of client IP addresses to a particular FE server (Affinity), in which case the clients are serviced by the same FE server as long as the configuration of the load- balancing cluster doesn’t change. For more information about Microsoft NLB, see the Windows 2000 Server product documentation.
• DNS round-robin This mechanism is based on the simple concept of having the same host name mapped to the IP addresses of multiple FE servers. To distribute user connections, DNS rotates the IP address it returns each time the host name is requested. Round-robin DNS does not monitor the status of the FE servers, however, and will continue to return the IP address of a failed system. Internet Explorer requests are repeated if a particular FE server is not responding, which eventually points the client to an available server. Compared to other load-balancing solutions, however, round-robin has significant disadvantages because information about client connections or unavailable servers is not maintained. If you use DNS Server for round-robin load balancing, make sure the Enable Round Robin setting is activated in the DNS snap-in; otherwise, DNS Server always returns the same IP address to the client.

More Info: How to Enable Windows 2000 NLB

You can activate Windows 2000 NLB individually for each network card in your FE servers using the following steps:

1. On the desktop, right-click My Network Places, and then select Properties.
2. In the Network And Dial-Up Connections window, right-click the network connection that is handling incoming client connections (such as Local Area Connection 1), and then click Properties.
3. In the Properties dialog box of your network connection, click Install.
4. In the Select Network Component Type dialog box, select Service, and then click Add.
5. In the Select Network Service dialog box, select Network Load Balancing, and then click OK.
6. To configure NLB, in the Properties dialog box of your network connection, select Network Load Balancing, and then click Properties. Use the Cluster Parameters, Host Parameters, and Port Rules property pages to configure the load-balancing cluster. Among other things, you must specify the cluster’s virtual IP address, for which the cluster is supposed to perform load balancing, as the Primary IP Address. You can read more about the configuration of NLB in the Windows 2000 Advanced Server and Datacenter Server product documentation.

Designing the FE Server Hardware

FE servers store very little data locally, so they do not require a high-performance hard disk system. They should be equipped, however, with multiple, powerful central processing units (CPUs) with up to 512 MB of RAM and a high-performance network interface to best handle the communication between messaging clients and BE servers.

Depending on the number of users you plan to support, you might want to consider dual- or quad-processor systems, as outlined in Table 8.2, although this is not a strict requirement. You can also achieve reasonably high capacity with moderate server configurations. As discussed in the previous section, you can deploy numerous FE systems in a load-balancing environment to reduce the workload per individual server. You can read more about designing server hardware in Chapter 3, "Assessing the Current Network Environment."

The configuration of FE servers depends on many factors, including the number of users per BE server, the protocols used, and the expected use of the messaging resources. To reliably determine whether the intended FE system configuration satisfies the messaging needs of your users in a test lab, use the Exchange Stress and Performance (ESP) tool from the Microsoft Exchange 2000 Server Resource Kit. Detailed information about optimal hardware configurations is also available in the "Microsoft Exchange 2000 Front-End Server and SMTP Gateway Hardware Scalability Guide." You can download this white paper from the Microsoft Web site (www.microsoft.com ). Search for the phrase "E2K_FEScalability."

Table 8.2 Microsoft Recommendations for Designing FE Server Hardware

	POP3	OWA	IMAP4
Processor	No more than two processors per server	No more than four processors per server	No more than two processors per server
FE/BE ratio	One FE server for up to four BE servers	One FE server for up to four BE servers	One FE server for up to eight BE servers
Memory	256 MB of RAM	30 KB of RAM per active connection	256 MB of RAM (512 MB of RAM for five or more BE servers)
Network interface	Two 100-Mbps network cards or one-gigabit Ethernet card on a dual-processor machine	Two 100-Mbps network cards or one gigabit Ethernet card if the system must service more than 5000 connections	One 100-Mbps network card (it might be necessary to add an additional 100-Mbps network card or upgrade to gigabit Ethernet if your users frequently work with large attachments)
SSL overhead	Twice the processor capacity	Three times the processor capacity and 60 percent more memory	50 percent more processing capacity and 10 percent more memory

Configuring FE Server Services

Perhaps the most complex task in configuring your FE servers for maximum performance is eliminating unnecessary services. Several services, such as the Information Store, run on every Exchange 2000 server by default, but are not needed on FE machines. Among other things, you have to edit the server’s Registry directly. Make sure you configure all of your FE servers identically and carefully test the configuration settings in a computer lab and during the pilot phase to avoid unpleasant surprises during the production rollout.

Use the following steps as a guideline to configure your FE servers:

1. Install Exchange 2000 Server on the FE machines and add the servers to the same organization as the BE servers.
2. Launch the Exchange System Manager snap-in. In the server’s General tab, enable the This Is A Front-End Server check box, and then restart IIS to load the FE drivers.
3. Configure HTTP virtual servers and virtual directories as desired. Keep in mind that the configuration must match exactly on all FE and BE servers. You can read more about virtual servers and virtual directories in Lesson 2.
4. Dismount and delete the mailbox and public folder stores. One exception applies to this rule: If you intend to run the SMTP service directly on an FE server, you cannot delete the mailbox store. If possible, implement a dedicated SMTP relay host in addition to the FE systems. In any case, you must delete the public folder store, or your users will experience problems when accessing public folders.

   Note

   ---

   Make sure you apply all desired configuration changes to the HTTP virtual directories in the Internet Services Manager console (such as enabling SSL encryption) before deleting the mailbox and public folder stores. Deleting the stores invalidates the file paths to the server’s M drive, which in turn prevents the configuration of Exchange 2000-related HTTP virtual directories from within the Internet Services Manager console.

5. Launch the Services snap-in to stop and disable all superfluous services on the Exchange 2000 server, such as the Network News Transfer Protocol (NNTP) service. You can also eliminate the SMTP service if you implement a dedicated SMTP relay host on another machine). Table 8.3 lists the required Exchange 2000 services for each Internet access protocol.

Table 8.3 Required Exchange 2000 Services for Internet Access Protocols on FE Servers

Internet Access Protocol	Required Services	Comments
HTTP	WWW Publishing Service IIS Admin Service System Attendant All other nested, dependent services	The System Attendant is required to transfer configuration changes applied to the HTTP virtual directories in the Exchange System Manager snap-in from Active Directory into the IIS database. If you do not intend to change the configuration, you can stop the System Attendant service.
POP3	Exchange POP3 service Information Store service System Attendant All other nested, dependent services	The POP3 service depends on the Information Store, which in turn depends on the System Attendant. However, on an FE server, these dependencies are not required. To remove them, edit the DependOnService value in the Registry under: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \POP3SVC The System Attendant is only necessary if you want to update the IIS metabase, as explained earlier. If you intend to leave the Information Store and System Attendant running, do not delete the default storage group from the server (but delete the mailbox and public stores) to avoid Information Store startup problems.
IMAP4	Exchange IMAP4 service Information Store service System Attendant All other nested, dependent services	Same as for the POP3 service. The DependOnService value is located in the Registry under: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \IMAP4SVC

Designing an FE/BE Environment for Trey Research

Trey Research, a medical supply company with 1500 employees, has headquarters in Chicago, Illinois, and several subsidiaries across the United States and Mexico. The company is considering an implementation of FE servers to simplify the messaging environment for its 500 mobile users. "As a medical supply company, we must obey very strict security policies," says Ted Bremer, Chief Information Officer. "These policies force us to rigorously control access to our internal network. On our firewalls, we can only allow SSL-encrypted communication via HTTP. Correspondingly, we’ve investigated several options to support our mobile users, and OWA turned out to be ideal for us. We don’t need to configure anything extra on our firewalls. Besides, the OWA client provides messaging, calendaring, and contact management functionality, which is exactly what our mobile users need. We are planning to implement front-end servers to maintain a single namespace for simplified access." Trey Research currently operates an Exchange 2000 organization with two mailbox servers, each holding 750 mailboxes.

Bremer designed the following FE server topology:

1. To support a single namespace, we will implement two FE servers in a load-balanced configuration. This will provide us with the desired level of performance and fault tolerance. We will install Windows 2000 Advanced Server on both of our FE servers and use NLB to implement the load-balancing cluster.
2. Because security is vital to us, we will enable SSL-based encryption on our FE servers. The communication between the FE and BE servers does not need to be encrypted because the network itself is considered secure. We need to design an appropriate firewall strategy to protect our internal data from exposure to unauthorized users.
3. We will implement two single-processor machines with 256 MB of RAM. Each FE server will have a single network card. We do not expect any bottlenecks, but will thoroughly test our systems prior to the production rollout.
4. With the exception of the WWW Publishing Service, all Exchange 2000- related services must be disabled on the FE servers.

Activity: Designing FE/BE Environments

In this activity, you decide whether and how to implement FE servers for two companies— Humongous Insurance and Proseware, Inc.—that plan to provide flexible access to Exchange 2000 resources.

Tip

---

You can use Figure B.22 in Appendix B as a guideline to accomplish this activity.

Scenario: Humongous Insurance

For more than 150 years, Humongous Insurance, a national financial institution with headquarters in New York and customer service centers in all major U.S. cities, has assisted its customers with their insurance needs. The company has deployed Exchange 2000 Server in all locations. All of the insurance company’s employees and licensed agents work with Outlook 2000 or Microsoft Office XP and Internet Explorer 5.5 on their desktops and mobile computers. "Our agents use Microsoft Outlook XP configured with offline folders to access information anywhere and anytime," says Stephanie Bourne, Director of IT. "An agent visiting a prospect simply can’t ask for an online connection to our network to request a personal quote or reevaluate the prospect’s coverage needs. However, we now have implemented a very complex Web-based workflow application that our licensed agents can use to report and track insurance claims whenever they are online. This solution is integrated with Outlook 2000 and later versions by means of public folder home pages. In this way, our users have convenient access to the Web-based workflow solution. Remote users access our claim-tracking system via dial-up connections only."

At Humongous Insurance, the Web-based claim-tracking solution is considered a business-critical application. Fault tolerance is very important. For this reason, the tracking system is replicated to three public folder servers. You now need to decide whether it makes sense to deploy FE servers in Humongous Insurance’s Outlook-based Exchange 2000 organization. The insurance agents must be able to work with the claim-tracking solution even if a particular server is down.

1. Which FE server strategy would you suggest to Humongous Insurance and why?

Scenario: Proseware, Inc.

Proseware, Inc., a modern and business-driven national ASP with its headquarters in Miami, Florida, is increasingly selling companies and governmental agencies on the idea of outsourcing IT operations. "My opinion is that gas stations should sell gasoline, airlines should fly airplanes, banks should deal with money, and IT companies should maintain IT infrastructures," says Guy Gilbert, Head of IT Operations at Proseware. "You don’t need an internal IT department if you’re not an IT company. Proseware started as an average Internet service provider, but we are constantly adding further functions to our portfolio, which keeps us on the cutting edge. With Exchange 2000 Server, we intend to run messaging and groupware services on behalf of our business customers. You might find us ambitious, but we are intending to roll out OWA to 350,000 private users."

It is your task to design a high-level configuration of FE servers for Proseware, Inc.

1. To maximize the utilization of high-end server hardware, Proseware, Inc. plans to place 5000 mailboxes on each information store server. How many FE servers would you have to implement according to Microsoft’s recommendations?
2. Proseware wishes to have a single namespace (for example, http://www. proseware.com/Mail ) in which all users can reach their mailboxes. The company wants to avoid bottlenecks and single points of failure. Can you use Windows 2000 NLB to configure a load-balancing cluster of FE servers?
3. Which load-balancing solution should you implement to achieve maximum system performance?
4. What hardware configuration would you recommend for the FE servers if you consider SSL-based encryption for incoming client connections?
5. Which Exchange 2000-related services do you need to run on the FE servers at minimum?

Lesson Summary

An FE server is a system that proxies client connections to appropriate mailbox or public folder servers, also known as BE servers. FE servers support HTTP, IMAP4, and POP3, but MAPI-based clients cannot benefit from this type of configuration. FE servers should not store any mailboxes or public folders.

FE servers provide several advantages to the Internet mail community. Among other things, they allow you to implement a single namespace in which all users can access the resources. FE servers are also an important component of sophisticated firewall configurations to protect the internal messaging environment. SSL encryption can be enabled on the FE computers and you can keep this workload away from the BE servers.

When designing a basic FE/BE environment, you need to determine the required number of FE servers and decide which load-balancing technology to implement, if any. You also need to clarify which services the FE servers are supposed to provide to the end users. To avoid wasting system resources, stop all unnecessary services on the FE servers. This might require you to edit the server’s Registry to eliminate the IIS services’ dependencies on the Exchange System Attendant and Information Store services. The System Attendant is only needed if you want to update the IIS metabase with configuration changes applied to protocol virtual directories in the Exchange System Manager snap-in. The Information Store is required if you plan to run the SMTP service on the FE system. Otherwise, you can safely disable these services.