Or maybe Google has bought Microsoft; to be honest, the details are a little hazy. All the author of today's haiku knows at the moment is that he has won 950,000 British pounds in the Microsoft and Google Anniversary Contest. As his award notification points out:

"Microsoft and Google is now the biggest search engine worldwide and in an effort to make sure that it remains the most widely used search engine, we ran an online e-mail beta test which your email address won 950,000,00. GBP {Nine Hundred And Fifty Thousand Great British Pounds}"

Pretty cool, huh? At the current exchange rate, 950,000 pounds equates to a little over $1.5 million; for the author of today's haiku, that's like two years' pay! And that's just for the beta test of the contest. Imagine how much he could have won if he'd won the real contest!

Of course, you might be thinking, "Well, that all sounds nice, but there's no way that the author of today's haiku could meet the requirements for winning the contest." Au contraire, naysayers: not only did the author of today's haiku meet the requirements for winning the contest, but he also passed the "… statutory obligations, verifications, validations and satisfactory report Test conducted for all online winners." So there!

At any rate, the author of today's haiku has often wondered what it would be like if Microsoft and Google combined forces to produce a single search engine, and now he knows: he'd end up with $1.5 million.

Which is just exactly what he deserves.

What do you mean, "I bet this is some kind of a scam." How could it be a scam? After all, the prize notification included both a file reference and a batch number:

FILE REF: HL/5564/08/09/MICSBATCH: MC11/834/5PDH /EU

And here's an interesting piece of trivia: the file reference and batch number are exactly the same as the file reference and batch number of someone who won a completely different contest! What do you suppose the odds are of that?!?

Note. The author of today's haiku is actually glad that he didn't win that other contest. In that contest, second prize was worth 950,000 pounds, but first prize was worth only 15,000 pounds. Whoever said that "winning is everything" obviously never took part in an online sweepstakes.

At any rate, while we wait for the " … Courier Delivery Of your Certified Winning Cheque Name" (and yes, that is a little disconcerting: we'd prefer to get the actual check rather than just the name of that check) we thought we'd talk about the CsNetworkRegionLink cmdlets. (That's right, the Microsoft Google Anniversary Contest and the CsNetworkRegionLink cmdlets, all in one day!) For those of you who like to keep track of this sort of thing, there are four CsNetworkRegionLink cmdlets:

And why do we even need any network region link cmdlets? We're glad you asked that question. Network region links are used as part of Call Admission Control, the technology introduced in Microsoft Lync Server 2010 that enables administrators to manage bandwidth use between two network regions.

Let's assume that you have two network regions – Northwest and Europe – and that the network connection between the two regions is a little shaky at times; because of that, you've created a bandwidth policy that places a limit on the amount of audio/video traffic that can travel between the two regions at any given time. That's good: we now have two regions, and we have a policy that limits audio/video traffic. That leaves us with just one problem: how do we apply that policy to traffic that travels between the Northwest region and the Europe region?

How do we do that? Hey, what do we care? After all, we just won $1.5 million; you can figure this one out yourselves.

No, hey, just kidding. The answer, of course, is that we create a network region link between the two regions, and then assign the bandwidth policy to that link. Why wouldn't we assign the policy to the two regions instead? Well, remember, there isn't anything wrong with either the Northwest region or the Europe region; we just have problems with the connection between the two. By creating a link and then assigning the policy to the link, we're able to place some limits on that one connection. Suppose we have an Asia region as well, but our connectivity between Europe and Asia and between Northwest and Asia is perfectly fine. That's great: in that case, we don't place any restrictions on those links. See how that works?

At any rate, the New-CsNetworkRegionLink cmdlet makes it pretty easy to create a network region link:

We told you it was easy, didn't we? Basically all we need to do is give the link itself an Identity (NorthwestToEurope) and then specify the two regions using the parameters NetworkRegionID1 and NetworkRegionID2. (Does it make any difference which region gets tabbed as region 1 and which one gets tabbed as region 2? Nope.) We then assign a bandwidth policy using the BWPolicyProfileID parameter. What if you don't know the Identities of your bandwidth policies? That's OK; just run this command:

Get-CsNetworkBandwidthPolicyProfile

That's really all there is to it. If you need to make a change to this link somewhere along the way (for example, if you want to use a different bandwidth policy) just use the Set-CsNetworkRegionLink cmdlet:

As you might expect, Remove-CsNetworkRegionLink deletes the links defined by any two regions (while leaving those regions exactly as-is), and Get-CsNetworkRegionLink returns information about your existing network links. For example, this command returns information about all your links:

Get-CsNetworkRegionLink

And this command returns information about all the links that use the policy RestrictedAudioVideoTraffic:

Before we go, we should also note that, as much as we'd like to, we cannot share our winning PIN number with you, thus giving you a chance to try and stake a claim to those 950,000 British pounds. As our notification email states:

"The Microsoft and Google Promotion Award Team has reached a decision from headquarters that any double claim discovered by the Lottery Board will result to the canceling of that particular winning, making a loss for both the double claimer and the real winner, as it is taken that the real winner was the informer to the double claimer about the lottery."

Hopefully you'll understand why we can't take any chances here. After all, the email concludes that we must " … keep your winnings strictly confidential until you claim your prize."

Note. What's that? Oh, there's nothing to worry about there. After all, if you want to keep something confidential and make sure that no one ever, ever reads it, well, what better place to publish that thing than a daily haiku about Lync Server PowerShell?