Lync Server Component Version using PowerShell (Windows Registry)

One of the first posts was about how to get Lync Server Component versions:

Lync Server Component Version with PowerShell (WMI Classes)

In that post, we used Get-WmiObject to query the server. Nevertheless, using that method can be slow, and for sometime it was the only one we knew.

In the post Hey, Scripting Guy! Blog – Use PowerShell to Find Installed Software, Ed Wilson describes a method to query Windows Registry in order to get all installed software. We could adapt it to get Lync Server related information only:

Get-ItemProperty HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall* |  ?{$_.DisplayName -like “*Lync Server*”} | Sort-Object DisplayName | Select DisplayName, DisplayVersion, InstallDate | Format-Table -AutoSize

LyncCompVer2_01a

We run both to see the difference in execution time:

Using Get-WmiObject

LyncCompVer2_02

Using Get-ItemProperty

LyncCompVer2_01

We can see how much quicker it is using the Get-ItemProperty. In this Front End, it only took 0,42 seconds to get the results, while on the same server the Get-WmiObject method took 32,39 seconds. Please keep in mind that these results may vary in your environment. Another advantage is that we get the InstallDate, which means we know when the last update was installed. In this example, the date format is YYYYMMDD.

Lync Server 2013: Event 31007 LS Certificate Manager

It is really important to regularly check the Event Viewer for Warnings/Errors (or to use System Center Operation Manager to do it for you). In one of these checks, the following event was found:

EdgeCertCRL01

Log Name: Lync Server
Source: LS Certificate Manager
Date: 06/10/2014 02:29:30
Event ID: 31007
Task Category: (1016)
Level: Warning
Keywords: Classic
User: N/A
Computer: ******
Description:
The CRL could not be downloaded for certificate:

Subject: GB, Berkshire, Reading, ******, Issuer: com, *****, Internal-CA, Extended Error Code: 0x80092013
Cause: This could happen if the CA is unreachable or the certificate did not specify the CDP location. It could also happen if the CA was overloaded.
Resolution:

You should contact the issuer and download/install the CRL.

This event mentions that Lync Server Edge couldn’t reach CRL Distribution Points (CDP) and download the latest CRL. We didn’t notice any Lync feature affected by it, but since Lync Server relies on certificates we decided to investigate it a little further.

CRL stands for Certificate Revocation List and contains all the certificates serial numbers which were revoked by this CA. This allows the certificate to be revoked within its valid period – for example, when we need to change the Subject Alternative Names (SAN), the old certificate serial number will be included in this list.

We could download the CRL from the CA and install it on the Lync Server Edge. In order to download the CRL, access http://CA-FQDN/certsrv, where there should be an option to download the current CRL:

 EdgeCertCRL03

EdgeCertCRL04

This approach isn’t so practical, since the CRL are only valid for a short period:

 EdgeCertCRL05

Checking the certificate CRL Distribution Points, we noticed that it only had LDAP entries:

EdgeCertCRL06

This means that our CA only had LDAP enabled for CDP. This is the default configuration when we install Active Directory Certificate Services.

The best option is to add the HTTP as CRL Distribution Point, which will allow non-domain joined computers to download the CRL. To add this, we need to access our CA and open the Certification management console.

Now, select the CA, then right click and select Properties:

EdgeCertCRL07

In Properties, go to Extensions tab. Enable the following option:

Include in CRLs. Clients use this to find Delta CRL locations.
Include in the CDP extension of issued certificates.

EdgeCertCRL08

After changing and restarting the CA services, we need to update the edge certificate. Only new certificates will contain the HTTP as CDP.

Coming back to the Edge Server, we can use the Lync Deployment Wizard or PowerShell:

Request-CSCertificate -New -Type Internal -Output “C:CertsEdgeInternal.req” -Country GB -State “Berkshire” -City “Bracknell” -FriendlyName “Edge Internal with CRL” -KeySize 2048 -PrivateKeyExportable $True -Organization “UC Lobby” -OU “IT” -Verbose

EdgeCertCRL09

Now, if we return to the CA, we can access http://CA-FQDN/certsrv or use the Command Prompt:

Certreq.exe –submit –attrib “CertificateTemplate:webserver” C:CertsEdgeInternal.req EdgeInternal.cer

We can also check if this new certificate includes HTTP CRL URL:

EdgeCertCRL12

Copy the EdgeInternal.cer file to the Edge and import and assign the certificate using PowerShell:

Import-CsCertificate -Path “C:CertsEdgeInternal.cer” -PrivateKeyExportable $True

Get-ChildItem -Path cert:LocalMachineMy | select Subject, FriendlyName, Thumbprint | Format-List

EdgeCertCRL10

Set-CsCertificate -Type Internal -Thumbprint <Certificate Thumbprint>

EdgeCertCRL11

After assigning the new certificate, we won’t get Event 31007 in the Event Viewer. Please take into consideration that the Certificate Manager only checks the certificates twice per day.