LS Data MCU error on Lync 201x & SfB 2015 after May 2017 OS patching

Update 23/05/2017 23:12 - Official confirmation should appear under https://support.microsoft.com/en-gb/help/4023993 within 24 hours. Product Group have Development Resource assigned so looks like a CU will be coming to fix this.

Seeing multiple customers on Lync 2010, Lync 2013 and Skype for Business server 2015 front ends:

Front End event log every minute, Event ID 41026 followed by 41025:




"No connectivity with any of Web Conferencing Edge Server, External Skype for Business clients cannot use Web Conferencing modality

On the Edge server seeing the following:


"Web Conferencing Server connection failed to establish

Over the past 3 minutes Skype for Business Server has experienced incoming TLS connection failures 1 times(s). The error code of the last failure is 0x80072746 and the last connection was from the host ""."

After trying disabling IP 6 on FE and Edge:

and “On FE you can change IIS Web sites bindings to IPv4 IP address instead of all unassigned.”


The fix so far was to uninstall the May Security and Quality rollup for the .Net Framework 4.5.2, reading the release notes this hardens TLS communications for EKU so seems to fit with the error messages being shown

Server 2012: https://support.microsoft.com/en-gb/help/4014513

Server 2012 r2: https://support.microsoft.com/en-gb/help/4014597

Logged with Microsoft as ticket 117051115723411

Update 21:54 (changed title as well):

Confirmed by Microsoft as known issue and public KB is being prepared:

"This update adds an additional check on Enhanced Key Usage (EKU), since all Lync/ SfB Server usually use the Web Server template they will only have the Server Authentication in the EKU."

Issue has been reproduced on Lync 2010, Lync 2013 and Skype for Business 2015 on all supported server versions (2008r2, 2012, 2012r2).

Current Workarounds:

1 - Request new Edge Internal certificate with the Client and Server Authentication.

OR

2 - On the Front Ends disable the check for the Web Conferencing Service. Please note that these registry keys are for the default install locations.

Lync Server 2010:

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\System.Net.ServicePointManager.RequireCertificateEKUs /v "C:\Program Files\Microsoft Lync Server 2010\Web Conferencing\DataMCUSvc.exe" /t REG_DWORD /d 0 /f

Note: Lync Server 2010 still uses the .NET 3.5 this is why we have the v2.0.50727.

Lync Server 2013:

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\System.Net.ServicePointManager.RequireCertificateEKUs /v "C:\Program Files\Microsoft Lync Server 2013\Web Conferencing\DataMCUSvc.exe" /t REG_DWORD /d 0 /f

Skype for Business Server 2015:

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\System.Net.ServicePointManager.RequireCertificateEKUs /v "C:\Program Files\Skype for Business Server 2015\Web Conferencing\DataMCUSvc.exe" /t REG_DWORD /d 0 /f

After adding the registry key simply restart the Web Conferencing service

Thanks to David Paulino (Twitter) at Microsoft for the update.

Update 22nd May 2017 11:07
Seeing different items broken in different environments from the following list: Q and A, Screen Share, Whiteboard, PowerPoint sharing via OWAS/WAK/OOS (Thanks Py7h0n and others for reporting).

8 comments:

  1. Thank you for the valuable update.
    I confirm the issue in at least a customer and reproducing on our labs.

    ReplyDelete
  2. Thanks. We had the same issue, and figured out it was the update for .Net framework. We are running 4.6.2 (that has been supportet sins last Skype update). I has just testet out the newes Skype update (from yesterday) - still truble with the .Net framework may update.

    ReplyDelete
    Replies
    1. Microsoft SfB Product team are investigating and a public KB will be available at some stage. At the moment not confirmation if the fix will be to deploy new certificates or if it will be addressed in a future Cumulative Update.

      Delete
  3. Whiteboarding and screen sharing. Once certificates were regenerated both worked as expected again.

    ReplyDelete
  4. Hmm, eerily familiar symptoms and workaround steps... Oh, right, something very similar happened last June, another hardened TLS setting (SchSendAuxRecord):

    https://support.microsoft.com/en-us/help/3165438/some-clients-can-t-connect-to-conferencing-modalities-after-you-install-security-bulletin-ms16-065

    We were fortunate this time as we use public CAs for internal names also, and both key usage is present in all our certificates.

    ReplyDelete
    Replies
    1. Yep - quite similar! That one had a client side fix though. This is between the servers so going to be either a CU fix or a change in what certificates are recommended.

      Delete
  5. Tobie, would you please do export of a new key so I can see the format. I would like to know hoe to import this key

    ReplyDelete