In case you haven't stopped by to visit us here at the Lync Server PowerShell blog lately, we just wanted to let you know that we're usually pretty busy Monday mornings. For example, here’s how things went this morning:

The Lync Server PowerShell blog writers got into work bright and early (early anyway, maybe not so bright) and sat down to eat donuts. (Hey, first things first.)

After making sure they had their energy up, Writer A (we’ll call him “Greg”) and Writer B (we’ll call her “Writer B”) then went straight to work. “On what?” you ask. (We know, you didn’t ask, but we’re sure you were just being polite.) They went to work on the weekly One of These Things is Not Like the Others Challenge.

Don’t be shy, go ahead and ask: “What does that involve?” Well, it involves things like, oh, actually writing up a new Challenge; looking through the Challenge entries from the past week and updating the Challenge Scores; writing updates for the Un-Blog Home Page, the Challenge Home Page, and the Challenge Archive; and, last but not least, writing the Challenge Answer.

When all that’s done they can sit back and relax…

Oops, hang on. Now we have to write the Daily Haiku…

And so it goes. Now, was this story written to impress you with how busy we are every Monday morning? No. (We know this is a tough crowd.) What we really want you to know is that every Monday morning this is what you’ll find here:

Daily Haiku (this is actually here every day, thus the “Daily” part of “Daily Haiku”)

New Weekly Challenge

Answer to Last Week’s Challenge

So if you haven’t been stopping by at least once a week (and in the case of the haiku, at least once per day) you’re missing out. (Can you believe you’ve been missing something every single day? Maybe that’s what that eerie feeling is you’ve been experiencing.)

And yes, there’s even more here than haikus and challenges. But if you show up for those you’ll also see all the new scripts and articles we have for you. See, even more reason to stop by.

All cmdlets are

Equal. We agree. Except

For voice policies.

Today's literary allusion (and, really, how could anyone write an article about Microsoft Lync Server PowerShell without having at least one literary allusion?) comes from George Orwell's classic satire Animal Farm. In Animal Farm, the animals on an English farm revolt, get rid of their drunken human overseer, and set up an animal utopia. As part of this utopia they draw up the Seven Commandments of Animalism, including this one:

Of course, as time goes by, the ruling animals inevitably become corrupt. (Animals: so unlike people.) Eventually, the Seven Commandments of Animalism are reduced to this one:

So why the allusion to George Orwell's Animal Farm? Well, as it turns out, this same sort of thing is true in Lync Server PowerShell. In Lync Server PowerShell, all cmdlets are equal. But some cmdlets are more equal than others.

Yes, it's true: as much as we love all the Lync Server cmdlets (where would we be without New-CsSipProxyUseDefaultCert?) there's no doubt that some cmdlets, like the CsVoicePolicy cmdlets (Get-CsVoicePolicy, Grant-CsVoicePolicy, New-CsVoicePolicy, Remove-CsVoicePolicy, Set-CsVoicePolicy, and, last but surely not least, Test-CsVoicePolicy), are just more interesting than others.

So what's so great about the CsVoicePolicy cmdlets? Well, the fact of the matter is that voice policies are where all sorts of cool settings can be found. For example, here are just a few of the settings available in a voice policy:

See what we mean? If you want to do cool things with Enterprise Voice – allow users to transfer or park calls; allow users to forward calls; all users to have, say, both their office phone and their cell phone ring any time someone calls their work number – well, you're going to need to use voice policies to do that. And if you want to use Windows PowerShell to manage your voice policies (hint: you do) that means using the CsVoicePolicy cmdlets.

When you install Microsoft Lync Server 2010, a global voice policy – a global policy that is automatically applied to all your users – is created for you. That's great, but what if some of your users are more equal than others? (Or, at the very least, what if some of your users require different voice policy settings than others?) That's fine; after all, you can use the New-CsVoicePolicy cmdlet to create custom voice policies at the site scope and/or at the per-user scope. For example, this command creates a new per-user voice policy (RestrictedVoicePolicy) that disables call forwarding, simultaneous ringing, and call transfer:

New-CsVoicePolicy –Identity RestrictedVoicePolicy – AllowCallForwarding $False –AllowSimulRing $False -EnableCallTransfer $False

If you don't want Ken Myer to have those capabilities (call forwarding, simultaneous ringing, and call transfer) then all you have to do is use the Grant-CsVoicePolicy cmdlet to assign Ken the policy RestrictedVoicePolicy:

Grant-CsVoicePolicy –Identity "Ken Myer" –PolicyName RestrictedVoicePolicy

That's all you have to do. The CsVoicePolicy cmdlets: how could you not love them?

