Haiku #35

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?

Note. You know, now that you mention it, that is a good point, isn't it? A first for the daily Lync Server PowerShell haiku!

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.

Note. No, need to thank us. After all, that's what we do here at Microsoft: we make things easier for you. Right? Right? Hello?

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.