The bandwidth service

Settings: They aren't real flashy,

But at least they work

 

Well, it's Monday again, but this Monday is different: this promises to be a great week. How do we know that? Well, yesterday was an almost-nice-day here in the great Pacific Northwest, so the author of today's haiku and his wife decided to go for a bike ride. About 4 ½ miles or so into their ride, the author's bike began to make funny noises, like it was shifting even though he wasn't actually shifting. Another half mile or so up the road the bike suddenly began shifting by itself, even when he had his hands off the handlebars and wasn't even pedaling.

 

And yes, as a magic trick that would have been pretty cool. But as a way to ride a bike, not quite as cool.

 

To say the least.

 

As a result, the author of today's haiku ended up parking the bike after an unexpectedly-brief ride, and then sat around for 45 minutes while his wife rode back to the car and came and got him. All told, his day went like this:

 

·         40 minutes to drive to the bike trail.

·         28 minutes actually riding his bike.

·         45 minutes sitting around waiting for his wife.

·         40 minutes to drive back home from the bike trail.

 

Did we mention that it's going to be a great week?

 

So was the author of today's haiku mad about his bike falling apart? Of course not. After all, he bought the bike way back in January of 2011. You can't expect these things to last forever, can you?

 

Trivia note. Based on the cost of the bike and the number of miles he's put it on it so far, the author of today's haiku estimates that it's cost him $20 for each mile ridden. That means that, if he was able to ride to his bike to work (which he can't: the streets around here are too scary to drive on, let alone ride a bike on) it would cost him $200 each day.

 

So is there a bright side to all of this? No; we tried to think of one, but there's absolutely no bright side whatsoever to a bike that's barely six months old falling apart. Therefore, let's talk about something completely different, and something much more pleasant: the CsBandwidthPolicyServiceConfiguration cmdlets (Get-CsBandwidthPolicyServiceConfiguration, New-CsBandwidthPolicyServiceConfiguration, Remove-CsBandwidthPolicyServiceConfiguration, and Set-CsBandwidthPolicyServiceConfiguration).

 

What's so pleasant about the CsBandwidthPolicyServiceConfiguration cmdlets? Well, for one thing, Remove-CsBandwidthPolicyServiceConfiguration is one of the two Lync Server PowerShell cmdlets that have 44 characters in the cmdlet name (tying it with Remove-CsDialInConferencingDtmfConfiguration); those are the two longest Lync Server cmdlet names.

 

Note. The cmdlet with the shortest name? Test-CsIM, with just 9 characters.

 

Perhaps more important, the CsBandwidthPolicyServiceConfiguration cmdlets are used to help manage the bandwidth policy service. What's the bandwidth policy service? Well, as you no doubt know, the Call Admission Control service introduced in Lync Server 2010 provides a way for you to place a limit on the amount of network bandwidth that can be used for audio and/or video transmissions between two sites; in turn, that lets you do things like ensure that 20,000 users in your Redmond location don't all suddenly make video calls to their peers in Dublin, thus totally overwhelming your network.

 

Note. Is that really that big of a deal? Yes, it is. Remember, with Voice over IP technologies like Enterprise Voice, audio and video calls travel over the same network as all your other data. If you have too many people using up too much network bandwidth for audio and video calls, that won't just wreak havoc with those calls, it will also wreak havoc with email, file transfers, Web sites, and anything else that uses the network.

 

In order to place limits on the connections between network sites, you create bandwidth policies. And in order to manage the bandwidth policy service, you use the CsBandwidthPolicyServiceConfiguration cmdlets.

 

Granted, that might sound like a big chore; it's not. As it turns out, managing the bandwidth policy service really only means two things: managing bandwidth policy logging, and configuring the length of time you can use a bandwidth policy authentication token before that token expires. If you want to enable logging all you have to do is set the EnableLogging property to True (hey, we told you it was easy):

 

Set-CsBandwidthPolicyServiceConfiguration –Identity global –EnableLogging $True

 

Note. In case you're wondering, logging is disabled by default.

 

You can also use the Set-CsBandwidthPolicyServiceConfiguration cmdlet to set the maximum file size for a log file and the amount of time a log file will remain on the system before the log is automatically deleted. For example:

 

Set-CsBandwidthPolicyServiceConfiguration –Identity global –LogCleanUpInterval 30.00:00:00 –MaxLogFileSizeMb 10

 

The LogCleanUpInterval property can be set to any value between 1 day and 60 days, inclusive. Be sure and take note of the format that you have to use when configuring this property:

 

–LogCleanUpInterval 30.00:00:00

 

The value 30.00:00:00:00 means 30 days, 00 hours, 00 minutes, and 00 seconds. If you wanted to set an oddball time interval (like 30 days, 7 hours, 11 minutes, and 44 seconds) you can do so using a value like this:

 

–LogCleanUpInterval 30.07:11:44

 

Why would you want to do that? We have no idea. But it's entirely up to you.

 

As for the maximum file size, that can be set to pretty much any integer value, anything from 0 to 999999999 megabytes. (The default value is 3.) You can even use a decimal value when setting the maximum file size:

 

–MaxLogFileSizeMb 10.4

 

If you do that, however, Lync Server will simply round the value off to the nearest whole number. Thus a value of 10.4 will be rounded down to 10.

 

Last, but surely not least, the MaxTokenLifetime parameter (which uses the same data format as LogCleanUpInterval) can be set to any value between 1 hour and 24 hours, inclusive. Want a token to last for 12 hours? No problem:

 

Set-CsBandwidthPolicyServiceConfiguration –Identity global –MaxTokenLifetime 0.12:00:00

 

Etc., etc.

 

And what about the other CsBandwidthPolicyServiceConfiguration cmdlets? Well, Get-CsBandwidthPolicyServiceConfiguration lets you retrieve information about your current bandwidth policy service settings. For example:

 

Get-CsBandwidthPolicyServiceConfiguration

 

Not fancy enough for you? OK, well how about this command, which returns any bandwidth policy service settings where the token lifetime is greater than the default value of 8 hours:

 

Get-CsBandwidthPolicyServiceConfiguration | Where-Object {$_.MaxTokenLifetime –gt "08:00:00"}

 

We thought you might like that one better. Meanwhile, the New-CsBandwidthPolicyServiceConfiguration cmdlet lets you create custom bandwidth policy service settings (at the site scope only), while the Remove-CsBandwidthPolicyServiceConfiguration cmdlet lets you go back later on and remove those settings. Want to get rid of all the bandwidth policy service settings configured at the site scope? Sure; why not:

 

Get-CsBandwidthPolicyServiceConfiguration –Filter "site:*" | Remove-CsBandwidthPolicyServiceConfiguration

 

Best of all, when you run the CsBandwidthPolicyServiceConfiguration cmdlets the brakes won't squeak, the chain won't fall off, and the derailleur won't start dragging on the ground.

 

Which, at the moment anyway, makes the CsBandwidthPolicyServiceConfiguration cmdlets a much better deal than a mountain bike.

 

Something to keep in mind if you've been thinking about going out and spending several hundred dollars on a new bike.