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

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.

© Copyright ECMS, Inc., 2001

Exchange 2000 Front-End/Back-End

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