This article is part 2 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.
Load Balancing
Unlike previous versions of Exchan...
Updated Jul 01, 2019
Version 2.0
Blog Post
Hi Ross; thanks for the article.
Actually, @Baptiste is correct. The first scenario you define is "single namespace, no affinity [persistence], L4 load balancing". You state "Since session affinity is not used by the load balancer, this means that the load balancer has no knowledge of the target URL or request content. All the load balancer uses is layer 4 information, the IP address and the protocol/port."
However, @Baptiste's assertion is that the URL *can* be used, independent of the single/multiple namespace decision. This requires L7 (rather than L4) knowledge and SSL decryption (and subsequent re-encryption prior to Exchange Server 2013 SP 1), but is really trivial to configure on advanced load balancing solutions, and is part of the standard configuration and guidance from F5 Networks, for example. [Note: I am an F5 employee.]
Actually, @Baptiste is correct. The first scenario you define is "single namespace, no affinity [persistence], L4 load balancing". You state "Since session affinity is not used by the load balancer, this means that the load balancer has no knowledge of the target URL or request content. All the load balancer uses is layer 4 information, the IP address and the protocol/port."
However, @Baptiste's assertion is that the URL *can* be used, independent of the single/multiple namespace decision. This requires L7 (rather than L4) knowledge and SSL decryption (and subsequent re-encryption prior to Exchange Server 2013 SP 1), but is really trivial to configure on advanced load balancing solutions, and is part of the standard configuration and guidance from F5 Networks, for example. [Note: I am an F5 employee.]