Joining meetings takes time / TLS negotiation started RRS feed

  • Question

  • Hi guys,

    Last week we deplyed Skype for Business alongside the current Lync Server 2013 environment. Federation route is still on the old edge pool.

    All DNS records are still poining towards the old environment and old reverse proxy.

    We have moved 5 pre-pilots (with the -MoveConferenceData flag) to the new Skype for Business pool and we are experinencing som issues:

    To get into a meeting that was previously created in the Lync environment it can take around 30-60 seconds. When we try to join the meeting a second or third time it opens up in 1 sek...new meetings takes less than 30 sek but not instant.

    External users cannot join old meetings on the old meeting url. however if a new meeting is scheduled and an external users points its hostfile towards the new reverse proxy it can join in 30-60 seconds...

    Our new skype edge pool does not have the same records as the old one, can this cause issues if the federation route is still on the lync edge pool?

    If runnings Clslogger and look into the snooper afterwads we can see tons of rows saying TLS negotiation started...it can be 50 rows at a time...

    My questions:

    1) Will the meet request to the old environment (both internal and external) redirect to the new server? Is this starting some  kind of loop and that is what were seeing in the logs?

    2) Shall one use the -MoveConferenceData when migrating users or should one not use that and move everything at a later point or not at all?

    3) How is it usually done? Moving all records to the new environment and that will redirect back to the legacy pool and the users?

    4) what would be our best approach to solve this? can it be done or shall we aim for pointing all records to the new environment,  change the federation route to the new edge pool and migrate all users?

    Saturday, November 4, 2017 11:15 PM

All replies

  • Hi zid,

    Based on your description, we suggest you use Meeting Update Tool for Skype for Business to update the meeting information, then test again. For details, please refer to

    According to my research, when you moving user account from Lync server 2013 to SFB server 2015, the meeting content won’t be migrated, in my opinion, after you migrated the user to SFB server, you can move conference data to the new server, please refer to the following document

    Migration considerations for meetings in Lync Server 2013

    Hope this reply is helpful to you.


    Alice Wang

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Alice-Wang Tuesday, November 7, 2017 7:55 AM
    Monday, November 6, 2017 9:45 AM
  • Hi zid,

    Are there any update about this issue?


    Alice Wang

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 9, 2017 9:11 AM
  • Hi Alice,

    Actually it seems that pilots on the new skype pool are experiencing 30 sec delay while joing a meeting first time in the morning. After joining that meeting there are no issues, one can join meetings very fast the upcoming hours. Then around 1-2PM the issue appears again. it takes around 30 sec to join the first meeting and then its fast again.

    So its seems there is a session open for a few hours after the user joins a meeting and then its open for a few hours.

    We've tried to bypass the HLB on the Skype environment but the same issue appeared. The current Lync 2013 users are not experiencing this.

    So meet.company.com still points towards the Lync 2013 HLB. Only pilots in the new Skype pool are experiencing this 30 sec delay on the first meeting, the next couple of hours it works great! Seems to be a redirect or proxy issue from Lync 2013 to Skype?

    Any suggestions?

    Thursday, November 9, 2017 10:07 AM
  • Hi zid,

    Thanks for your reply.

    Based on my understanding, now your topology seems like this:


    LyncRP – LyncEdge – LyncFE


    And your DNS records (meet.domain.com, lyncdiscover.domain.com, sip.domain.com …) are all pointing to LyncRP and LyncEdge. If anything I misunderstood, feel free to let us know. And I think the federation route is not the point as it would only affect the federation organization traffic.

    Based on our research, when a conference is generated or a scheduled conference is sent through email, the meeting join URL is shared. When an external user clicks the meeting URL or types it into a web browser, it connects to the reverse proxy over HTTPS. The reverse proxy then proxies the web request to the configured Director or Front End pool.

    Then external client will do a “join a meeting” process like this:

    In your scenario, it seems some delay in the join meeting process, could you please provide some error logs about the server and client side for future analyze?

    As your DNS records are all points to the Lync pool, we suggest that you could try to use a host file to point all DNS records to the new SFB pool and test again. If it works, it may be related to the DNS missing.

    Thanks for your understanding!


    Alice Wang

    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, November 14, 2017 8:26 AM