A major upgrade is now available to my popular OCS and Lync Sign-In Troubleshooting Tool. This is a small free tool to help troubleshoot client-side Communicator and Lync sign-in issues (see The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0 for more information on previous releases).
In addition to several bug fixes, Version 3 of the tool now supports remotely retrieving certificate information from the TLS port on the OCS or Lync server where the client will connect (based on the matching returned DNS records). This will be a major help when trying to debug sign-in issues.
You can read more about the tool and download it here: http://www.insideocs.com/tools/MOCLogin.htm
Here is a screenshot of the main screen:
Here is a screen shot of the certificate information that is retrieved remotely, including the Common Name (CN), Subject Name, Issuer, Certificate Authority, Expiry Date, Creation Date, and Subject Alternative Names (SANs):
Thanks to all the users who have reported bugs. Retrieving the installed version of Lync or Communicator now works on x64 along with a few other issues.
.
Twitter
LinkedIn
Hi Greg, most Lync & Communicator sign-in errors are related to DNS or Certificates, and this tool greatly helps resolve sign-in troubles in these two areas. Just enter your user SIP address in the box and hit the “Go” button. The tools will use DNS to show which server it will use to sign-in (the top match). You can then make sure the server is online and remotely retrieve the certificate.
If you are using Lync Online, the server certificate is likely configured correctly.
I have seen heard of a similar error with Lync Online. Read this thread – there is a suggested work around: http://community.office365.com/en-us/f/166/t/3771.aspx.
Curtis
What does this tool actually do? I’m getting 2 different sign-in errors on Lync and cant for the life of me understand why.
“There was a problem acquiring personal certificate required to sign in” is what I keep seeing. Any help would be hugely appreciated.
We’re using Lync hosted off-prem by the way, using Office 365.
Make senses, and that would be a good feature. It make not make it into the next version, but I’ve added to the list.
Thanks for the feedback.
Curtis
The reason that I asked, is because from where I am at, I cannot depend on my internal DNS to resolve SRV records, so when I do a NSLOOKUP, I always change to 4.2.2.2 or 8.8.8.8 etc for external lookups. I have been using DNS DATAview from nirsoft.net, which does allow me to choose what DNS server to check against. but if I could do this with your tool, I would be mega happy!
Currently it is limited to using the DNS server that your client is configured with – it was originally built as a client side troubleshooting tool. Likewise with the federation DNS record isn’t used by the clients to do an automatic login so it wasn’t included.
Timely feedback however, I was just about to release a major upgrade which includes a search for the Federation _tls record, the Lync Simple URL records, and some DNS records used by Lync devices. And some additional very useful certificate features.
Being able to specify a DNS server is a good idea – for a variety of troubleshooting scenarios. I’ll add it to the list.
Thanks,
Curtis
Is there any way to add the feature to choose which DNS server to do the SRV lookup with?
Also I don’t see it looking up the _sipfederationtls._tcp. record either.
Curtis –
Thanks for the updated tool. Good to see you’re still alive and well. Stay in touch!
Mark
Thanks for the feedback – I’ll check into the case sensitivity.
I started to add the registry version retrieval – while the code is in there i’ll retrieve several other settings as well.
Curtis
One issue I’ve noticed is that the field for the SIP domain is apparently case sensitive, and it shouldn’t be. I can enter my SIP domain in upper case, and when testing the port availability on the _sipinternaltls._tcp.DOMAIN.com record, it will successfully connect, but then says “Warning: the supplied SIP Domain DOMAIN.com does not match the domain of the PREFERRED DNS record (domain.com). If you are using TLS the OCS/Lync server certificate will likely require sip.DOMAIN.com listed in teh Subject Alternative Name (SAN) field.”
However, if I enter the domain name in lower case, I don’t get that prompt.
As for not detecting the installed client, peek at “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{11849FBC-C416-4742-8279-17C3A2C85F72}\InstallLocation” for the path to the client.
Fantastic little tool! The cert functionality helped me (needed another name on the SAN)
I remember when I was coding the client version retrieval, I thought it was a safe assumption that Lync would be installed in the default “Program Files” directory. I will fix that soon.
Thanks for the heads-up.
a must-have tool! thanks so much for the update. Just a minor issue, it won’t pick Lync client on my desktop (”No version .. installed”). Perhaps it’s because I installed Lync on a non-default path?
[...] http://blog.insideocs.com/2011/07/19/communicator-lync-lync-sign-in-troubleshooting-tool-version-3/ [...]