I have come across this scenario in two customer deployments now whereby a user attempts to sign onto Lync Mobile 2013 using a Wi-Fi only connection on their Windows Phone the first time they connect to Lync on their mobile device. It simply does not work. Once the user signs on from a cellular data connection either by disabling Wi-Fi or when out of range, the user can then come and go from their office as they please and sign in and out of Lync without any issues.
This behavior does not occur on IOS devices in the testing I have done. I cannot comment on Android devices as of yet.
In all customer deployed scenarios the Microsoft guidance was strictly followed using a proper reverse proxy and defining the DNS records properly. See Technical Requirements for Lync 2013 Mobility on TechNet for more details. As well the use of the Lync Connectivity analyzer showed successful testing of the Lync Mobile requirements in these environments.
If anyone else has seen this experience please feel free to comment. I will provide more info as I get it. Perhaps someone from the Microsoft Lync Product Group can comment on this behavior.
To try this in your environment (assuming the Mobility guidance was followed) clear your Lync 2013 Mobile on WPE sign in info, disable your cellular data connection and attempt to sign on.
Reviewing the logs shows the correct attempts but fails with the following errors:
I have highlighted the interesting info to look at:
2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/77:Starting CUrlRedirectAndTrustResolver with url = https://lyncdiscoverinternal.domain.com/?sipuri=sip:[email protected], maxHops = 10
2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/201:CUrlRedirectAndTrustResolver::processUrl called with url = https://lyncdiscoverinternal.domain.com/, hopCount = 0, maxHops = 10
2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/610:UrlRedirectAndTrustResolver complete with url = https://lyncdiscoverinternal.domain.com/, Hops = 0, status = S0-0-0
2013-11-05 18:07:53.899 Lync[2196:2200] INFO TRANSPORT CCredentialManager.cpp/176:getSpecificCredential for serviceId(4) returning: credType (1) signInName () domain () username () password.empty() (1) certificate.isValid() (0) privateKey.empty() (1) compatibleServiceIds(4)
On an IOS device with WiFi only the following successful logon is logged. This is also logged on a WPE when its working properly:
https://lyncdiscover.domain.com/?sipuri=sip:[email protected], maxHops = 10
2013-11-05 19:20:44.332 Lync[106:3ba6b18c] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/201:CUrlRedirectAndTrustResolver::processUrl called with url = https://lyncdiscover.domain.com/, hopCount = 0, maxHops = 10
2013-11-05 19:20:44.332 Lync[106:3ba6b18c] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/610:UrlRedirectAndTrustResolver complete with url = https://lyncdiscover.domain.com/, Hops = 0, status = S_OK (S0-0-0)
2013-11-05 19:20:44.333 Lync[106:3ba6b18c] INFO TRANSPORT CTransportThread.cpp/131:Added Request(UcwaAutoDiscoveryRequest) to Request Processor queue
2013-11-05 19:20:44.333 Lync[106:4d3e000] INFO TRANSPORT CTransportThread.cpp/343:Sent Request(UcwaAutoDiscoveryRequest) to Request Processor
2013-11-05 19:20:44.334 Lync[106:4d3e000] WARNING TRANSPORT CCredentialManager.cpp/317:CCredentialManager::getSpecificCredential returning NULL credential for serviceId (4) type (1)!
2013-11-05 19:20:44.335 Lync[106:4d3e000] INFO TRANSPORT TransportUtilityFunctions.cpp/631:<SentRequest>
GET https://lyncdiscover.domain.com/?sipuri=sip:[email protected]
Request Id: 0x1183fc8
HttpHeader:Accept application/vnd.microsoft.rtc.autodiscover+xml;v=1
Comments