Well, another week, another weekly challenge. And just like we saw in our first One of These Things is Not Like the Other Challenge, everyone who entered was able to figure it out. That includes Aleksandar N., who isn't even using Lync Server yet but has still managed to come up with the correct answer to both our weekly challenges. So there you have it: Lync Server PowerShell is so easy to use that even people who don't use it know all the gory details.

Last week we showed you the following set of Set-CsConferencingPolicy parameters and asked you to tell us which parameter was not like the others:

And the answer is (for added effect, click here to listen to a drumroll as we unveil the answer): AllowExternalUserControl. Why? Well, as most of you pointed out, AllowExternalUserControl is the only parameter that gets applied on a per-user basis; the other three parameters get applied on a per-conference organizer basis.

What does that mean, and what difference does it make? Well, a policy that gets applied per-user always applies to that user, regardless of the conference he or she is participating in. For example, suppose we've applied a conferencing policy to Ken Myer that prohibits external user control, and we've applied a second policy to Pilar Ackerman, one that allows external user control. Ken Myer organizes a conference and invites Pilar to take part. Will Ken be allowed external user control? Nope; his conferencing policy prohibits that. Will Pilar be allowed external user control? Yep; that's because her policy allows her to do that.

OK, now switch things around: this time Pilar organizes a conference and Ken is invited to take part. Will this affect their abilities to allow external user control? No; a per-user policy always applies to the user in question, regardless of the conference he or she is taking part in. Pilar will always be allowed external user control; Ken will never be allowed external user control

Hey, life is tough, right?

Now, let's compare that to a per-organizer setting, such as AllowPolls. As we've seen, a per-user setting affects individual users; that means you could have a conference where some users (like Pilar) are allowed external user control while other users in that very same conference (like Ken) are not. But let's assume that Ken's conferencing policy allows polls in conferences but Pilar's policy does not. This setting affects the conference organizer, which in turn affects every single person in that conference. If Ken organizes a conference then everyone in that conference will be allowed to conduct polls, even Pilar. That's because the setting only applies to the conference organizer.  And what about a conference that Pilar organizes? In that case, no one will be allowed to conduct polls. Why not? Because AllowPolls applies to the conference organizer, and Pilar is not allowed to conduct polls. That means that polls will not be allowed in any conference organized by Pilar. Period.

It's a little confusing, yes, but if you play around with it a bit you'll see how it works. And, on the bright side, it's the only policy that has this distinction between per-user and per-organizer settings. Which means that you only have to worry about this when you’re configuring conferencing policies.

As we noted, everyone who submitted an answer came up with the same answer we did: AllowExternalUserControl. That's outstanding, and we congratulate all of you. On the other hand,  that means all of you think exactly like we do. And yes, you should be afraid of that. Very afraid.

Thank you all for playing along, and remember, Challenge 3 is already up and just waiting for you.

Challenge Home

One of These Things is Not Like the Others: Challenge 3

When we posted our first challenge, we were concerned that we'd made the thing a little too difficult; much to our surprise, however, everyone who submitted an answer got it right. Because of that, when we posted Challenge 2 we decided to make that challenge really difficult. The result of our herculean efforts to create a really difficult, incredibly tricky challenge? Everyone who submitted an answer got it right.

Sigh ….

With that in mind, we decided to make round 3 in our weekly series really challenging. And what if everyone gets it right again? Then we will immediately quit our jobs, run away, and join the circus.

