Haiku #188
Test certificate:
Do not try this at home. Try
Something else instead.
The author of today's haiku has always had an affinity for product disclaimers, those little warning labels that tell you why you should never, ever use whatever it is you just bought. Car makers – and car company commercials – are notorious for their product disclaimers, and often for good reason: a car commercial might show someone racing a car over a drawbridge that's beginning to open, or maybe spinning out over a set of train tracks just before the train whizzes by. Admittedly, the author of today's haiku isn't sure how many people watch a commercial and think, "Wow, I want to take my truck to the Mojave desert and have it tow a trailer up a steep, winding path and through a tunnel of fire!" But better safe than sorry, right?
Last night, however, the author of today's haiku saw what had to be the ultimate product disclaimer. What he saw was a car commercial and, to be honest, a pretty boring car commercial at that: it just showed the car driving along the road. However, as the car puttered along the following disclaimer appeared at the bottom of the screen:
Professional driver on closed course. Do not attempt.
Now, again, there was no drawbridge and no tunnel of fire, not even a rushing train to deal with: this was just a car driving along the road. Which, of course, can only mean one thing: although the car company obviously wants you to buy the car, they don't want you to ever actually drive the car. Oh, sure, if you're a trained professional and you have access to a closed course, well, maybe then you can drive the car. But otherwise, do not attempt to drive this car.
Ever.
Note. Which, considering the fact that the price of gas has gone up a good 20 cents or so per gallon in the past week, might actually be pretty good advice.
As it turns out, at least one of the Lync Server 2010 PowerShell cmdlets (Test-CsCertificateConfiguration) should also be accompanied by a product disclaimer, one that reads something like this:
Not designed for use by administrators. Do not attempt.
We should hasten to add that there's nothing wrong with Test-CsCertificateConfiguration: it works just fine, even in a tunnel of fire. (Well, we're not totally sure about the tunnel of fire. But we assume it works in a tunnel of fire.) However, there's really no reason for administrators to use Test-CsCertificateConfiguration; in fact, the cmdlet was never designed to be used by administrators in the first place. (It's actually intended for use by the Lync Server Certificate Wizard.) Instead, administrators should use the Get-CsCertificate cmdlet, a cmdlet we'll discuss in a little more detail in the next day or two.
You know, that's a good idea: maybe we should explain what the heck we're talking about. (We can do that, because we're trained professionals working on a closed course.) If you just look at the cmdlet name you might think that the Test-CsCertificateConfiguration cmdlet tests the certificate configuration on a computer. However, that's not really what it does. Instead of testing the certificate configuration, the cmdlet really just returns some information about your Lync Server certificates, and minimal information at that. For example:
Thumbprint Use
---------- ---
D00F5752C2363EBBCFE1B2F44247EE055109A6A2 Default
FC4AC602AA418B934CD5BB90A39CC366441AC913 WebServicesInternal
A72971C2355B8803D635BF9B353754F40AA1BBAB WebServicesExternal
Is that useful information? Well, it does tell you that you have three different certificates installed on this computer, and it does give you a Thumbprint for each of those certificates. But it doesn't give you any other information about those certificates, information like, say, who issued the certificate or when the certificate expires.
If you want that kind of information, then you need to use the Get-CsCertificate cmdlet. Get-CsCertificate will return information like this for each of your Lync Server certificates:
Issuer : CN=MyCa
NotAfter : 4/19/2013 8:55:09 AM
NotBefore : 4/19/2011 8:55:09 AM
SerialNumber : 6138B0000000091363
Subject : CN=atl-cs-001.litwareinc.com
AlternativeNames : {meet.litwareinc.com,dialin.litwareinc.com}
Thumbprint : D00F5752C2363EBBCFE1B2F44247EE055109A6A2
Use : Default
Interestingly enough, when you run Test-CsCertificateConfiguration one of the first things the cmdlet does is call the Get-CsCertificate cmdlet in order to retrieve certificate information. If you just use Get-CsCertificate in the first place you cut out the middleman.
Oh, and we should also mention this: Test-CsCertificateConfiguration can only be run on the local computer; the cmdlet is not available when you're using remote PowerShell. If you want to get certificate information from a remote computer you have no choice but to use Get-CsCertificate.
Note. But isn't it true that Test-CsCertificateConfiguration automatically generates a report (in HTML format) for you each time it runs, a report that will list any errors or misconfigurations that it finds? Yes, that is true. However, you can also ask Get-CsCertificate to generate a similar report for you simply by tacking on the Report parameter:
Get-CsCertificate –Report C:\Logs\Certificates.html
Like we always say, however: to each his own. If Test-CsCertificateConfiguration does everything you need it to do, well, then by all means use Test-CsCertificateConfiguration. All you have to do is run the following command:
Test-CsCertificateConfiguration
Or, if you want to specify a file path for the report that the cmdlet generates, include the Report parameter as well:
Test-CsCertificateConfiguration –Report C:\Logs\Certificates.html
That is – literally – everything that you can do with Test-CsCertificateConfiguration.
Well, everything that we trained professionals on a closed course can do. Everyone else should just use Get-CsCertificate instead.
See you tomorrow.