We want to allow our mobile devices to connect using the Lync client only when connected via VPN. I'm getting a headache from reading the Lync 2013 Mobility deployment & planning documentation from trying to determine which parts I don't need. Do we still need reverse proxy & edge roles if the mobile client is already considered internal because it's connected via VPN? If anyone has any links describing what is exactly needed for this scenario that would be wonderful.

Thanks!

• Edited by JimCass Monday, August 19, 2013 6:00 PM

Hi Jim,

You would still need a reverse proxy/edge roles as the internal mobile users must finally connect to External Mobility Service through proxy server and reverse proxy server.

The user cant just connect to the external mobility server from inside, as the listening port for internal website and external website are different.

On a side note, I would ask the question "why" a VPN is necessary for mobile clients.  Lync 2013 Mobile still uses SRTP and TLS for both signaling and media.  Adding another "hop" for VPN could cause for worse overall client experience.

We already have the infrastructure to make the mobile phones appear to be internal by using Cisco AnyConnect so they can directly access internal resources. To me, if there is no need for external or federated clients, then 1) it is needless expense to purchase a UCC when not needed and 2) needless time for planning, deployment, and management of those resources.

By default the Mobility client will require a reverse proxy (internal and external), you can set the mobility to only work internally removing this requirement:

"Although the default configuration enables mobile client traffic to go through the external site, you can restrict mobile client traffic to the internal corporate network. When you restrict the traffic to the internal network, users can use Lync mobile applications on their mobile devices only when they are inside the network. 

To set mobility for internal use only, you would use a command similar to the following: Set-CsMcxConfiguration -Identity site:Redmond -ExposedWebURL Internal"

 http://technet.microsoft.com/en-us/library/hh690039.aspx

Keep in mind you will then need to install your internal Root CA cert on all mobile devices if you are not going to purchase a UCC.

As Adam said you will be double encrypting Lync traffic for the mobile phones (Lync SRTP/TLS & VPN), this could impact performance/user experience. 

• Marked as answer by Kent-HuangModerator Monday, August 26, 2013 7:07 AM
• Unmarked as answer by Kent-HuangModerator Monday, August 26, 2013 7:17 AM
• Proposed as answer by Richard Brynteson (dawho9) Thursday, October 03, 2013 12:30 AM
• Unproposed as answer by JimCass 20 hours 9 minutes ago

By default the Mobility client will require a reverse proxy (internal and external), you can set the mobility to only work internally removing this requirement:

"Although the default configuration enables mobile client traffic to go through the external site, you can restrict mobile client traffic to the internal corporate network. When you restrict the traffic to the internal network, users can use Lync mobile applications on their mobile devices only when they are inside the network. 

To set mobility for internal use only, you would use a command similar to the following: Set-CsMcxConfiguration -Identity site:Redmond -ExposedWebURL Internal"

 http://technet.microsoft.com/en-us/library/hh690039.aspx

Keep in mind you will then need to install your internal Root CA cert on all mobile devices if you are not going to purchase a UCC.

As Adam said you will be double encrypting Lync traffic for the mobile phones (Lync SRTP/TLS & VPN), this could impact performance/user experience. 

• Marked as answer by Kent-HuangModerator Monday, August 26, 2013 7:07 AM
• Unmarked as answer by Kent-HuangModerator Monday, August 26, 2013 7:17 AM
• Proposed as answer by Richard Brynteson (dawho9) Thursday, October 03, 2013 12:30 AM
• Unproposed as answer by JimCass Thursday, October 03, 2013 2:39 PM

I'll make note of the performance concerns, but for the existing IM/presence deployment that should not be a concern, correct?

I made the change Michael referenced above, but the Lync 2013 client on my Samsung S3 still won't connect when using the Cisco Anyconnect client 3.0.09156. But my laptop using Cisco Anyconnect 2.5.6005 will allow Lync 2013 to connect. Details:

S3 using WiFi, connected to "BC" SSID

interface: WLAN0

IP: 192.168.88.31

Gateway: 192.168.88.1

Mask: 255.255.255.0

DNS1: 192.168.88.1

DNS2: 0.0.0.0

After connecting to VPN, additional interface listed:

Intrface: CSCOTUN0

Inet Addr: 192.168.255.119

P-t-P addr: 192.168.255.119

Mask: 255.255.255.0

*****

Laptop using WiFi, connected to "BC" SSID

Wireless

IP: 192.168.88.236

Mask: 255.255.255.0

Gateway: 192.168.88.1

After connecting to VN, additional interface listed:

Local Area Connection 3

IPv4 address: 192.168.255.113

Mask: 255.255.255.0

Gateway: 192.168.255.1

*****

So both VPN clients are receiving the same client IP range. When connected to VPN from the S3, I can browse to internal Windows server shares.

We have a single forest single domain, but have multiple SIP domains. These are the mobile Lync sign-in values I'm using:

Sign-in address: [My SIP address]

Password: My domain password

Auto-Detect server: Off

User Name: NetBIOSDomain\username

Internal Discovery Address: https://lyncdiscoverinternal.domain.com/autodiscoverservice.svc/root

External Discovery Address: fake FQDN because it won't accept a blank field

HTTP Proxy: [We use ISA2006 as an internal proxy, I have this configured with my domain credentials]

Using the above settings, it will not connect. If I change it to auto-detect the server it still fails to connect. So since it works from the laptop going over the same network, I have to think that it's either the mobile client or missing settings some where.

I cannot get the Lync Connectivity Analyzer to do anything but crash upon startup, and I'm trying to get that resolved for more insight. When connected to VPN, my S3 can ping the internal discovery FQDN listed above, average latency is 32ms.

Can you set the Exernal discovery address to : https://lyncdiscoverinternal.domain.com/autodiscoverservice.svc/root as well instead of a fake one?

Can you set the External Discovery address to the same as the Internal instead of a fake one?

I set the external address the same as the internal, and it will still not sign in.

Hi JimCass,

The views of Michael is right.

For the VPN, when users connect to the corporate network using a VPN client, Lync media traffic is sent through the VPN tunnel. This configuration can create additional latency and jitter because media traffic must pass through an additional layer of encryption and decryption.

Best Regards,

Eason Huang

• Edited by Eason HuangMicrosoft contingent staff Wednesday, August 21, 2013 12:57 AM 12345

So is the official response that mobile clients over VPN will not work on an internal-only deployment?

• Marked as answer by JimCass 20 hours 8 minutes ago
• Unmarked as answer by JimCass 20 hours 8 minutes ago

So is the official response that mobile clients over VPN will not work on an internal-only deployment?

• Marked as answer by JimCass Thursday, October 03, 2013 2:40 PM
• Unmarked as answer by JimCass Thursday, October 03, 2013 2:40 PM

A working answer was not given, and they gave up on the request as a product limitation.

• Marked as answer by JimCass 20 hours 8 minutes ago

A working answer was not given, and they gave up on the request as a product limitation.

• Marked as answer by JimCass Thursday, October 03, 2013 2:40 PM