It’s possible my new Edge is jinxed. First I couldn’t RDP to it, and now I’ve installed SfB, CLS Logging isn’t working.
It might have something to do with the fact that Windows Updates put .NET 4.7 on it before I’d even had a chance to run Pat’s script to block it.
The quick way to check for it in Server 2016 is to look for the KB:
PS C:\Users\Administrator> get-hotfix Kb3186568
Anyway, despite having excised that, CLS logging wasn’t working. The service would start and appear to run fine, with no errors in the event log, but it wasn’t listening on the usual ports, and of course that was resulting in errors when I tried to start logging from the Front-End:
PS C:\Users\greig> Show-CsClsLogging -Computers sfb2015edge2.blah.local WARNING: Failed on 1 agents
Agent - sfb2015edge2.blah.local, Reason - Error code - 20000, Message - Unknown error - Error calling agent sfb2015edge2.blah.local; Could not connect to net.tcp://sfb2015edge2.blah.local:50002/. The connection attempt lasted for a time span of 00:00:20.9811488. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.19.89:50002. . Please refer CLS logs for details. PoolFqdn: sfb2015edge2.blah.local
MachineFqdn ResponseMessage AlwaysOn ScenarioName Remaining ProductVersion
Mins
----------- --------------- -------- ------------ --------- --------------
sfb2015edge2.blah.local Error code - 20000, Message - 0 6.0.9319.0
Unknown error - Error calling
agent
sfb2015edge2.blah.local;
Could not connect to net.tcp:/
/sfb2015edge2.blah.local:5
0002/. The connection attempt
lasted for a time span of
00:00:20.9811488. TCP error
code 10060: A connection
attempt failed because the
connected party did not
properly respond after a
period of time, or
established connection failed
because connected host has
failed to respond
192.168.19.89:50002. . Please
refer CLS logs for details. PS C:\Users\greig>
Not on CU5 yet
In the process of debugging this I checked the patch version and found it was only at ~CU4, which is similar to other people’s experiences of the “Connect to the internet to check for updates” process in the Install Wizard. I updated it to CU5 and rebooted, to no avail.
A Corrupted DLL?
I had a good shop around the ‘net. It wasn’t Trevor’s problem with another process using the ports. (Awesome post BTW Trevor!)
Lots of my searches kept coming back to an earlier CLS problem with Lync 2013 that was fixed in October 2014. The kb contained this gem:
“This issue occurs because the Microsoft.Rtc.ClsAgent.IISLog folder is missing from the .Net global assembly cache after you install September 2014 Cumulative Update 5.0.8308.815 for Lync Server 2013. Therefore, the Centralized Logging Service Agent Service does not listen on designated ports”.
I checked and found I had that folder, but I wasn’t being put off so easily, because the DLL file here has caused OTHER problems before.
Taking a long shot I copied the same file across from my earlier working Edge (running Server 2012 R2) & rebooted, and VOILA, we’re good!!
PS C:\Users\Administrator> netstat -ano | findstr 5000*
TCP 0.0.0.0:50001 0.0.0.0:0 LISTENING 4980
TCP 0.0.0.0:50002 0.0.0.0:0 LISTENING 4980
TCP 0.0.0.0:50003 0.0.0.0:0 LISTENING 4980
TCP [::]:50001 [::]:0 LISTENING 4980
TCP [::]:50002 [::]:0 LISTENING 4980
TCP [::]:50003 [::]:0 LISTENING 4980
UDP 0.0.0.0:500 *:* 1120
UDP 0.0.0.0:4500 *:* 1120
UDP [::]:500 *:* 1120
UDP [::]:4500 *:* 1120 PS C:\Users\Administrator>
And my Front-End is happy now too:
PS C:\Users\greig> Show-CsClsLogging -Computers sfb2015edge2.blah.localPoolFqdn: sfb2015edge2.blah.local MachineFqdn ResponseMessage AlwaysOn ScenarioName Remaining ProductVersion Mins ----------- --------------- -------- ------------ --------- -------------- sfb2015edge2.blah.local False 0 6.0.9319.0 PS C:\Users\greig>
Summary
Is this a Server 2016 thing? Is it because of .NET 4.7? Could it be because I installed SfB by following the Wizard and *not* manually installing CU5 first? Is it just me?
Time may reveal the answer to that, but for the time being, I hope this post might help someone else get their logging going.
Revision History
4th September 2017: this is the initial post.
– G.
Same issue, but replacing the DLL had no affect. No ports listening on ClsAgent.exe
The proposed answer worked: https://social.technet.microsoft.com/Forums/projectserver/en-US/d30a0476-4147-48eb-a066-b5a1f5fa12a7/skype-for-business-centralized-logging-service-agent-error-starting-background-thread-to-process?forum=lyncdeploy
1. Switched the Logon On User of the Service “Skype for Business Server Centralized Logging Service Agent” to Local System account
2. Started the Service once (I have seen in Process Monitor that an .msi was reinstalled and waited for some Minutes)
3. Switched back to Network Service and started the Service again