Haiku #123
Don't thank us; instead
Thank CS Network Region.
But thank us, too. Please?
Before we get started this morning, we'd like to take a moment to salute ourselves for today's haiku, the 100th in our series of daily Lync Server PowerShell haikus. We feel that this unprecedented achievement will prove to be –
What's that? You say we already saluted ourselves for our 100th haiku, and that we did that over a month ago? Oh. Well, that's very different then. Never mind.
Sorry about that. To be honest, we just got caught up in a long-standing Microsoft tradition: sending out a notice to the entire world that says, "Please congratulate me for being so darn good at what I do!" Admittedly, this doesn't happen very often (it never happens in our particular group), but on rare occasions you will get an email from someone that basically says "Please thank me for having done my job." Typically you'll get at least three copies of these emails. You'll get the first copy and then, a few minutes later, you'll get a second copy. (Just in case your office was on fire, you were having your gall bladder removed, or for some other reason hadn't had a chance to read the original email.) And then a couple of hours later you'll get a revised email that reads something like this:
"Please excuse the spam, but when I originally sent out this email I used Times New Roman instead of Arial. My apologies for the inconvenience."
Of course, you might be thinking, "OK, even if those emails are extremely rare (which they are), aren't they a little annoying?" And the answer to that is: no, not in the least. That's because the people who send out these emails are clever enough to thank everyone currently working at Microsoft, everyone who has ever worked at Microsoft, and everyone who ever will work at Microsoft. After all, you can't get annoyed at someone who's thanking you for your contributions, can you?
Note. How many times has the author of today's haiku been thanked in one of these emails? Well, he hasn't actually – hey, this isn't about us, you know, this is about … something else ….
Anyway, we got a little carried away this morning, and we apologize for that. We promise that, from now on, we will no longer write articles asking people to congratulate us on our achievements.
Note. Would that still be true if we ever did achieve something? Needless to say, we'll never know, will we?
Besides, we have more important things to talk about than our 100th – um, than today's haiku: after all, today we're going to talk about the CsNetworkRegion cmdlets (Get-CsNetworkRegion, New-CsNetworkRegion, Remove-CsNetworkRegion, and Set-CsNetworkRegion).
Thank you, thank you very much.
So what are network regions? Well, without getting too bogged down in the intricacies of Call Admission Control (CAC), you typically set up your network by creating a series of sites based on fairly well-defined locations: say, an office building or a city. These sites are then collected in a series of regions; for example, your offices (sites) in Seattle, Portland, and Vancouver might be gathered together in the Northwest region.
Note. We should probably point out that you need to create your network regions before you create your network sites. That's because each site has to be associated with a region; if you try to create a site without associating it with a region (that is, without specifying a value for the NetworkRegionID parameter) you'll get this error message:
New-CsNetworkSite : Cannot bind argument to parameter 'NetworkRegionID' because it is an empty string.
So why do you even need regions? Well, as you probably know, Call Admission Control is used to apply bandwidth restrictions to your network connections. For example, suppose you have a less-than-reliable connection from your offices in the Pacific Northwest to your offices in Singapore. In that case, you might create a Northwest region and a Singapore region, then apply a bandwidth policy to that connection that prohibits using from making video calls that would likely overwhelm a connection that's a bit ... sketchy … to begin with. But the only way to apply a bandwidth policy between two regions is to, well, first have two regions.
So how do you actually create a region? Here's one example:
New-CsNetworkRegion -Identity Northwest -Description "Pacific Northwest offices" -CentralSite Redmond
A couple of notes here. First, each region you create must be associated with a central site; that simply means a site that's running the bandwidth policy service.
Note. How do you know if a site is running the bandwidth policy service? One way is to use the Get-CsWindowsService cmdlet and check each Front End server in the site; if you have a server running the RTCPDPCORE service then you have a server that's running the bandwidth policy service:
Get-CsWindowsService –Name RTCPDPCORE
You might also check for the RTCPDPAUTH service, which is the bandwidth policy authentication service.
As you can see, in addition to denoting the central site, we also specified an Identity for the site (mandatory) and a Description (optional). Each site must also include a BypassID, a globally unique identifier (GUID) that maps regions to bypass settings. What's that? We just said that you must include a BypassID, yet our sample command didn't include a BypassID?
Ah, good observations. As it turns out, you don't have to include a BypassID; if you leave out that parameter, an ID will automatically be generated for you. (That’s actually the recommended way of doing things.) But suppose you desperately want to create your own BypassID. Can you?
Sure. We're not totally sure why you'd want to do that, but these commands will work:
$x = [guid]::NewGuid()
New-CsNetworkRegion -Identity Northwest -Description "Pacific Northwest offices" -CentralSite Redmond –BypassID $x
What we've done here is use the NewGuid method to create our very own GUID, a value that we stored in a variable named $x. We then pass that variable as the parameter value to the BypassID parameter.
Note that, if you do this, you'll get a confirmation prompt that reads like this:
You are attempting to set the bypass ID manually. In most cases, this is computed for you automatically. Setting the bypass ID manually can have unintended consequences.
You'll then have to answer either yes or no before you can proceed.
You can also set "alternate paths" for your regions; as the name implies, these are alternate network paths that calls can take should your primary network path reach the saturation point. But we aren't going to talk about alternate paths today, simply because we already discussed these paths in haiku #58.
Note. Hey, no need to thank us for haiku #58. We were just doing our job.
Although, if you do want to thank us, well ….
As you might expect, you can use the Set-CsNetworkRegion cmdlet to modify existing regions, and use the Get-CsNetworkRegion cmdlet to return information about those regions. For example, here's a command that returns all the regions associated with the central site Redmond:
Get-CsNetworkRegion | Where-Object {$_.CentralSite –eq "site:Redmond"}
And here's a fun one. This command returns information about any regions where alternate paths for either audio or video (or both) are not allowed:
Get-CsNetworkRegion | Select Identity –ExpandProperty BWAlternatePaths | Where-Object {$_.AlternatePath –eq $False} | Format-Table Identity, BWPolicyModality, AlternatePath
See? We told you it was fun.
And, needless to say, you can use Remove-CsNetworkRegion to remove any (or all) of your network regions:
Remove-CsNetworkRegion
Etc., etc.
That should do it for today. And no, please don't bother to thank us for bringing you another daily haiku. After all, we couldn't have done it without your help!
See you tomorrow.