Exchange 2003 Front-End use

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

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.

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.

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.

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.

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.  

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.

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.  

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?

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.

I don't see a front-end properties page, though I may just be looking in the wrong place.

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.