Don't get scrammed and don't

Worry about your passwords.

Kerberos accounts.

This morning the author of today's haiku noticed an email in his Junk Mail folder that had the following subject line:

DON'T GET SCRAMMED!!!

Definitely not wanting to get scrammed, the author of today's haiku proceeded to read the email, which including the following note:

"Today many people on the Internet are victims of fruads and scrams. For example, you might be told to click a link and go to web site where you enter personal information; scrammers can then use this personal information for indentity theft. DON'T GET SCRAMMED!!!"

Gadzooks! thought the author of today's haiku. It's bad enough to have people try to steal your identity but now they're apparently trying to take your indentity as well. Is there no decency left in this world?

So how can you avoid getting scrammed? The email suggested that you go to their Web site and enter your personal information, including your credit card numbers. After that, they will "monitor the entire Internet and notify you if anyone tries to use this information or tries to buy something with your credit card." And how much will all this cost? Nothing! The service is entirely free.

And yes, we know what you're thinking: how could a service that monitors the entire Internet be free? Well, as it turns out, this service is sponsored by the US government. See? Nothing to worry about.

At any rate, something to think about, eh? Trust us: you do not want to get scrammed.

Which is all the more reason to continue visiting the Lync Server PowerShell blog which, after nearly a year in existence, has yet to scram even a single person! Instead of scramming people, we like to tell you about useful things, like the CsKerberosAccountAssignment cmdlets (Get-CsKerberosAccountAssignment, New-CsKerberosAccountAssignment, Remove-CsKerberosAccountAssignment, and Set-CsKerberosAccountAssignment). And if you'll just send us your credit card numbers, we'll be happy to tell you about this cmdlet.

Nah, just kidding. Although – nah, never mind.

As the name implies, the CsKerberosAcocuntAssignment cmdlets are used to assign Kerberos accounts. What are Kerberos accounts? As you know, in Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 your Web services all ran under a standard user account. Was that a problem? Well, it could be: if the password for that account expired you could lose those Web Services, an issue that was often difficult to diagnose. To help avoid this problem, Lync Server enables you to create a computer account (for a computer that doesn’t actually exist) that can serve as the authentication principal for all the computers in a site (or at least all the computers that are running IIS and a Lync Server Web service). Because these accounts use the Kerberos authentication protocol we cleverly refer to them as Kerberos accounts, and have dubbed the new authentication process as "Kerberos web authentication." The punch line? Kerberos web authentication lets you manage all your Lync Server Web servers by using a single account. The password for that one account could still expire, but there's only one account (and one password) you have to worry about, and we even provide a very simple way for you to change that password (Set-CsKerberosAccountPassword).

So how do you implement Kerberos web authentication? Well, the first step is to create a Kerberos account; that's an activity we discussed in haiku 85. (Thank you; it's our favorite haiku, too.) After you have an account, you can then assign it to one or more of your Lync Server sites (one account per site, although the same account can be used in multiple sites). For example:

New-CsKerberosAccountAssignment -UserAccount "litwareinc\kerberostest" -Identity "site:Redmond"

Enable-CsTopology

As you can see, all we've done here is taken an existing account – litwareinc\kerberostest – and assigned it to the Redmond site. (And yes, the parameter is UserAccount, even though a Kerberos account is actually a computer account. That's just one of those quirky things that make Lync Server PowerShell so lovable.) And then after we make the assignment we call the Enable-CsTopology cmdlet in order to create the required service principal name and effectively seal the deal.

Not bad, huh? Now, suppose you want to assign the same Kerberos account to all your sites. Can you do that? You bet, although it takes a tiny bit more work than you might first expect. That's because the New-CsKerberosAccountAssignment cmdlet won't take pipelined input. That means that a command like this one will fail:

Get-CsSite | New-CsKerberosAccountAssignment -UserAccount "litwareinc\kerberostest"

But that's fine. Instead of retrieving all our sites and piping them directly to New-CsKerberosAccountAssignment we can pipe that data to the ForEach-Object cmdlet and let ForEach-Object take care of things for us:

Get-CsSite | ForEach-Object {New-CsKerberosAccountAssignment -UserAccount "litwareinc\kerberostest" –Identity $_.Identity}

Needless to say, you can then use Get-CsKerberosAccountAssignment to retrieve information about the assignments already made in your organization, and use Set-CsKerberosAccountAssignment to modify any of those existing assignments (which basically means assigning a different Kerberos account to a site). You can also use the Remove-CsKerberosAccountAssignment cmdlet to delete an assignment:

