We whistle while we
Work. Why? Because of Network
As the author of today's haiku was climbing the stairs this morning, he noticed a series of signs – one at each floor – that read:
PLEASE DO NOT WHISTLE IN THE STAIRWAYS. IT DISTURBS THE PEOPLE IN NEARBY OFFICES.
The author of today's haiku was fascinated by those signs. Apparently, people – here at Microsoft! – are whistling as they go up and down the stairs, and whistling so often and so loudly that they're disturbing everyone around them. Amazing. And, needless to say, the author of today's haiku has been oblivious to all of this. Although he's sure it's happened at some point in his life, he can't ever recall seeing someone just walking along whistling. It just seems like an odd thing to do.
We should probably note that the author of today's haiku tried to find evidence that people really do walk around whistling all the time, but he didn't have much luck. About the best he could do was uncover an article from the August 26, 2007 Boston Globe which suggested that whistling was cool again (again?). Why? Because the " … the whole world whistles with Peter Bjorn and John," Peter Bjorn and John being a Swedish rock band that the whole world apparently whistles with.
Of course, the important thing here is this: if people at Microsoft really are whistling while they work, what the heck are they whistling about? After extensive research, the author of today's haiku uncovered the likely answer: the CsNetworkConfiguration cmdlets (Get-CsNetworkConfiguration, Remove-CsNetworkConfiguration, and Set-CsNetworkConfiguration).
So what is it about the CsNetworkConfiguration cmdlets that makes you want to just start whistling? Well, among other things, the CsNetworkConfiguration cmdlets are used to enable and disable Call Admission Control, the network bandwidth management technology introduced in Microsoft Lync Server 2010. When you install Lync Server, Call Admission Control is disabled. And for good reason: Call Admission Control is completely useless until you've set up subnets, bandwidth policies, regions, and all those other good Call Admission Control elements. After you've done that, you can then enable Call Admission Control by running this command:
Set-CsNetworkConfiguration –EnableBandwidthPolicyCheck $True
Actually, we should clarify that last statement: you can potentially enable Call Admission Control by running that command. Why do we say "potentially?" Well, when we call Set-CsNetworkConfiguration along with the EnableBandwidthPolicyCheck parameter, the first thing the cmdlet is going to do is run an extensive validation of your entire Call Admission Control infrastructure. If it finds a problem of some kind, the cmdlet will pause, describe the problem, and ask if you want to continue:
There is no InterNetworkRegionRoute between the regions "NorthAmerica" and "Europe". When EnableBandwidthPolicyCheck is set to true, there must be a region route defined between every pair of regions.
Regions are not routable.
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):
What happens next? Well, that's up to you. If you want to, you can answer yes (just press Y on the keyboard) and Set-CsNetworkConfiguration will continue its validation check. However, at that point it's pretty much a guarantee that Call Admission Control isn't going to work; after all, the error message noted that "… there must be a region route defined between every pair of regions." A better approach might be to press N, address the problem (in this case, create a region route between NorthAmerica and Europe), and then try again.
And what if you later decide to disable Call Admission Control? That's fine; just set EnableBandwidthPolicyCheck to False:
Set-CsNetworkConfiguration –EnableBandwidthPolicyCheck $False
Believe it or not, enabling and disabling Call Admission Control is the primary use for the CsNetworkConfiguration cmdlets. (Which makes us want to whistle, because we don't have to do very much work today.) Theoretically, you could make other changes using Set-CsNetworkConfiguration; for example, you could use the Subnets parameter to create/delete subnets. As a general rule, though, you'll find it much easier to create and delete subnets using the CsNetworkSubnet cmdlets. The same thing is true for sites, regions, region links, and everything else that can kind of sort of be done using Set-CsNetworkConfiguration.
Likewise, Get-CsNetworkConfiguration lets you retrieves information about how Call Admission Control has been configured; however, Get-CsNetworkConfiguration's output isn't the most user-friendly output we've ever seen. Again, you're probably better off using different cmdlets to get a detailed, and easy-to-read, look at the various Call Admission Control components. For example, if you want to see information about your network regions, use this command:
But, hey, if that makes you sad, and makes you feel like you'll never want to whistle again, well, don't fret; you can get this same information using Get-CsNetworkConfiguration:
Get-CsNetworkConfiguration | Select-Object –ExpandProperty NetworkRegions
Whatever makes you happy.
As for the Remove-CsNetworkConfiguration cmdlet, well, that cmdlet pretty much wipes out your entire Call Admission Control infrastructure: it will delete your sites, your regions, your region routes, pretty much everything that can be deleted. And what about the occasional item that can't be deleted (like media bypass settings)? Well, in that case, those properties will all be reset to their default values.
Incidentally, if you ever do decide to wipe out Call Admission Control completely, this command won't work:
Even though you can only have a single, global collection of network configuration settings (which explains why there isn't a New-CsNetworkConfiguration cmdlet), you still have to specify the Identity of the network configuration settings to be removed. If you're bound and determined to wipe out your entire Call Admission Control infrastructure you need to run this command:
Remove-CsNetworkConfiguration –Identity global
Strange, but true.
That's about it for today; we'll keep you posted on any updates to the whistling situation around here. Someone suggested that perhaps people were "whistling past the graveyard," but that made no sense whatsoever. After all, to whistle past the graveyard means to try and remain cheerful under the most depressing and distressing of situations. What could that have to do with working at Microsoft?
See you tomorrow.