If you were hoping for an in depth article on Skype for Business Health Agent Probes, keep on looking, you won’t find it here. I did wrestle with one such probe failure, Event 56001 LS Health Agent.
One or more Health Agent Probes encountered an unexpected error. The component(s)/Service(s) intended to be monitored by the Probe may be functioning correctly.
Probes: System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority ‘lync01.company.com’. blah blah blah.
SSL/TLS secure channel, naturally start checking the certs; nope, they’re all good.
Next, off to check IIS, maybe the certs are mixed up or something… Opened up the Bindings for the Skype for Business External website to view the assigned cert, the port are wrong. For some reason the External web site was assigned 80 and 443 instead of 8080 and 4443. Internal was set to 8080 and 4443 instead of 80 and 443. Very odd. Joys of troubleshooting other peoples installations, and I have no idea if this was manually done or a glitch in the system somewhere along the way.
After juggling the ports around, didn’t even have restart, poof, Agent Health Probes all happy again. Hopefully this shouldn’t be something that people encounter very often, but at least there are some clues to look at for drilling down as to why these “Health Probes” might be failing.
Update: Published to fast. Turned out someone messed with the Internal and External ports in the Topology. Unfortunately just setting them back to the correct configuration isn’t enough, probably buried deep in the settings are more references to the Ports that do not update automatically when you republish. Final resolution was to uninstall the Web Components and re-run the Deployment wizard, re-run the Server Component installation and the Certificate wizard.
Safe to say though, the Health Agent Probes are programed with the default Web site ports, changing them will likely result in probe failures.