Haiku #160
The sky is sprinkling,
The donuts aren’t. But our voice
Config seems to work
You may have already guessed by reading that haiku that the haiku writer is a little off today. The reason is that this writer was presented with a box of donuts this morning. Now, that’s normally a very good thing, and all in all it was today, too. But, being a little on the slow side this morning (yes, just this morning), this writer was the second person to get to the box of donuts. You might think that in a box of a dozen donuts that wouldn’t be a problem, but it turned out that there was only one donut in the entire dozen that had colored sprinkles on the top. And ‘lo and behold, the first person to the box snatched it up.
Needless to say, we were just a little disconcerted. It still beats the time this same writer went to the coffee shop to get a donut and the person immediately in front of the writer took the last donut. That was pretty traumatic.
So, the haiku writer at least got a donut this morning, but is still really missing those sprinkles. What the writer isn’t missing (besides the donut of course) is a way to test out voice configurations in Microsoft Lync Server. All what’s needed for that are the CsVoiceTestConfiguration cmdlets (Get-CsVoiceTestConfiguration, New-CsVoiceTestConfiguration, Set-CsVoiceTestConfiguration, Remove-CsVoiceTestConfiguration, and Test-CsVoiceTestConfiguration).
Note. Yes, that was a lousy segue. It would have been better with some sprinkles.
The CsVoiceTestConfiguration cmdlets allow you to set up scenarios that you can use to ensure that given a specific telephone number, that number would be correctly normalized and would follow the expected voice policy, voice route, and dial plan. As you can imagine, this is a pretty handy set of cmdlets to have. You can use them to ensure your Enterprise Voice implementation is set up correctly and to help you troubleshoot any issues you might be having. These cmdlets are sort of like the sprinkles on top of Enterprise Voice.
Note. All right, we’ll stop with the sprinkles. For now.
These test scenarios are defined at the global scope, so you can name them pretty much anything you want as long as you stay within the character limits (maximum of 32) and the name is unique within your Lync Server deployment. You can set up a very simple test scenario by calling New-CsVoiceTestConfiguration and giving the scenario a unique Identity, like this:
New-CsVoiceTestConfiguration –Identity TestFourDigit
A test scenario must include a phone number against which the test will be run. If you don’t define a number it will default to 1234. You can also configure a test scenario that will run against a specific dial plan and/or voice policy. For example, let’s say you’ve defined a voice policy for your Redmond site (site:Redmond). Now you want to configure a test scenario where you can enter a phone number and see what would happen to that number if it were dialed by a user who was using the site:Redmond voice policy. Here’s what the command to create the scenario looks like:
New-CsVoiceTestConfiguration –Identity TestRedmondPolicy –DialedNumber 5551234 –TargetVoicePolicy site:Redmond
Test scenarios are run against expected outcomes. By default the expected translated number is +1234. If you don’t expect the number you enter as the DialedNumber to be normalized to +1234, you need to specify a value for the ExpectedTranslatedNumber parameter. For example, suppose you’ve set up a dial plan named SevenDigitDialing. You’ve set up that dial plan so that if a user assigned to that dial plan dials the number 5551234, that number will be normalized to +12065551234. To make sure that the normalization rules are applied correctly, you’d create a test scenario that would check the dialed number against the expected results using that dial plan. Kind of like this:
New-CsVoiceTestConfiguration –Identity TestSeattlePlan –DialedNumber 5551234 –TargetDialPlan SevenDigitDialing –ExpectedTranslatedNumber +12065551234
To retrieve all your voice test configurations, simply all the Get-CsVoiceTestConfiguration cmdlet:
Get-CsVoiceTestConfiguration
If you’d like to retrieve all the scenarios configured against a specific dial plan, such as the Redmond site dial plan, use a command like this:
Get-CsVoiceTestConfiguration | Where-Object {$_.TargetDialPlan –eq "site:Redmond"}
To modify a test configuration, use the Set-CsVoiceTestConfiguration cmdlet. This command will change the expected translated number of the TestSeattlePlan configuration:
Set-CsVoiceTestConfiguration –Identity TestSeattlePlan –ExpectedTranlatedNumber +15551234
And of course, to remove a test configuration, call the Remove-CsVoiceTestConfiguration cmdlet:
Remove-CsVoiceTestConfiguration –Identity TestSeattlePlan
You might have noticed that, while we’ve configured some voice test scenarios, we haven’t actually run any. So let’s give that a try. To run our test scenarios, we use the Test-CsVoiceTestConfiguration cmdlet:
Get-CsVoiceTestConfiguration -Identity TestSeattlePlan | Test-CsVoiceTestConfiguration
The first thing you’ll notice is that you can’t simply call Test-CsVoiceTestConfiguration and pass it the name of a test configuration. Test-CsVoiceTestConfiguration requires you to pass it a reference to an actual voice test configuration object. We get that reference by calling Get-CsVoiceTestConfiguration, giving it the Identity of the configuration we want to use for our test, and piping that to Test-CsVoiceTestConfiguration. Your output will look similar to this:
Result: Success
TranslatedNumber: +15551234
MatchingRule: Description=;Pattern=^(\d{4})$;Translation=+1\d;Name=Test;IsInternalExtension=False
FirstMatchingRoute: site:Redmond
MatchingUsage: Local
And that’s all there is to it. If your test doesn’t succeed, the Result will come back as Fail. The reasons for failure might be a little tough to figure out, but if FirstMatchingRoute is empty, that means that a voice route wasn’t found that can work with that scenario. You’ll just have to kind of work through any failures on your own.
In the meantime, we’ll hope for brighter days in the future, where the sun is shining and the sky isn’t sprinkling, but the donuts are.