Eye of newt and toe
Of frog. Or just use CS
Yesterday afternoon, while waiting for a meeting to start, the author of today's haiku found himself browsing through an online copy of the Malleus Maleficarum (The Hammer of Witches). If you aren't familiar with the Malleus Maleficarum, it's a treatise written in 1486 that served as a manual for the witch trials that swept over Europe in the 15th and 16th century (and, just for good measure, was heavily relied upon by the folks responsible for the Spanish Inquisition).
Note. In case you're wondering, it's just a coincidence that the meeting the author of today's haiku was waiting on was his annual performance review.
At any rate, the Malleus Maleficarum makes for some interesting reading, even if it doesn't include any haikus or references to Lync Server PowerShell. (Go figure.) For example, how do you even know whether or not someone is a witch? Well, one way to determine that is to toss them in prison for a few weeks and then bring them to trial. If they don't cry during the trial, well, then they must be a witch, because witches (and other people possessed by the Devil) are unable to cry.
And so if the prisoner does cry then she's off the hook, right? Well, not exactly. After all, the Devil – regardless of what else you might think of him – is no dummy: he'll often instruct his minions to cry in an attempt to fool their jailers. Which simply means this: if you don't cry then you're probably a witch and if you do cry, well, then you're probably a witch. Damned if you do, and damned if you don't.
Like we said, just a coincidence that he was reading this right before his annual performance review.
Note. For the record, the author of today's haiku would like to state that he did not cry during his performance review. That only came later, after he actually saw his review score.
We mention all this simply because many people believe that witchcraft and black magic are required in order to manage trusted application computers in Microsoft Lync Server 2010. Granted, that might have been true in an early beta version of the product; we can't remember for sure. But witchcraft and black magic are definitely not required in order to manage trusted application computers in the released version of Lync Server 2010. Instead, all you need are the CsTrustedApplicationComputer cmdlets: Get-CsTrustedApplicationComputer, New-CsTrustedApplicationComputer, and Remove-CsTrustedApplicationComputer.
Those of you who are witches (or otherwise have magical powers) might have guessed that a trusted application computer is a computer that runs trusted applications. In turn, a trusted application is an application that isn't actually part of Microsoft Lync Server but, thanks to its trusted status, is allowed to run as if it is a built-in part of Lync Server. (For example, Outlook Web Access can be configured to run as a trusted application.)
Admittedly, the trusted application landscape (which includes everything from trusted application pools to trusted application endpoints) can get a little complicated. We'll try to keep things as simple as possible today by saying that trusted applications must run on trusted computers, and trusted computers must belong to a trusted application pool.
That's easy enough, right? Now, as it turns out, there are two different types of trusted application pools: there are pools that can contain multiple computers, and there are pools that can contain just one computer. If you want to house multiple computers in a single trusted application pool then, when you create that pool, all you need to do is use the computer's fully qualified domain name as the pool Identity (and specify the site where the pool will be located). For example:
New-CsTrustedApplicationPool -Identity atl-trust-00l.litwareinc.com -Site Redmond
Do that, and you'll have a pool that consists solely of the computer atl-trust-001.litwareinc.com. If you try to add an additional computer to that pool the command will fail with a somewhat-vague error message:
New-CsTrustedApplicationComputer : A pool consisting of Standard Edition servers can contain only one computer.
Alternatively, you can give your trusted application pool a different Identity than the first computer to be added to the pool. (You can't have empty pools by the way: all trusted application pools must contain at least one computer). For example:
New-CsTrustedApplicationPool -Identity trusted-computers.litwareinc.com -Site Redmond –ComputerFqdn atl-trust-00l.litwareinc.com
What we have now is a trusted application pool (trusted-computers.litwareinc.com) that contains the computer atl-trust-001.litwareinc.com. And this is a pool we can add additional computers to.
And how exactly do we do that? That, at long last, is where the New-CsTrustedApplicationComputer cmdlet comes in. To add another computer to a trusted application pool, we need to use a command similar to this:
New-CsTrustedApplicationComputer Identity atl-trust-002.litwareinc.com -Pool trusted-computers.litwareinc.com
See how that works? All we did was specify the Identity (FQDN) of our new trusted computer, as well as the fully qualified domain name of the pool the computer should be added to. If we now run the Get-CsTrustedApplicationComputer cmdlet we should see two different trusted application computers, both in the same pool:
Identity : atl-trust-001.litwareinc.com
Pool : trusted-computers.litwareinc.com
Fqdn : atl-trust-001.litwareinc.com
Identity : atl-trust-002.litwareinc.com
Fqdn : atl-trust-002.litwareinc.com
What do you know about that: the system works!
Note. OK, admittedly, it's not always quite that easy: like we said, for the purposes of today's haiku we're simplifying things a bit. You might want to take a peek at the article General Application Activation for a little more detail on the trusted application infrastructure.
The moral of the story is that New-CsTrustedApplicationComputer is used to add additional computers to a trusted application pool. However, this cmdlet is only required if you create a pool that can house multiple computers in the first place. If you create a single-computer pool you don't need to use this cmdlet; instead, New-CsTrustedApplicationPool will automatically create a new trusted application computer for you. For example, suppose we run this command:
New-CsTrustedApplicationPool -Identity atl-trust-999.litwareinc.com -Site Redmond
That command creates a new trusted application pool with the Identity atl-trust-999.litwareinc.com. Let's now see what happens when we run Get-CsTrustedApplicationComputer:
Identity : atl-trust-999.litwareinc.com
Pool : atl-trust-999.litwareinc.com
Fqdn : atl-trust-999.litwareinc.com
Black magic? Witchcraft? Sorcery? Maybe; to be honest, we've never actually seen the source code. However, we think it's just due to the fact that New-CsTrustedApplicationPool automatically creates a new trusted application computer for you.
So what happens if you change your mind and want to decommission a trusted application computer? Well, if that computer is one of several computers in a trusted application pool then all you have to do is run the Remove-CsTrustedApplicationComputer cmdlet. You know, like this:
Remove-CsTrustedApplicationComputer -Identity atl-trust-001.litwareinc.com
As long as atl-trust-001.litwareinc.com is in a pool that contains multiple computers then the preceding command will get rid of atl-trust-001.litwareinc.com. Period.
Ah, but what happens if atl-trust-001.litwareinc.com is the only computer in a trusted application pool? In that case, the preceding command will not work. Instead, you'll get an error message like this one:
Remove-CsTrustedApplicationComputer : A pool must have at least one computer. You cannot convert a pool consisting of Standard Edition servers to an Enterprise pool, or vice versa. Instead, you must re-create the pool.
OK, again, maybe not the best error message ever written. What we probably should have said is this: if there's only one computer in a pool then you can't get rid of that computer by running Remove-CsTrustedApplicationComputer. (Why not? Because then you'd have an empty pool, and we've already learned that Lync Server won't allow you to have an empty pool.) Instead, you need to delete the pool itself:
Remove-CsTrustedApplicationPool -Identity trusted-computers.litwareinc.com
That command will work: it will remove the trusted application pool and, by extension, any trusted application computers in that pool.
Note. If you remove a trusted application computer that computer, as you might expect, will no longer be able to run trusted applications, and will no longer show up when you run Get-CsTrustedApplicationComputer. In addition to that, the computer will no longer show up when you run the Get-CsComputer cmdlet: as far as Lync Server is concerned, that machine no longer exists. Just something to be aware of if you start playing around with trusted applications and the CsTrustedApplicationComputer cmdlets.
And there you have it: the CsTrustedApplicationComputer cmdlets. As for the Malleus Maleficarum, well, the author of today's haiku was definitely interested in the following paragraph:
If he confesses and is impenitent, he is to be handed over to the secular courts to suffer the extreme penalty … or he is to be imprisoned for life …. But if he does not confess, and stoutly maintains his denial, he is to be delivered as an impenitent to the power of the Civil Court to be punished in a fitting manner …
Which boils down to this: if you admit to being a witch, you will be punished. And if you don't admit to being a witch, you will be punished.
Just a coincidence that yesterday the author of today's haiku had his annual performance review ….
See you tomorrow!
Note. All kidding aside, don't worry about the author of today's haiku. He got just exactly the kind of performance review you'd expect someone who spends his days writing haikus about Lync Server PowerShell to get.