Haiku #126
It's 4:00 AM. Seems
Like a great time to try out
Dial-in conferencing
Cats are evil.
Now, the author of today's haiku isn't saying that cats are evil – oh, wait, he did say that, didn't he? Well, you can't blame him for thinking that way: after all, cats are evil. Have you ever seen a cat that's cornered a mouse? If so, then you know that the cat won't just swiftly and mercifully swoop in and kill the mouse. Instead, the cat toys with the mouse, letting it go, catching it again, letting it go, catching it again, etc., etc. If the cat gets bored enough it might finally put the poor mouse out of its misery but, in general, cats just like to torture things. If that it isn't evil, then the author of today's haiku doesn't know what is.
Oh, wait: yes he does. Evil is a cat that you graciously agree to babysit for a month, and who shows its gratitude by meowing like crazy every morning around 4:30. The cat will meow like crazy (for no apparent reason) and then stop (again, for no apparent reason). And then, just in case you might have drifted off to sleep, the cat will start meowing again around 5:00 or so. And then again half an hour or so later. And won't stop until everyone is finally out of bed.
Why? Because cats are evil, that's why. Does the cat want to be fed? Nope. Does the cat want to play? Nope. Does the cat want to go for a walk? Hey, this is a cat we're talking about here! No, the cat just wants everyone to get out of bed and then, as soon as everyone is up and her mission has been accomplished, the cat goes back to bed herself and then sleeps for the rest of the day.
Evil.
On the bright side, however, we – well, never mind: we couldn't actually come up with a bright side to having a cat who gets everyone up at 4:30 each morning. But if we think of one, we'll be sure to let you know.
Have we mentioned yet that cats are evil?
Until then, let's talk about something that isn't evil. And yes, here at Microsoft there are plenty of things that aren't evil. And if you give us a few minutes, we'll try to come up with something.
Note to our fellow Microsoft employees. That was just a joke. Sheesh.
Ah, here's something that is anything but evil: the CsDialInConferencingAccessNumber cmdlets (Get-CsDialInConferencingAccessNumber, New-CsDialInConferencingAccessNumber, Remove-CsDialInConferencingAccessNumber, and Set-CsDialInConferencingAccessNumber). As you no doubt know, Lync Server 2010 provides a way for users to join the audio portion of an online conference by using a plain old telephone (or cell phone): you just phone a designated number, enter the appropriate conference ID, and away you go. That designated number is known as a dial-in conferencing access number, and you configure those numbers by – you got it – using the CsDialInConferencingAccessNumber cmdlets.
Note. OK, obviously there's more to setting up dial-in conferencing than just supplying a phone number. We're not going to go through all the details today, in part because that's not what the daily haiku is for, and in part because we don't actually know all the details ourselves. Fortunately, though, someone on our team did know all the details.
As you're about to see, there isn't anything too terribly difficult about configuring a dial-in access number. There's really only one thing you need to watch out for: each access number must be associated with a dial plan region (that is, with a region that appears in at least one of your dial plans). How are you supposed to know what dial plan regions are even available to you? Well, here's one way to retrieve the available dial plan regions:
Get-CsDialPlan | Select-Object DialInConferencingRegion
Or, if you want to get fancy and eliminate any duplicates from the output, you could run this command instead:
Get-CsDialPlan | Select-Object DialInConferencingRegion | Sort-Object –Property DialInConferencingRegion –Unique
Note. And yes, we wrote that last command having gotten only a few hours of sleep. Imagine the cool commands we could write if we were actually awake for a change.
As long as you have at least one region that can be associated with a dial-in access number then you can create a number using a command as simple as this:
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:RedmondDialIn@litwareinc.com" -DisplayNumber "1-800-555-1234" –DisplayName "Redmond Dial-In Access Number" -LineUri "tel:+18005551234" -Pool atl-cs-001.litwareinc.com -Regions "Redmond" –PrimaryLanguage "en-US"
A few comments about this command. When you create a dial-in conferencing access number, you actually create a contact object in Active Directory.
What do you mean you don't believe us? Do this: open up Active Directory Sites and Services, click View, and then click Show Services Node. Expand Services, expand RTC Service, and then click Application Contacts. You should see a bunch of objects with "names" like this:
{704179b1-0fea-405a-911c-8005ec85a34a}
Those all are your Lync Server application contact objects. And one of those will be the contact object representing your new dial-in access number.
Note. That's one reason why we included the DisplayName parameter and gave our dial-in access number a display name. It's a bit easier to identify an access number using a display name like Redmond Dial-In Access Number than to use a "name" like {704179b1-0fea-405a-911c-8005ec85a34a}.
When creating the dial-in access number, we had to give our new number a primary URI (which is just a SIP address); we had to specify a line URI (the actual phone number users can call in order to join a conference); we set the PrimaryLanguage to US English (en-US); and we had to specify a Registrar pool that the number will be associated with. (And, of course, the dial plan region, or regions.) We also gave our new number a DisplayNumber:
-DisplayNumber "1-800-555-1234"
Is that important? We think so. For one thing, it's a required parameter; if you leave it out, New-CsDialInConferencingAccessNumber will prompt you to enter it. Equally important, this is the number users will see when they access the Dial-in Conferencing Settings and PIN Management Web page. You don't want users to see a line URI when they access this Web page:
Instead, make the display number – the number the users will see – something a little friendlier. For example"
Etc.
We should also mention that, by default, dial-in access numbers are all assigned to the global scope. If you'd like to limit a number for use in a single site (the site where the number's Registrar pool resides) then just tack on the ScopeToSite parameter, like so:
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:RedmondDialIn@litwareinc.com" -DisplayNumber "1-800-555-1234" –DisplayName "Redmond Dial-In Access Number" -LineUri "tel:+18005551234" -Pool atl-cs-001.litwareinc.com -Regions "Redmond" –PrimaryLanguage "en-US" -ScopeToSite
Depending on the size of your organization, you might create several dial-in access numbers. Which leads to an obvious question: is there any way to configure the order of the access numbers on the Dial-in Conferencing Settings and PIN Management Web page? After all, suppose you have a primary access number that you prefer users to dial. If so, wouldn't you want to have that number listed first in the Web page?
Of course you would. And here's how you do that:
Set-CsDialInConferencingAccessNumber -Identity "sip:RedmondDialIn@litwareinc.com" -Priority 0 -ReorderedRegion Redmond
What we've done here is use the Set-CsDialInConferencingAccessNumber to modify the dial-in access number with the SIP address sip:RedmondDialIn@litwareinc.com. We want this number to be the first number listed for the Redmond region. To do that, we had to do two things:
· Set the Priority to 0. The Priority property indicates which number will be listed where; the first number to be listed is given Priority 0. What if we wanted this to be the seventh number listed? In that case, it would be given Priority 6. (Because the first number is 0, the second number is 1, and, if you continue along these lines, the seventh number is 6.)
· Set the ReorderRegion to the appropriate region; in this example, that’s Redmond. That simply tells Set-CsDialInConferencingAccessNumber which region is to be modified.
Got all that? Suppose we had these dial-in numbers for the Redmond region:
0. sip:aaaa@litwareinc.com
1. sip:bbbb@litwareinc.com
2. sip:cccc@litwareinc.com
3. sip:RedmondDialIn@litwareinc.com
We've now run a command that sets the Priority for sip:RedmondDialIn@litwareinc.com to 0. What will the Redmond region look like after we run this command? Like this:
0. sip:RedmondDialIn@litwareinc.com
1. sip:aaaa@litwareinc.com
2. sip:bbbb@litwareinc.com
3. sip:cccc@litwareinc.com
See what happened? sip:RedmondDialIn@litwareinc.com moved to the top of the list (Priority 0) and everything else just slid down one spot.
Yes, it is pretty straightforward, isn't it?
As you might expect, the Remove-CsDialInConferencingAccessNumber cmdlet deletes existing access numbers (although the cmdlet doesn’t delete the associated Active Directory contact object). Likewise, the Get-CsDialInConferencingAccessNumber cmdlet lets you retrieve information about your existing access numbers. Get-CsDialInConferencingAccessNumber has two parameters you might find interesting: EmptyRegion and Region. The EmptyRegion parameter lets you identify any access numbers that, for some reason, are no longer associated with a dial plan region:
Get-CsDialInConferencingAccessNumber -EmptyRegion
Meanwhile, the Region parameter makes it easy to return all the numbers associated with a specific dial plan region:
Get-CsDialInConferencingAccessNumber -Region "Redmond"
See? We told you that the CsDialInConferencingAccessNumber cmdlets weren't evil.
As for cats not being evil, well, evil is a pretty strong word. But yes, cats are evil. Or at least those cats that get everyone up at 4:30 in the morning would appear to be evil.
See you tomorrow.
Note. OK, OK: during most of the day the cat doesn't seem to be evil; just a little ... eccentric …. But come on: 4:30 in the morning, every morning? Even the Devil doesn't get up at 4:30 in the morning.
Or so we assume. We'd have to get hold of someone at ****** in order to clarify that.
Note to ****** employees. That was just a joke. Sheesh.
Editor’s Note. The author of today’s haiku seems to be forgetting the trouble we once got into for mentioning that there might be other companies out there other than Microsoft. The editor hasn’t. Therefore, names have been changed to protect … us.