Haiku #82
To AV or not
AV? That's a question for
Test AV conference.
This past weekend the author of today's haiku was flipping through the TV listings when he noticed at least two shows that were obviously ripping off the plot to the classic movie It's a Wonderful Life.
Note. That's the one problem with doing something truly great: everyone immediately rips off your idea and then proceeds to do a vastly inferior version of whatever it was you already did. Fortunately, the authors of the Lync Server PowerShell blog have figured out a way to combat this intellectual piracy: we start with a vastly inferior version, and dare anyone to try to do worse. Outside of this blog, have you ever seen anyone write a Lync Server PowerShell haiku? See: the system works!
At any rate, the whole idea behind It's a Wonderful Life is this: George Bailey (Jimmy Stewart) thinks the world would be better off if he'd never been born, and an angel comes down from heaven to show him just exactly what the world would be like if he had never been born. So did that get us to wondering what the world would be like if Windows PowerShell had never been added to Lync Server? No, not really. After all, we know what the world would be like: for one thing, we'd actually have to work for a living, rather than just sit around and write haikus all day. That was too depressing to even think about.
Instead, we got to wondering "What would the world be like if the Test-CsAVConference cmdlet had never been created?" Now, you might be thinking, "I doubt that would make much difference; after all, I've never even heard of the Test-CsAVConference cmdlet." But stop and think about that for a moment: if there was no such thing as the Test-CsAVConference cmdlet then how could you verify that you could carry out audio/video conferences in your organization without having to organize and conduct a full-fledged conference? If you there was no such thing as the Test-CsAVConference cmdlet how could you troubleshoot situations where user A can't seem to hold a conference that includes user B? If there was no such thing as the Test-CsAVConference cmdlet then how could you run a command like this one:
Test-CsAVConference –TargetFqdn atl-cs-001.litwareinc.com
Note. OK, OK, relax. Remember, this is all hypothetical: the Test-CsAVConference cmdlet really does exist. Take a deep breath, and we'll try not to panic you anymore.
We can see that while everyone is truly grateful that the Test-CsAVConference cmdlet really does exist, many of you might still be a little puzzled as to what the thing actually does, and why it's so cool that we can run a command like the one we just showed you.
The Test-CsAVConference cmdlet is one of the "synthetic transaction" cmdlets included in Microsoft Lync Server 2010. A synthetic transaction is exactly what the name implies: it's an artificial transaction, a way to ensure that the system can perform some task without actually performing that task. (In this case, verifying that Lync Server can hold an audio/visual conference without actually holding that conference.) In order to use the Test-CsAVConference cmdlet you need to have a pair of user accounts to employ as part of the test. In the command we just showed you, you might have noticed that we didn't specify any user accounts; all we did was include the fully qualified domain name (FQDN) of the pool we wanted to test. Why didn't we include any user accounts? Well, that command assumes that we have used the CsHealthMonitoringConfiguration cmdlets to create a pair of test user accounts for the pool atl-cs-001.litwareinc.com. (If you're not sure what that means, take a look at one of our previous haikus.) What if we haven't created these test accounts, or what if we're troubleshooting a problem and we'd like to use two real user accounts when running this cmdlet? That's fine: you just need to create a pair of Windows PowerShell credential objects before running the test. In other words, you need a set of commands like these:
$cred1 = Get-Credential "litwareinc\pilar"
$cred2 = Get-Credential "litwareinc\kenmyer"
Test-CsAVConference -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:pilar@litwareinc.com" -SenderCredential $cred1 -ReceiverSipAddress "sip:kenmyer@litwareinc.com" -ReceiverCredential $cred2
Note. One important thing to keep in mind here: if you want to use a pair of actual user accounts when running the Test-CsAVConference cmdlet that means you have to supply both the user name (in the format domain_name\user_name) and the password for each account. In this case, that means you need to know the password for both litwareinc\pilar and litwareinc\kenmyer if you want this command to work.
And what if you don't want that command to work? Well, we hadn't really considered that possibility, but we suppose that, in that case, it probably doesn't matter much, does it?
So what actually happens when you run Test-CsAVConference? Well, the first thing the cmdlet does is try to log the two users on to Lync Server. If that succeeds, the Test-CsAVConference cmdlet then has the first user create an A/V conference, then waits to see if the second user is able to join that conference. After a brief exchange of data, the conference is deleted and the two tests users are logged off.
Incidentally, no actual conference takes place: you won't see Microsoft Lync popping up onscreen, and you won't see any audio or video flitting across the network. Instead, the cmdlet simply verifies that the two users can make the connections necessary to carry out an A/V conference.
And here's a handy little tip: any time you run Test-CsAVConference (or any of the synthetic transaction cmdlets) it's a good idea to tack on the Verbose parameter:
Test-CsAVConference –TargetFqdn atl-cs-001.litwareinc.com -Verbose
Why? Well, the Verbose parameter causes Test-CsAVConference to display a running account of everything it does while conducting a test. For example, without the Verbose parameter we ran a test and got back these results:
TargetFqdn : atl-cs-001.litwareinc.com
Result : Failure
Latency : 00:00:00
Error : 504, Server time-out
Diagnosis : ErrorCode=1008,Source=accessproxy.vdomain.com,Reason=Unable to
resolve DNS SRV record
Microsoft.Rtc.Signaling.DiagnosticHeader
That sort of implies that we're having a DNS problem. However, take a look at some of the detailed information we got back when we added the Verbose parameter:
VERBOSE: 'Register' activity started.
Sending Registration request:
Target Fqdn = pool0.vdomain.com
User Sip Address = sip:vt1_user1@VTenant1
Registrar Port = 5061.
Auth Type 'Trusted' is selected.
'Register' activity started.
Sending Registration request:
Target Fqdn = pool0.vdomain.com
User Sip Address = sip:vt1_user2@VTenant1
Registrar Port = 5061.
Auth Type 'Trusted' is selected.
An exception 'The endpoint was unable to register. See the ErrorCode for specific reason.' occurred during Workflow Microsoft.Rtc.SyntheticTransactions.Workflows.STPresenceWorkflow execution.
Take a look at the text in red: The endpoint was unable to register. As it turned out, we had specified a test account that didn't actually exist. When we replaced that bogus account with a real user account (that is, an account that can actually log on to Lync Server), we got these results:
TargetFqdn : atl-cs-001.litwareinc.com
Result : Success
Latency : 00:00:00
Error :
Diagnosis :
To be honest, we probably never would have figured that out without the additional information provided by the Verbose parameter.
So there you have it: that's why it's so important that the Test-CsAVConference was created. See you tomorrow,
Note. Is it true that every time you run the Test-CsAVConference cmdlet an angel gets its wings? Well, we think so: that was in the original spec, but we aren't 100% sure if it actually made it into the finished cmdlet or not. We'll get back to you on that.