Lync Mobile Clients and TMG Server Farms

January 3, 2012

Quick update here for those of you publishing Lync web services with TMG and having trouble with mobile clients:

If you’re following the Mobility load balancing requirements you’ll find that cookie-based persistence is recommended in order to ensure the clients are always directed to the same Front-End server and session. This isn’t an issue for a single FE, but once you start publishing a farm of FEs within TMG you’ll notice the Lync mobile clients can’t sign in. Android clients can for some reason, but WP7 and iPhone cannot.

The issue you’ll face is that while TMG offers you cookie persistence when publishing a web farm, it really only works when the web listener is enabled for forms-based authentication. Since the Lync Web Services cannot be published via FBA the cookie never gets inserted. The end result is that TMG will now round-robin requests between the published farm members and the mobile clients will never sign in due to a ping-pong behavior. You can verify this behavior by draining all Front-End servers from the farm except for one and you’ll see the clients can now sign in.

For a small deployment where a single FE can handle your entire user load I recommend switching your TMG persistence to source IP. All requests will hit a single FE, but the mobile clients can now maintain their session. And if an FE fails TMG will then fail over to the next server in the farm automatically. For the folks where multiple FEs are used more for capacity reasons you’ll need to use something other than TMG for publishing Lync going forward.

Peanut Gallery

2 Pat Richard January 3rd, 2012

We have TMG doing a round-robin type scenario directly to the Front End servers, bypassing the HLB (defined as a pool on the “web farm” tab in TMG). Enabling cookie load balancing would cause the above mentioned issue with the client bouncing around between FE servers. Switching to source IP allows the clients to connect.

3 Aaron Miller January 3rd, 2012

I think it is important to note that you are talking about using TMG as your Load Balancer. If a hardware load balancer was deployed as is recommended\required, you would point TMG at that VIP and this issue would not exist.

TMG is certainly capable of performing Reverse Proxy functions for Enterprise deployments of Lync Server. Its ability to perform Load Balancing in the manor required for Lync Mobility seems to be lacking.

4 Tom Pacyk January 3rd, 2012

@Aaron, I left the HLB out of the equation here, but prior to mobility a typical Lync config would have an internal VIP serviced by the HLB, and then the external VIP HLB VIP would point at TMG array members which then reverse-proxied the connections directly back to the FEs. Pretty standard issue deployment, worked great.

That changes now with mobility and the options (if you want to continue with TMG) are to stick with source IP persistence and hammer away at one FE, or create yet another VIP on the internal HLB which you would point TMG to instead of the individual FEs. So the flow now has to become Client-HLB-TMG-HLB-FE, and you’ve decrypted and re-encrypted the SSL stream 3 times to maintain session persistence.

Pulling TMG out of the mix entirely would be the equivalent of publishing your Exchange CAS servers to the Internet with nothing but an HLB in front of them, which is a tough sell to any security group. But then again, if TMG can’t do what Lync requires, why bother? It’s just a disappointing limitation and one that probably deserves a much more thorough article than this! I at least wanted to point out the issue for anyone else struggling with it.

5 Aaron Miller January 4th, 2012

I see your point. However, I understand the Client-HLB-TMG-HLB-FE method as the supported configuration. Yes it could add an additional decrypt\encrypt steps depending on the way you have the external HLB configured. Otherwise it would be the same as if you had only one TMG box, which is Client-TMG-HLB-FE. As for standard deployment, my deployments always point the TMG to the internal HLB.

6 John February 15th, 2012

Thanks for your post. We have this problem. I changed the config on the TMG to persistence to source IP, but that did not help. Only when I removed one of the two FE servers from the Web Farm in TMG, did it work for the iPhone. The WP7 client still does not work. I can see from the Lync Logger – McxService logs that connections are still ping-pong to both FE servers. Any other ideas?

2 Pat Richard January 3rd, 2012

We have TMG doing a round-robin type scenario directly to the Front End servers, bypassing the HLB (defined as a pool on the “web farm” tab in TMG). Enabling cookie load balancing would cause the above mentioned issue with the client bouncing around between FE servers. Switching to source IP allows the clients to connect.
3 Aaron Miller January 3rd, 2012

I think it is important to note that you are talking about using TMG as your Load Balancer. If a hardware load balancer was deployed as is recommended\required, you would point TMG at that VIP and this issue would not exist.

TMG is certainly capable of performing Reverse Proxy functions for Enterprise deployments of Lync Server. Its ability to perform Load Balancing in the manor required for Lync Mobility seems to be lacking.
4 Tom Pacyk January 3rd, 2012

@Aaron, I left the HLB out of the equation here, but prior to mobility a typical Lync config would have an internal VIP serviced by the HLB, and then the external VIP HLB VIP would point at TMG array members which then reverse-proxied the connections directly back to the FEs. Pretty standard issue deployment, worked great.

That changes now with mobility and the options (if you want to continue with TMG) are to stick with source IP persistence and hammer away at one FE, or create yet another VIP on the internal HLB which you would point TMG to instead of the individual FEs. So the flow now has to become Client-HLB-TMG-HLB-FE, and you’ve decrypted and re-encrypted the SSL stream 3 times to maintain session persistence.

Pulling TMG out of the mix entirely would be the equivalent of publishing your Exchange CAS servers to the Internet with nothing but an HLB in front of them, which is a tough sell to any security group. But then again, if TMG can’t do what Lync requires, why bother? It’s just a disappointing limitation and one that probably deserves a much more thorough article than this! I at least wanted to point out the issue for anyone else struggling with it.
5 Aaron Miller January 4th, 2012

I see your point. However, I understand the Client-HLB-TMG-HLB-FE method as the supported configuration. Yes it could add an additional decrypt\encrypt steps depending on the way you have the external HLB configured. Otherwise it would be the same as if you had only one TMG box, which is Client-TMG-HLB-FE. As for standard deployment, my deployments always point the TMG to the internal HLB.
6 John February 15th, 2012

Thanks for your post. We have this problem. I changed the config on the TMG to persistence to source IP, but that did not help. Only when I removed one of the two FE servers from the Web Farm in TMG, did it work for the iPhone. The WP7 client still does not work. I can see from the Lync Logger – McxService logs that connections are still ping-pong to both FE servers. Any other ideas?

Peanut Gallery

Speak Up