Pidgin to Lync integration: solved
I had been trying to get the open source instant messenger client Pidgin to connect to Lync using SIPE. However, they wouldn’t play nice.
The Pidgin GUI kept saying “Web ticket request to https:// webdir0e- ext.online.lync.com:443/ CertProv/ CertProvisioningService.svc failed” while the debug log from running pidgin –debug ended with an XML containing “Web ticket request error – SIP URI mismatch” – after confirming username and password to be ok.
My environment was Pidgin 2.10.7 and SIPE 1.15.0 on Win8 connecting to Office 365 (no local AD).
The great interwebs did not have a lot of information, but the case was eventually solved by heroic effort from Microsoft support engineer Sankaranarayanan (v-9sak). He went above and beyond on my support request, consulted superiors, spent several hours with me on the phone while we worked together on debugging and fixing this – and this on a problem and client (Pidgin) that Microsoft does not even support!
I am duly impressed both by Microsoft and the-man-whose-name-contains-a-lot-of-a’s in this case.
The problem was due to my primary email being different from my account user name. Possibly because we were early adopters of BPOS (previous version of Office 365), possibly because my first-time signin on Lync was using my primary email, possibly because of something else entirely, Lync signed in with my primary email while Outlook and everything else signed in with my username. Pidgin required that my username be my Office 365 username (or else it would give password error), but it would give the elusive SIP URI mismatch error if I put anything else than blank or my username in the logon field.
While Microsoft told me it was possible to fix this by changing my Lync logon from primary email to username, the best solution for me was to change my username to match my primary email address.
This consisted of backing up my email into a new PST-file (not needed), deleting everything under C:\Users\mywindowsuser\AppData\Local\Microsoft\Office\15.0\Lync and changing the username part-by-part first the last part from domain.no to domain.onmicrosoft.com, then the first part, then the last part back again – and logging in to portal.microsoftonline.com between the steps, checking that my Lync settings was being propagated. I am not sure how much of this was “just to be sure”.
In the end my Pidgin settings was just like SIPE tells us to:
Pidgin Basic settings
On the General tab:
Protocol: Office Communicator
Username: Office365-username of the form name@domain.no
Logon: blank
Password: duh
Local alias: blank
On the advanced tab:
Server: blank
Connection type: automatic
Useragent: UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)
Authentication: TLS-DSK
Single sign-on unchecked
NOTE: For Lync 2013 a reader has reported that you need useragent
UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)
Pidgin Advanced settings
Nothing else.
Thanks to Stefan Becker for looking at my debug log output, and to Tor Arne Helgesen for the Lync 2013 user agent string.
I’m leaving a comment here in order to further improve the Google search results on a related issue:
Stefan updated sipe in 1.15.1 to address the issue you describe above. However, as a result, if you still have your old BPOS login (or potentially any other value than whatever the correct value might be) in the Login field, Office 365 will return a different cryptic error:
“The specified member name is either invalid or empty.”
This was really confusing to me, as I haven’t touched my config settings since we were upgraded to Office 365 in March 2012, and it had been working happily all this time…
In my case, setting the Login value to blank restored connectivity for me. If that hadn’t worked, Stefan suggested I would have needed to determine what the current correct value for my O365 login is and supply that instead. (Not sure how to get that though; he just said “ask your IT” but I don’t think anyone here really knows as it’s all abstracted away from us.)
Anyway, hope that helps someone else at some point!
Thanks for writing the informative blog post. Finally I found a solution through you to the mind numbing problem.
Guys, so can you give a concrete example?
You changed your Ubuntu username from what to what to work?
I don’t get what exactly you changed your linux username into…
Pls help?
Thanks!
What if im using a perl script and i need to put the lync settings as is server name,username and password
This change did not work for me. I keep getting the same error repeatedly. I’ve tried both the Lync 2010 and Lync 2013 user-agent strings. My company uses Lync 2013 thought the firefox browser plugin works (with very limited functionality). Pidgin does not. Running on Linux.
Holy crap on a cracker! This was exactly my problem.. I should have suspected as much. Thank you so much for this, and thank you to Sankaranarayanan!!! I can only imagine how much time you two have saved me.
Thanks a lot, this was exactly my problem!
IT WORKS!
Thank you so much for this. Finally the only Linux dude in our company doesn’t force all others to use GoToMeeting for the release chats.
Worked for me after my company migrated from an on-site lync installation to a cloud installation.
Removed the login name and set the user agent: now it works again.
Thanks!!!
for pidgin Version 1:2.12.0-1ub and pidgin-sipe version 1.23.3+sipe-. The best way to go forward is to
1. Basic: Only Put the user name and password – Do Not Put in the Domain\User
2. Advanced: Leave Server:Port Blank. and add in User Agent as UCCAPI/16.0.6965.5308 OC/16.0.6965.2117
3. Do Not Touch any other tabs
Thatś work for me
this was working for me :
UCCAPI/16.0.6001.1073 OC/16.0.6001.1073 (Skype for Business)