Remove-CsKerberosAccountAssignment -Identity "site:Redmond"

Enable-CsTopology

Or, to delete all the assignments:

Get-CsKerberosAccountAssignment | Remove-CsKerberosAccountAssignment

Enable-CsTopology

Note that deleting an assignment doesn't delete the corresponding computer account from Active Directory; all it does is configure things so that your Lync Server Web servers in the specified site no longer use Kerberos web authentication. Instead, they'll use whatever authentication method/user account was configured before you set up Kerberos web authentication.

See? That wasn't so bad, was it? And now if you'll excuse us, we need to run to the bank. After reading about fruads and scrams this morning we came up with a great idea. Banks get robbed all the time, typically by people who walk into a bank and demand that all the money be taken out of the vault and put into a brown paper bag, right? Well, we thought we'd go into the bank and tell them, "Look, we know you get robbed all the time by people who demand that all the money be taken out of the vault and put into a brown paper bag. In order to protect you and your money, why don't you take all the money out of the vault and put it into our brown paper bag. And then, if anyone tries to steal that money, we'll notify you immediately."

Hey, it sounds good to us. We'll let you know how it goes.

Let sleeping cats lie.

Instead, make changes using

CS Registrar.

Why yes, as a matter of fact, the author of today's haiku is a bit tired this morning. Thank you for asking.

Coincidentally, the author of today's haiku and his wife are babysitting a cat for the next three weeks. How hard could it be to take care of a cat? Well, it's not hard at all to take care of a cat. But taking care of this cat is a different story.

Not that we're dealing with a bad cat here; on the contrary, this cat seems pretty nice, and even sort of likes people. (Although we had to promise not to tell other cats that.) However, she does have … interesting … sleeping habits. For example, Monday morning she woke up at 4:00, which would be fine except that she enthusiastically tried to get everyone else in the house to get up and join her in whatever cats and people do at 4:00 AM on a Monday.

Last night the author of today's haiku was doing a little in-bed reading when the cat hopped on the bed and nestled up against him. Sweet, huh? Except that the cat went to sleep and refused to move. That might have been fine, except that it was a little stuffy in the room last night, and the author of today's haiku began roasting under the combined warmth of the bed covers and the cat. He couldn't peel back some of those covers, because he had a sleeping cat on one side and a sleeping wife on the other side. Eventually he managed to wriggle his way outside the covers, which bought him about 15 minutes of relief until he then started to get a little cold. And then – well, you get the idea. The whole thing continued on its merry way until the cat got up around 4:30 AM (slept in today!), which gave the author of today's haiku the chance to get back into bed, with the right amount of covers, and then try to cram an entire night's sleep into an hour and a half.

It didn't work.

At any rate, the point of all that is just to point out that if today's haiku seems a little disjointed and doesn't make a lot of sense, well, there's a good reason for that: the author of today's haiku is a bit tired this morning.

Fortunately, we found a sure-fire way to get the blood flowing again no matter how tired you might be: just start playing around with the Set-CsRegistrar cmdlet. As you might expect, Set-CsRegistrar provides a way for you to configure and manage your Registrars. As you might also expect, this includes doing such exciting things as configuring the ports used for Web service or SIP traffic. For example:

Set-CsRegistrar –Identity "Registrar:atl-cs-001.litwareinc.com" -SipPort 5072

That does get the heart pounding a little bit, doesn't it? What we thought we'd focus on today, however, is something that might be even more exciting than SIP ports: failover and failback.

Did we say "failover and failback?" You bet we did. Microsoft Lync Server 2010 provides a way for users to automatically be redirected to a backup Registrar any time their primary Registrar is unavailable. What does that mean? Well, suppose you're homed on atl-cs-001.litwareinc.com. You try to log on to Microsoft Lync, but atl-cs-001.litwareinc.com is unavailable for some reason. If you've configured a backup registrar for that pool (for example, atl-backup-001.litwareinc.com) then you have nothing to worry about: you'll automatically be redirected to, and be able to log on to, that backup registrar.

Excited? We thought you would be. To allow for this automatic failover, you need to do two things: enable failover in the first place, and specify a backup registrar. How do you that? That's right: you use the Set-CsRegistrar cmdlet. In other words:

Set-CsRegistrar -Identity "Registrar:atl-cs-001.litwareinc.com" -BackupRegistrar "Registrar:atl-backup-001.litwareinc.com" -EnableAutomaticFailover $True

