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.
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
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:
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.
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:
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 |
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
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
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
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 administrator@adventure-works.com. 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:
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:
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:
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.
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.
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.
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:
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:
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:
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 |
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:
Note
Table 8.3 Required Exchange 2000 Services for Internet Access Protocols on FE Servers
Internet Access Protocol | Required Services | Comments |
---|---|---|
HTTP | | 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 | | 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 | | Same as for the POP3 service. The DependOnService value is located in the Registry under: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \IMAP4SVC |
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:
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
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.
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.
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.