Are Front-End/Back-End Servers Necessary?
Exchange 2000 is a lot smarter than I first thought. Since its folders and mailboxes are published to the Active Directory, it actually knows to look there before checking for local Exchange resources. Let me explain a lab I set up to demonstrate this, then we will dive in a little more. Here is a sample of “servers” in my lab:
In this Exchange 2000 Org, I have added mailboxes to each server. The Active Directory keeps these settings under an Exchange attribute on the Class object USER for each specific person having a mailbox. But if you look at the Exchange objects in the Users and Computers console, you see that the folders (in the default TLH) are also added into the Active Directory and are further identified by what server holds the master copy of the folder.
As you can see, this view represents specific system accounts and various public folders. When you add public folders, the related information is published in the Active Directory. Each Exchange Server in the routing group is notified of a hierarchy change and information concerning the folder structure is replicated.
In this case, I created a folder called OWATEST on Server2 and, within minutes, a folder was created on the M: drives of the two other Exchange 2000 servers.
Not only that, IIS on the other servers had begun to report the folder as well. So I now have a folder called OWATEST that is homed on Server2, but also appears to be on ServerA. This is where the magic lies; the data does not exist on ServerA, but the hierarchy does. Remember how this occurred in Exchange 5.5? The hierarchy was always replicated to the other servers. Well now in Exchange 2000 (using the default store) the servers can automatically redirect us to the appropriate server.
Here is an example of what I mean. I launched IE from the client machine, entered HTTP://SERVERA/PUBLIC/OWATEST, and hit the Enter key.
ServerA does a quick reference and sends me to the server that actually contains the data: Server2.
Cool, huh? This also works on mailboxes. By default, Exchange 2000/IIS servers will make a quick check to see which server holds the data, then the client is redirected. It does not matter how you create the folder. In this example, I created the folder using Windows Explorer. You can also create the folder with the OWA interface or custom interfaces.
The nice thing about this is that you can still have a single namespace and route folks to their mail server. Let me give you an example:
On ServerA, I added an additional IP Address of 10.10.10.50 to the NIC. Using DNS, I created a record for the a host named EXCHANGE and assigned the record to the 10.10.10.50 address.
Next, I opened the IIS console and changed the properties of the Default Web Site so that it does not use 10.10.10.50. More specifically, I told IIS only to use 10.10.10.1. Now, I could create a new web-site named Exchange on the same server and assign 10.10.10.50 to that site.
On the properties page of the new Exchange site, I instructed the site to redirect users to http://servera/exchange. There, we have now created a single name space for all email. Users need only to enter http://exchange and they will be sent directly to their mail.
Now imagine if your network looked like this:
In this scenario, you could use the same procedures for each server and allow each localized DNS server to point users to the appropriate server. In an environment with fast links, you could even consider DNS round-robin or some other way to provide DNS look-up for the server. The beauty in this is that users are always redirected to their server, which, in most cases, should be local. You will find out later that FE/BE servers will not do this for you.
Front-End/Back-End Overview
After you have installed your second Exchange 2000 server in the organization, you can elect to turn it into a front-end server. There are no settings involved for a back-end server, which basically operates as a normal Exchange 2000 server. In fact, there are no real front-end settings either. You are either an Exchange 2000 front-end server or a regular Exchange 2000 server, period.
We are going to track exactly what an FE server does and what it does not do. We’ll also look at the actual performance of a BE server with and without its FE counterpart. To help us do this, I put together another small lab.
First, let’s turn Server1 into the FE server. Making this change is the easiest thing you will ever do! Open the Exchange System Manager console and expand the Servers node under your org.
Right-click on the server you want to convert to the FE and place a check-mark in the This is a front-end server checkbox. Click OK and reboot the server to complete the transition. In our case, we selected Server1 and chose This is a front-end server.
So what have we done? By checking this box, we have instructed the server to no longer refer us to the server that holds the requested information. Now the server must perform the same look-ups as before, but now it will handle the authentication and all communication to the “BE” server. Let me demonstrate; first I try to open our OWA session from the FE server:
I enter the same information as before. Only this time I am prompted for a password.
Note: FE servers ALWAYS prompt for a password even if you already have a token in memory. FE servers only understand basic authentication. So if you have an in-house application and do not want to prompt the user for authentication, don’t use FE servers.
Next, instead of redirecting me to the appropriate Exchange Server, the FE server acts like the server it found in the back. Notice the Address bar shows an Exchange directory on Server1.
Guess what? Server 1 has no local store. I stopped all the services. There are a couple of ways to do this, the easiest is to simply stop ALL Exchange services and turn their start-up settings to manual. If you want to totally dismount the local stores, use the Exchange System Manager to dismount the public store(s). It is recommended that you leave the private store in place in order to generate NDRs, etc. In my example, I do both just to make sure no store is loaded.
In essence, Exchange Server is no longer running or even functioning on the FE server, Server1. What is functioning is a WebDAV redirector that still understands how to look at the Global Catalog for Exchange objects.
Remember our OWATEST folder? It is also addressable using the OWA interface and, as you can see, Server1 claims the folder is in its own local store (even though there is no local store.)
Front-End Redirection
As I mentioned before, Exchange Servers research the Active Directory to find Exchange objects. In a normal situation, the server that actually holds the data instructs the referring server to redirect the client. FE servers are told to respond as if they hold the data. In many cases, it is the BE server that tells the FE server what to do.
Following is a packet trace I did in the lab while a client requested an OWA session from the FE server. In this case, the mailbox was on ServerA. First, the client performs a DNS lookup for SERVER1.BRYANT.COM. The response comes and the client then performs a GET request for an OWA session. I started this whole process by accessing http://server1/exchange from Internet Explorer. (Remember that Server1 is the FE.)
The FE then tries to locate the appropriate BE server. This is done through a series of LDAP and DNS calls, as well as scattered RPC sessions.
Once the FE Server finds the appropriate BE Server, it begins to echo the client requests verbatim to the BE server.
You would expect the BE server to then respond with http://servera/exchange/mailbox information, but instead it tells the Front-End server exactly what to say to the client. The BE tells the FE to respond with http://server1/exchange information. Basically, the BE is doing a lot more than I thought it would.
I have already mentioned WebDAV in this article because this protocol is at the heart of Exchange 2000. WebDAV, an extension to HTTP, is an emerging protocol standard for performing basic file system operations across the Web using Distributed Authoring and Versioning (DAV). Because it is based on HTTP, it is an excellent way to code through firewalls. When used in conjunction with XMLHTTP, WebDAV can also define the XML post data structure. OWA for Exchange 2000 is a prime example of this combination. In fact, it is this combination that we analyzed earlier in this article.
WebDAV and pure HTTP are currently the only (programmers) protocol that FE servers can “proxy” to BE servers. Let me repeat that:
FE servers will only process WebDAV requests destined for an Exchange 2000 Web Storage Sytem. FE servers will not proxy CDO, ADO, MAPI or any other programming protocol other than WebDAV.
Performance
Network Considerations
There are none. What I mean by that is you must place FE servers in the same domain as their BE counterparts. As we saw in the protocol traces, the FE must also be able to find your internal DNS Server, Active Directory Domain Controller, and a Global Catalog for your domain. The FE server uses these tools, and RPC in many cases, to find and talk to the BE servers.
Also, a FE server does not care where you came from. Its sole intention is to proxy your requests. It will not make a determination of your LAN, access speeds or anything else. The FE server will look in AD to find the source you are requesting and proxy the request to that server on your behalf. Essentially, there are no load-balancing characteristics nor can the server provide your mail if your mail server is unavailable.
Here is my one-sentence summary:
If you are creating WebDAV applications and need to prompt users for authentication information and have no specific performance SLAs (for example, folks entering from the Internet), and expect tens of thousands of people to use this application then FE/BE is what you want!”
Internet Access Example:
This model is exceptional for a company who wishes to use OWA as the default mail access, especially if this access will be available from the Internet. In this configuration, there are no Exchange stores directly exposed to the Internet. Moreover, the first firewall needs only to open port 80 to allow users to connect to the FE server. You will however, need to open quite a few ports between the FE and BE servers to allow for DNS, LDAP, and quite possibly RPC traffic. This should be pretty easy with a direct IP map that allows the FE greater access to your network.
Server Performance
So, what exactly does an FE server offload from the BE servers:
- Authentication As I mentioned earlier, FE servers only support basic authentication. If you are using SSL, the FE will handle this as well. SSL adds a tremendous amount of overhead on transactions. In most cases, it doubles or more than doubles the processor usage on the server and the amount of data that is sent over the wire.
- Controls Your custom applications will use a set of tools or controls for the client. The FE server acts as an IIS server and provides the controls you specify to the HTTP client.
How much load is actually taken from the BE server? Here is a short performance snapshot
The peak on the left was generated when a client entered http://server2/exchange directly to access mail. The peak on the right was generated when the client entered http://server1/exchange and accessed data on Server2 through the FE server. As you can see the load on the server is slightly lower when accessed this way. Based on this data, routing clients through an FE does not dramatically reduce the load on the BE servers. The bottleneck will continue to be on the BE servers (in most cases.) The overall recommendation is one FE to four BEs. This should provide good balance.
As a general rule, add BE servers as you would normally to overcome capacity issues on the mail-servers. Add FE servers to provide redundancy to the browser clients (think of it as an IIS server farm.)
I recommend that you perform more thorough tests when identifying potential volume on your servers.
Summary
FE/BE is not the cure-all for application development. It is great for a lot of things, and not-so-great for other things:
- Unless all Public Folders are fully replicated, it will probably take two HTTP queries and hashing to find the server with the data.
- You have little control over where users are redirected. If FE servers are placed in Dallas, BE servers in Dallas will probably be used for data access even though a replica exists closer to the user.
- A BE server that returns to service may not be known to the FEs for 10 minutes
- FE/BE does not support NTLM or Kerberos. The users will always be prompted for a user name and password at the start of the session.
- Only Basic HTTP 1.1 authentication is supported by FE/BE
- The supported FE client protocols include HTML/HTTP, POP3, IMAP4, NNTP, WebDAV, FrontPage and Office Server Extensions protocols, H.323 and T.120. The server-to-server protocol services include SMTP, NNTP, and X.400. CDO and ADO is not supported in an FE/BE configuration.
Let’s consider the big picture; how many applications are you going to run? What is the best way to publish all applications in your environment?
Here’s one idea: DNS provides an excellent way to use a single namespace for applications. By providing site specific entries such as http://application, users can be assured that they are always being directed to the appropriate server—and the closest server for that matter.
In this scenario, a degree of load-balancing becomes a matter of design. If traffic loads are high, build an application server that is closer to the user population. Load-balancing will occur over the enterprise with little to no restrictions. The application determines its availability and replication schedules. If a local site needs fast access to the application, a local server is built and a local DNS entry is added for the application. Each site can determine if clustering is required and no additional servers are required.
If you are considering creating WebDAV applications for access to data behind a firewall, FE/BE is absolutely your best choice.