And while you're at it, there are two other properties you might find useful. The first – FailoverDetectionInterval – specifies how long the system will wait before deciding that a Registrar is not available. (Lync Server periodically sends "heartbeat" messages to its Registrars to verify that they're still up and running.) If the detection interval has passed and a Registrar still has not responded to the heartbeat message, then the system will "failover," which simply means that Lync Server will begin directing users to the backup Registrar.

The other property of interest is FailbackDetectionInterval. Let's suppose a Registrar is unavailable, and you've been "failed over" to the backup Registrar. That works but, as we noted, there are some limitations: the complete Lync Server feature set is not available to you when you're working on a backup Registrar. Because of that, the ideal situation is for you to move off the backup Registrar as soon as the primary Registrar is back in business. The FailbackDetectionInterval property specified the amount of time Lync Server waits before checking to see if the primary Registrar is available. If it is, then users homed on that Registrar will see their sessions "failed back;" that simply means that users on the backup Registrar will be re-registered on their home Registrar.

Which is actually pretty cool.

Two quick notes about Set-CsRegistrar. First, there is no corresponding Get-CsRegistrar cmdlet. Does that mean that you can't retrieve information about how your Registrars are currently configured? No. It just means that you have to use the Get-CsService cmdlet instead:

Get-CsService –Registrar

Second, the Set-CsRegistrar cmdlet doesn't accept pipelined input; that means you can't run a command like this one and configure all your Registrars at the same time:

Get-CsService -Registrar | Set-CsRegistrar -SipPort 5072

But now that you mention it, there is a way to work around that: instead of directly piping the Registrar data to Set-CsRegistrar, pipe it to the ForEach-Object cmdlet instead:

Get-CsService -Registrar | ForEach-Object {Set-CsRegistrar -Identity $_.Identity -SipPort 5072}

Give that a try and see what happens.

As for the cat sitting, well, we'll see what happens. As it turns out, cats (who typically sleep as many as 16 hours a day) are "crepuscular," which means that they are most active at dawn and at dusk. Is "crepuscular" what the author of today's haiku called "his" cat at 4:00 in the morning? Uh, sure, yeah …. Crepuscular ….

It's my party and

I'll send IMs if I want

To. Test Group IM.

You know, the one question everyone has been afraid to ask regarding Microsoft's proposed acquisition of Skype is this: how will this venture affect the Lync Server PowerShell Haiku of the Day?

Admittedly, due to scheduling differences we haven't had the opportunity to sit down with Steve Ballmer and discuss the future of the Lync Server PowerShell Haiku of the Day. Speaking strictly for ourselves, however, the authors of the Lync Server PowerShell blog can say this much: we are anxiously awaiting approval of the Skype acquisition.

Why are we so excited about adding Skype to the Microsoft arsenal? Well, historically speaking, haikus have never rhymed, and the Lync Server PowerShell Haiku of the Day is no exception. Is that because of our deep reverence for the history and the tradition of the haiku? Yes.

Well, that and the fact that it's really hard to find things that actually rhyme with "Microsoft Lync Server". So far this is all we've been able to come up with:

I have a fervor

For Microsoft Lync Server.

Which, come to think of it, is pretty good. But, to tell you the truth, it's hard to find a way to keep using that same exact rhyme day after day.

On the other hand, all sorts of things rhyme with Skype:

·         Gripe

·         Hype

·         Pipe

·         Ripe

·         Snipe

·         Stripe

·         Swipe

·         Tripe

·         Type

·         Wipe

Needless to say, we can't wait for Skype to become part of the Microsoft family of products. When that happens, we believe we can take the haiku to places it's never been before.

In fact, we only have two minor regrets when it comes to Skype. For one, we were hoping to get an $8.5 billion raise this year; that's probably not going to happen now. For another, if and when the acquisition is approved, we won't be able to write a rhyming haiku about the Test-CsGroupIM cmdlet. Why not? Because that's what we're writing about today.

Test-CsGroupIM is another one of the "synthetic transaction" cmdlets that ship with Microsoft Lync Server. (You've got a lot of nerver? Don't throw a fastball, throw him a curver?) Synthetic transaction cmdlets provide a way for you to test various Lync Server capabilities and verify that those features are working as expected. In the case of Test-CsGroupIM, the cmdlet allows you to verify that a pair of users can create and join a conference, exchange instant messages as part of that conference, and then log out.

The key word in that definition is this: conference. When you run Test-CsGroupIM, the cmdlet tests Lync Server's conferencing capabilities. For example, if you run the cmdlet using the Verbose parameter (which provides a blow-by-blow account of every activity the cmdlet undertakes as part of the test) you'll see actions such as these:

