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.