locked
Lync Phone Edition with Office 365 RRS feed

  • Question

  • This question is really about whether Lync Phone Edition works with Exchange Online, or if it only works with Exchange on-premises.

    We have an on-premises Lync 2013 server.  Our email is with Exchange Online (the Enterprise E4 plan).  We are using Dirsync + AD FS for SSO.  Lync works.  Exchange Unified Messaging works.  My SIP domain and primary SMTP domain are the same.

    What doesn't work is when I use a Lync Phone (with the latest firmware update 4.0.7577.4455) and try to access the calendar.  It gives me an error "Connection to Microsoft Exchange is unavailable."

    I am tethered via USB to a PC with Lync 2013 running.  It shows calendar events (from Exchange) on the desktop client without issue.  The desktop client shows the EWS External URL as: https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity​   The EWS Internal URL is blank (obviously).

    My guess?  It's either not supposed to work at all (please someone verify for me), or it is, and I just missed some little step somewhere in my setup process.  If it is supposed to work, I'm guessing it has to do with certificate issues... like perhaps Lync Phone Edition doesn't trust the CA of outlook.office365.com by default.

    Thanks for any advice anyone has to offer.

    Thursday, February 5, 2015 12:26 AM

Answers

  • I am reporting back with my solution.  I can now confirm that one can have Lync servers on-premises with Exchange Online using Office 365 and the Lync Phone Edition devices will work.  Contact search, calendar (although it only shows the day's Lync meetings), and visual voice mail all work.

    Summary of fix: AD FS certificates have to be issued by CAs that Lync Phone Edition trusts.

    The problem was when the Lync Phone Edition came back and tried to log in through AD FS.  Since we had single sign-on with Office 365 set up before we even ventured down the Lync path, the certificates for AD FS weren't issued by a CA that Lync Phone Edition trusted.  Getting new certificates solved the issue.  (They were issued by the same CA that did the "external web" certificate on the Lync Front End in case that matters.)

    I tried hard to get the phones to trust the original certificate first, putting it in Active Directory using the certutil -dsPublish method, putting the original CA on the Lync Web Services trusted list using Set-CsWebServiceConfiguration.  But nothing seemed to work until I finally just gave up and got a new certificate issued.  I am now running without any certificates listed in Active Directory nor any explicitly listed in Lync's Get-CsWebServiceConfiguration and it works great.

    The Technet articles are woefully out of date when it comes to the trusted CA list, but here's a link to the list of trusted CAs (with the updated firmware): http://blog.schertz.name/2014/10/lync-phone-edition-and-public-certificates/ 

    • Marked as answer by MidSpeck Sunday, March 8, 2015 9:26 AM
    Sunday, March 8, 2015 9:26 AM

All replies

  • Do you have an autodiscover A record configured internally in DNS which points to IP of outlook.office365.com?.


    http://thamaraw.com

    Thursday, February 5, 2015 2:17 AM
  • Ah, very good question.  Yes, I do have that set, but I have it pointing to autodiscover.outlook.com instead as per Office 365 instructions.  Is this okay?  Below are relevant DNS entries.

    It should be noted that I tried adding the _autodiscover._tcp SRV record just recently trying to solve this issue.  It didn't seem to hurt or help.

    IP addresses
    1.1.1.28 is the Web Application Proxy (Reverse Proxy)
    1.1.1.32 goes to the Web Conferencing Edge service (Lync Edge)
    1.1.1.33 goes to the A/V Edge Service (Lync Edge)
    1.1.1.34 goes to the Access Edge service (Lync Edge)
    
    A records
    lync		1.1.1.28
    owa		1.1.1.28
    sso		1.1.1.28
    webconf	1.1.1.32
    av		1.1.1.33
    sip		1.1.1.34
    
    CNAME records
    autodiscover	autodiscover.outlook.com
    lyncdiscover	lync.domain.com
    lyncweb		lync.domain.com
    msoid		clientconfig.microsoftonline-p.net
    
    SRV records
    _autodiscover._tcp	80	autodiscover.outlook.com
    _sip._tls			443	sip.domain.com
    _sipfederationtls._tcp	5061	sip.domain.com
    _xmpp-server._tcp	5269	sip.domain.com


    • Edited by MidSpeck Thursday, February 5, 2015 3:14 AM Clarifying
    Thursday, February 5, 2015 3:08 AM
  • configure an an A record instead of CNAME that resolves to the IP of the autodiscover.outlook.com. and have a go at it. and remove the SRV record.


    http://thamaraw.com


    Thursday, February 5, 2015 3:32 AM
  • Alright, I removed that SRV record.  And I set up an autodiscover A record to point to some of the autodiscover.outlook.com IP addresses (I just picked 4 of the hundreds available).  After clearing DNS caches and making sure everything was resolving with the new records, I tried again.

    Still no luck.  I still get "Connection to Microsoft Exchange is unavailable."

    Do you have Lync Phones connecting to Exchange Online successfully then?

    PS: I checked out your website.  It has some nice informative posts there.
    • Edited by MidSpeck Thursday, February 5, 2015 5:07 AM
    Thursday, February 5, 2015 5:07 AM
  • Thank for checking up my blog :). Below is a post that talks about a similar situation and describe the process to enable logging on the device. I'd recon it'll be useful to look at the log file to see where it's failing because, the functionality should work with O365

    http://www.xlync.com/my-blog/Article/47/lync-phone-edition-with-office-365-calendar-not-functioning-solved


    http://thamaraw.com

    • Proposed as answer by Eric_YangK Friday, February 6, 2015 2:45 AM
    Thursday, February 5, 2015 6:47 AM
  • Thanks for the link.  It seemed very pertinent.  Unfortunately we seem to have different problems, as my mail field is populated.

    However, I did take and try to dissect some of those crazy log files.  When I try to view the calendar and sign in via tethered USB, it goes through the auto-discover process from my domain, eventually to autodiscover-s.outlook.com, and then to another Microsoft website which redirects the phone back to my SSO (AD FS) server.

    I can't tell if it works or fails at this point.  The logs don't really make it clear one way or the other for me.  (Then again, they aren't very clear to begin with.)  I wonder if there are certificate requirements that the AD FS server needs to follow specifically for Lync Phone Edition.  While I have publicly issued certificates for AD FS, Lync Phone Edition might not trust the CAs like a regular Windows machine would.

    That's going to be my next round of testing unless anyone has a better idea.

    Saturday, February 7, 2015 10:44 AM
  • As a quick update:

    I still don't have the Exchange integration working with Office 365 on these Lync Phone Edition devices.  However, when I enabled my ADFS server to support non-SNI clients (like these phones) the log files seem to indicate it makes it a little bit further (I get new error messages.)

    As I am using ADFS 3.0, I followed the directions at https://newsignature.com/articles/federation-adfs-3-0-sni-support

    The search continues for whatever is causing the issue.  Can someone confirm that they have a Lync Phone Edition device working with Lync on-premises and Exchange online (with absolutely no Exchange servers on-premises).

    Tuesday, February 10, 2015 11:23 AM
  • I am reporting back with my solution.  I can now confirm that one can have Lync servers on-premises with Exchange Online using Office 365 and the Lync Phone Edition devices will work.  Contact search, calendar (although it only shows the day's Lync meetings), and visual voice mail all work.

    Summary of fix: AD FS certificates have to be issued by CAs that Lync Phone Edition trusts.

    The problem was when the Lync Phone Edition came back and tried to log in through AD FS.  Since we had single sign-on with Office 365 set up before we even ventured down the Lync path, the certificates for AD FS weren't issued by a CA that Lync Phone Edition trusted.  Getting new certificates solved the issue.  (They were issued by the same CA that did the "external web" certificate on the Lync Front End in case that matters.)

    I tried hard to get the phones to trust the original certificate first, putting it in Active Directory using the certutil -dsPublish method, putting the original CA on the Lync Web Services trusted list using Set-CsWebServiceConfiguration.  But nothing seemed to work until I finally just gave up and got a new certificate issued.  I am now running without any certificates listed in Active Directory nor any explicitly listed in Lync's Get-CsWebServiceConfiguration and it works great.

    The Technet articles are woefully out of date when it comes to the trusted CA list, but here's a link to the list of trusted CAs (with the updated firmware): http://blog.schertz.name/2014/10/lync-phone-edition-and-public-certificates/ 

    • Marked as answer by MidSpeck Sunday, March 8, 2015 9:26 AM
    Sunday, March 8, 2015 9:26 AM
  • Here's the fix:-

    https://newsignature.com/articles/federation-adfs-3-0-sni-support

    Its to do with Lync Phone Edition not supporting SNI which ADFS 3.0 (Windows 2012 R2 onwards) utilises.

    Andy

    • Edited by Tefty Wednesday, March 9, 2016 2:10 PM Fixed
    • Proposed as answer by Tefty Wednesday, March 9, 2016 2:19 PM
    • Unproposed as answer by MidSpeck Sunday, October 30, 2016 7:02 PM
    Wednesday, March 9, 2016 10:59 AM
  • Thenk you very much tefty. it worked for me
    Tuesday, January 24, 2017 10:26 AM