In my previous post about this I explained about how I had worked through in a test lab getting Exchange Direct Push devices to connect to a Front-End Server and then have requests relayed through to a pair of Exchange 2003 cluster databases servers. I left the post in the position where I was getting access to OWA, OMA and A/S on the devices and P.C with no problems whatsoever - however the environment was not suitable for production as I needed to perform a number steps to make it workable(bearing in mind I had done all of my testing on the internal LAN).

First Things First: In order to progress this into my live environment I needed to consider the steps required in order to get my system into the outside world

Domain Name Space: Currently in production my users connect only to a single DNS names space internally which is http://mail..com which they achieve by connecting through the Front-End server - now without going into the details, my company has an external DNS namespace which is .com - and we also have (via AD integrated DNS - Now some of you my be thinking - is his internal AD DNS names space the same as his external name space? - ohhhh naughty! - IT’s NOT, we have a secondary DNS domain on our DNS servers for internal resolution for systems which loosely matches the outside DNS servers). Wanted I wanted to accomplish was to have a single DNS entry to connect to both internally and externally - this would also help with the SSL certificate registration as:

I could use a single FES with two network adapters to service both internal and external traffic off of one IIS site

I needed to register the mail. with our external DNS hosting company - which is done by allocating an external (public) IP address to the site and then asking the DNS hosting company to register a HOST (A) record called mail.maildomain.com to the allocated public address. Configure Firewall to allow traffic to the Front-End Server; Obviously we now have our public IP address which has a corresponding DNS entry - but we now need to allow the traffic into our network. I decided that I was not going to have the FES in a DMZ but just a single interface on the FES (as the server has two interfaces) which would have the traffic from the public address NAT’ed to it and then the second interface in the server would sit on our public network. With this configuration in mind we only needed to open up two ports on our Firewall port 80 and 443 below is an example of how we configured the firewall settings (Our firewall is a Cisco PIX):

names name 192.168.1.69 exFES - Assign a global name to the FES IP

address access-list outside_in permit tcp any exFes eq www - Allow port 80 traffic from the outside to the FES access-list

outside_in permit tcp any exFes eq https - Allow port 443 traffic from the outside to the FES

static (inside,outside) tcp interface www exFES www netmask 255.255.255.255 0 0 - Static Mapping to the FES for port 80

static (inside,outside) tcp interface https exFES https netmask 255.255.255.255 0 0 - Static Mapping to the FES for port SSL

access-group outside_in in interface outside - Apply the access lists to interface

Register and obtain a SSL certificate from a root source; There are many SSL suppliers out on the web - however the one that I have had the best experiences with and also the best support from is Thwate which (if you are in the UK) can be obtained from Herald I am sure that most of you know how to generate a request file (and in many cases the supplier that you are working with will tell you) but there are a couple of important things to remember:

Ensure that the name and the Common Name for the certificate match the DNS name of the site (not the server name)

Issuers such as Thwate also offer certificates that check the registrant information to ensure accuracy - so when you generate the request file from IIS ensure that the company information corresponds to your DNS registration information.

When you have the certificate file from the issuer you are then in a position to configure your Front-End and Back-End servers. Now that I had the Certificate: Now that I had the certificate in place and had configure the companies firewall to NAT the requests to my Front-End server I was in a position to implement the correct permissions on the Exchange Virtual directories that I had learned in the test lab. For convenience the following are the permission sets that I used, but they can also be found in part 1 - remember that all of these permission need to be set via the ESM - NOT IIS: Permissions On the Front End Server(s)

Exadmin VDIR = Should all be grayed out Exchange VDIR = Anonymous access - not ticked (Account inherited from parent object), Basic authentication (Default domain should be set to “\”), Digest authentication should not be ticked, Integrated Windows Authentication should be grayed out) Microsoft-Server-ActiveSync VDIR = No access to the authentication settings should be allowed (all should be grayed out). OMA VDIR = Anonymous access - should be grayed out, Basic Authentication - the tick box should be grayed out but the default domain should be set to “\”, both Digest authentication and integrated authentication should be grayed out.

Permissions On the Back End Server(s)

In both my production environment and my lab Environment all of my back end servers are Clustered which according to Microsoft you need to assign host headers to the IIS in some instances.

I found that by adding Hosts headers that severely interfered with the operation of OWA / OMA / ActiveSync via the Front-End Server therefore I removed ALL traces of host headers from both the ESM and IIS system manager (which bizarrely seemed to work just a well as when configured with them - perhaps a fix in SP2?).

I then applied the following permission (via the ESM) to the HTTP virtual directories; Exadmin VDIR = Should all be grayed out Exchange VDIR = Anonymous access - not ticked (Account inherited from parent object), Basic authentication - should not be ticked, Digest authentication should not be ticked, Integrated Windows Authentication should be ticked.

Microsoft-Server-ActiveSync VDIR = No access to the authentication settings should be allowed (all should be grayed out). OMA VDIR = Anonymous access - should be grayed out, Basic Authentication - the tick box should be grayed out but the default domain should be set to “\”, both Digest authentication and integrated authentication should be grayed out With all of the permissions set all I needed to do was apply the SSL certificate to the IIS site and then apportion the correct virtual directories that require SSL encryption - on the Front-End Server, remember the Front-End server proxies the requests from the Back-End servers therefore they do not require SSL. Adding an SSL certificate to an IIS site is pretty straight forward - however the following are the VDIRS that require SSL enabled: Exchange ExchWeb Microsoft-Server-ActiveSync OMA Public After all of that I was able to correctly sync with my mail using our companies T-Mobile devices.

---

Add this page to your favorite Social Bookmarking websites