Haiku #92
They have 8 million
Dollars for me. Will my dial
Plan let me call them?
Yesterday afternoon, the author of today's haiku got an email telling him that there was $8 million sitting in the Central Bank of Nigeria, just waiting to be transferred to him. And yes, he knows: that sounds like a scam, doesn't it? But this time it appears to be legitimate; after all, just seconds after he received the email informing him of the $8 million he received a second email (from Robert Mueller III, the Executive Director of the FBI) assuring him that the first email was not a scam:
"Be rest assured that every thing regarding this is legitt and legal, and we are monitorring all their services accordingly. It is also our duty to protect your interest at any time. We will be hear to guide you during and after this project is been completed."
Now, granted, the spelling was a little questionable, and that's probably not the most grammatical paragraph ever written. But that's exactly why the author of today's haiku believes that this is legitimate. After all, most of the people who work for the FBI are American citizens; in addition, the American educational system has been declining year after year after year. We have a paragraph riddled with misspellings and grammatical errors? It had to be written by an American!
Besides, the email was quick to point out that many similar messages purportedly sent from the Central Bank of Nigeria are scams. But, apparently, the best way to stop these "hoodlums" is to ignore the scam emails and respond to legitimate emails, like the one from Robert Mueller III, the Executive Director of the FBI. As Mr. Mueller noted:
"So at this junction, you are advise to contact the said bank immediately you receive this mail.The Government Of Nigeria said this is the Little way they could only support the new Elected President to achieve this goal to stop the Economic Problem by all of us saying yes we can."
To be honest, the author of today's haiku doesn't have any idea what that means. Needless to say, the fact that this makes no sense at all simply increases the likelihood that it was sent by the U.S. government.
Mr. Mueller also included a fax number that the author of today's haiku could use to fax his personal information to the Central Bank of Nigeria. And that got the author of today's haiku to start thinking. "That's a long distance call," he thought. "I won't be able to make that call unless my Lync Server dial plan has a normalization rule that will let me make a call like that. Maybe I should just forget about the $8 million and look into the Lync Server dial plan cmdlets instead." And so he did.
Note. But don't feel bad: he's already gotten an email this morning about $6 million waiting for him in a different Nigerian bank. He'll be fine.
Actually, he'll be better than fine, because he now knows a little something about the CsDialPlan cmdlets (Get-CsDialPlan, Grant-CsDialPlan, New-CsDialPlan, Remove-CsDialPlan, Set-CsDialPlan, and – hang on a second while we catch our breath – Test-CsDialPlan). If you aren’t familiar with dial plans, dial plans are policies (even though they don’t have the word Policy anywhere in the cmdlet name) that provide information that enables users to make phone calls using Enterprise Voice. Remember the location profiles used in Office Communications Server 2007 R2? Well, dial plans are the Lync Server 2010 equivalent; the name was changed from location profile to dial plan in order to be more consistent with the terminology used in Microsoft Exchange.
Or so we've been told anyway.
This is usually the place where we tell you something like this: dial plans are so easy that you probably already know how to use them. This time, however, we aren't going to say anything like that. Granted, that's mostly true. However, there is one slightly tricky aspect to dial plans: dealing with normalization rules. Let's take a few minutes to go over how you work with normalization rules, and then we can say that dial plans are so easy that you probably already know how to use them.
Normalization rules are used to convert the number that a user dials into a number that Lync Server understands. For example, suppose a user picks up a phone and dials 1219. What kind of a phone number is 1219? Well, if you have a normalization rule that handles four-digit numbers like that, then Lync Server knows that 1219 is actually an extension number, and it should be converted to 1-206-555-1219. You dial 1219, and the normalization rule tells Lync Server which phone number you were really dialing.
And yes, that is handy. Otherwise, you'd have to dial 1-206-555-1219 any time you wanted to call someone in an office right down the hall from you.
Normalization rules need to be associated with dial plans. How do you do that? Let's say we have a brand-new dial plan and we want to assign that dial plan a brand-new voice normalization rule. The easiest way to do that is to run two separate commands: one to create the dial plan and the other to create the voice normalization rule:
New-CsDialPlan -Identity site:Redmond -SimpleName RedmondSiteDialPlan
New-CsVoiceNormalizationRule -Identity "site:Redmond/SeattlePrefix" -Pattern "^9(\d*){1,5}$" -Translation "+1206$1"
Good question: don't we need a third command here, one that associates the new dial plan with new normalization rule? That would seem to make sense, but that's not how it works. In the first command, we created a dial plan for the Redmond site; this dial plan has the Identity site:Redmond and a "simple name" (i.e., a friendly name) of RedmondSiteDialPlan. That gives us a dial plan with a default, and mostly useless, normalization rule.
In the second command, we create a new voice normalization rule. (One that isn’t useless.) So then where's the third command, the one that assigns this rule to the dial plan for the Redmond site? Well, as it turns out, we don't need that third command; instead, the rule is automatically assigned to the site based on the Identity given to that rule. In this example, we gave the rule the following Identity:
site:Redmond/SeattlePrefix
See? We can only have one dial plan at the Redmond site, so this new rule automatically gets assigned to the dial plan at that site. If we wanted to assign the rule to a per-user dial plan, we'd just specify the name of that dial plan as the identity:
New-CsVoiceNormalizationRule -Identity "TestPlan/SeattlePrefix" -Pattern "^9(\d*){1,5}$" -Translation "+1206$1"
See how that works? Now, if you go digging through the help for the CsDialPlan cmdlets, you'll probably notice that there's a parameter named NormalizationRules. Couldn't we just use that parameter to add a normalization rule to the new dial plan? No, not if the rule doesn't already exist. As we noted, normalization rules have to be associated with dial plans: you can't have orphaned normalization rules floating around in the system. If you don't have a dial plan it's impossible to create an unassigned normalization rule and then later assign that rule to a dial plan. Consider this command again:
New-CsVoiceNormalizationRule -Identity "TestPlan/SeattlePrefix" -Pattern "^9(\d*){1,5}$" -Translation "+1206$1"
If the dial plan TestPlan doesn't exist, this command is going to fail:
New-CsVoiceNormalizationRule " Invalid identity "tag:TestPlan": "Cannot add a normalization rule to missing dial plan "Tag:TestPlan". You must create the dial plan first."
So what's the point of having the NormalizationRules parameter? Well, as near as we can tell, the main reason for having this parameter is to enable you to copy a normalization rule from one dial plan to another. For example, suppose we have a rule in our global dial plan that we'd like to copy to the Redmond site. These two commands will do just that:
$x = Get-CsVoiceNormalizationRule –Identity "global/LongDistanceRule"
Set-CsDialPlan –Identity "site:Redmond" –NormalizationRules @{Add=$x}
That's pretty cool. We can even get a little fancier, and copy all the normalization rules from the global plan to the site plan:
$x = Get-CsVoiceNormalizationRule –Filter "global/*"
Set-CsDialPlan –Identity "site:Redmond" –NormalizationRules @{Add=$x}
Now we're talking. You can also use the NormalizationRules parameter to remove a rule from a dial plan. However, that requires you to first create an object reference to the rule, and then use that object reference when calling Set-CsDialPlan:
$x = Get-CsVoiceNormalizationRule –Identity "global/LongDistanceRule"
Set-CsDialPlan –Identity "global" –NormalizationRules @{Remove=$x}
That works, but it's probably easier just to remove the rule itself:
Remove-CsVoiceNormalizationRule –Identity "global/LongDistanceRule"
But it's up to you. We should note, however, that Set-CsDialPlan does make it easy to remove all the rules from a dial plan:
Set-CsDialPlan –Identity "global" –NormalizationRules $null
We don't know how often that comes up but, if it ever does, you're in business.
That's about all we have time for today; after all, we still have to gather up all our personal information and send it off to the Central Bank of Nigeria. And don't worry: if you're tired of receiving email from Nigeria claiming that there is several million dollars sitting in a bank in that country, just waiting for you to claim it, well, the FBI is well aware of this, and is on the job:
"I have just receive a notification from the Executive Governor of the central bank of Nigeria Emmanuel Stevel, stating that they noticed that some hoodlums are contacting some of their clients claiming to be from the central bank of Nigeria using that means to extort money from them and also to tarnish the image of all the staffs at the central bank of Nigeria and we have already start our investigation regarding this notification, and we have also contacted the Economic and Financial Crime Commission (EFCC) in Nigeria to assist in this investigation. We are still working on how to get this hoodlums and bring them to book."
Needless to say, the author of today's haiku will sleep much better tonight.