• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 411
  • Last Modified:

Exchange 2003 Front-End use

What is a front-end server used for?  I tried to set one up, but when I logged into OWA it just forwarded me to the server that holds my mail.  I would like to have the web server only hold the web components and have the mail-boxes actually be on a different server completely inside the firewall.  Can this be done?  I have Exchange 2003 Enterprise edition.
0
SkipFire
Asked:
SkipFire
  • 6
  • 4
  • 4
  • +1
3 Solutions
 
Carlo-GiulianiCommented:
From Microsoft:
"The primary advantage of the front-end and back-end server architecture is the ability to expose a single, consistent namespace. You can define a single namespace for users to access their mailboxes (for example, https://mail for Outlook Web Access). Without a front-end server, each user must know the name of the server that stores their mailbox."

Probably the second-most important advantage is that SSL processing is offloaded to the front-end server(s).

There are a number of other so-called advantages, including keeping mailboxes inside the firewall(s).  The front-end does not actually forward to the back-end...it proxies.  But the front-end does still need to communicate with AD servers by RPC, so the advantage of putting it in the DMZ is limited.

Read all about it here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E64666FC-42B7-48A1-AB85-3C8327D77B70&displaylang=en
0
 
rajeev_niceCommented:
There is something called a DMZ (DeMillitarized Zone) in a Network which normally is the area between the Outer Firewall and inner Firewall of an Enterprise network. The DMZ is used to keep those servers and Frontends which wud interact with outside requests like from Internet or Remote Network. These servers in turn send the requests to the internal Network (Intranet) thru a Firewall which permits only specific trusted IPs and Ports.

+---------+                                        +------------+      
|Internet |          External Firewall       |                |   Internal Firewall
| Zone    |-------> |------------|           | DMZ         |  |-----------------|         INTRANET Zone
|            |            |------------|           |                |  |-----------------|    
+---------+                                         +------------+

U keep ur Exchange Server Front End in this DMZ which is exposed to outer netwrok and the Backend Server is kept inside the Internal Network. The front End interacts with Backend to fetch emails and other stuff.

U can search on Microsoft Knowledge base for more info on Keeping ur Front End in DMZ.

HTH
0
 
SkipFireAuthor Commented:
I did some tests and what you both describe does seem to be the case for all the protocols client protocols, but it doesn't seem to work with OWA.  Every time I log into my front-end server's OWA it tries to send me to the OWA on the server that houses my mailbox.  If I am inside my office that is fine, but if I am outside it can't get to that box because of the firewall and because the box with my mailbox is on a private address.  Is it not possible for the front-end Exchange server to retrieve messages for use with OWA?  The POP and SMTP seems to work regardless of what Exchange server I connect to, even the ones that aren't listed as front-end will retrieve messages from other boxes.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jsavage66Commented:
If your OWA server is on the DMZ you'll need to open some ports to allow traffic from OWA to your internal Exchange server.  You can check out the following web page.

http://support.microsoft.com/?kbid=259240

Another option is to place your OWA server inside your firewall (on the same subnet as your Exchange box) and use your firewall to filter ONLY SSL traffic to your OWA server.  Since both servers are on the inside network, you'll save yourself a lot of headache by opening a ton of ports on the firewall, and ultimately making it less secure.


0
 
SkipFireAuthor Commented:
I have no DMZ, just an internal network with a few ports forwarded to a single box.  WWW has port 80, 443, and a few others forwarded to it from the outside world.  If a user whose mailbox is on EX logs into OWA at WWW their browser is redirected to EX.sub.domain.com.  Of course the address of EX is a 192.168.x.y address so resolution and communication fails.  I need for WWW to actually serve up the OWA mail, but it won't.  POP3 and SMTP get served by WWW correctly, it just won't handle OWA requests beyond the login.
0
 
jsavage66Commented:
So WWW is your server that has OWA running on it?  I'm assuming you have a separate server for Exchange?  Have you checked to see whether your OWA server is set up as a "front-end" server and Exchange as a "back-end"?