'CreateConference' activity started.

'CreateConference' activity completed in '0.2645174' secs.

'JoinConference' activity started.

'CreateConference' activity completed in '0.0858095' secs.

That's the difference between the Test-CsGroupIM cmdlet and the Test-CsIM cmdlet. Test-CsIM verifies whether a pair of users can exchange instant messages in a peer-to-peer session, a test that doesn't use Lync Server's conferencing services at all. With Test-CsIM you see actions such as these:

'InviteP2PIM' activity started.

'InviteP2PIM ' activity completed in '0.1269747' secs.

'SendP2PIM' activity started.

'SendP2PIM' activity completed in '0.0090779' secs.

In other words, Test-CsGroupIM verifies whether you can exchange instant messages in a conference setting, while Test-CsIM verifies whether you can exchange instant messages in a peer-to-peer setting.

Just in case you were wondering.

So how do you actually use Test-CsGroupIM? Well, if you've configured a pair of health monitoring test accounts for a pool, you can use Test-CsGroupIM by running a command similar to this one:

Test-CsGroupIM atl-cs-001.litwareinc.com –Verbose

Nothing too hard about that: you simply call Test-CsGroupIM followed by the name of the pool to be tested (in this case, atl-cs-001.litwareinc.com) and, optionally, the Verbose parameter. If all goes well, you'll get output similar to this:

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Success

Latency    : 00:00:01.6932425

Error      :

Diagnosis  :

If all doesn't go well, then you might see output similar to this:

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Failure

Latency    : 00:00:00

Error      : The log on was denied. Check that the proper credentials are

             Being used and the account is active. Inner Exception:

             NegotiateSecurityAssociation failed, error: -2146893044

Diagnosis  :

In case you're wondering, the preceding test failed because we used an invalid test account. And, thanks to the verbose output, we can even determine which account failed:

Sending Registration request:

 Target Fqdn      = atl-cs-001.litwareinc.com

 User SIP Address = sip:pilar@litwareinc.com

 Register Port    = 5061

Auth type 'IWA' is selected.

An exception 'The log on was denied. Check that the proper credentials are being used and the account is active'

As you can see, the account pilar@litwareinc.com was unable to log on.

Speaking of logging on, we should also note that you can run Test-CsGroupIM using a pair of real, live user accounts. (Something you might want to do if a pair of users tried, and failed, to create and join a conference.) The only catch is that you'll need to know the logon name and the user account password for each of those users. Assuming you have that information at your disposal, then you can run Test-CsGroupIM using a set of commands similar to these:

$cred1 = Get-Credential "litwareinc\pilar"

$cred2 = Get-Credential "litwareinc\kenmyer"

Test-CsGroupIm -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:pilar@litwareinc.com" -SenderCredential $cred1 -ReceiverSipAddress "sip:kenmyer@litwareinc.com" -ReceiverCredential $cred2

Pretty cool, huh?

That's pretty much everything you need to know about the Test-CsGroupIM cmdlet. In the meantime, what about this:

Microsoft Lync Server?

It's like a messaging life preserver,

Said a totally unbiased observer.

Good point. We'll keep our fingers crossed and hope the whole Skype thing gets approved as soon as possible.

If you can't trust your

Application then who can

You trust? Trusted apps.

Just to bring a little closure to our continuing saga concerning the weather here in the Seattle area, we're happy to report that last Friday the temperature did, indeed hit 70 degrees Fahrenheit. That was pretty exciting, although our excitement was tempered a bit by the fact that, thanks to a 70 degree day on Thursday, Fairbanks, AK got to 70 degrees before we did.

Yes: Fairbanks, Alaska.

At any rate, sometime in the late afternoon on Friday we hit 70 degrees; fortunately for all of us here in this area, by 4:30 PM the clouds had already started rolling in and the temperature mercifully began to drop. Saturday we had a high of 56, and Sunday a high of 60 degrees. At that point, we could all breathe a sigh of relief.

And in case you're wondering, yes, the only thing that people in Seattle like more than complaining about the rotten weather we're having is this: complaining about any good weather we might have. In this part of the country, we complain about it being cold and then, as soon as the temperature climbs above 70, we start complaining about it being too hot. If it rains for 10 straight days we complain about that, but if it doesn't rain on the 11^th day we start saying things like, "We really could use a little rain." If you're one of those who think that people who live in the Seattle area are weird, well, you're absolutely right.

