I am new to TechNet forums and am not sure if I'm posting this question to the right forum.
The company I work for recently migrated from Sametime to Lync and I installed it on my phone as soon as it became available for downloading on Nokia Suite.
After installing the app, I completed all the required fields but I never got signed-in. The startup screen just idles forever while starting a session. I tried to connect while connected to a wifi network and to my provider's 3G network.
I asked the support staff at my company and they told me to try again providing the internal and external discovery address (https://......../Autodiscover/autodiscoverservice.svc/Root), but this didn't work either. I was also asked to try connecting to my account from an Android device, and this time I was able to connect with my username. I also tried to connect using another Nokia N8 running Symbian Belle and, again, it failed to sign-in. The owner of this phone was also unable to get signed in.
Of course, while trying to connect from my phone, I tried many different variations: entering domain and username in their own fields and only on the username field (domain\username), checking and unchecking the registration option, using the IP address for the server instead of its name, etc., etc. And I also went for a hard reset of my phone and reinstalled everything from scratch. I'm still having the same problem.
The support staff confirmed that the Lync server has all the latest mobility components installed, as specified here: Set up Lync for mobile devices. I have the feeling that the support staff at my company is already giving up on all users trying to connect from a Symbian device since they are not company-owned personal devices.
Does somebody know if this is an issue with the Symbian version of Microsoft Apps, or if other Symbian users have experienced the same problem?
- Edited by Carlos Spörk Tuesday, July 10, 2012 1:04 AM Corrected title
Symbian is supported as you can see in this link.
But sometimes it is difficult to troubleshoot.
Try to open your (https://......../Autodiscover/autodiscoverservice.svc/Root) in IE. you should receive a file with the default website for your mobile.
Is your account enabled for Lync voice enterprise, because Lync mobile works only for voice enterprise user.
If not you can use this client from damaka
regards Holger Technical Specialist UC
Thank you, Holger.
I appreciate the information on the Xavy client but, to be honest, I do not intend to spend any of my own money on an application just to access the corporate IM system from my personal device. I'd gladly use Lync on my device if I get it to work but, again, just because I have an unlimited data plan.
I tried to open the discovery service page on IE. It starts a download dialog and then pops up an error msg that reads "Unable to download Root from <server>.<domain>.com". Is that the expected behavior?
My company didn't enable voice enterprise for Lync. Does it mean that Symbian devices cannot use Lync mobile? Other users can connect from to Lync using their iPhones and Android devices to use IM. I'm not sure I follow here...
I have exactly the same problem and have tried almost everything that you did.
I was not even able to use Communicator on my phone. And after we upgraded to Lync, I believed my phone will never support it. But today when I got the latest Microsoft Apps 2.0.1, I was happy to be able to use Lync and MS Exchange on my phone. But it seems nothing is working and the install is a waste.
Please let know if you find something.
I guess you are right, Prasanth. To my knowledge, only Symbian phones have a problem connecting to corporate accounts.
And, again, you are right: Lync for Symbian has a logging option. I have this option already enabled. Problem is, I don't know where to find the log file, not even what the filename might be. I tried a search for files with a .log extension and a number of possible filenames and didn't find but log-files kept by other apps on the phone.
Do you know where to find them, or what the filename might be?
I was able to find the logfile created by Lync on my Symbian Belle phone. I masked my username and the server names. Can you please review the log and let me know if it provides information to diagnose the reason for not allowing me to sign in?
- Edited by Carlos Spörk Saturday, July 21, 2012 3:23 AM
I reveiwed the logs and i see the cause of the failure being an Authentication problem
By Authentication, I mean that the device is unable to Retreive the web ticket from Web Ticket URL. Below is a excerpt of the log
i,2012-07-20 20:03:39.484,LYNC,tid:2705,D:/bt/5778/src/lync/src/dev/como/transport/ucwaautodiscovery/private/cucwaautodiscoveryresponse.cpp,TRANSPORT,131,location value is external
i,2012-07-20 20:03:39.486,LYNC,tid:2705,D:/bt/5778/src/lync/src/dev/como/transport/ucwaautodiscovery/private/cucwaautodiscoveryresponse.cpp,TRANSPORT,210,User url is https://otheraddr.company.com/Autodiscover/AutodiscoverService.svc/root/user
i,2012-07-20 20:03:39.488,LYNC,tid:2705,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/private/chttprequestprocessor.cpp,TRANSPORT,273,Sending event to main thread for request(0x92145f8)
i,2012-07-20 20:03:39.490,LYNC,tid:2705,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,351,Close Connection Called
i,2012-07-20 20:04:38.896,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,351,Close Connection Called
e,2012-07-20 20:04:38.903,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,764,Received Error signal Qt code: 5 Error code = 268435462 ErrorDescription = Operation canceled request WebTicketRequest
i,2012-07-20 20:04:38.908,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,499,Received Finished signal for request WebTicketRequest
e,2012-07-20 20:04:38.912,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,403,Connection timedout for request (WebTicketRequest) - notifying error E_ConnectionTimeoutError
i,2012-07-20 20:04:38.916,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/private/chttprequestprocessor.cpp,TRANSPORT,134,Received response of request(WebTicketRequest) with status = 0x22020005
i,2012-07-20 20:04:38.920,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/private/chttprequestprocessor.cpp,TRANSPORT,273,Sending event to main thread for request(0x9274b10)
i,2012-07-20 20:04:38.925,LYNC,tid:2717,D:/bt/5778/src/lync/src/dev/como/transport/requestprocessor/privates60/chttpconnection.cpp,TRANSPORT,351,Close Connection Called
i,2012-07-20 20:04:38.932,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/transport/webticket/private/cwebticketsession.cpp,TRANSPORT,369,Received webticket resposne with status 570556421
i,2012-07-20 20:04:38.943,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/transport/webticket/private/cwebticketsession.cpp,TRANSPORT,1017,Raising WebTicketEvent for https://otheraddr.company.com/Autodiscover/AutodiscoverService.svc/root and https://otheraddr.company.com/WebTicket/WebTicketService.svc with status 570556421
i,2012-07-20 20:04:38.955,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/transport/authenticationresolver/private/cauthenticationresolver.cpp,TRANSPORT,591,Web-Ticket retrieval for url https://otheraddr.company.com/Autodiscover/AutodiscoverService.svc/root completed with status 570556421
e,2012-07-20 20:04:38.961,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/transport/authenticationresolver/private/cauthenticationresolver.cpp,TRANSPORT,657,Failing the original request as we weren't able to get thewebticket
i,2012-07-20 20:04:38.965,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/transport/transportmanager/private/ctransportmanager.cpp,TRANSPORT,631,Notifying response of request(UcwaAutoDiscoveryRequest) with status = 0x22020005
i,2012-07-20 20:04:38.969,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/infrastructure/private/ctransportrequestretrialqueue.cpp,APPLICATION,293,Req. event received: responseErrorCode=E2-2-5
i,2012-07-20 20:04:38.974,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/infrastructure/private/ctransportrequestretrialqueue.cpp,APPLICATION,943,No more req. timing out
i,2012-07-20 20:04:38.975,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/infrastructure/private/cucwaautodiscoveryservice.cpp,APPLICATION,1013,Received autodiscovery response with status 570556421
i,2012-07-20 20:04:38.976,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/infrastructure/private/cucwaautodiscoveryservice.cpp,APPLICATION,970,Raising Autodiscovery event with status 570556421 for eventType 0
e,2012-07-20 20:04:38.978,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/infrastructure/private/cucwaautodiscoveryserviceretrialwrapper.cpp,APPLICATION,354,Auto-discovery failed. Analysing the failure
e,2012-07-20 20:04:38.979,LYNC,tid:2691,D:/bt/5778/src/lync/src/dev/como/applicationlayer/objectmodel/private/calertreporter.cpp,APPLICATION,49,Alert received! Type 16384, level 0, error E2-2-5, context '
Looking through the logs, I am surprised that other Platforms(Iphone) are not encountering this issue
Getting back to the point, I would like to to understand what is connection termination point for the session initated by the Lync Mobile on symbian(Is it a TMG,ISA,UAG,F5 HLB acting as a Reverse Proxy,Bluecoat or any other solution).
It helps if you can schematically tell me the route of the connection path. As i have it below for my Lab setup
External Clinet on 3G(Lync mobile)--->(TCP/443) --> TMG (External Interface) -- -->(TCP/4443) --> Ext Lync Web Services(autodiscover)
Similarly, what would be yours?
Are you able to browse https://otheraddr.company.com/WebTicket/WebTicketService.svc and https://otheraddr.company.com/Autodiscover/AutodiscoverService.svc/root successfully.
WebTicket URL should give you a Static site and Autodiscover URL should allow you to download a file(On a Mobile, It can simply say unable to download which is fine)
I'm sorry for the delay in my reply. Here are my answers:
I was not able to get the information on the connection termination point or the connection path from the support staff at my company. What they told me is that my user was assigned to the wrong pool and moved me over to the right pool. That's why I was connecting to the "otheraddr" server instead of the address specified in the external/internal autodiscover address fields.
Anyway, I am still unable to connect. I can provide the new log files if it helps. Please let me know. I promise I'll reply at once.
This is the link to the log file. I imported it to MS Excel for easier view/access. Lync log file from Nokia N8-00 Symbian Belle
I know for certain that at least Android devices have no issues to connect to my company's implementation of Lync. I connected with my username from an Android device. And my support staff confirmed that iPhone and Nokia Lumia (Windows phones) users are not having any issues connecting.
I also know of at least three other Symbian Belle users that have the same issue, but I can't tell for certain if there other Symbian Belle devices that are not experiencing any issues at all.
Looked at the log.
From what i gather, I don't see your phone being able to reach
What happens when you access the site from your phones's Browser.
Ideally it would say the file cannot be downloaded(Atleast windows phone,Iphone doesn't allow the file download)
If you were to access the URL from the desktop you should be able to save the file
I am not able to Validate because the URL is not accessible possibly because you changed the server name
I am able to save the file (Root) when I try to access the autodiscovery service address from my desktop's browser. However, my phone's browser can't connect to the site.
On this new version of the log, I kept the original server names.
By the way, someone in the Nokia discussions forum wrote the following:
"...one potential reason for the Lync sign-in failure has been found. Not sure if it's the issue in your case but please check with your server administrator that SSLv3 connections are enabled on the server side. Lync client uses SSLv3 for the communication and it has turned out that in some cases SSLv3 has been disabled on the server, causing the Lync sign in to fail.
The instructions for adjusting the SSLv3 setting can be found in the MS KB article below:
If SSL 3.0 is now disabled, turn it on and try signing in again."
I reported this to the support staff at my company and they said that SSLv3 was not enabled, and that before enabling SSLv3 they need to evaluate the company-wide side effects on the implementation.
https://autodiscsrvr.my-company.com/Autodiscover/autodiscoverservice.svc/Root is not accessible from my system. Considering that this is an external site, I would expect it to work
Regarding SSLV3, I am certainly aware of a known issue around TLS 1.2 with Iphone
However if the issue were due to Incomaptible SSLV3 versions being negotited, You would typically get a error such as "can't verify certificate is from a Trusted Source" error when you access the site
Below is the info on TLS compatibities around Iphone
IOS 5.0 uses TLS 1.2 by default for SSL connections to mitigate BEAST attacks. It is now well assumed that TLS 1.2 is more secure than TLS 1.0, and browsers and servers are all supporting this TLS version now. However, some non-compliant TLS server implementations do not implement TLS 1.2 and, more importantly, do not downgrade gracefully to a supported protocol version.
Because of this, load balancers and reverse proxies MUST support TLS 1.2, because they act as a SSL termination point for Lync mobile clients. However, not all load balancers and reverse proxies handle TLS 1.2 correctly, including but not limited to:
BIG IP F5 (http://support.f5.com/kb/en-us/solutions/public/13000/100/sol13147.html) (resolved in 10.2.2 HF1)
Windows 2008 R2 servers MAY also need to support TLS 1.1 and 1.2, but it is not enabled by default
If SSLV3 is the issue, They need to enable it where the Lync Mobile connection terminates
for example in the below case, Connection is getting terminated on TMG server
External Clinet on 3G(Lync mobile)--->(TCP/443) --> TMG (External Interface) -- -->(TCP/4443) --> Ext Lync Web Services(autodiscover)
So based on the above info Security Incompatibity could be a cause, However i cannot validate as We need a Network Monitor trace on the connection Termination point when you attempt to use symbian Phone
I'll be on vacation for a week but will be following up on the post
I'm sorry, but I thought the new version of the file had the original server names. Can you please check if this version lets you access the "Root" file: https://skydrive.live.com/redir?resid=75933EAF5601A3A9!927&authkey=!ANMk2YGHoUTTMbo?
I forwarded your post to the support staff at my company and they told me they are actively looking into it. I will also ask them if we can arrange tracing my attempts to access Lync.
I will keep you posted.
Thanks so much for your help so far.
We have problems too with Nokia Symbian Lync clients (E7 and E6). We can connect internally through Wi-Fi but not using mobile connection through our reverse proxy (Forefront UAG). iOS, Android and Windows Phone -clients are all good. I checked that our Lync server supports SSLv3 and so does UAG. Finding Lync logs from Symbian seems impossible.
Any help is appreciated.
I don't know if the E7 and E6 have a native "Files" app installed. I use this app to find the Lync log files on my N8. Upon starting the app, I perform a search for "*lync*log*" (without the quotes) on the "Root" folder of the phone's mass memory.
I hope this helps.
On my N8, the app is installed on the phone's memory. I believe it can only be installed there. However, I've always located the log files on the phone's mass storage.
You should also know that I was only able to find the log files with the "Find" feature of the "Files" app on my N8. I've never been able to find these files by manually browsing through the folder structure.
The filename follows the following naming convention: E-sys-bin-lync.exe0.log, E-sys-bin-lync.exe1.log, and so on.
The problem has not been fixed. My company implemented SSL v3 on the Lync servers, but I still was not able to connect. The support staff worked with MS Consultants to monitor, trace and analyze my phone's attempts to connect on the server side. I also had to provide the log files created on my phone during those attempts. They finally told me that the connection attempts were all successful on the server side, even when my phone was not able to establish a connection. They asked me to send the server logs and my phone's log to Nokia, which I did. Nokia quickly replied requesting me to take the phone to a Nokia Care Center to re-flash my phone, reinstall Lync and then report back to them if I was able to connect. I had to work, again, with the support staff at my company to get the server log files of my new attempts, which I sent to Nokia, along with the new log files on my phone. I sent everything to Nokia again, but I haven't heard back from them (this was about 3 weeks ago). I insisted twice, but then I gave up. Interestingly, only a week ago, a friend of mine, who also has a Nokia N8 and works for a different company, told me that he was told by a Nokia official that Microsoft Apps had been withdrawn from the Nokia online Store for all N8s.
I leave it up to you to draw your conclusion. I uninstalled MS Apps from my phone 3 days ago.
For what it's worth, I was trying to get this working today/yesterday too, and came across this thread.
It got as far as trying to do the initial unauthenticated request for the autodiscovery URL, and whilst the logs hinted at SSL issues, I don't believe this is the actual reason.
In the logs, it sends an HTTP Accept header of application/vnd.microsoft.rtc.autodiscover+xml;q=1. The problem is that Lync Server appears to reject the Accept header, even if it's valid.
Below is a couple excerpts from using wget to test this:
> wget --no-check-certificate --secure-protocol=SSLv3 https://lyncdir.mydomain/Autodiscover/AutodiscoverService.svc/Root?sipurl:user@mydomain
WARNING: cannot verify lyncdir.mydomain's certificate, issued by `/DC=mydomain/CN=MyDomain Issuing CA':
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 282 [application/vnd.microsoft.rtc.autodiscover+json]
> wget --no-check-certificate --secure-protocol=SSLv3 --header=Accept:application/vnd.microsoft.rtc.autodiscover+xml https://lyncdir.mydomain/Autodiscover/AutodiscoverService.svc/Root?sipurl:user@mydomain
WARNING: cannot verify lyncidr.mydomain's certificate, issued by `/DC=mydomain/CN=MyDomain Issuing CA':
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 406 Not Acceptable
Even when changing xml to json, so it matches exactly the mimetype returned when an HTTP Accept header is not explicitly sent, it still replies with 406 Not Acceptable.
This seems like a bug in the Lync Server to me, as it's basically flat out rejecting any requests that explicitly request a specific format. And since by default it returns JSON, instead of XML, which the Symbian Lync client is expecting, the lack of supporting the HTTP Accept header correctly makes it a complete show-stopper for the Symbian Lync client.
And yes, my phone already has the certificates for the Lync servers (both internal and external) stored on the phone, and as the above shows, using SSLv3 isn't an issue either.
Thank you jessic4h.
I performed a full restore of my phone and reinstalled Microsoft Apps on my phone again, just for the fun of it (!), but Lync is obviously not working yet.
The question now is: Where do I go now for support on this issue? Or should I just drop the whole thing and consider it part of a learned lesson on how long it takes to troubleshoot an issue that turns out to be, probably, a bug in the underlying platform?
Is there a way for someone who is knowledgeable in this matter to report the eventual bug to Microsoft and ask them to look into it?