We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Setting up Exchange FE/BE securely

Medium Priority
Last Modified: 2008-02-01

I need some advise please on the best way to setup Exchange 2003 Front-end / Back-end topology securely.

I have read many techincal documents with conflicting methods and I am confused about the best approach for us.

We are a small non-profit organisation, single site, single domain, all servers running Windows 2003.

Our current setup is two Exchange 2003 servers one front-end one back-end, both currently sat on the internal LAN.
We are using a Watchguard Firebox X700 firewall which is currently Natting through port 443 SSL for OWA and port 25 SMTP to the front-end Exchange server.
I am also able to configure remote laptops using Outlook 2003 for use with RPC over HTTP which means we no longer need VPN's on the laptops but can still connect to the Exchange server. The front-end Exchange server is also the RPC-Proxy.

My original plan was to put the new front-end Exchange server in to the DMZ of the firebox firewall and open the nessecary ports
from the DMZ to in internal network so the front-end server could communitcate with the DC's, GC's etc.

However the more I read about front-end / back-end Exchange setups the more I think this might not be the best way as you end up with lots of ports open from the DMZ to the internal LAN.

All the Microsoft documentation recommends using ISA Server. I am not sure I can afford yet another box and an ISA licence
as its all getting rather expensive.

Could I leave the setup as it is? or is that not secure enough?

Should I use IP/SEC between the front-end / back-end Exchange servers and how do I go about setting that up?

Should I run the Security Configuration Wizard that is part of Windows to hardern the front-end Exchange server or should I use the default security templates instead?

This was an interesting article on why DMZ's might not be as affective as you think:

What would you recommend for our organisation?

Thank You.
Watch Question

Given the size of the orginazation, if you are confident in your firewall and that everything behind your firewall is secure. You don't have to put the front end in the DMZ.
May client that use Cisco PIX use this scenerio once you are sure your firewall is secure.

check the following article treat ISA configuration as your Watchguard Firebox X700 firewall u actually have to know which ports u should open thats all.
it is a detailed article


We have 25 client PC's on the internal LAN and about 10 laptops who connect from home all Windows XP SP2.

I am confident I have configured our Watchgaurd Firebox firewall correctly. I actually have the firewall support company
on site tomorrow as they are upgrading the firewall OS to Fireware Pro.

The upgraded firewall OS will hopefully offer even more protection, it has (IPS) intrusion prevention service.
IPS does "protocol anomaly detection in the proxy policies with traffic analysis to proactively block many common attacks"


Any other comments?



Thanks for the link on the Front-end Back-end Exchange Server Trihomed DMZ Network Scenario.


Thanks for the link on the Front-end Back-end Exchange Server Trihomed DMZ Network Scenario.
I have read that document before and was unable to understand how all this would work with my watchguard firewall instead of ISA server. Think I will have another read of it however.
Expert of the Year 2007
Expert of the Year 2006

With 35 users I wouldn't have even bothered with a frontend / backend.

Many people are under the impression that a frontend/backend is introduced for security reasons. That is not the case.
A frontend/backend is introduced to take some load off the backend server with a single server deployment, and to provide a single point of entry with a multiple server deployment.

It can be used to enhance the security, for example using at as the place to scan inbound email.

However I wouldn't dream of putting it in the DMZ. That is the worst place it can go. Once you have punched all the holes in your firewall that a domain member needs, the firewall is like swiss cheese and is basically not protecting your production network from attacks from within the DMZ at all.
I blogged my reasons for Frontend in DMZ being a bad idea here: http://msmvps.com/blogs/sembee/archive/2006/02/23/85671.aspx

In this scenario I would be seriously considering dropping the frontend server completely. Then rebuilding the machine as a workgroup machine and putting it in to the DMZ with ISA. You can then publish what you need through ISA. That would provide the security I think you are looking for - ie no machine inside is directly connected to anything outside - it all goes through the ISA server.

