Determine Whether or Not a Number has Been Assigned to a Call Park Orbit
When you work at Microsoft you often find yourself involved in truly fascinating discussions. For example, just the other day a couple of us were sitting around talking about the call park service when someone posed this question: does the Get-CsCallParkOrbit cmdlet provide an easy way for you to determine whether or not a given number has been assigned to a call park orbit? For example, take number 7452. Is that number assigned to a call park orbit, or not assigned to a call park orbit? How can you tell?
Note. Well, we thought it was a truly fascinating discussion.
As it turns out, the answer to that question is no, Get-CsCallParkOrbit does not provide an easy way to determine whether or not a given number has been assigned to a call park orbit. When you create a new call park orbit you don't assign individual numbers to that orbit; instead, you assign a range of numbers (for example, 7319 through 7428) to that orbit. So has 7452 been assigned to a call park orbit? Well, the only way to determine that is to look at all the call park orbits you've created and check the values of the NumberRangeStart and the NumberRangeEnd properties and see if the number in question (7452) can be found in any of those call park orbit ranges.
That's what we thought, too: bummer.
But you know what they say: if life hands you lemons, then make a Windows PowerShell script that can determine whether or not a number has been assigned to a call park orbit. And that's exactly what we did:
$cpnumber = $args[0]
$orbits = Get-CsCallParkOrbit
foreach ($cpo in $orbits)
{
if ($cpnumber -ge $cpo.NumberRangeStart -and $cpnumber -le $cpo.NumberRangeEnd)
{
$counter = 1
"The call park number $cpnumber is assigned to the " + $cpo.Identity + " call park orbit."
}
}
if ($counter -ne 1)
{
"The call park number $cpnumber is not assigned to a call park orbit."
}
This is a pretty simple little script (for example, it doesn't include any sort of error handling), but it seems to do the job. And just how does it do the job? Well, the script starts off by taking the first argument passed to it and storing that value in a variable named $cpnumber. That means that you need to include the call park number as a command line argument when starting the script. For example, if our script is named C:\Scripts\NumberChecker.ps1 and we want to see if 7452 has been assigned to a call park orbit then we need to use this command to start the script:
C:\Scripts\NumberChecker.ps1 7452
If you leave off the number the script will still run, but it will simply tell you that no completely blank number has been assigned to a call park orbit.
Which you probably could have figured out for yourself without having to run the script.
After assigning the command-line argument to $cpnumber, we next use Get-CsCallParkOrbit to retrieve a collection of all the call park orbits configured for use in our organization; this information gets stashed in a variable named $orbits. We then use this line of code to set up a foreach loop that loops through each call park orbit stored in $orbits:
foreach ($cpo in $orbits)
This is where the fun begins. (Although we like to think that things have already been pretty fun.) The first thing we do inside our foreach loop is check to see if the number ($cpnumber) is greater than or equal to the NumberRangeStart value for the first call park orbit and if the number is less than or equal to the value of the NumberRangeEnd property for that same orbit:
if ($cpnumber -ge $cpo.NumberRangeStart -and $cpnumber -le $cpo.NumberRangeEnd)
What does that mean? Well, let's say our call park orbit includes these property values:
NumberRangeStart: 7400
NumberRangeEnd: 7499
The number we're interested in is 7452. Is the value 7452 greater than or equal to (-ge) 7400? You bet it is; that means 7452 has met the first criterion. Now, is 7452 less than or equal to (-le) 7499? Yep; that means 7452 has met both our criteria. And that can only mean one thing: 7452 has been assigned to a call park orbit.
At that point we run the following two lines of code:
$counter = 1
"The call park number $cpnumber is assigned to the " + $cpo.Identity + " call park orbit."
In the first line, we set the value of a variable named $counter to 1; we'll explain why we do that in just a second. In the second line, we simply echo back the fact that the number has been assigned to a call park orbit, as well as reporting back the Identity ($cpo.Identity) of that orbit.
And then we loop around and repeat the process for the next call park orbit in the collection.
And what happens if we have a number – say, 9993 – which isn't assigned to a call park orbit? That's fine: in that case, the variable $counter will never get set to 1, and we'll never execute the line of code that says that the number has been assigned to a call park orbit. Instead, as soon as we exit our foreach loop we'll encounter this line of code:
if ($counter -ne 1)
Here we're simply checking to see if $counter is not equal to (-ne) 1. If the number has not been assigned to a call park orbit then this will be true: $counter will not be equal to 1. Therefore, we then run this line of code to report the fact that the number in question is not assigned to a call park orbit:
"The call park number $cpnumber is not assigned to a call park orbit."
Didn't we tell you that this was truly fascinating?