The current temperature here in Redmond is 51 degrees, which means we can kick back, relax, and do what we do best … well, OK, we couldn't actually come up with anything that we do best. So let's just talk about the CsTrustedApplication cmdlets (Get-CsTrustedApplication, New-CsTrustedApplication, Remove-CsTrustedApplication, and Set-CsTrustedApplication) instead.

To tell you the truth, we had a bit of an ulterior motive in choosing to discuss the CsTrustedApplication cmdlets. Late last week we received an email telling us that one of our examples was wrong, that we didn't specify a valid Identity for a trusted application. As it turned out, however, it wasn't one of our examples that was wrong, it was actually an example written by the Exchange team. So does that mean we're writing this article simply so we can gloat a little at the misfortune of the Exchange team and, while we're at it, show off our knowledge of trusted applications? You bet that's why we – um, no, of course not.

That never even occurred to us.

At any rate, a trusted application is an application that isn't part of Microsoft Lync Server 2010, but has been given a trusted status that allows it to run as though it was a built-in component of Lync Server. We should note that you can't just set up any old application as a trusted application: it has to be something that was written specifically to work with Lync Server. But assuming that you have such an application, here's how you can give it trusted status:

New-CsTrustedApplication -ApplicationId FabrikamMessagingApplication -TrustedApplicationPoolFqdn TrustPool.litwareinc.com -Port 6000

Two important things to keep in mind when creating a new trusted application: First, the TrustedApplicationPoolFqdn must point to a, well, trusted application pool. That's not necessarily the same thing as your Registrar pools; instead, it's something you need to create using the New-CsTrustedApplicationPool cmdlet. If you aren't sure if you even have any trusted application pools, try running this command:

Get-CsTrustedApplicationPool

Second, the ApplicationID parameter specifies the name of the trusted application. This is where the Exchange team went wrong. In their documentation, they gave the following as an example of an ApplicationID:

Outlook Web App

What's wrong with that? That's an easy one (well, for us it's an easy one): you can't have blank spaces in the ApplicationID. Instead, you need to use an ApplicationID like this one:

OutlookWebApp

Why can't you use blank spaces? Well, when you create a trusted application, Lync Server constructs an Identity consisting of three parts:

·         The fully qualified domain name of the trusted application pool.

·         The string value /urn:application:.

·         The ApplicationID.

If you include a blank space in the ApplicationID, that results in an invalid URI:

trustpool.litwareinc.com/urn:application:outlook web app

That's just not going to work. Instead, you need a URI that doesn't have any blank spaces:

trustpool.litwareinc.com/urn:application:outlookwebapp

That URI will work.

Oh, and here's another little tip: after you create a new trusted application, you might need to run the Enable-CsTopology cmdlet in order to get that new application incorporated into your Lync Server topology. How hard is that going to be? Well, not too terribly hard:

Enable-CsTopology

As long as we're on the subject, we might also mention that the Get-CsTrustedApplication cmdlet provides a number of options that make it easy for you to retrieve the trusted application (or applications) that you're most interested in. If you want to, you can specify the entire Identity when trying to retrieve information about an application:

Get-CsTrustedApplication –Identity trustpool.litwareinc.com/urn:application:outlookwebapp

If you don't like doing all that typing, however, you can specify the ApplicationID and the trusted application pool separately, like so:

Get-CsTrustedApplication –ApplicationID outlookwebapp –TrustedApplicationPoolFqdn trustpool.litwareinc.com

That's a little bit less typing, especially if you don't spell out all the parameter names:

Get-CsTrustedApplication –A outlookwebapp –T trustpool.litwareinc.com

Or just use the Filter parameter and a couple of wildcards, like so:

Get-CsTrustedApplication –Filter "*outlook*"

That's pretty much all you need to know to get started using the CsTrustedApplication cmdlets. And here's pretty much all you need to know about the upcoming weather in Seattle:

Don't you just love spring?

It's time once again for the weekly Lync Server One of These Things is Not Like the Others challenge. We're in an especially good mood this morning, so we decided to be nice to everyone and give you an easy challenge this week.

What's that? Are we really in a good mood this morning? No, not really; after all, it is a Monday. But we think this week's challenge will be an easy one nonetheless. Take a quick look at it, send us your answer, and then you'll have the rest of the week to do whatever it is you do when you're not trying to solve the weekly Lync Server PowerShell challenge.

In the meantime, we've got this week's competition to deal with. We've said it before, and now we'll say it again: which of the following four Lync Server PowerShell cmdlets is not like the others?

Challenge 19 Hint

Challenge 19 Answer

Challenge Home