Haiku #194

Turn out the lights, the

Party's over: today's our

Last haiku (for now).


Today is a very auspicious, and somewhat sad, occasion: it marks, for the moment anyway, the end of the Lync Server PowerShell Haiku of the Day. (Trust us, we thought this day would never come, either.) Believe it or not, by the time today's haiku is finished we'll have worked our way through all the Lync Server PowerShell nouns. In turn, that means we can't have any more haikus, at least not until we have some more Lync Server PowerShell nouns to work with.


Note. Will there be more Lync Server PowerShell nouns in the near future? Well, we're not allowed to talk about future Lync Server plans, simply because no one ever fills us in on future Lync Server plans. But let's just say that we haven't thrown away our haiku-writing hat, not just yet.


So what does this all mean for the Lync Server PowerShell blog? Well, to be honest, we're not totally sure about that. We'll continue to post articles to the blog, and we'll continue to keep you as up-to-date as possible on Lync Server PowerShell. But what it actually means to "keep you as up-to-date as possible" is still to be determined. Why? Well, for one thing, now that we're done writing haikus, our managers think maybe it might be time for us to do some real work.


Note. But don't worry: they'll change their mind once they see what happens when we do try to do some real work.


But hey, we'll worry about tomorrow come tomorrow. As for today, we thought we'd spend a large portion of our time reviewing some of the great moments and happy memories from the Lync Server PowerShell Haiku of the Day:




OK, well, apparently there aren't quite as many great moments and happy memories as we thought. (But hey, we'll always have the story of Planet Nibiru, right?) With that in mind, there's only one thing left to do: talk about the CsCertificate cmdlets (Get-CsCertificate, Import-CsCertificate, Remove-CsCertificate, Request-CsCertificate, and Set-CsCertificate).


Before we begin we should probably note that we aren't exactly experts when it comes to certificates, let alone Lync Server certificates. (What's that? But we were experts on all the other topics we covered in our previous haikus? Well, maybe not experts, mind you ….) We'll try to give you an overview of what the CsCertificate cmdlets do, but if you're thinking, "I should ask these guys if it's a good idea to use wildcards in my SANs," well, then you should probably think a little harder.


But hey, give us a break: after all, we are haiku writers. Would you ask Masaoka Shiki if it's a good idea to use wildcards in your SANs?


Although even he'd probably know more about that than we would.


Note. Masaoka Shiki was a famous Japanese poet and is acknowledged as one of the 4 great haiku masters. (Shouldn't that be 5 great haiku masters? Well, modesty prevents us from saying anything about that.) Here's a sample haiku from Masaoka Shiki:


getting a shave!

on a day when Ueno's bell

is blurred by haze...


So yes, obviously he does know more about certificates than we do. But, then again, who doesn't?


We thought we'd kick things off by talking a little bit about the Request-CsCertificate cmdlet. Request-CsCertificate is actually a remarkably clever cmdlet: you simply tell Request-CsCertificate that you need a certificate, and it does a lot of the work involved in figuring out what kind of certificate you need and how to configure that certificate. For example, suppose you request a WebServicesExternal certificate. If you do that, request-CsCertificate will read your topology and automatically add the Simple URLs for meet and dialin (as well as your reverse proxy URL) to the Subject Alternative Name field. What's that? You say there's also a third Simple URL: admin? Yes, there is. But typically you don't want to expose your admin URL to the outside world. And Request-CsCertificate is smart enough to know that.


Like we implied earlier, certificates can be a … challenge … to work with. Because of that, we won't run through all the different parameters available when running Request-CsCertificate; we could start a whole new haiku series just on those. (But don't worry: we won't start a whole new haiku series on Request-CsCertificate parameters.) Instead, we'll just give you an idea of what a command asking for a new certificate might look like:


Request-CsCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -ComputerFqdn "atl-cs-001.litwareinc.com" -CA "atl-ca-001.litwareinc.com\myca" -FriendlyName "Enterprise Edition Pool Certificate" -Template jcila -PrivateKeyExportable $True -DomainName "pool1.litwareinc.com,pool1int.litwareinc.com,pool1ext.litwareinc.com"


Like we said, this can be a bit of a challenge.


Note. On the bright side, Lync Server's Certificate Wizard actually uses Request-CsCertificate when it comes time to ask for a new certificate. Because of that, and because no one wants to do that much typing, you might consider just using the Wizard to request new certificates. The Wizard is a bit more user-friendly, but you'll still get to take advantage of all the cleverness built into Request-CsCertificate.


When you use Request-CsCertificate (or the Certificate Wizard) to make an online request for a new certificate, that new certificate will be retrieved and will automatically be available to use with Lync Server. But what if you make an offline request, or what if you have certificates that weren't obtained using Request-CsCertificate? That's fine; if you have certificates that were acquired without using Request-CsCertificate (or the Certificate Wizard) you can still use those certificates with Lync Server. All you have to do is use the Import-CsCertificate wizard to, for all intents and purposes, let Lync Server know that the certificate exists:


Import-CsCertificate -Path "C:\Certificates\WebServer.cer" -PrivateKeyExportable $True


And after the certificate has been imported, you can then use Set-CsCertificate to assign that certificate to a Lync Server server or server role:


Set-CsCertificate -Type WebServicesExternal -Thumbprint "B142918E463981A76503828BB1278391B716280987B"


What did we tell you? Certificates can be a challenge, but the CsCertificate cmdlets are anything but a challenge.


That leaves just two cmdlets to talk about: Remove-CsCertificate and Get-CsCertificate. As you might expect, Remove-CsCertificate removes a Lync Server certificate. Except, to be a bit more accurate, it doesn't really remove the certificate: the certificate will remain on your computer and can be used for other purposes. Instead, Remove-CsCertificate simply marks the certificate as no longer being available for use by Lync Server, removes any certificate bindings, and revokes access permissions to the certificate. The certificate will still exist, but Lync server won’t know that: if you run the Get-CsCertificate cmdlet that certificate will not show up.


Speaking of which, now might be as good a time as any to mention that Get-CsCertificate returns information about your Lync Server certificates. (And only your Lync Server certificates: if a certificate wasn't obtained using Lync Server or wasn't imported using Lync Server, well, then Get-CsCertificate won't return information about that certificate.) You say you want to see information about all your Lync Server certificates? Then just run this command:




Want information about just the Default certificate? Then use this command:


Get-CsCertificate –Type Default


How about all the certificates that don't include sip.fabrikam.com in the AlternativeNames property? Sure; why not:


Get-CsCertificate  | Where-Object {$_.AlternativeNames -notcontains "sip.fabrikam.com"}


Etc., etc.


The only drawback to the Get-CsCertificate cmdlet is that it only returns certificates from the local computer. You say you need certificate information from a remote computer? Then you're either going to have to log on to that remote computer or connect to it using remote PowerShell in order to get that data.


But, then again, nobody's perfect right? With the possible exception of Masaoka Shiki, of course.


Note. After all, not only did Masaoka Shiki save the ancient art of haiku writing, but he's also a member of the Japanese Baseball Hall of Fame. For comparison purposes, Wade Boggs is in the Major League Baseball Hall of Fame, but did he help save the ancient art of haiku writing?


Well, OK, maybe Wade Boggs did. But we're pretty sure that Walter "Big Train" Johnson didn't.


That's pretty much all we have to say about the CsCertificate cmdlets. Typically we sign off each day by saying "See you tomorrow," not because that was a clever way to sign off but simply because we could never actually come up with a clever way to sign off. But now that the daily haiku series is done for a while, we can't just end things by saying "See you tomorrow." So, we'll just end things.










Skip to main content