Lync Server: Event 41029 LS Data MCU – No connectivity with the Lync Web App

In a recent support case we were working on an issue where sometimes the users couldn’t use the Lync Web App.

The troubleshooting started in the Event Viewer > Lync Server, we notice that we had a few errors:

Log Name: Lync Server
Source: LS Data MCU
Date: 01/03/2017 15:00:43
Event ID: 41029
Task Category: (1018)
Level: Error
Keywords: Classic
User: N/A
Computer: lync2013fe01.gears.lab
No connectivity with the Lync Web App. Affected Web browser clients cannot use Web Conferencing modality.

Server Machine FQDN: lync2013fe01.gears.lab, Port:8061
Server Type: External-WebApp-Edge [HTTP side error:Unable to connect to the remote server]
If the problem persists this event will be logged again after 20 minutes
Cause: Service may be unavailable or Network connectivity may have been compromised.

Another error was mentioning an issue HTTP connectivity:

Log Name: Lync Server
Source: LS User Services
Date: 01/03/2017 15:04:57
Event ID: 30988
Task Category: (1006)
Level: Error
Keywords: Classic
User: N/A
Computer: lync2013fe01.gears.lab
Sending HTTP request failed. Server functionality will be affected if messages are failing consistently.

Sending the message to https://lync2013fe01.gears.lab:444/LiveServer/Replication failed. IP Address is Error code is 2EFD. Content-Type is application/replication+xml. Http Error Code is 0.

Cause: Network connectivity issues or an incorrectly configured certificate on the destination server. Check the eventlog description for more information.
Check the destination server to see that it is listening on the same URI and it has certificate configured for MTLS. Other reasons might be network connectivity issues between the two servers.

Both events showed that the server could not establish a connection himself.

Then we check if the server was listening on that port:

netstat -anp TCP
netstat – Info

Get-NetTCPConnection -State Listen -LocalPort 80,8080,443,444,4443,8061 | ft -AutoSize

The HTTP/HTTPS bindings were only on and this is the loopback address.

Then we run the same on a working server in the same pool:

Note: For Get-NetTCPConnection :: is any available IPV4/IPV6 address.

So, in a working server the binding was on any available IP address, while the non-working was only on the loopback address.

Initially, we thought the issue was in IIS/certificate bindings, but both were properly configured:

Get-WebBinding | ft -AutoSize

netsh http show sslcert

After checking other parameters available in netsh we found that the non-working had the loopback address configured in the HTTP IP Listen List:

netsh http show iplisten

While the working server we didn’t had any IP address configured:

This was causing the wrong binding, to fix it we only had to remove the loopback address from the list:

netsh http delete iplisten

After this change the server started to listen in the correct IP address/ports:

netstat -anp TCP

We also confirmed in the Event Viewer that the Lync Web App was starting:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.