I recently enabled the new 2013 mobile client for a couple of customers, through the Lync Server 2013 February update (aka CU1). One of the deployments was a Migration scenario from Lync Server 2010, whereas the other was a “first timer”. A couple of experiences to make notice of:
1. When you have a migration scenario, make sure you update your Reverse Proxy to publish the 2013 pool, or the new UCWA web Components will not be available
2. The Lync 2013 mobile client relies on the external web servides for mobility service, so make sure you also direct your INTERNAL users to the Public Reverse Proxy address (or they will Connect to the 443 port instead of 4443).
3. Since your mobile clients will get the final connection info through the Autodiscover Service, they will also need to be able to lookup the external web services FQDN, which they will get, which also needs to point to the Public Reverse Proxy address for proper Connection.
So, a quick summary:
- Internal DNS, lyncdiscover.<sipdomain> -> Public IP address of Reverse Proxy (for initial lookup)
- Internal DNS, extpoolFQDN.<sipdomain> -> Public IP address of Reverse Proxy (for Connection)
- Reverse Proxy Publishing rule -> Internal Web Pool address port 4443
Especially when having a split-brain DNS, for which the internal DNS is authorative for the same namespace as the public one, the extpoolFQDN record can kinda throw you off – at least it did for me – since you would not normally need to apply that. At least it’s not mentioned anywhere.
Rune's blog about things I see and UC 
Reblogged this on Unified Communications, My experiences. and commented:
Check out Rune’s experiences regarding deployment of the Lync Mobility service.
This is a definitely a task that to be included when planning for Lync mobility offering in any implementation.
I had ran into this problem and had to redirect internal clients to the Public IP as stated in the article.
But in my case, iOS clients only had the issue. Other mobile clients (Windows\Android) were connecting though. Did you notice that too or dint i test it well?
Hi Sai.
I did not do extensive testing, and at the moment I only had iOS Client available (Android not released at the moment either – the 2013 Version at least).
A good Catch on Your side though, I remember encountering problems Publishing the Mobility service through UAG back when it arrived in Nov 2011. Back then, the problem only Applied to non-Windows Phone Clients as well, and was due to how the Client parsed the autodiscovery reply (root token). Maybe a Client update will fix it this time as well?
Brgds,
Rune
The one I encountered 1st was Lync 2010 implementation, there were other mobile platforms too which were working positively and just not the iOS.
In my other implement with Lync 2013 recently after 2013 mobile client was released for iOS and Windows, I had the same problem and believe me, it was only iOS not working.
I used TMG for 2010 client and using IIS-ARR for 2013 implement. Looks like, i need to look a little bit more before redirecting the client to Public next time or just wait for an update as you said.
Thanks,
Sai Prasad
Mars Blog artikler fra Atea konsulenter – LyncAtea.no
Taking this approach in a 2013 deployment will send all clients out to the reverse proxy, not just the mobile clients. The Windows Lync Client 2013 initially queries LyncDiscover. during the autodiscover process. Lync 2010 clients will not be affected as they will query SRV records first.
That is correct, Corey, but unfortunately the only way of supporting mobile Clients on internal WiFi since they need to Connect to the External Web Services UCWA. Or at least it seems so, and the only way described by Microsoft.
For the Lync MX/Modern UI and other Clients using the Lyncdiscover record for service registration, luckily only signalling will traverse/hairpin the firewall – as media still will try to establish P2P Connections.
Brgds,
Rune
that’s what the lyncdiscoverinternal.sipdomain record should be used for. that will make sure 2013 and mx clients connect correctly but the mobile client will get the proper webservices url.
in my scenario though i’m constantly getting timeouts on ios clients saying ‘your configuration has changed’ has anyone else run into that?
Hi Jim.
I have only been able to do Limited testing on the matter, working from Remote on customer solution, and only With iOS clients. What I get from the scarce Microsoft documentation on the subject (as cited in my post) as well as a slide from Lync Conference 2013 (where I also had the chance to discuss a little With Microsoft representative) the Lync 2013 mobile Client needs to connect to external web services for UCWA. I did try to use the Lyncdiscoverinternal without luck, but had to push forward to resolve matters and could not test more extensively. Therefore it might be possible to do it the way you say (and which was true for the 2010 Client), but the way I interpret what Microsoft has presented it is not.
I have not encountered the error you describe, but have seen several others like “Connection to server was lost”, being unable to sign out or receiving IM Messages double up – all on iOS Client. Hopefully this is only a Client bug and will be corrected.
Brgds,
Rune
hi all,
I am currently testing the lync mobile client and want to know if I need an edge server to make the Audio/Video P2P sessions working between Two Mobile users one Inside the network and the other outside the network.
Thanks in advance
You would almost certainly need an Edge server, since corporate firewalls normally would deny the incoming media stream.
That is what the AV Edge is there for, proxying/relaying media between inside and outside Clients.
Brgds,
Rune
Thanks Rune!!!
Hi
I have gone through all of your comments. I am new to lync and setting up lync 2013. currently i am facing issue with mobile lync client. i am trying with both ios and android. from your experiences i understand that ios connectivity will be possible by external auto discover url.
As of now I havn’t setup an edge server. I would like to have the lync andriod mobile clients to connect internally. I am using standard edition front end pool. could you be more specific about what all things to configured or checked for it to be get done.
currently when I try to connect to lync 2013 server using lync 2010 android client I get the following error – “can’t connect to the server, verify your network connection or server address. please check them and retry.”
Couild you be of a helping hand?
Best Regards,
Jobish George
Is it mandatory to have reverse proxy if I need to connect lync mobile devices internally?
Hi there…George, is it?
Thanks for Reading and posting. I will try to answer both of Your posts as a Whole here.
1. Is it mandatory to have reverse proxy if I need to connect lync mobile devices internally?
A: Yes, you need the reverse Proxy, or something equivalent to it. The reason is that UCWA for Lync Mobile is only available on the Lync External Web Services, running on port 4443 on the Front End server. The Client will only try to Connect to port 443, so a reverse Proxy redirecting traffic from requests made on port 443 to the Front End port 4443 is necessary. For simplicity and “internal-only” Connectivity for Lync mobile, you could easily use an IIS ARR or just a firewall With NAT/PAT to redirect this traffic. That way you could just point Your internal DNS records for lyncdiscover and Lync Web services to this “redirection point” – do you get the idea? I would normally recommend though, that you deploy a reverse Proxy which you can later utilise for external Connectivity as well – but as a test/pilot, or if you would not allow external traffic but still allow the use of Lync Mobile internally, then it is feasible and for the latter part also necessary.
2. As of now I havn’t setup an edge server […] Couild you be of a helping hand?
A: I will clarify my blog post about this as well, but here it goes: The mobile Client will Connect using predefined Logic and based on the SIP address you log in With. If Your SIP domain is contoso.com, then Lync Mobile will look for
These are the only records the Client will look for, unless you og With the manual URL entry – in which case you could point to any FQDN, as long as it ends With the /autodsicover/autodiscoverservice.svc/root path.
This means that you could use one or both records internally. The lyncdiscoverinternal record can point to Your Front End server, where the Client would then retrieve information about the Lync Web Services URL. With Lync Mobile 2010, this would point directly to the Front End server internal web site, using port 443 – and it worked. For Lync Mobile 2013 the Client will only try to Access the external web services URL, such as webext.contoso.com, still using port 443. Thus leading to the fact that even if you try to “trick” the Client Publishing that record internally and pointing to the Web Services on the Front End server, there is no UCWA service running on port 443 (only 4443) – and the Connection would fail.
So to repeat the conclusion from question 1: You will need to make the Lync External Web services site available, preferably through a reverse Proxy.
The Edge server is necessary for any external Connectivity, also for Lync Mobile Client. Even if you deploy the reverse Proxy, making external login for Lync Mobile possible, this would only take care of the signalling part, or SIP Messages over HTTPS if you will. To enable audio/video from the mobile Client a media path must be available. As long as Your mobile Clients are “internal-only” (or “external-only”) and have Direct Connectivity to other Lync (or mobile) Clients, then it will work. Connecting from the outside and trying to Reach an internal client, however, would require the A/V Edge service to act as a media relay. The Edge is also useful for internal-to-internal Connectivity in cases where the Clients reside on different subnets and do not have full transparency between them, using the internal Edge NIC for Media relay.
I hope this answers Your questions, if they do not then you know where to Reach me! 🙂
Hi Rune,
Thank you so much for finding time to explain me the concept.
Regards
Jobish George
Lync Server 2013 mobility – revisited – Rune's blog about things I see and UC
Hi Rune,
I am trying to develop UCWA enabled application where the users can create meeting request. Hence I have setup the Lync Server 2013 with Standard Edition Server only. There is no Edge Server or Edge Server Pool.
I don’t have even reverse proxy server since I don’t worry about the external users to log in with this service At the moment, I am worried about enabling log in for the internal users and creating meeting request through a UCWA enabled web app.
Server setup details follows
AD Server running on Windows 2008 Server R2 Service Pack 1 VM
Lync Server 2013 on Windows 2008 Server R2 Service Pack 1 VM
Since this is R&D project, we don’t have the real servers for this setup.
At the moment, the following pieces are working
1. Lync Client is able log in
2. Lync Connectivity Analyzer is able to verify the minimum requirements with the given User Name in addition to SIP Address and Password. (It is not working without user name since SIP address and UPN of the user don’t match)
I have tested the setup with UCWA demo app, the log in credentials are not working. It fails while getting OAuth token. The request and response details captured from browser are below
OAUTH TOKEN REQUEST
OPTIONS https://lyncwebint.lyncapp.mydomain.com/webticket/oauthtoken HTTP/1.1
Host: lyncwebint.lyncapp.mydomain.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: https://lyncapp.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Access-Control-Request-Headers: accept, x-ms-origin, content-type
Accept: */*
Referer: https://lyncapp.mydomain.com/Autodiscover/XFrame/XFrame.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
RESPONSE
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-MS-Server-Fqdn: LYNCAPP.mydomain.com
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Date: Wed, 23 Oct 2013 07:49:36 GMT
Content-Length: 3429
Please guide me towards the direction. I am stuck here for past 2 weeks.
Your timely help is really appreciated.
Thanks,
Nat
Hi Nat, fashionably late response here so I hope you may have figured it out on Your own by now.
I am not skilled With UCWA Application Development, but from what I have learned and experienced With other UCWA Applications (such as the mobile Client) the only way of connecting to the UC Web API is through the External Lync Web Services site (running on HTTP listener port 4443). Since you do not have a reverse Proxy or other service to redirect HTTPS/TCP 443 traffic to the Front End IIS service on port 4443, it will probably fail the same way.
If I were you, I would attempt setting a Reverse Proxy, for example using the IIS ARR role on a Windows Server (see the Technet blog article for guidance). This will not need to open up for external (internet) Access, but simply be an internal server address that will redirect Your request. When setting up Lync in Topology Builder you are prompted to define the External Web Services URL (e.g. lyncwebext.lyncapp.mydomain.com); use Your Public domain name for this, and then enter this DNS record internally pointing to Your brand New “reverse Proxy” server. That way HTTPS traffic destined for Your UCWA service will be redirected to Your External Lync Web services site running on the Front End.
Hope that will be helpful.
Regards,
Rune
Heya i’m for the first time here. I found this board and I
find It truly useful & it helped me out much. I hope to give
something back and help others like you helped me.
I have a edge server deployed, three separate IPs all services on 443, a set of load balancers on the inside doing the reverse proxy services and three front end enterprise pools. Remote clients work fine, desktop/laptop but mobile phone fail to login. Both connectivity tests you can run by Microsoft pass with no issues. Using a UCC SSL and the intermediate for Dijicert is installed.
Static routes and Host file entries are configured on the edge server also.
Thoughts?
The edge server has no part in mobile client communication (SIP signalling) except media relay for voice/video between internal and external clients communicating.
Is the problem related to internal or external mobile clients – or both? If external clients cannot login then there is a problem with access to the reverse proxy – or between reverse proxy and Front end pool. If so, then other services should be affected as well, even the Lync 2013 client will use Lync autodiscover to connect (but will fall back to DNS resolution with sip.domain.com etc if it is not available).
If the problem is internal mobile clients not connecting then remember that they are being redirected to the Web Services External DNS entry (reverse proxy outside address), and if that is not reachable from inside then it will fail.