How NOT to Deploy Client Access Servers
I have obviously been really busy since December since that is the last time I posted a blog entry. It's rather embarrassing, but I've been devoting a lot of my time to an Exchange Troubleshooting tool hopefully to be unveiled in the Exchange 14 timeframe - more to come later on this.
In these 5 months, I've had plenty of time to see customers do some "interesting" things with the Client Access Server deployments. Since many customers still ignore our prescriptive guidance, I'm just going to give you the gun to shoot yourself in the foot.
Here are some things you can do so you can ensure you have fun-filled days, every day of the week, on the phone with Microsoft Exchange Support.
Deploy multiple Client Access Servers in the same AD Site with different configurations
Here are some common things that lead customers to do this:
- Want different functions for Client Access Servers. I.E. "This is my OWA / ActiveSync CAS, and this is my Autodiscover / EWS CAS", or "This is my Internal CAS, and this is my External CAS."
- Want the Client Access role on the mailbox server as a "backup" in case the CAS goes down.
- Have their "Test" or pre-production environment in the same AD-Site/Same Exchange Org as their Production environment.
Exchange cannot read your mind!
Don't assume that just because you have deemed CAS A as Internal and CAS B as External that Exchange will know the difference. I will admit there are (most times) certain configurations changes that can make configurations like this work, but they are extremely complicated and prone to error. All Client Access Servers in the same site should be configured the same way. I make mention of this on my previous blog post, CAS Load-Balancing Best Practices (Part 1). You will run into problems if you try this. There is no reason to try and split services as mentioned in reason 1 above. This was never tested and is not recommended. In general CAS Services scale well together and you should not try to isolate any particular service. For #2 and #3 above, just remember, that Exchange and Outlook can't read your mind. As soon as a server is deemed a CAS (in AD), it is fair game for Outlook clients, proxy targets from other sites, etc, etc. It is very difficult to understand and implement all the different factors that are considered when a client or a CAS in another site is choosing a CAS to connect to. This will cause you issues; so just don't do it.
Deploy your Client Access Servers in a DMZ or Perimeter network, but "pretend" it's not a DMZ
We've seen customers again and again try and skirt our support stance on this. Just in case you didn't know:
Planning for Client Access Servers: https://technet.microsoft.com/en-us/library/bb232184(EXCHG.80).aspx
Installation of a Client Access server in a perimeter network is not supported. The Client Access server must be a member of an Active Directory directory service domain, and the Client Access server machine account must be a member of the Exchange Servers Active Directory security group. This security group has read and write access to all Exchange servers within your organization. Communications between the Client Access server and the Mailbox servers within the organization occurs over RPC. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.
Don't pretend your DMZ/Perimeter network isn't a DMZ/Perimeter network
We've had numerous customers who want to argue about what is and is not a Perimeter network. What was meant in the original documentation by "perimeter network" is any network that does not have unrestricted access to every Domain Controller and Exchange Server in the Organization. We've had customer who have called it a "pocket-DMZ" meaning that it's not their main DMZ where there web servers are. This DMZ sits off their internal network in a separate "pocket" where access to and from the internal network is restricted. This is still a Perimeter network and falls into the above support policy. If your CAS is NOT on your internal network, it's probably safe to assume that it's in a DMZ and likely not supported.
Not supported, means not supported
If you call into PSS and the support engineer you are working with finds that your Client Access Server is in a restricted or perimeter network, you are deemed unsupported. This does not mean that the PSS engineer hangs up the phone and says "too bad" right off the bat. What this does mean is that the Engineer will gather logs and attempt to better understand your issue. If at any point during troubleshooting, the PSS Engineer feels your issue may be caused by, or complicated by, the Client Access Server being in the perimeter, the engineer may request that troubleshooting be suspended until the Client Access Server in question be moved into the internal network. If the customer is not willing to do this, then the customer is at that point unsupported by Microsoft PSS.
It's not even a good idea...
Our guidance recommends that an ISA Server or another reverse proxy server be placed in the DMZ to handle requests for Internet Exchange Services such as OWA and ActiveSync. ISA 2004 and later allows ISA to operate in a Workgroup (non-domain) configuration and still pre-authenticate requests to Active Directory. This ensures that no unauthenticated traffic is ever passed to the Client Access Servers and also ensures that every URL and request is processed and scanned by ISA URL Filtering/Scanning/and IDS feature-set. This allows for a single port to be opened up (443) to each Client Access Server in the internal network (to allow ISA Web publishing) and is the most secure configuration by far.
If an Exchange 2007 Client Access Server is deployed in the perimeter, a plethora of ports must be opened (both random and static) to Exchange mailbox servers, Domain Controllers, and other infrastructure roles such as DNS. For an Exchange Mailbox Server, you must open Dynamic RPC ports 1024 and above, in addition to 135, 139, and 445 (standard Windows RPC and File sharing ports). These ports essentially make your back firewall in the perimeter scenario into swiss cheese and is counter-productive to a secure environment.
All of the Above
A picture is worth a thousand words. Names have been changed to protect the guilty.
This customer was doing all of the above. The CAS was in a DMZ, though according to the customer "It's not really a DMZ...Look, we even labeled it something different on the visio!" Additionally, they had Client Access Servers "designated" as "internal" or "external" in the same AD site.
Guess what? They ended up on the phone with us! (shocking I know).
And guess what the problem was? ActiveSync was attempting to proxy from the CAS in Data Center A's DMZ to the CAS in Data Center B's DMZ, but this traffic was not allowed. The customer intended for the proxy traffic to only go the the HUB/CAS combo servers in the Internal Network in data center B. But it didn't (obviously) and the firewall/routing caused the request to be blocked and fail.
This is an illustration of the simplest of all crazy issues you can and will hit if you deploy this way, but hey - maybe you're weird and just love problems or perhaps you just love calling into PSS. Either way - happy deployments!
I'm sure I'll be adding to this list as time goes on (or as I think about more things). Please spread the word, help our customers, and don't let them get into this situation. This goes out to the field, partners, MVP's, etc - It's your job to help our customers make the right call; together we can make a difference.
Comments
- Anonymous
July 17, 2008
The comment has been removed - Anonymous
July 18, 2010
The comment has been removed - Anonymous
July 18, 2010
The idea is that your CAS servers should live in your internal network. We recommend putting ISA Server, IAG, TMG, UAG, or another reverse proxy solution in your perimeter network instead of the CAS itself. - Anonymous
September 15, 2010
The comment has been removed - Anonymous
June 22, 2011
Hi. Good article. I'm assuming that this also applies in Exch 2010 to having a separate CAS server in the same site with a different Gateway. Have already set up a CAS array for this client. However, they want a CAS/HUB that's ready to go on a backup ISP. Without getting into expensive hardware, my thought is that the best practice would be to just change the gateway on the current CAS/HUBs in the event of an ISP outage. They don't need to spend the money to have seamless and immediate failovers. - Anonymous
October 18, 2011
The comment has been removed - Anonymous
November 22, 2011
completely agree with Reinhard Duerr and David Olson - Anonymous
November 22, 2011
Hi David, Can, and Reinhard,Thanks for your comments. This type of deployment can be achieved with any reverse proxy / firewall between the internet and your Client Access Servers (obviously not just ISA/TMG). The issue is with firewals between your Client Access Servers and mailbox servers. This is the kind of feedback we need when making decisions for the next versions of the product. The best place to provide feedback is on the technet content. I will also deliver this feedback to PM's personally, but without more information on your scenario it may not have as much impact.You can also post feedback at the Exchange Team Blog post here: blogs.technet.com/.../3408587.aspxBrad - Anonymous
January 11, 2012
Brad - ran across your article just in time. Question - we don't want people downloading attachments when accessing owa externally. Web ready viewing only. However we do want to allow internal people to have direct file access. 2 CAS servers was my first thought (internal and external). But you metion this above as a bad idea. How do I achieve this then? Thanks! - Anonymous
March 14, 2012
Jeff - You can configure your CAS server to behave differently for public and private access: technet.microsoft.com/.../bb124232.aspx - Anonymous
March 16, 2012
What if you want to provide ActiveSync / OWA both using standard username/password authentication AND client certificate only authentication. Wouldn't you need two separate CAS servers with different configurations to make this possible? - Anonymous
March 19, 2012
Jason,You can do this with separate web sites on the same server. The New-OwaVirtualDirectory, New-EcpVirtualDirectory, and New-ActiveSyncVirtualDirectory all have a -WebsiteName parameter that will allow you to create these VDirs in a secondary web site. I'd recommend doing it this way if you don't have ISA or TMG that could actually do the authentication for you. If ISA/TMG was available, I'd handle the two different listeners at TMG and leave the CAS servers alone entirely.If you do choose to offer two types of auth for Activesync and OWA, you would need to make sure that you don't have ExternalUrl's specified on those virtual directories. Otherwise, regular ActiveSync clients might get the wrong URL handed out via Autodiscover. Also, if you're providing two types of auth for activesync, you'd have to manually enter the URL for the devices where you wanted cert auth, because Autodiscover will only hand out the virtual directory with the ExternalUrl.Brad