You can check this by opening the Exchange System Manager, expand your Administrative Groups folder, expand your Admin Group, and click on your servers folder.  Right click your OWA server, click properties, and verify "This is a front-end server" has been checked.
0
 
SkipFireAuthor Commented:
Yeah, WWW is my web server with Exchange Enterprise 2003 with Front-End checked.

EX is my mailbox server with Exchange Enterprise 2003 with Front-End NOT checked.
0
 
jsavage66Commented:
I found something you may want to look over.  It's based off of Exchange 2000 but should give you some additional information about your problem.  It has to do with logging into OWA with an account that has an email box on a server other than the one OWA publishes to.  

You may want to search the document for "redirect", the document is pretty big.

http://www.securityfocus.com/infocus/1658

You could also try removing OWA from the administrative group and adding it again.  
0
 
jsavage66Commented:
This is an excerpt from that site I just posted.  Seems pretty similar to your problem.  (it might have more meaning with the pictures, but you'll probably get the idea)

Given that owa.satchels.com publishes to Corp-Ex2k, we will have no issues if JJones or HSmith log on to https://owa.satchesl.com/exchange. However, if JGranick logs on to https://owa.satchesl.com/exchange, Corp-Ex2k will know the mailbox is on Legal-Ex2k, and will automatically re-route the client browser to https://Legal-Ex2k.satchels.com/exchange. Likewise, if GBrown logs on to https://owa.satches.com/exchange, the client browser will be redirected to https://Sales-AD1.satchels.com. Since none of these host addresses are valid to an external client, these users will not be able to log in. The only way around this- that is, the only way to have direct server publishing where the client only needs to know one host address (when you have multiple servers), is to add host names to the external DNS servers for the actual host names of the internal machines (with an external address of course)- something you may not want to do. The security ramifications of adding actual host names to your external DNS are somewhat dubious, but many consider any such information as too much information.

Alternately, you could Sever Publish each internal machine as its own publishing rule, each with its own external IP address (Web publishing would let you base this on the URL) and tell each user what host name to use for their own mail server. This may seem like a lot of work, but it does ensure that each OWA server is set to only use HTTPS (you'll need certificates for all servers), and you have direct control of how each server gets published. Whether you create DNS entries for the actual host names (so that the end user only knows one address) or make up separate host names for each individual OWA machine (as in owa2.satchels.com, owa3.satchels.com, etc.) you know that every user that logs in does so directly to the server hosting their mailbox, and that SSL is used at all points in the log-on process. Since all access is ultimately a direct client-to-server connection, one can better control things like IP restrictions and authentication methods as one could with any individual server-based configuration.
0
 
Carlo-GiulianiCommented:
All the text quoted by jsavage66 above does *not* apply to a front-end/back-end configuration.  It applies only to the "direct server access" configuration in the first part of that article.

As far as I can tell, SkipFire's configuration should *not* be behaving like it does.  It is acting almost like they are not configured for front-end/back-end.  
0
 
Carlo-GiulianiCommented:
SkipFire, are you *sure* the HTTP requests are being redirected instead of proxied?  Could it be failing for some other reason?  What exactly are the symptoms/evidence?
0
 
SkipFireAuthor Commented:
I see the URL in the address bar changing to point to the new server, then if I am on the outside it says server/dns error, if I am inside it works fine.  This is what I would expect with the URL changing to point to an internal resource.
0
 
Carlo-GiulianiCommented:
Skipfire, it looks like your front-end server is not acting like a front-end.  
  - are there any mailboxes on this server?  (The answer should be *no*).
  - are you able to access the front-end properties page?
0
 
SkipFireAuthor Commented:
I don't see a front-end properties page, though I may just be looking in the wrong place.
0
 
SkipFireAuthor Commented:
I found the problem, I forgot to remove the storage group, once I did that it actually became a front-end server, until then it was checked but since it had a storage group (even with no mailboxes) it couldn't become a front-end server.

Thanks.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 6
  • 4
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now