My final thought on security is make sure that you are using a purchased certificate rather than a home grown certificate. That will not only ease the deployment, but avoids any security prompts.




I wanted to take advatage of using Outlook 2003 with RPC over HTTP as I wanted to reduce the number of laptops using a full VPN connections. I have installed my own certificate on the front-end Exchange server rather than a purchased one. Only issue with that is you get the certificate security warning in IE when accessing OWA but clicking Yes gets you past that.

I have the Watchguard firewall scanning for e-mail viruses at the gateway entry point. I also have Sophos Pure Message on the front-end Exchange server also scanning e-mail for viruses and it also has a SPAM blocker / quarantine functionality.

The front-end Exchange server is the bridge-head server and all SMTP traffic in and out of the building goes via this box.

I am beginning to agree that the front-end Exchange server in the DMZ and your firewall then ending up like swiss cheese is a bad idea.

I eventually would also like to take advantage of OMA so we can use mobile devices to connect to the Exchange system.

When you say install ISA in the DMZ on a workgroup machine you mean it is not a domain member server? Its just in its own workgroup? ISA is then used to publish OWA to the Internet?
Expert of the Year 2007
Expert of the Year 2006

The security warning on certificates I think is unprofessional and should be avoided. If you have gone to the expense of purchasing additional servers to do a deployment, then try to save $60 on a certificate, you have your priorities wrong.

My feelings on home grown certificates are well documented on this site (http://msmvps.com/blogs/sembee/archive/2006/03/05/85588.aspx also has them in a more readable format).

With regards to the ISA installation - I mean exactly that - a workgroup, not a domain member. For a machine to act fully as part of the domain means opening a number of holes in the firewall which shouldn't be opened. The entire point of a DMZ is to limit the exposure of the production network - and opening a dozen or more ports does not help with that.



I did originally have a purchased certificate on OWA on the back-end server, I can switch back to that.
Is ISA server fairly easy to setup and configure in this scenareo?

Is it possible to use the RPC over HTTP functionality if I ditch the front-end server for an ISA server and only have one back-end Exchange server?

Any more information about just leaving things the way they are and port forwarding (NAT) SSL and SMTP to the internal LAN.
I know this is probably not recommended either but I guess a lot of small companies without the resources in I.T do things this way?



I really think I cannot afford an ISA server is there anyway to put the FE Exchange server in the DMZ without opening all these ports from the DMZ to the internal?


keep the FE on the inside as dmz is less secure...unless you are going to use ISA and put the FE behind the ISA...otherwise keep the FE where it is.
Expert of the Year 2007
Expert of the Year 2006

If you cannot afford an ISA server, then don't bother with the DMZ.
If we could put a frontend in the DMZ without opening those ports then I would have posted that method - you don't open ports for the fun of it.

RPC over HTTPS does NOT require a frontend/backend scenario, although Microsoft's marketing makes it look like it does. Many people have that misconception, but it is not the case. I deploy most of my clients without an FE/BE and it works fine.

If you don't have the budget for an ISA, then I would stick with having both servers on the production network and open the ports directly.
Just move the certificate from the backend to the frontend so that the clients can use it. It is wasted on the backend.



So if I dropped the FE Exchange server competely and just have a BE Exchange server I could install the RPC Proxy on the BE instead of current FE and connect Outlook 2003 clients to the BE server using RPC over HTTP? I can then just open SMTP, HTTPS on the firewall to the internal network to the BE Exchange server?

I think ISA in the DMZ would be the best around solution and have the FE/BE Exchange servers on the internal LAN. That's if I had the cash for ISA. So I think I will leave the servers on the LAN and not use the DMZ.

Expert of the Year 2007
Expert of the Year 2006
What you have outlined is how most of my smaller customers are setup. SMTP and HTTPS is the only thing that comes through the firewall and it goes straight to the backend server. It has been fine.
The license that you have for your frontend could either be used for another Exchange server or a lab environment.


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.