Skip to main content

When a Lync Certificate Error is actually a .NET problem.

By February 1, 2017September 16th, 2020Blog
cannot sign in to Lync error message

JR1

We couldn’t join you to the meeting because the security certificate isn’t trusted.”

“‘Runtime Error in ‘/meet’ Application.”

Recently we encountered a Lync meeting problem I have not seen before. Internal and external participants reported wide array of ‘Certificate not trusted’ errors when attempting to join the meeting. Certificate errors are pretty commonplace with Lync and usually fall within the ‘forgot to renew’ ‘did not add intermediary’ easy-to-troubleshoot categories.

With this particular customer the inability to join and host meeting were the only problems – everyone could sign in, call, IM and share desktops.

The error seemed inaccurate from the get go – we just renewed internal and public certs for this customer 2 weeks back. Since meeting functionality was not used very often in this scenario I suspected DNS issues and run my favorite DNS testing tool to verify all the records point into the right place.

(Link included below, disclaimer: do not run PS1 code you have not verified yourself)

https://www.myskypelab.com/2014/03/lync-edge-testing-suite-part-2-lync-dns.html

The powershell script above is just a neat gui-based tool that prompts you for the domain and records you want to test, usually my first go-to place to get acquainted with what’s where in a particular deployment.

DNS was fine, having obtained a test meet URL from customer I moved on to see how it looks like in the browser: ‘Runtime Error in ‘/meet’ Application.

JR2

We have the culprit – clearly an issue with the web server, nothing wrong with certificates.

A quick look into IIS on Front End and everything looked up and running. Having kicked the can around for a solution that wouldn’t involve any downtime I dug a little deeper with a close eye on how .NET works with IIS. Long story short, I found out a quick way to address this was to force .NET to recompile.

Below is a temp directory that upon removal causes the .NET app to recompile.

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\meet

After deleting the temp files meet website started right up and everyone was able to join the meeting. No restart, no re-sign in and no services touched, no interruption of services of any kind.

Ultimately this can be easily done by just restarting the Front End, except good luck getting that approved in the middle of the day!

I hope you found this article helpful. This has been a hard piece of information to come by – if this tip forked for you please let me know.

@JACOBR_PEI

Jacob R, PEI

Leave a Reply