The Microsoft TechNet documentation covering Technical Requirement for Mobility includes a statement explaining that “all mobility service traffic goes through the reverse proxy, regardless of where the origination point is” but does not explain exactly how this is achieved.
This article will explain and demonstrate how both Lync 2010 and 2013 mobility clients are designed to be redirected out to a reverse proxy in most deployments by forcing the use of the External Web Services FQDN. But what is important to understand is that this is achieved by completely different methods between 2010 and 2013 mobility clients.
Back in Cumulative Update 4 of Lync Server 2010 Microsoft introduced an entirely new web service to the Front End server role. In fact a pair of services were added to both of the separate internal and external web sites in IIS which were covered in detail in the previous article Deploying the Lync 2010 Mobility Service. This included a new Autodiscover service which paved the way for an entirely new approach that future Lync clients would leverage to automatically locate servers, starting with the mobility clients in Lync 2010.
Initially there was much confusion in the field regarding both the behavior and intended design of these new services, but eventually a few important items came to be understood and some best practices arose to assist in designs and deployment.
With the later release of Lync Server 2013 the new Windows clients would also leverage this service, which was explored in the previous article Lync 2013 Client Autodiscover. This brought some important changes to the mobility story which also blurred the lines a bit between these clients and the standard desktop clients as mentioned above. No longer was the Autodiscover service only handling connections from mobile device clients, but now also Windows clients. This forced a change in the previous best practices as not all client could be treated the same.
Lync 2010 Behavior
As mentioned Lync Server 2010 received two new web services to handle the new mobile clients provided across Apple, Android, Windows, and other mobile device platforms. The Autodiscover service was created to allow these clients to easily locate a Lync server using only a SIP URI and connecting from any network. What was most unique about these new clients was that they were not SIP clients like the others, thus were the first Lync client to not utilize the SIP registrar services located on either Front End, Director, or Edge servers. These clients were completely serviced by a new web service called Mcx. This approach provided for a lighter client which was not heavy on SIP chatter and battery usage. Sure the Edge server still played a role in the overall mobility story in terms of handling features like Push Notifications, but for the basic client-to-server communications the web services were handling the entire workload. This approach further cemented the importance of a reverse proxy solution in the Lync deployment as publishing the external web services was now a requirement if external mobility client connectivity was desired.
After a fair amount of deployments were leveraging this new functionality and the behavior was generally understood a number of new practices were sifted out from the results. Most important of these was related to how internally connected mobile clients would be directed to the Mcx service to sign-in to Lync. The following statements outline the key behaviors and practices used in Lync 2010 Mobility.
- Mobile clients can be directed to either the internal or the external Autodiscover service. Regardless of which DNS records are populated (lyncdiscover, lyncdiscoverinternal) or where they point to (Front End server, Reverse Proxy) all mobile clients would still be redirected toward the external web services to sign-in. This happens because by default both the Internal Mcx service and External Mcx service URLs are set to the same value: the external web services FQDN. In the event that Lync Server 2010 only needs to support internal mobility clients and there is no external connectivity then the Set-CsMcxConfiguration cmdlet should be issued on the Lync servers with the ExposedWebUrl parameter set to Internal. This would result in both the internal and external URLs using the internal web services FQDN.
- Either the Internal Mcx service and External Mcx service can support 2010 mobility client connections, but not at the same time. As will be shown towards the end of this article the internal and external Mcx FQDNs will always be set to the same value, either the internal or external FQDN depending on the state of the ExposedWebUrl parameter. Mobile clients cannot be allowed to use either service as the Mcx services on Front End servers do not talk to each other and cannot coordinate connection state for a device which might move between an external network (e.g. 4G cellular data) and an internal network (e.g. corporate Wi-Fi). Thus all mobile clients in an environment must be directed to either the internal web service or the external web service. In any typical deployment with external Lync connectivity the external Mcx web service will handle all connections and the internal Mcx web service would never be used.
The fact that internally-connected mobile clients would by default be passed the external web services URL then this would create the ‘hair-pinning’ traffic scenario which was the topic of so much discussion when introduced. Deployments needed to be configured to allow and support this type of traffic from internal clients to reach the external interface of a reverse proxy server and travel back into the Front End servers.
But before the registration process could occur the mobile client would need to be redirected to the Mcx URL by first connecting to the Autodiscover service. But due to the complexities of dealing with HTTPS connections and the potential headaches of managing private internal root certificates on a multitude of mobile devices in the organization, most of which are personal devices, a general best practice arose to simply point any internal mobile clients directly to the reverse proxy for even the initial autodiscover attempt. This was typically done by configuring one or both of the lyncdiscover or lyncdiscoverinternal DNS host records located on internal DNS zones to point directly to the external IP address of the reverse proxy. This approach simplified the configuration by treating all mobility clients as external clients regardless of their location. This also insured that all of these clients would able to connect via HTTPS across the board as a trusted third party certificate would be in place on the reverse proxy. In a Lync 2010-only world this workaround was fine as only the mobility clients leveraged the autodiscover service, so nothing else was impacted.
Unfortunately for any environments configured with this work-around then the introduction of the Windows Lync 2013 client would result in an undesirable communication path.
Lync 2013 Behavior
In Lync 2013 both the standard Windows and Windows Store applications begin to leverage the Autodiscover service and will perform the same autodiscover steps as the mobility clients first, even before the now ‘legacy’ SRV/Host record lookup process. What this means in the scenario where all autodiscover requests are pointed externally is that all internal Lync 2013 Windows clients (which is typically the critical mass of deployed users) could also be forced outside and be registering to an Edge server and hair-pinning all traffic. This is certainly a less than ideal configuration.
As this behavior became known in Lync 2013 then it was evident that the autodiscover service first provided in Lync 2010 was not meant solely for mobility clients, but eventually for all Lync clients. This means that the proper configuration of autodiscover DNS records was now imperative for a healthy Lync environment.
- In the internal DNS zones for the SIP domain namespace a single lyncdiscoverinternal.<sipdomain> host record should be created which points to either a Lync Front End or Director server or pool.
- In the external DNS zones for the same SIP domain namespaces a single lyncdiscover.<sipdomain> host record should be created which points to a reverse proxy server which has published the external web service ports from the internal server(s).
This simple approach will insure that internally connected clients are treated as ‘inside’ and externally connected clients are categorized as ‘outside’. What is important to understand here is that not all Lync clients will behave the same way given this configuration, which introduces the primary topic of this article: the behavior of the Lync 2013 mobility client.
In Lync Server 2013 a new web service was introduced which plays a major part in this story: the UCWA web service. The Lync Unified Communications Web API (UCWA) service was created to aid third-party developers with an API platform for using with customized application. Microsoft also optimized this service for mobility applications and thus the Lync 2013 Mobility clients are programmed to use this new web service, and no do not utilize the previous Mcx web service. Note that the Mcx web service is still included and operational on Lync 2013 servers for backward compatibility with Lync 2010 mobile clients (with the same behavior as described in this article for 2010 servers), but the 2013 mobility clients will only leverage the UCWA web service.
The following example screenshots show the list of internal and external web services provided on a Standard Edition Lync 2013 Front End server.
The functionality of this new UCWA web service differs from the Mcx service as that was solely designed for the 2010 mobility clients while the UCWA service can be used by more than just the 2013 mobility clients; third party applications can be written to leverage this service. Additionally the new UCWA service improves over limitations in the Mcx service by removing the requirement for cookie-based affinity on a load balancer
Client Behavior Comparison
Most importantly the programmed client behavior differs between 2010 and 2013 mobility clients in one key area. Although they both will receive the same list of service URLs from the Lync Server the 2010 client has the ability to choose from either Mcx URL while the 2013 client is in essence dumb and only leverages a single URL.
In order to illustrate this behavior the response from the Lync autodiscover service can be viewed in any Lync Server environment by downloading and running the Microsoft Lync Connectivity Analyzer tool.
- Launch the Microsoft Lync Connectivity Analyzer tool and then enter the SIP URI and password of a Lync-enabled user in the desired environment. Select the appropriate Network access location and select Lync mobile apps to test those specific requirement.
- Allow the tool to complete all tests and then select All Results from the Show menu.
The results pane should display at least one occurrence of results from a mixture of unencrypted and encrypted connections to both internal and external servers. The provided parameters are used by different Lync clients to locate various services for SIP registrations, mobility access, Web Scheduler information, client certificate provisioning, etc.
In these results three unique FQDNs are provided which are resolve to three different systems.
- Internal Lync 2013 Front End Server FQDN: lync.schertz.name
- External Lync 2013 Access Edge Server: sip.mslync.net
- External TMG Reverse Proxy Server: lyncwebext.mslync.net
Lync 2010 Mobile Client
The Lync 2010 clients will look at both the Internal MCX service and External MCX service parameters and the client will select the URL that matches the associated location. So if the mobile client is identified as connecting to Lync either from an internal or external network it will use the appropriate URL to contact the server and sign-in.
The key here is that the Lync 2010 (or Lync 2013) server has defined both of those parameters as the same exact value, so in the end the client really has no choice.
Internal MCX service : https://lyncwebext.mslync.net/Mcx/McxService.svc
External MCX service : https://lyncwebext.mslync.net/Mcx/McxService.svc
Note that because both of these URLs are identical then 2010 mobile clients are forced to use (in this example) the external web service regardless if their network location.
Lync 2013 Mobile Client
On the surface it would be logical to assume that the Lync 2013 clients, which leverage UCWA, will instead utilize the following parameters.
Internal UCWA service : https://lync.schertz.name/ucwa/v1/applications
External UCWA service : https://lyncwebext.mslync.net/ucwa/v1/applications
Unfortunately that would be an incorrect assumption. These parameters are not currently used by the 2013 mobility clients and are reserved for future use, or for third-party applications to leverage. Notice that the internal URL is using the internal web services FQDN while the external URL is pointing to the external web service FQDN. This configuration allows for an application to select the appropriate URL for its location, if desired.
What the Lync 2013 mobility clients actually use to connect to the server and sign-in is a third UCWA parameter simply entitled ‘Ucwa’ which was included specifically for these 2013 clients. This parameter is set to always use the external web services FQDN.
- In order to see this additional parameter in the analyzer tool change the results view to Detailed Information and look then for the Autodiscover response which includes all of the service URLs. The Ucwa URL should be located adjacent to the two other internal and external Ucwa parameters.
<Link token=”Ucwa” href=”https://lyncwebext.mslync.net/ucwa/v1/applications“ />
<Link token=”Internal/Ucwa” href=https://lync.schertz.name/ucwa/v1/applications />
<Link token=”External/Ucwa” href=”https://lyncwebext.mslync.net/ucwa/v1/applications“ />
Although the 2013 mobility clients are using a separate dedicated Ucwa parameter the URL is the same web services location as provided by the External/Ucwa parameter.
In summary the Lync 2010 mobile clients are basically ‘tricked’ by the server into all registering to the external services regardless of their network location. But by comparison all Lync 2013 mobile clients are hardcoded to look for a unique parameter which always pushes them to the external services.
85 thoughts on “Understanding Lync 2013 Mobility”
Thanks Jeff, Excelent Article!
Should you mention that adding a lyncwebext A record in internal DNS would be required for domains with splitbrain or disparate namespaces? I know we had to do that, but many people fail to mention it and just mention the public DNS record only.
Yes, for proper hair-pinning an internally connected client would need to resolve the externally-accessible IP address of the external web services ingress point. This may be the same external IP address that is published in the external DNS zone record, or it could be a different address depending on how the traffic is hair-pinned. It's possible the network may be configured to direct those requests into a perimeter network without first leaving the WAN, or in the case of something like ISA/TMG that traffic could be hitting the internal reverse proxy interface and be applied against the same rules.
Fantastic article! Does a great job of detailing all the connection paths. I definitely learned a lot from it. Got a quick thing to note…it's not clear from your article, but I'm assuming lyncdiscoverinternal should point to the network load balancer if you're using an Enterprise pool, correct?
Thanks, and yes. The internal record would point to the same place as any other internal web services records for the same pool. Or to a Director, if installed.
Thanks, great article and very helpfull
[…] http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/ […]
Hello Jeff, great work
Slight clarification on internal vs. external MCX values. With cookie affinity the HLB should route the mobile request to the same FE server, regardless if connected internally or externally. The reason we force all connections to either the external or internal MCX instance based on the ExposedUrl value is because IIS doesn’t share session state information between virtual directories, even on the same server. If we didn’t force all connections to a single instance, you could potentially exhaust the maximum number of client registrations (8), simply by moving between internal and external networks.
[…] like to start off by pointing out the excellent blog post from MVP Jeff Schertz on the same subject, and for someone wanting to delve into the same level of […]
[…] Understanding Lync 2013 Mobility | Jeff Schertz’s Blog – Overview of mobility connectivity options in Lync 2010 and 2013 […]
I am not using hairpinning with my standard edition server and my MX clients work internally without issue. I have a friend that is using enterprise edition and his non-domain joined MX clients will not connect. Every other client connects fine as well as non-domain joined MX clients when used externally. Is there a different connection process between standard edition and enterprise edition that would require hair-pinning for one and not the other?
By 'MX' are you talking about the mobility clients or the Windows Store App client (which was previously referred to as MX or RT)? The non-domain joined clients (if Windows 8-based) will not trust a private Enterprise CA by default, hence the registration failure (TLS is not allowed).
[…] Understanding Lync 2013 Mobility: http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/ […]
[…] Understanding Lync 2013 Mobility: http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/ […]
We're have recently deployed Lync 2013 Standard in a OCS2007R2 environment and moved a few users. Since we'reonly using IM/Presence at this time, we want to allow mobile devices connecting via VPN access without needing a reverse proxy or edge server. I changed the ExposedWebURL to Internal, and I've hardcoded both the internal and external server names in the mobile client config to be https://lyncdiscoverinternal.domain.com/autodisco…. The mobile client will not login, but a laptop using the same VPN software, connecting to the same SSID, getting the same network IP range, does work.What could I be missing? I previously removed the record for lyncdiscover.domain.com, should I recreate this and if so should I point it to the front end?
Modifying the ExposedWebURL parameter only impacts Lync 2010 mobile client, you cannot point 2013 mobile clients directly to the internal web services. In fact the internal UCWA web service (listening on 443) does not even work with the 2013 client if you are successful in pointing them directly there by messing with DNS records. A reverse proxy is a requirement as you need to get the 2010 clients to connect to the external web services (listening on 4443).
Hi Jeff , thank you for the great article , I have tried in my lab to connect Lync 2013 mobile client to my Lync 2013 CU2 server and I was successfully able to connect without any reverse proxy or modification just an access point connecting to my network , I also verified that it is connected to internal web services by stopping the Lync external web from IIS and vise versa , all clients were able to connect successfully (Windows phone – IPhone – Android – IPAD and Surface ) , That is without Edge or reverse proxy for Internal access only .
It's possible that Microsoft fixed this in CU2, but when tested previously 2013 Mobility clients were unable to sign-in when forced to connect to the internal UCWA web service. Regardless the recommended approach is to provide external access as designed in normal deployments. If this works now in an internal-only lab environment that is good to know.
Thanks for your geat article.
However I am still puzzuled, what DNS recors I have to create.
Is this correct?
lyncdiscover.mydomain.com –> reverse proxy –> frond-end pool
lyncdiscoverinternal.myinternaldomain.com –> frond-end pool
lyncwebext.mydomain.com –> reverse proxy –> frond-end pool
Where does the name lyncwebext comes from. Where do I set this? Or does this exists by default?
The 'lyncwebext' name is just an example I used to reflect the Lync Web Services name. You have to define the external Lync Web Services FQDN manually, during the initial pool configuration or afterward if you like.
Just to be cristal clear, in a split DNS
– you don't create a lyncdiscover record internaly at all
– only the lyncdiscoverinternal record point to the FE.
Is this correct?
That is correct.
thank you for great article.
Do I need hair-pinning when all mobile clients are connecting from internet directly to Reverse proxy external interface ?
I have only public Lyncdiscover available, LyncdiscoverInternal is not present because nobody is connecting from internal.
I have an issue, when user is connected via Mobile client and is timeouted to static registration only (after few hours inactivity), device is not waking up when you try co make a lync call. Device is recieving push notification and trying to contact reverse proxy but ends with:
ms-diagnostics: 24118;Component="RTCC/188.8.131.52_UCWA/184.108.40.206";Reason="Application accepts invitations via static registration only.";Source="lyncFES.domain.com
I am using only windows phones with latest updates.
Do you have any idea where could be a problem?
You should still deploy the Lyncdiscoverinternal record as internal Windows Lync 2013 clients will leverage that. If this is some type of hosting environment and there will never be any internal clients of any type then I suppose you could omit that record.
Hi Jeff, great article. Ive been looking for a solution to my mobile clients. So far 2013 Android client is working but not ios or WP. I have a split brain dns but the same domain internal/external. My big doubt is if from my FE pool should be able to resolve the lyncwebext located in my ARR Proxy. I really appreciatte your answer.
Not necessarily the pool, but the clients should be able to.
Is contact picture set in Lync 2013 client also supposed to display on Lync 2013 Mobile client? If yes, do we need to do allow this through policy? I can see picture on Lync 2013 Client.
Contact photos work in the mobile clients, but I don't think there is a way to block them for only the mobile clients and not disable them for others at the same time. They should be working by default.
[…] Основой для написания статьи стала отличная статья Understanding Lync 2013 Mobility. Рекомендуется естественно прочитать в оригинале, но […]
Thanks for this great article. I have been having issues getting external clients to work. Could it be because I am using the same DNS name lyncpool.domain.com for both internal (points to FE server) and external (points to reverse proxy)? I tried using the Lync connectivity tool from the outside and it always tells me that my SSL certificate is invalid (purchased from GoDaddy).
I imagine that might cause some major issues. you should be using unique FQDN for each Lync component. You'll need to update your topology and request new certificate after defining a unique external web service FQDN.
Thanks for your blog, it has been very helpful in deploying my lync 2010 but I am having challenges with lync 2013 external users. I tried to examine the problem and I noticed that the link returned for them is the internal link instead of external. This I confirmed by using lync connectivity analyzer. Please what can I do to correct this problem.
I can't say what the issue would be for your specific deployment. I recommend posting a question to the TechNet Lync discussion forum for a timely response.
Great write-up. So how do I convince my "security guys" that allowing non authenticated traffic through a reverse proxy to the internal network is safe?
Jeff, nice post. I had a question, which is unrelated to this post of yours. Hoping to get some directions from you. I have a requirement where I want to set multiple conferencing policies based on the selected features I am enabling in Lync 2013 for different policies. I further want that when there is a change in the user AD attribute (like movement from Department = HR to Department = Finance), the associated lync conferencing policy should also change. How can I acheive this automation on the Lync 2013 conferencing policy which can dynamically change on user attribute change of AD? Any help would be greatly appreciated.
"What this means in the scenario where all autodiscover requests are pointed externally is that all internal Lync 2013 Windows clients (which is typically the critical mass of deployed users) could also be forced outside and be registering to an Edge server and hair-pinning all traffic. This is certainly a less than ideal configuration."
Can you please elaborate on why this is not a good idea? I have seen a couple of organizations route all internal traffic through their Edge and Proxy with no issues. I am not sure how this would affect pool pairing with another site either.
Mikey, if you intend it to support all client connections via external services and the topology is sized correctly to do so then that is fine. If for readers unaware of this behavior who assume that the majority of connections are directly to the internal Pools this could have a major impact if the Edge pool and reverse proxy is sized for a fraction of that traffic.
We have standard Lync 2013 Deployment with FE , Edge and Reverse proxy. Currently we have publish topology with single internal & external URL that is lync.xyz.com. Now we are facing problem with lync mobile client to connect through 3G internet over the WAN. As per your blog, we have decided to separate internal and external URL as lync.xyz.com for internal & lyncext.xyz.com for external.
I have below queries :
1) whether I am able to resolve mobile client issue by changing URL as per above?
2) what DNS internal & external entry require for Lyncdiscover?
3) I am going to add one more SAN entry in certificate that is lyncext.xyz.com. whether it is fine?
Please response so accordingly we will make changes.
Jeff, I am a big fan of yours and rely on your blog a lot.
I have a strange issue with one of my Lync 2013 implementations
Situation: 2 FE pool, 2 SQL DB with mirroring and Sqlexpress witness. 1 IISARR reverse proxy and 1 edge in DMZ.
edge has 2 Nics with both of them in DMZs, 1 DMZ routed to production and 1 NIC with 3 IP's in DMZ natted to public IP's.
Every single functionality is working perfect squeaky clean. The one strange issue I am having is as follows
Issue: when a user is logged into a phone Lync 2013 app from outside the Corp network (via 3g/4g/wifi)
1) the user logs in successfully. Can have IM conversations with corp user or federated user. can search directory etc.
2) When logged in user uses Lync app to make Lync voip calls
a) to a corp user outside the corp network (home or starbucks) everything works fine
b) to a federated user – everything works fine.
c) to a corp user inside the network the call rings (signaling is fine) when the other party picks up there is silence and the call disconnects. Interestingly this happens only for iphones and Android's. Windows phone and windows surface (Store App) works fine,
Error in diagnostics is 52156;reason="Failed to start audio stream."
Have you ever seen such a problem elsewhere? Any insight will be helpful.
I have been working with Microsoft Partner technical support for the past 6 weeks and no resolution so far.
Scorched and rebuilt FE's
Bypassed IISARR with port forwarding to FE
Opened every port and all IP on both DMZ's for testing, got cisco involved to make sure nothing is blocked or dropped – no go.
Would you happen to know any magic words 🙂
We have engaged Microsoft Premier support for this. Its been 6 weeks and they are still scratching their heads
Did you ever reach a resolution on this problem? One of the sites that I look after is experiencing exactly the same problem.
Make sure ports 50000-59999 TCP & UDP are open to the AV NIC of your Edge Server. Although initial connection and signalling go via Reverse Proxy, the media goes via the Edge.
Hi Javed, have you find solution of your problem as we also faced same problems, cisco users is unable to call lync mobile users either using 3G/4G/Wifi services. please response as soon
did you ever resolve this we have the issue
if user calls DDi and its answered outside the iPhone app (Cellular)
the call drops
Excellent article, who knew Lync could be so tricky!
A question: We have a functional Lync Front End and what seems to be a functional Edge server. However, users that are signed in from outside our network seem online but they are not recieving messages sent from within the network. What can possible be wrong? How can I troubleshoot?
Not sure what could be causing that as IMs are delivered in-band so if the external clients are successfully registered I can't say that I've ever seen issues like that before.
Yeah, I know it is very strange. Do you know what parts of the debugger tool I should be using to see where the trafic is going? Im not 100% sure if it is from all clients being outside the network or only for those who are using the Windows Metro app.
We have successfully configured Lync 2013 but are having problems with mobile clients. If we browse to https://lyncdiscover.domain.com/autodiscover/autodiscoverservice.svc/root we are getting the internal Lync FE pool name instead of the External Web Services URL although its configured in our topology as lyncweb.domain.com. Do you have any idea on what might be causing this?
Are the mobile clients connected to 3G or internal wireless?
I would like to know your thoughts on how you handle having BYOD scenarios. I have a customer that doesn’t want to configure Internal Trusted Root CA’s on all user devices.
When using the lyncdiscoverinternal the mobile device complains about CA certificate. When using lyncdiscover via Reverse proxy, then of course all clients start autodiscovering via the reverse proxy.
Do you assign a trusted Public Certificate to the Web services on the front end? Or do you setup a new DNS just for Wifi users?
Using public certificates on the Front End servers is the easiest way to solve the issue, but that may not be possible if the internal AD domain and or SIP domain names are not valid TLDs that cannot be validated by a third-party certificate authority. If that is the case then the devices would need to be provisioned with any private CA certs via some custom enrollment solution. Or push all WiFi devices to the external FQDN.
A question around mobility for clients on VPN with 2013 Lync.
I understand that the ExposedWebUrl is for the 2010 clients, and that the 2013 clients don’t use this, but in my deployment albeit there is a reverse proxy, there is no external DNS. Have you seen a deployment/are able to offer advice on how we can get mobile devices on VPN to sign in without the use of external DNS?
Without a DNS zone to manage I don’t see how you can control this as the mobile clients must use Lyncdiscover to function properly.
Thank you so much Jeff for you text about Lync Mobility..
I did all of your considerations about configuration Lync Mobility, and I can sign in to with my cell phone and Tablet (both of them have the same android version 4)
but, when I want to call or send IM , I just send One message and then I get this error :”Failed to process the server response ….” after that my users in both of devices going to offline status or something like that.
P.S: I should say my users have “Presence Unknown” status when they are login 🙁
i have the same Problem with lycn 2013 for android :(((((((((
Please Someone Help Me…. :(((
[…] One of the most helpful articles in my quest to understand the Lync Discover process was by Jeff Schertz, Cheers! – http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/ […]
This might not be the best place to ask you this, but it can be useful to others if you know a solution.
We are trying to prepare a template for directly calling a VMR on a external MCU from lync.
From what I see in the internet if we make a “sip:firstname.lastname@example.org” hyperlink, this should work fine, unless you have other sip clients installed on your machine.
The best one I found is im: which at least opens an IM and you can press the Video Call Button, but I was thinking if there is some specific format that Lync only uses and will not overlap with other sip clients.
I’ll appreciate an answer from you.
Have a great day!
Not that I’m aware of, if there are multiple clients on the PC which understand the sip: prefix then the most recently launched application will typically own those links.
Thank you very much for the answer, Jeff!
[…] One of the most helpful articles in my quest to understand the Lync Discover process was by Jeff Schertz, Cheers! – http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/ […]
hmm so let me get this right :
the internal MCX service uses the same URL as external MCX service ??
I can see my internal MCX and external MCX service both point to lyncext.domain.
which is why my lync 2013 mobile client works find when on the internet but fails while on the company network ??? is that so ??
if this is so when what do I need to do , to get mobile clients to work on the internal network?
do I add a DNS ahost on the internal DNS server for lyncext = LYNC FE server ip ??
how do I get the mobile client to translate the url it receives (ie lyncext ) to the internal (ie lyncint)
No, the Lync 2013 mobile client do not use the MCX URLs, those are only used by the 2010 mobile clients. All Lync 2013 mobile clients will always use the UCWA external URL, regardless of their network location. You need to create an internal DNS record for the external FQDN and point it to your external reverse proxy IP, and allow hairpinning of the traffic.
I’m in the same position.
Mobile devices can’t connect in our wireless networks but works fine on the internet.
Have you find the solution for this issue
Thanks a lot ..well written article with a lot of explanations
If I manually enter the server address in Lync 2013 mobile app, what address should it be for Internal Discovery Address and External Discovery Address? lyncdiscoverinternal.domain.com and lyncdiscover.domain.com ? or just External web services address?
If I use lyncdiscoverinternal.domain.com and lyncdiscover.domain.com it takes forever to sing in and if used External web services address, it says “We can’t sign you in. Please check your account info and try again.” the log shows “You do not have permission to view this directory or page using the credentials that you supplied”
I’m not using an actual reverse proxy like TMG or ARR. But a port forward from the router to the FE server with a port translation as “from 443 to 4443”. Kindly advice me. Thanks a lot.
I have inherited a Lync environment that isn’t fully functioning with iOS devices. The challenging part is the there are 5 Sip domains, and unfortunately they were trying to use wildcard certs for everything.
I have purchased new SSL certs for the FE and RevProxy. I installed the certs and intermediate certs on my phone, too. With the Skype for Business app, I can login, sync my presence, search the address book, and find users
However, when I send or receive an IM, update my status, join a Conference Call, Lync audio Call, or video call, I get an error: “Failed to process the server response. Please try again….” This error pops up on my phone the second I accept the IM on the distant end Lync client.
Then my app says Connecting and just sits there. I have to log out of Lync on the app. And then log back in.
I have been watching IIS logs on the FE, and my Apache Logs on the RevProxy. Everything seems okay. No glaring errors.
Lync Connectivity Analyzer says I am good both internal and external (using a 4G hotspot). I have not been able to find any good troubleshooting documentation that goes beyond the initial setup.
Would you be able to advise me or point me towards additional information?
Also, Lync 2010 app works fine. I can IM back and forth no problem.
I ended up getting Lync Mobility working. YEAH!
I patched my FE and Edge to the latest cumulative update pack. And I switched from Apache RevProxy to IIS ARR.
Now everything is working perfectly.
In an organization we have Lync 2010 and SFB 2015 in co-existence located in different sites.
is it possible to bring up a separate Reverse Proxy for SFB 2015 to handle the HTTP and HTTPS requests.
Please give some advice on this.
Don’t see why not.
Your articles have been extremely helpful in our quest at installing Lync 2013. We are stumped on one thing at this point; mobile. So we have a .local and .com configuration, however I have added an additional sip domain and users can log in internally as .com or .local so that is working. Our issues comes in on mobile. On the Lync Connectivity Analyzer we are succeeding through the mobile tests when entering the sip uri as .com and additionally entering the username as domain\username, and the client setting is Lync Mobile 2013 App. Everything in the detailed information is successful and would make me assume our config is correct, however when logging in on a mobile device we get a “cannot connect to the server” error. Now if we go through the Connectivity Analyzer and do not enter the Username(optional), we fail all autodiscovery tasks with an internal server error 500.
Does this information apply as is for Skype for Business 2015 or are there any differences in the behaviour of the mobile clients ?
As far as I know the SfB 2015 mobile clients operate the same way but I haven’t performed much testing with them yet.
i have problem in Skype for business mobility service.
my internal and external domain is different. when i change external web service to external domain from topology, i can not connect to Skype from mobile devices, but if i change web service to default mode ( internal domain), i can connect to Skype mobile client from internal network.
how can i fix this problem ?
thank you for your kind support.
Hey Jeff I am running 2 front end pools running from two different sites. Site A has FE1, Edge and Reverse Proxy IIS AAR, Site B has FE2. When I move a user from my FE1 to FE2 they are no longer able to login to the Skype4Bus mobile app. If I move that same user back to my FE1, the mobile app works. Is there more to the basic reverse proxy setup when you have 2 front end pools?
I would assume that FE2 is not correctly published through your reverse proxy which would cause the mobile clients to lose access as they do not use SIP signaling through your end server like the desktop clients do.
This is (as most of your blogs are) quite helpful, but what I don’t get is how you can add an A record for webext.domain.com to Windows DNS when your external DNS name is different from internal DNS name as in webext.company.com on the outside and webext.adst.company.com, DNS won’t let you add an A record for the outside name. Just where exactly is the webext entry supposed to go? Our DNS is different on the outside and the inside. And is it even required in 2013/SfB? All of this stuff is just misleading, even Microsoft don’t tell you to add external IP addresses and DNS entries into your internal DNS.
This can be handled in a couple of ways. The shortcut method is to create a new DNS zone with the desired FQDN as the name (eg. webext.domain.com) and then add an A record in that zone of ‘@’ pointing to the external IP. The other method is to create the a full DNS zone for domain.com internally and then setup forwarding so that unresolved requests are forwarded to the external DNS zone for domain.com. Then create a single A record on the internal zone for webext.domain.com.
Hi, i am not sure wthr you are still open to help queries related to Lyc/SFB Exernal autodiscovery issues.
I am facing a strange issue, i have two sites pointing autodiscovery for one site works fine but for the other site its not working. The reason is it tries it tries to look for the internal web services record.
From reverse proxy its pointing to external webservices 4443 to front end i am not sure why it looks for internal webservices record which is not obviously not published in the public network.
The workaround works in a way when i keep both internal and external web services record same in the topology but that not a proper solution. I dont want to keep internal web services records published externally
Can you help me with this??
We are implementing SFB2015 External Mobility with F5 (Reverse Proxy).
When we probe to make a call or videocalll between a Mobile Phone with other Mobile Phone this work fine! Edge server work it.
But, when we try to establish a call between a Mobile Phone (user external) and Phone IP HP 4210 (user internal) (Traditional Phone IP that we have in the office), the call is established but media feature (Audio/Video) doesn’t work!
It seems that this communication does not pass through the Edge server but that the Mobile Phone(external user) tries to communicate directly with the HP 4120 phone in the office. The call is established but the audio does not work. Will you know what may be happening?
The clients will always attempt to establish media directly and if that fails then fallback to reflexive and relay methods (via Edge). As they two clients appear to have direct IP connectivity then that approach will win out even if some of the communications appear to still be failing. Most likely a firewall issues between the networks where the IP phones are (VLAN?) and the networks where the mobile clients are (WiFi).
Thank you so much Jeff.
I had to enable some rules in our Network Firewall from IP phone to Edge Server.
I am just getting ready to deploy a LYNC Reverse Proxy using WAP Server 2012 R2. I have most working if not all.
My URL’s for LYNC Web Services and LyncDiscover differ from Internal to External. Internally Web Services is lyncwsint.domain.com and for discovery internally its lyncdiscoverinternal.domain.com.
Externally my web services URL is lyncwsext.domain.com and discovery is lyncdiscover.domain.com.
For my published rules in WAP meet, dialin and WAC were straightforward. The external URL matches the internal URL and external URL redirects to Backend URL on 4443. Those are working.
My question is this. For the publishing of Web Services and LyncDiscovery URL’s I can only get it to work if I redirect from lyncwsext.domain.com:443 –> lyncwsint.domain.com:4443 and lyncdiscover.domain.com:443 –> lyncdiscoverinternal:4443
When I make them match I get an error that it cannot connect to backend server. I am doing this correctly? If I hit those External URLs in a web browser with the redirection using different external and backend URL’s I do get a response and it appears to work.
Any advise would be great!