So here we go. (And this week's challenge is a tough one. Promise.) Which one of these Microsoft Lync Server 2010 cmdlets is not like the others?

Here’s a hint.

And here’s the answer.

Challenge Home

Can you hear me now?

Oh. Can you hear me now? Oh.

Well, OK, can you --

We're going to let you in on a little secret here: sometimes (just sometimes, mind you) setting up and maintaining Enterprise Voice, Microsoft's implementation of the Voice over IP (VoIP) technology, can be a tad bit complicated. That's not because there's anything wrong with Enterprise Voice; it's just a fact that VoIP itself is complicated. After all, depending on your needs you might find yourself dealing with Mediation Servers, PSTN gateways, trunk configurations, call admission control, and who-knows-what-else. That's a lot of pieces to keep track of, and a lot of places where things could go wrong.

So does that mean that you shouldn't even consider using Enterprise Voice? Heavens no. After all, VoIP (i.e., Enterprise Voice) offers a whole slew of advantages over the public switched telephone network (PSTN), beginning with the fact that it tends to be cheaper: with Enterprise Voice you just have to pay for your Internet connection, you don't get charged by the minute for your long-distance calls. And while there are a bunch of nifty Enterprise Voice-compatible phones out there, you don't have to use them if you don't want to: all you really need is a computer that has a speaker and a microphone.

And – well, you get the idea. Besides, the point here isn't to sell you on Enterprise Voice, the point is … well, we've forgotten what the point is. So let's make one up: the point here isn't to sell you on Enterprise Voice, the point is that, now that you've got Enterprise Voice up and running, how do you make sure that it stays up and running?

So how do you make sure that Enterprise Voice stays up and running? Well, one way that you make sure that you stay up and running is to periodically test your health: you check your weight, your check your blood pressure, you go to the doctor for a routine physical. You don't do this because anything is wrong; instead, you do this because you want to catch any little problems before they become big problems. A pound of prevention is worth two in the bush, you know.

Or something like that.

At any rate, you should do the exact same thing with Enterprise Voice: you should periodically test its health. And while that sounds like a somewhat daunting task (how in the world do you take Enterprise Voice's blood pressure?), here at Microsoft we've made things easy for you: we've included a number of PowerShell cmdlets, like Test-CsPstnPeerToPeerCall, designed specifically to let you test the health of Enterprise Voice and the rest of your Lync Server deployment.

Test-CsPstnPeerToPeerCall is designed to verify that you can make a peer-to-peer phone call over the PSTN gateway. (A peer-to-peer call is nothing more than a call that involves just two people. If you have more than two people on the call with you it's then referred to as a conference call.) When you run Test-CsPstnPeerToPeerCall the cmdlet will first attempt to log the two test users on to Lync Server. (We'll explain who these test users are in just a minute.) If the logons succeed, the cmdlet will have user 1 place a call to user 2 by using the PSTN gateway; Test-CsPstnPeerToPeerCall makes this call using the dial plan, voice policy, and other policy and configurations settings assigned to the test user. If everything goes the way it's supposed to, the cmdlet will verify that user 2 was able to answer the call, then log both test accounts off of the system. And all you have to do is start the cmdlet; Test-CsPstnPeerToPeerCall does everything else for you.

Incidentally, Test-CsPstnPeerToPeerCall makes an actual phone call, a call that not only verifies that a connection can be made but that also transmits dual-tone multifrequency (DTMF) codes across the network; sending these DTMF codes lets you know whether media can be sent over the connection. However, the call is answered by the cmdlet itself, and no manual termination of the call is necessary. (That is, no one has to answer the call and no one has to hang up the phone that was called. In other words, no user intervention is required.)

As for the users employed by the cmdlet, well, the easiest way to use Test-CsPstnPeerToPeerCall is to configure a pair of test users for the Registrar pool being tested. (See the help topic for New-CsHealthMonitoringConfiguration for more details.) That's nice because you can then run your test using a command no more complicated than this:

Test-CsPstnPeerToPeerCall -TargetFqdn atl-cs-001.litwareinc.com

When called with just a single parameter (the fully qualified domain name of the pool being tested) Test-CsPstnPeerToPeerCall will automatically conduct the test using the two preconfigured test accounts.

However, you don't have to use preconfigured test accounts; if you want to, you can conduct your test using a pair of real, live user accounts. (This is especially useful if Pilar Ackerman says she can’t make a call to Ken Myer; you can run Test-CsPstnPeerToPeerCall using Ken and Pilar's accounts and see for yourself if Pilar is really unable to make this call and, if so, why.) That will require a set of commands similar to these:

$cred1 = Get-Credential "litwareinc\packerman"

$cred2 = Get-Credential "litwareinc\kenmyer"

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

As you can see, these commands make use of Windows PowerShell's Get-Credential cmdlet, a cmdlet that creates a credentials object for the specified user. What does that mean? That means that you have to enter the user name (in the form domain_name\user_name) and the password for each user. If you don’t enter the correct user name and/or password then the test will fail, not because the call could not be completed, but because the cmdlet was unable to log the user on to Lync Server.

Just something to keep in mind.

Oh, and here's something else to keep in mind: Anytime you run one of the Test-Cs cmdlets you might want to tack the Verbose parameter onto the end:

Test-CsPstnPeerToPeerCall -TargetFqdn atl-cs-001.litwareinc.com -Verbose

The Verbose parameter is nice, because it provides a step-by-step account of everything that the cmdlet does as it tries to complete the call. This transcript can be extremely handy if something goes wrong and you now have to figure out why something went wrong.

So is that all for today? No, not quite; after all, it wouldn't be the daily Lync Server PowerShell haiku if we didn't include some random bit of trivia that had nothing whatsoever to do with Lync Server or with PowerShell. Today we're happy to report that Paul Marcarelli, the actor who played the "Test Man" in all those old can-you-hear-me-now Verizon commercials, is alive and well. For a while there, rumors were sweeping the Internet (imagine that!) that Marcarelli was suffering from a brain tumor allegedly due to having used his cell phone too much. Turns out that was just an urban legend and Marcarelli (who also played Magical Fan #1 in the movie Colin Fitz Lives!) is alive and well.

Which is good to know, because now we can focus all our attention on trying to determine whether or not Paul is dead. We'll let you know what we find out.