Forum Discussion
NimbostratusLync 2010 Fail
Good day, New stand alone APM deployment running 11.5.1 HF7 Lync works after initial logon and Webtop is available. However when Network Access is initiated and complete, Lync fails.
5 Replies
Hi, can you give us more detail about your deployment? Which Lync services are you using? If you have Lync Edge services running, the clients should not have a route to the internal Lync servers; they should be forced to connect through the Edge as if they were external clients.
- Chase_Abbott
Admin
Unless they have internal and external names defined for the Lync pools against the client. If that's the case the client shouldn't need to connect to edge services or reverse proxy as the FE Pool will handle all of that traffic. However, if the client is connected prior to VPN tunnel and they don't allow the client split-tunnel, the client would fail until reconnected to the internal address space. At that time, for 2010 at least, it would try to use 5061 for the internal client port by default. Not the best setup but is supported by MSFT. And per Mr. Shimkus, we would need to know more about the deployment specifics.
- Chase_Abbott
There are a couple spots to look at here depending on your lync configuration. If Lync was signed in previous to network access (assuming full VPN), fist determine what FQDN the client is trying to get to. If you used group policies or manually assigned internal and external names, it should be trying to connect to the internal lync pool on 5061 or 443 (2010 allows both). If it's setup to autodiscover, it may still be trying to attach to the previously used external name and then network config is preventing the client from resolving proper external address spaces and ports.
I would grab client logs and tcp dumps (from the client) to see what the error conditions are (be prepared to SSL dump or deencrypt the traffic on your test client with the key of the SIP cert), I suspect it cannot resolve the name it was previously using OR the name's available but the port isn't. One other thing to check is turn on the client ONLY after you've established a full tunnel. Just for testing.
gjohare_189599Sorry, left out some key elements...we have a direct connection to Microsoft which hosts our Lync and exchange. Here are my OWA links in the F5 APM:
https://owa.weatherford.com:443/owa/attachment.ashx* https://owa.weatherford.com:443/owa/auth/logon.aspx* https://owa.weatherford.com:443/owa/ev.owa* https://owa.weatherford.com:443/*
Also, here is my Edge server is sipfed.weatherford.com
But not sure how the Edge is required?
- Chase_Abbott
Ahh.... big difference then. Given that the SRV records point to your domain but the IP is xxx.dedicated.lync.com, the client is always connecting externally. If the VPN tunnel prevents this connection, most likely the client cannot resolve 443 to ae1.032d.dedicated.lync.com due to either outbound firewall route paths that overwrite the client default settings.
I would look to see what the client receives for routing from the VPN connection and compare to an internal computer. They should have the same access out at least in regards to the Lync client. Again, this is also where the client logs an tcp dump should show what the client is attempting to do and what's not responding. I'd expect oneway traffic. If firewall, you should see some denies.
