Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

   

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath
 
 

Exchange 2000 Front-End/Back-End

Page 1 | Page 2 | Page 3 | Page 4 | Page 5

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.

To learn more about WebDAV, see:
http://msdn.microsoft.com/workshop/standards/webdav.asp
http://msdn.microsoft.com/library/default.asp?URL=/library/techart/wssdevaccess.htm

Exchange 2000 Front-End/Back-End

Columnist's Index
Page 1 | Page 2 | Page 3 | Page 4 | Page 5

Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Stephen Bryant or Pro Exchange. OutlookExchange.Com, Stephen Bryant and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Copyright Stephen Bryant 2008