CAS Array Issues - Internal Clients falling back to HTTPS Outlook Anywhere

We have recently implemented a CAS Array and we have since noticed that all internal clients not on the local subnet where the exchange servers are hosted are falling back to Outlook Anywhere HTTPS connections. Very odd situation.

Site1 where the servers are hosted is 192.168.1.0/24. All users in this office connect via RPC/TCP to the CAS Array.

After about 24 hours, we noticed a massive increase of HTTPS sessions to the server that has Outlook Anywhere enabled and Port 443 access pointed to it from the Corporate Firewall. After comparing netstat's across all 3 CAS servers, it was very clear that all non-192.168.1.0/24 subnets were falling back to Outlook Anywhere HTTPS.

Unfortunately there is no logging or a way to actually view service levels across the Windows NLB CAS Array. The only proof that I have that this is happening is from a netstat.

Here is how the CAS environment is setup:

Windows NLB Setup across 3 CAS Servers with the VirtualIP of 192.168.1.233. Unicast mode is enabled. We've also had it on Multicast mode during our troubleshooting. Neither resolved this issue. It is currently showing Converged across all 3 CAS servers in WNLB Interface.

CAS1.ourdomain.local - Virtual Server on Hyper-V
Primary Interface: 192.168.1.244
Secondary Interface: 192.168.1.184 - IP and Subnet Only. No Gateway and DNS Registration Enabled.

CAS2.ourdomain.local - Virtual Server on Hyper-V
Primary Interface: 192.168.1.251
Secondary Interface: 192.168.1.185 - IP and Subnet Only. No Gateway and DNS Registration Enabled.

CAS1.ourdomain.local - Virtual Server on VMWare
Primary Interface: 192.168.1.247
Secondary Interface: 192.168.1.186 - IP and Subnet Only. No Gateway and DNS Registration Enabled.

The only difference between the 3 is 2 are on Hyper-V and 1 is on VMware.

We use split DNS:
Our internal namespace: ourdomain.local
Our external namespace: ourdomain.com

The CAS Array is configured to: outlook.ourdomain.com pointing to internal IP 192.168.1.233. outlook.ourdomain.com DNS is only setup internally. Internal users, across about 20 internal subnets, can resolve outlook.ourdomain.com to 192.168.1.233. External users cannot resolve outlook.ourdomain.com. SMTP, OWA, AutoDiscover, etc. are all attached to mail.ourdomain.com. During the fear of not being able to keep .local domains on SSL certs, we migrated all internal services to our external FQDN.

Get-ClientAccessArray shows:

Name                Site                 Fqdn                           Members
----                ----                 ----                           -------
CAS-Site1         Orlando-FL           outlook.ourdomain.com       {CAS1, CAS2, CAS3}

At this point I'm looking for some input. Perhaps I am missing something obvious. I was visiting an internal site yesterday and it connected just fine directly to the CAS server. Once I updated the Outlook profile to the CAS array, I started experiencing the same issues as the other users.
LVL 1
danherbonAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Amit KumarCommented:
There are two things which can connect clients on RPC over HTTPS,

1. if you have applied any group policy or checked option to connect outlook over RPC over HTTPS even on fast connections. You can check it in Exchange proxy settings of e-mail account, there will be two options on Fast networks and Slow networks. Fast networks should be unchecked.

2. On the other hand whatif you have published internal DNS for OWA with public IP, try pingning OWA DNS it should resolve NLB IP, if this is Public IP then you may get direct hit on Firewall.
0
danherbonAuthor Commented:
1. The box is not check at all on any clients.
2. resolving mail.ourdomain.com which is our OWA resolves internally, via split dns, to the internal ip of the mail server.
0
Simon Butler (Sembee)ConsultantCommented:
The CAS Array should be in your INTERNAL domain, not your external domain.
Therefore if you set it up as outlook.domain.com but your Windows domain is domain.local then I would have configured it as outlook.domain.local. The CAS Array address doesn't go on to SSL certificates, so this isn't a problem there.
For the clients to connect to the CAS Array the name MUST NOT resolve externally. If you have a wildcard in the domain or anything like that, then it can cause problems.

Do you have any Exchange servers in that other site? CAS Arrays are AD site specific.

One last thing - Windows NLB isn't recommended by the Exchange product team. The first thing I do whenever I see a site with problems that has deployed WNLB is bypass it. Most of the problems then go away. I would start by changing the CAS Array address to point to a specific server and see if the problem continues.

Simon.
0
danherbonAuthor Commented:
Simon, thanks for the response. You were right on one point, it was the Windows NLB. Late last night we updated 5 machines Host file DNS to point outlook.ourdomain.com to one of the three CAS. Flushed DNS and when we opened up Outlook it immediately connected in milliseconds over RCP/TCP rather than HTTPS.

Changing the Host file back, flushing DNS and opening up Outlook started with the 1 minute delay before eventually falling back and connecting via HTTPS.

So we've pinpointed the issue on the NLB setup. If Windows NLB isn't recommended what is the preferred setup? We've been looking at HLB however we're still a few months out from purchasing anything. I have read so many conflicting blogs and articles on Round Robin DNS however I'm pretty sure Microsoft is recommending it for 2013. What do you suggest?
0
Simon Butler (Sembee)ConsultantCommented:
The preferred option is a hardware load balancer.
I would accelerate the purchase if at all possible, as the quicker you can get rid of WNLB the better.
Round Robin DNS may well work for you. There is no availability function, so if you want to remove a server then you will need to take it out of the DNS entry for the array some time in advance (hopefully the array has a short TTL time on it).
If a small number of users you could look at the free load balancer from Kemp. If you know which load balancer you are going to get, see if you can get an extended trial from the vendor.

Simon.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.