Haiku #162
The next best thing to
Getting a haircut: Trusted
Application pools.
Well, the author of today's haiku is back from his one-day journey to the TechReady conference. His overall impressions of the conference? Well, the mini-cannoli were surprisingly good, but the pasta salad in balsamic vinaigrette was a major disappointment. After all, if something is in a balsamic vinaigrette shouldn't there actually be some balsamic vinaigrette there, somewhere?
As for the presentation he assisted on, well, the presentation was titled Extreme PowerShell and was aimed at people who, having mastered the basics of Lync Server PowerShell, were ready to take their scripting skills to the next level. However, when the author's co-presenter asked the crowd how many people had even opened the Lync Server Management Shell (let alone did anything with it) only 6 people raised their hands. And when he asked how many people had written Windows PowerShell scripts of any kind (not just Lync Server PowerShell scripts), only four people raised their hands. Interestingly enough, that's what we said: uh-oh.
Oh, well: easy come, easy go. It was still way better than working, and with any luck, we managed to impart a little knowledge about Lync Server PowerShell, and how you can extend its capabilities, along the way. More importantly, the author of today's haiku also got a wristband that will allow him to attend tonight's Attendee Party. How exciting is that going to be? Well, here's one quote from the party flyer:
"Need a haircut? There's even a salon and spa where you can take advantage of their express services during the party."
Wow, you can go to a party and get your hair cut! And people keep think that Microsoft employees don't know how to have a good time.
Here's another quote from the flyer:
"The on-campus Company Store will be open during the party, providing you with the perfect opportunity to purchase Microsoft-branded merchandise, software, and hardware for yourself, your family, and friends."
Whoa. Now the author of today's haiku is thinking that maybe he won't go to the party. After all, it is possible to have too much fun and too much excitement.
That's especially true when you consider the subject of today's haiku: the CsTrustedApplicationPool cmdlets!
Note. Sure, we can tell you what individual cmdlets are included in the CsTrustedApplicationPool cmdlets: Get-CsTrustedApplicationPool, New-CsTrustedApplicationPool, Remove-CsTrustedApplicationPool, and Set-CsTrustedApplicationPool.
So what exactly do you do with the CsTrustedApplicationPool cmdlets? Well, in Microsoft Lync Server 2010, a trusted application is a third-party application that is granted trusted status and is allowed to run as if it was a built-in component of Lync Server. Trusted applications are allowed to run in any Lync Server pool. However, it's highly recommended that you create a separate trusted applications pool and run your trusted applications from within that pool. If you do that, you can more-easily manage all those applications, doing everything from specifying whether or not your trusted applications require authentication and whether or not the pool should take part in the Lync Server replication cycle. As you might have guessed, this is where the CsTrustedApplicationPool cmdlets come into play.
Note. We know how incredibly cool that sounds, but just take a deep breath and try to relax. Like we said earlier, it's possible to have too much fun and too much excitement.
Let's start out by showing you a simple command that creates a new trusted application pool:
New-CsTrustedApplicationPool -Identity trustedpool.litwareinc.com -Registrar atl-cs-001.litwareinc.com -Site Redmond
As you can see, that's actually a pretty simple little command. All we do there is call the New-CsTrustedApplicationPool cmdlet, specifying the Identity of the pool, the Registrar associated with the pool, and the site where the pool is homed. None of that is too-terribly difficult, but there are a few things you should know about these parameters. First, the Identity parameter should be the fully qualified domain name of the computer that is going to host the trusted applications. New-CsTrustedApplicationPool is actually a pretty easy cmdlet to get along with: it will accept pretty much any value for the Identity parameter, regardless of whether that value points to a real computer or not. But your trusted application won't actually work if the identity points to a mythical computer.
Incidentally, it’s recommended that you run trusted applications on a dedicated computer. It’s generally not a good idea to run SQL Server, Exchange, SharePoint, Lync Server, and all your trusted applications on one machine.
In fact, it's probably safe to say that that is never a good idea.
Now, what about the Registrar parameter? The truth is, you don't have to include a Registrar when creating a trusted application pool; the cmdlet will run just fine without it. However, once again, your trusted application won't work unless it's associated with a Registrar.
Note. What's that? You say you forgot to associate your trusted application with a Registrar? Oh, bother. Well, don't worry about it; after all, that's what the Set-CsTrustedApplicationPool cmdlet is for:
Set-CsTrustedApplicationPool –Identity TrustedApplicationPool:trustedpool.litwareinc.com –Registrar atl-cs-001.litwareinc.com
Oh, yeah: good observation. When we created our trusted application pool we gave it the Identity trustedpool.litwareinc.com. However, notice the Identity we used with the Set-CsTrustedApplicationPool cmdlet:
–Identity TrustedApplicationPool:trustedpool.litwareinc.com
What's the deal there?
Well, the deal there is relatively simple. When you create a new pool you use the fully qualified domain name of the computer that will host the pool as the Identity. Once the pool is created, however, the Identity is prefaced with TrustedApplicationPool: . As for the original Identity, it becomes the value of the PoolFqdn property:
Identity : TrustedApplicationPool:trustedpool.litwareinc.com
Registrar : atl-cs-001.litwareinc.com
FileStore :
ThrottleAsServer : True
TreatAsAuthenticated : True
OutboundOnly : False
RequiresReplication : True
AudioPortStart :
AudioPortCount : 0
AppSharingPortStart :
AppSharingPortCount : 0
VideoPortStart :
VideoPortCount :
Applications : {}
DependentServiceList :
ServiceId : redmond-ExternalServer-1
SiteId : site:Redmond
PoolFqdn : trustedpool.litwareinc.com
Version : 5
Role : TrustedApplicationPool
As you can see, there are a whole bunch of other properties that can be configured on a trusted application pool. We're not going to discuss all these properties today, but we will briefly explain three of them:
· ThrottleAsServer. This property determines how many simultaneous connections are allowed between trusted applications and the server. If you set this property to True you will be allowed a larger number of connections than if you set it to False. In other words, if performance is an issue then set ThrottleAsServer to False.
· TreatAsAuthenticated. If set to True, then trusted applications within the pool will be treated as having already been authenticated, and will be able to connect to the server without having to provide credentials. If set to False, then trusted applications must be authenticated whenever they connect to the server.
· OutboundOnly. If set to True, then trusted applications within the pool are not allowed to initiate contact with the server. Instead, they must wait for the server to contact them.
As you might expect, you can set these property values at the time you create a trusted application pool:
New-CsTrustedApplicationPool -Identity trustedpool.litwareinc.com -Registrar atl-cs-001.litwareinc.com -Site Redmond –ThrottleAsServer $False –TreatAsAuthenticated $False –OutboundOnly $True
Or, you can set these property values any time after the pool has been created:
Set-CsTrustedApplicationPool -Identity TrustedApplicationPool:trustedpool.litwareinc.com –ThrottleAsServer $False –TreatAsAuthenticated $False –OutboundOnly $True
Oh, yeah: after you run either the New-CsTrustedApplicationPool or the Set-CsTrustedApplicationPool you should also run the Enable-CsTopology cmdlet. How much trouble is that going to be? Not too much:
Enable-CsTopology
As you might expect, the Get-CsTrustedApplicationPool cmdlet enables you to return information about your trusted application pools. For example, here's how you get information about all your pools:
Get-CsTrustedApplicationPool
And here’s how we can get information about a single pool:
Get-CsTrustedApplicationPool –Identity trustedpool.litwareinc.com
Note. Wait, didn't we say that after a pool has been created it gets a new Identity, one like TrustedApplicationPool:trustedpool.litwareinc.com? Well, yes, we did say that, and the pool really does get a new Identity. However, the CsTrustedApplicationPool cmdlets do allow you to leave off the TrustedApplicationPool prefix when specifying the Identity.
And even though we are trying to keep the excitement level down a bit today, here's a command that returns all the trusted application pools that require replication:
Get-CsTrustedApplicationPool | Where-Object {$_.RequiresReplication –eq $True}
And here's one that lets you see all the pools that are not currently associated with a Registrar:
Get-CsTrustedApplicationPool | Where-Object {$_.Registrar –eq $Null}
And if trusted application pools are just too exciting for you to deal with, hey, no problem; just use Remove-CsTrustedApplicationPool to remove those pools. You can remove pools one at a time:
Remove-CsTrustedApplicationPool –Identity trustedpool.litwareinc.com
Or you can remove them all in one fell swoop:
Get-CsTrustedApplicationPool | Remove-CsTrustedApplicationPool
It's up to you. Just remember that removing a trusted application pool also removes any trusted applications, trusted application computers, and trusted application endpoints associated with that pool.
And yes, that would be a fun activity to do at the Attendee Party, wouldn't it? Not quite as much fun as getting your haircut, true. But probably the next best thing.
See you tomorrow.