Log in


Archive for October 21st, 2009

Client Access Servers in the DMZ

Categories: Microsoft Related
October 21st, 2009 by Scott

I came across an interesting article over at the Exchange Team blog, http://msexchangeteam.com/archive/2009/10/21/452929.aspx.  Basically explaining why not to place a CAS in the DMZ. 

I have to agree, I have come across this request a number of times in the past while at client sites stating that they would like to place a CAS in the DMZ and I have always recommended (even when the subject doesn’t come up) to place an ISA server in the DMZ to act as a reverse proxy.  ISA 2006 really gives you added benefit protecting your servers from a number of different attacks.  By allowing users to authenticate at the ISA level in the DMZ your remove the opportunity for a malicious user to attack your servers.  There is also the aspect that you can use ISA to load balance and perform link translation, that’s where your internal link is different than your external link. 

The other added benefit?  You don’t have to open your internal firewall to all the required ports Exchange will use.  This would be termed swiss cheese. 

So, if you’re thinking about placing a Client Access Server in the DMZ think twice, you really shouldn’t.

Thanks to the MS Exchange team for posting a reminder out there!

Tags:
No Comments »

Network Load Balancing recommended for Exchange 2010 CAS public facing (internet facing) and internal

Categories: Microsoft Related
October 21st, 2009 by Scott

I was reading an interesting note on the Client Access Server role in Exchange 2010 and ActiveSync.  When ActiveSync connects to a CAS it will constantly use that same connection for receiving emails and communication.  What occurs in the event the CAS server goes off line?  The Mobile device will continue to try to connect to that same server.  This means that if you have an outage for an extended period of time users will not be able to receive email on their mobile.   In order to resolve this issue Microsoft recommends to NLB the Client Access Servers both internally and externally (internet facing).  When a device is proxied to the proper CAS it will maintain that connection.  If you point the URL/IP to a NLB device the mobile will use the NLB information rather than the server information.  What this means then is that when a CAS is off line that is behind a NLB device users will use the NLB information and connect to the remaining server rather than trying to connect to the down server. 

MS Provided a nice diagram of Proxying for NLB CAS:

In an organization that has multiple Active Directory sites and multiple Client Access servers in each site, you can use Network Load Balancing (NLB) to optimize traffic among the Client Access servers in each site. We recommend that you include only Client Access servers within the same Active Directory site in a load-balancing array. You can deploy NLB in an Internet-facing Active Directory site and in a non-Internet-facing Active Directory site. The following figure shows two Active Directory sites that implement NLB.

 

As a note it appears that the Hub Transport Server in 2010 is not supported for NLB:  “In many deployments, the installation of the Client Access server role and the Hub Transport server role are on the same computer. In this topology, you can configure NLB for the Client Access server role separately from the Hub Transport server role. Currently NLB isn’t supported on the Hub Transport server role. However, it’s supported for the Client Access server role.”

More info:  http://technet.microsoft.com/en-us/library/bb310763(EXCHG.140).aspx

Tags:
2 Comments »

  • You are currently browsing the Scott Feltmann's Blog blog archives for the day Wednesday, October 21st, 2009.