Hi

Just a little question to verify if I have understood things correct :-)

In 2013, CAS is automatic loadbalanced via AD for Outlook clients? Or?
Only for OWA, ECP, ActiveSync devices I can loadbalancing via eighter, DNS RR, WNLB or a HWLB?

I have set up a testlab at home with 2 cas and 2 mb servers, and the DAG is as expected, but I am in doubt what goes for the CAS, since we don't have a CAS array object anymore. I don't know how Outlook finds the CAS?

BR
Steen

No, You will have to loadbalance all the services using HLB

It's a automated process, autodiscover takes care of it
http://technet.microsoft.com/en-in/library/bb124251(v=exchg.150).aspx#works

Hmmm....technet says dns rr is ok. Anyway, how would you lb CAS when there no fqdn anymore? I have not been able to find an example. Since outlook connects guid@domain.com where would you send the traffic? And what record would you create for this? BR Steen

Here is the well explained article of Tony Redmond
http://windowsitpro.com/blog/exchange-2013-dumps-cas-arrays

Hi

DNS RR is not recommended but it is one of the more basic ways of spreading load.  Windows NLB is better but still not recommended - leaving hardware load balancers as the only recommended solution but the others will still work within their limitations.

The URL Outlook clients will connect to is the Outlook Anywhere one which is published by Autodiscover.  You can have different internal and external versions of this URL but I find it easier to keep them the same using split DNS.

Cheers, Steve

Steve got the "Mark as answer"

No one is answering my question, I think (or I can't express myself :-))

I have red Tone Redmonds and all other blogs - and they are all saying the same I also can read on technet - but I need some example.

How do I LB CAS servers inside, when CAS array is gone?

I might think Steve answered. But then, I can't see the difference. Now it seems that is has just been a outlook anywhere array? Different protocol, different port - but still the same?

Now I have to set up "outlook.contoso.com" pointing to my CAS servers (rpc/https) - earlier it was outlook.contoso.com pointing to my CAS servers (mapi).

Sorry, but I want to understand this :-)

BR
Steen

Hi Steen

The CAS Array object in 2010 was an AD object that provided a logical grouping of CASs in the same site.  This on its own did not provide any load balancing functionality, you would still need some mechanism for spreading the load preferably in the form of a hardware load balancer.  You would send your MAPI traffic to the VIP of the load balancer, this would either be in the form of a couple of locked down ports or the whole dynamic range ... plus port 135 in both cases.

In 2013 there is no MAPI or RPC between the clients and the servers as all traffic flows over HTTPS 443 (other than POP/IMAP) so the CAS Array object is not required anymore and you will be using Outlook Anywhere (RPC/HTTP) internally.  This simplifies the task as you only have a single port to deal with and you don't need to worry about maintaining session affinity.

When using DNS RR if you lose one of your CASs then clients will still be directed to the dead server until you do something about it.  Windows NLB will stop sending traffic if a server dies completely but it does not detect a service outage so your clients may still get errors if the IIS service stops for example.  A layer 4 hardware load balancer is the minimum recommendation to get around these shortcomings.

Cheers, Steve

Hi Steve

Thanks for clearing things out. Now it makes sense.

The old hwlb vs. wnlb discussion is the same I can hear, - and for dns rr I get the point, not optimal at all :-)

BR
Steen

This simplifies the task as you only have a single port to deal with and you don't need to worry about maintaining session affinity.

TCP Session Affinity is the only thing that actually has to be maintained otherwise the network conversation itself would be broken.

You no longer have to worry about utilizing Source IP affinity, ExchangeCookie, SSL Session IDs, Authentication Tokens, or any of the other fun stuff used before with a L7 load balancer.

So go ahead and let TCP sessions fly across all CAS in an AD site, but once the session is connected it stays on the CAS it originally hit unless the session is properly terminated by the client or it fails for some reason. If the TCP session fails then the client will establish a new TCP session and that session can once again go to any CAS in the AD Site.

TCP Session Affinity is the only thing that actually has to be maintained otherwise the network conversation itself would be broken.

Hi Brian

I meant the session affinity discussed by Ross here.

Cheers, Steve

A slightly better wording in that particular blog may have been Protocol Affinity or Application Level Affinity. We do need TCP Session affinity or else the network connections would outright fail.

I agree

Brian, do you have an authorized article on this? I need it to support the statements.