No need to lose your

Head. Instead, test your CS

Address book service.

Hey, everyone. It's July 14^th, and we'd like to be the first to wish everyone out there a happy Bastille Day. For those of you who aren't up on your French history, Bastille Day commemorates the storming of the Bastille fortress/prison in Paris way back in July of 1789. "Intoxicated with liberty and enthusiasm" an angry crowd of Parisians gathered at the Bastille and demanded that the gates be opened and the prisoners set free. After a series of negotiations the Bastille's commandant gave in, opened the gates, and set the prisoners free. As a token of their appreciation, the Parisians rioted anyway, 98 people were killed, and the Bastille commandant and several of his men were paraded through the streets of town and then brutally beaten, lynched, stabbed, and shot.

And then, just to be on the safe side, they chopped off his head as well. Hey, you can't be too careful, you know?

That was day 1 of the French Revolution, a day that pretty much set the tone for the ensuing festivities. In a nutshell, the French Revolution worked like this: someone would seize power and then, in the spirit of liberty, fraternity, and equality, immediately chop off the head of anyone who might disagree with them in the slightest way. A few weeks later, someone else would seize power, and immediately chop off the head of anyone who might disagree with them in the slightest way. This went on for a good 10 years, until Napoleon Bonaparte swooped in and seized power for himself.

In other words, the final score for the French Revolution was this: tens of thousands of people with their heads chopped off, and a dictatorship imposed by Napoleon Bonaparte. Hey, why wouldn't you have a holiday to celebrate something like that?

At any rate, and courtesy of the Internet, here are some suggested Bastille Day activities for those of you interested in celebrating today's holiday:

·         Offer up a few of your favorite Francophone words of wisdom for discussion. If anyone disagrees with you, chop off their head.

Note for the lawyers. Remember, this is from the Internet; we personally don’t recommend you chop off anyone’s head.

·         Talk about famous French people who share each guest's birthday. For example, here are some famous French people who share a birthday (December 18^th) with the author of today's haiku: Alexandre Chatrian, André S. Labarthe, Bettina Rheims, Germaine Aussey, and Noël Roquevert. Who wouldn't have a great time sitting around talking about André S. Labarthe?

Note. And if there is someone who wouldn't have a great time sitting around talking about André S. Labarthe, chop off their head.

Note for the lawyers. Yeah, same thing here.

·         Anyone who has been to France will be eager to talk about it. Set up a projector to swap stories and photos. For example, the author of today's haiku has been to Paris, and has seen the prison cell where Marie Antoinette was held before they chopped off her head.

Such fun!

Of course, here in America we have our own way of celebrating Bastille Day: we like to spend the day running the Test-CsAddressBookService cmdlet. Why? Well, a better question would be: why not? After all, the Test-CsAddressBookService provides a quick and easy way to verify that your Address Book servers are all up and running. When you call Test-CsAddressBookService, the cmdlets starts off by connecting to the Address Book Download Web service on the specified pool; if it makes the connection, the cmdlet then requests the location of the Address Book files. If that request is filled, then the test is considered a success, and you'll see output similar to this:

TargetUri  : https://atl-cs-001.litwareinc.com/abs/handler

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Success

Latency    : 00:00:00

Error      :

Diagnosis  :

We should also point out that you'll see a whole bunch of XML data displayed on screen before you actually get the results of the test. To the best of our knowledge, there's not a whole heck of a lot you can do about that. We've tried several different ways to suppress that XML output, but we couldn't do it; the feature team that produced the cmdlet couldn't come up with any suggestions either. That's something you'll just have to accept.

So how do you actually run the Test-CsAddressBookService cmdlet? Well, if you have set up health monitoring test accounts for a pool, you can run it using a command as simple as this:

Test-CsAddressBookService -TargetFqdn atl-cs-001.litwareinc.com

And what if you haven't set up these test accounts, or what if you'd like to see if a specific user is able to connect to the Address Book service? That's fine; in that case, you can use a couple commands like these:

$cred1 = Get-Credential "litwareinc\kenmyer"

Test-CsAddressBookService -TargetFqdn atl-cs-001.litwareinc.com -UserCredential $cred1 -UserSipAddress "sip:kenmyer@litwareinc.com"

The one catch here? We're running this command under Ken Myer's user account, which means we need to know both Ken Myer's user name (litwareinc\kenmyer) and his password. (Oh: and his SIP address as well.) Get any of those things wrong and the test will fail:

TargetUri  :

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Failure

Latency    : 00:00:00

Error      : The log on was denied. Check that the proper credentials are

             Being used and the account is active.

             Inner Exception:NegotiateSecurityAssociation failed, error:
             -2146893044

Diagnosis  :

Not a pretty sight, by any means.

And what if you have multiple Address Book servers, and you'd like to test all of them with a single command? Well, one way to do that is to pipe the Address Book FQDNs to the ForEach-Object cmdlet, like so:

"atl-cs-001.litwareinc.com", "Dublin-cs-001.litwareinc.com" | ForEach-Object {Test-CsAddressBookService -TargetFqdn $_}

And while we aren't exactly experts on the Address Book service, this command might be useful as well: it picks out each of your Lync Server pools that happens to be running the Web service, then tests the Address Book service on each of those pools:

Get-CsPool | Where-Object {$_.Services –match "WebServer"} | ForEach-Object {Test-CsAddressBookService -TargetFqdn $_.Identity}

To be honest, we aren't sure how useful that particular command is, but it gives you a template to work with: all you have to do is figure out the best way to retrieve your Address Book server FQDNs and then pipe those babies to the ForEach-Object cmdlet.

That should do it for now. Enjoy the rest of your Bastille Day: don't drink too much, don't party too hard, and, whatever you do, don't lose your head.

See you tomorrow.

We're gonna party

Like it's 1582.

Setup permissions.

Last week the author of today's haiku got an interesting email from one of the internal departments here at Microsoft, a message that said, in part, "You are receiving this message because you have been identified as a(n) requester/approver of at least one purchase order with a PO line item delivery date impacted by the shift to the Gregorian calendar."

Now, the author of today's haiku found this interesting for two reasons. For one, there's the notion that had been identified as a "requester/approver of at least one purchase order;" to be honest, he found it really, really hard to believe that Microsoft would let him have anything whatsoever to do with money.

What he really found interesting, however, was this part of the message " … the shift to the Gregorian calendar." As you probably know, the Gregorian calendar was introduced by Pope Gregory XIII back in February of 1582. The Gregorian calendar was devised to fix a few problems with the Julian calendar, problem number 1 being the fact that the Julian calendar miscalculated the length of a year by about 11 minutes. That might not sound like a very big deal, but that does result in the loss of about three days every 400 years; if the Julian calendar was still in effect, today would actually be July 2, 2011 and we'd all get to live the past 13 days all over again.

That's what we said: how … nice ….

After the proposed new calendar was unveiled, the new system was adopted by a number of Catholic countries within a year. However, many Protestant countries refused to make the switch, viewing the new calendar as some sort of Catholic plot to take over the world.

Eventually, however, every country in the world had little choice but to make the change. Great Britain held out until 1752; when they finally chose to adopt the Gregorian calendar, Wednesday, September 2, 1752 was followed by Thursday, September 14, 1752. Russia finally made the switch in 1918, and Greece followed in 1923.

And now, at long last, Microsoft is also switching to the Gregorian calendar. Hurrah!

Of course, you're probably thinking that, if Microsoft is just now switching to the Gregorian calendar, well, that must mean that Microsoft is a stodgy old company that couldn't possibly do anything useful or cool. Do we have anything to counter that belief? You bet we do: the CsSetupPermission cmdlets (Grant-CsSetupPermission, Revoke-CsSetupPermission, and Test-CsSetupPermission).

So what's so useful, and cool, about the CsSetupPermission cmdlets? Well, you might not be aware of this, but when you run the domain preparation phase of Lync Server setup, setup does not automatically add the permissions that enable members of the RTCUniversalServerAdmins group to run the Enable-CsTopology cmdlet. Does that matter? It might; after all, that means you must be a domain administrator in order to enable a topology. In some organizations, that might not matter: the domain administrator and the Lync Server administrator are one and the same.

In other organizations, however, it might matter: you might not want to give your Lync Server administrators domain admin rights. The solution? Run the Grant-CsSetupPermission cmdlet to give members of the RTCUniversalServerAdmins group the right to install and enable Lync Server.

As for actually running Grant-CsSetupPermission, well, that's not too terribly complicated; all you have to do is run a command similar to this:

Grant-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

As you can see, all you have to do is call Grant-CsSetupPermission along with the ComputerOU parameter; the parameter value for ComputerOU is simply the distinguished name of the Active Directory container where your Lync Server computer accounts are residing. You say that entering the distinguished name of the Active Directory container is too much trouble? That's fine; as long as that container is located with the domain root you can run a command like this one instead:

Grant-CsSetupPermission -ComputerOU "ou=CsServers"

We thought you might appreciate that.

We should probably point out two things before we go any further. First, setup permissions can only be granted to the RTCUniversalServerAdmins group; there's no way to grant these permissions to any other group. The moral of the story? If you want someone to be able to setup and enable Lync Server, you need to add them to the RTCUniversalServerAdmins group.

Second, you must be sure to run this cmdlet against each and every Active Directory container housing Lync Server computer accounts. What if your Lync Server accounts are in several different OUs? That's fine; you'll just have to run the command several different times:

Grant-CsSetupPermission -ComputerOU "ou=CsFrontEndServers,dc=litwareinc,dc=com"

Grant-CsSetupPermission -ComputerOU "ou=CsBackEndServers,dc=litwareinc,dc=com"

Grant-CsSetupPermission -ComputerOU "ou=CsEdgeServers,dc=litwareinc,dc=com"

Or, if you want to get fancy:

"ou=CsFrontEndServers,dc=litwareinc,dc=com", "ou=CsBackEndServers,dc=litwareinc,dc=com",

"ou=CsEdgeServers,dc=litwareinc,dc=com" | ForEach-Object {Grant-CsSetupPermission –ComputerOU $_}

If you later change your mind, and decide that you don't want the RTCUniversalServerAdmins group to have setup permissions after all, well, then just use the Revoke-CsSetupPermission cmdlet to revoke those permissions:

Revoke-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

Last, but definitely not least, you can verify the permission status for a container by using the Test-CsSetupPermission cmdlet:

Test-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

That command will return the value True if permissions have been granted to the specified container. And if permissions haven't been granted to the specified container? You got it: the command will return False.

Which, all in all, makes a lot of sense.

And there you have it. We hope you enjoy the weekend (which, we hasten to point out, would already be half over if we were still using the Julian calendar). Enjoy the Gregorian calendar, and we'll keep you posted on any other new developments here at Microsoft; for example, any day now we expect to announce that the sun does not revolve around the Earth. Stay tuned!

I now pronounce you

The brand new CMS store.

Congratulations!

Well, it's Monday, the day after yet another absolutely thrilling weekend here in the greater Seattle area. How thrilling was this past weekend? Well, on Sunday, the temperature topped out at a scorching 62 degrees Fahrenheit! How hot is that? Well, at one point, the author of today's haiku got so warm that he had to remove his mittens and his wool scarf. In July, mind you!

And if that wasn't enough excitement for a single weekend, on Saturday the author of today's haiku got to go to a wedding, his single favorite thing to do in the entire world (with the possible exception of getting to sit through a high school graduation). Or at least he thinks he went to a wedding on Saturday. The service drug on and on and on, and then all of a sudden the bride and groom walked out, without even a "Ladies and gentlemen may I present to you Mr. and Mrs. Ken Myer." (Which, of course, might be due in part to the fact that this wasn't the wedding of Mr. and Mrs. Ken Myer.) To be honest, it appeared as though the priest officiating at the ceremony decided to zip through most of that boring I-now-pronounce-you-man-and-wife stuff, the better to focus on his sermon on the joys and responsibilities of holy matrimony.

Either that or the bride and groom got bored, too, and decided to duck out and go get married at a Justice of the Peace.

Regardless, Saturday's wedding was every bit as exciting as you would expect a wedding to be, so exciting that the author of today's haiku go to thinking that maybe he should get married, too.

Which, surprisingly enough, turned out to be something his wife was strongly in favor of.

In all fairness, we should point out that there was one really good thing about this last wedding: for the first time in his life, the author of today's haiku had the perfect wedding gift. That's right, no waffle iron or Wal-Mart gift card, not this time around. Instead, he gave the happy new couple a gift that will keep on giving: The CsManagementServer cmdlets (Move-CsManagementServer and Set-CsManagementServer).

Now, we know what you're thinking: you call two Lync Server PowerShell cmdlets a good gift, especially when one of those cmdlets (Set-CsManagementServer) can only be used to change the replication port used by the Central Management store? How can you call that the perfect wedding gift?

Well, look at it this way: you're a newly-married couple, fresh out of college, looking for work, and hoping to someday start a family. In a situation like that, what's the last thing in the world you want to worry about? That's right: the last thing in the world you want to worry about is how in the world you could move your Central Management store to a new pool. The author of today's haiku didn't just give the happy couple a Lync Server PowerShell cmdlet; he gave them peace of mind.

How so? Well, suppose you have the Central Management service running on one of your Lync Server pools and now, for some reason, you need to transfer that service to a different pool. (For example, perhaps you need to decommission the pool where the service is currently running.) Can you move the Central Management service using a waffle iron or a Wal-Mart gift card? Not as far as we know. However, you can move that service by following these simple steps:

·         Verify that you have created the new Central Management store in the alternate pool. This is done by running the Install-CsDatabase cmdlet and using the CentralManagementDatabase parameter. If you are moving the Central Management store to a Standard Edition server, you also need to use local setup to run the Prepare Standard Edition server option. That configures firewall rules that will allow Windows PowerShell to remotely access the new Central Management store.

·         Verify that there is enough free disk space on the computer where Move-CsManagementServer is being run to accommodate the Central Management Server. Kind of a no-brainer, but it's a good thing to double-check, just to be on the safe side.

·         Make sure you are logged on to a Front End server in the pool where the Central Management store will be moved to. You have to run Move-CsManagementServer locally, and on a Front End Server. No exceptions.

·         Verify that you can successfully run the Enable-CsTopology cmdlet. If you can't, then the move will fail and you will no longer have a functioning Central Management store of any kind.

And yes, then you have real problems.

After you've completed those initial steps, you can then move the Central Management service by running this command:

Move-CsManagementServer

Believe it or not, that's all you have to do. Good luck finding a waffle iron that's as simple to use as that.

That's what you do when you have a fully functioning Central Management store that you simply want to transfer to a different pool. Now, suppose a meteor has hit your server room and destroyed your Central Management server. How can you "move" the Central Management service when that service no longer exists? Why, like this, of course:

Move-CsManagementServer -ConfigurationFileName "C:\CsConfiguration.xml" -LisConfigurationFileName "C:\CsLisConfiguration.xml" -Force

What's going on with this command? Well, in this command we're calling Move-CsManagementServer along with three parameters. The ConfigurationFileName parameter represents a backup copy of our Lync Server topology and configuration settings; this is a file you create by periodically running the Export-CsConfiguration cmdlet. In order to move the Central Management store you need to have this backup file, which means that you should get in the habit of periodically running Export-CsConfiguration in order to always have an up-to-date backup of your Lync Server settings. Likewise, the LisConfigurationFileName parameter is used to restore your Enhanced 9-1-1 settings. And where does that file come from? It comes from periodically running the Export-CsLisConfiguration cmdlet.

Last, but definitely not least, you also need to include the Force parameter. Why? Well, when you call Move-CsManagementServer, the cmdlet temporarily sets the Central Management store to read-only before the move takes place; that helps guard against data loss. In a disaster recovery scenario, however, the Central Management store cannot be marked as read-only; as you might recall, our Central Management store was obliterated by a meteor and no longer exists. The Force parameter instructs the cmdlet to move the Central Management store even though it has not been configured as read-only.

And that's why the CsManagementServer cmdlets are the perfect wedding gift. Granted, you can make waffles with any of these cmdlets but, then again, some things in life are more important than waffles.

Incidentally, if you're wondering why the author of today's haiku didn’t also give the happy couple a copy of the Get-CsManagementServer cmdlet, well, it's not because he's a cheapskate (although he is). Instead, it's because there's no such thing as the Get-CsManagementServer cmdlet. If you want information about your Central Management server and your Central Management store, use these two commands instead:

Get-CsService –CentralManagement

Get-CsService –CentralManagementDatabase

That should do it for now. For more gift ideas, please contact the good folks here at the Lync Server PowerShell blog. And be sure to check out our back-to-school specials: buy one copy of the CsClientVersionPolicyRule cmdlets, get a second copy absolutely free! (You pay only shipping and handling.) Needless to say, you'll be hard-pressed to find a better price than that anywhere.

OK, maybe on Amazon. But other than that ….

We'll have fun, fun, fun,

Till daddy takes our Hosting

Provider away.

In case you were wondering (and we assume that you were wondering) yesterday something different happened to the author of today's haiku: he actually had some fun!

OK, good point: seeing as how he works at Microsoft and gets to deal with the Microsoft bureaucracy day-in and day-out, well, obviously he has fun every day. But yesterday he managed to have even more fun than usual.

Yesterday the author of today's haiku went for a bike ride after work. His intrepid party started down one bike trail, only to discover that the trail is closed for maintenance and upgrading. For those of you keeping score, that's now the third major bike trail the author of today's haiku has tried to go down, only to discover that the trail is closed for the summer.

At any rate, having been turned away from yet another bike trail, the author and his wife next set their sights on riding up Mt. Rainier, elevation 14,411 feet. Admittedly, it's possible that it wasn't really Mt. Rainier they were riding up; it just seemed that way as they continued to slog – slowly – up a long, reasonably steep hill that never seemed to end. And hey, if that isn't fun, we'd like to know what is!

Oh, wait: now that we think about it, going up wasn't the fun part: coming down that hill was the fun part. Fortunately for everyone involved, there was essentially no traffic on the trail at that time, which meant that the author and his wife were free to just let 'er rip and go zipping down the mountain. That was fun.

At any rate, after all the fun and excitement he had yesterday, you might think coming in to work this morning would be a letdown. Ha! Barreling down a mountainside on a bike is fun, but that's nothing compared to writing a haiku about the CsHostingProvider cmdlets (Disable-CsHostingProvider, Enable-CsHostingProvider, Get-CsHostingProvider, New-CsHostingProvider, Remove-CsHostingProvider, and Set-CsHostingProvider).

So what exactly are the CsHostingProvider cmdlets used for and, while we're on the subject, what exactly is a hosting provider? Well, a hosting provider is simply an organization that provides SIP communication services for other organizations; for example, Fabrikam Hosters might host users from Contoso, Northwind Traders, and Wingtip Toys. That's nice, but the cool thing about hosting providers is this: when you establish a federation relationship with a hosting provider you establish federation with all the organizations hosted by that provider. For example, if you federate with Fabrikam your users will be able to exchange instant messages and presence information with users from Contoso, Northwind Traders, and Wingtip Toys.

You can see why we find the CsHostingProvider cmdlets to be so much more fun than bike riding.

Hosting providers are also used in split domain scenarios. What's a split domain scenario? Well, for our purposes, a split domain scenario is simply one in which some of your Lync Server 2010 users have accounts hosted on-premises (that is, hosted on your local implementation of Lync Server) while other users have their accounts maintained off-premises by the third-party hosting provider. Federating with the hosting provider enables on-premises and off-premises users to communicate with one another. The primary example of that? You got it: Office 365.

Now, admittedly, the whole idea of hosting providers and split domain scenarios and all those other good things are still somewhat in their infancy; it's going to take a while before the industry begins to take advantages of these new capabilities built into Microsoft Lync Server 2010. In the meantime, though, you can definitely use the New-CsHostingProvider cmdlet to set up federation with Office 365. How? Well, after enabling federation, period (see Haiku #83 for more information), you can connect to Office 365 by running the following PowerShell command:

New-CsHostingProvider –Identity LyncOnline –ProxyFqdn sipfed.online.lync.com –Enabled $True

Yep, that's it: you call New-CsHostingProvider, you specify an identity and a proxy FQDN (the fully qualified domain name of the proxy server used by the hosting provider), and set the Enabled property to True. It's as easy as riding a bike down a hill.

Except you don't have to slam on your brakes at the bottom when you realize there's a cross street filled with speeding cars down there.

Ah, good question: what are the other 16 million CsHostingProvider cmdlets for? Well, the Set-CsHostingProvider cmdlet lets you modify the property values of an existing provider. However, there's one very important caveat here: you can't modify the ProxyFqdn for a provider. Suppose LyncOnline decides to change its proxy FQDN to newsipfed.online.lync.com. How do you change the proxy FQDN for LyncOnline? You don't. Instead, you'll have to remove the old provider and create a new one, like so:

Remove-CsHostingProvider –Identity LyncOnline

New-CsHostingProvider –Identity LyncOnline –ProxyFqdn newsipfed.online.lync.com –Enabled $True

Why do you have to do it that way? Beats us; you just do. But, on the bright side, now you know what the Remove-CsHostingProvider cmdlet is for.

You probably also know what the Get-CsHostingProvider cmdlet is for, too: it lets you retrieve information about the hosting providers configured for use in your organization. For example, this command returns information about all your hosting providers:

Get-CsHostingProvider

Not impressed? Then how about this command, which lets you know which hosting providers have been created, but are not currently enabled:

Get-CsHostingProvider | Where-Object {$_.Enabled -eq $False}

We thought you'd like that one. And this command shows you which hosting providers (if any) are used to host Microsoft Lync users:

Get-CsHostingProvider | Where-Object {$_.HostsOCSUsers -eq $True}

OK. Then what are Disable-CsHostingProvider and Enable-CsHostingProvider used for? Well, obviously you can use these cmdlets to disable/enable a hosting provider. For example:

Disable-CsHostingProvider –Identity LyncOnline

Enable-CsHostingProvider –Identity LyncOnline

What's wrong with that? Nothing. However, we should point out that you can do the same exact thing by using the Set-CsHostingProvider cmdlet instead:

Set-CsHostingProvider –Identity LyncOnline –Enabled $True

Set-CsHostingProvider –Identity LyncOnline –Enabled $False

So does that mean we have two different ways to enable/disable a hosting provider, yet no way to change the proxy FQDN of a hosting provider? Yes, that's exactly what this means. But take heart: there's a bright side to having things set up this way.

We just don't have any idea what that bright side might be.

But that's a very minor quibble, and nothing to worry about. The important thing is that you've got your CsHostingProvider cmdlets, you’ve got the wind in your hair, and you're having the most fun you've ever had in your life.

See you tomorrow.

Mom says that we have

To tell everyone about

Policy profiles.

We thought we'd try something a little different today: today we're going to randomly select one of the many emails sent in by our devoted readers and see if we can answer the reader's question by writing a haiku; this is our way of trying to give everyone what they really want. Let's see what we have here:

"The Lync Server PowerShell blog is a travesty. This is by far the worst example of – "

Um, never mind. As it turns out, that mail was sent by a family member, and it wouldn't seem sporting (or ethical) to use something sent by a family member.

Let's try another one:

"I cannot believe that this is what Microsoft pays you to do. As far as I'm concerned – "

Hmmm …. Apparently Steve Ballmer isn't the soft-spoken guy we always assumed he was. OK, let's try a – whoa. Never mind about that one.

OK, by now it should be pretty obvious what everyone really wants: everyone really wants us to address the CsNetworkBandwidthPolicyProfile cmdlets!

So what exactly is a network bandwidth policy profile, and why do we need cmdlets to manage these policy profiles? Good question. As you probably know by now, in Lync Server 2010 Microsoft introduced Call Admission Control, the ability to place bandwidth usage restrictions on all (or some) of your network connections. We won't go into all the whys and wherefores of Call Admission Control today; if you need that sort of background information, take a look at the article Call Admission Control in Lync Server.

What we will tell you is that bandwidth policies are used to determine the amount of bandwidth that can be used for audio and/or video transmissions. These policies let you place two different kinds of restrictions on bandwidth use: you can limit the total bandwidth allocated for all audio/video sessions, and you can limit the amount of bandwidth allocated for a single session. For example, you might decide that an individual audio session will be allowed 100 kilobits per seconds (kbps) of bandwidth use, while a grand total of 1000 kbps will be allocated for all the current audio sessions. What does that mean? Well, suppose you have 10 audio sessions going on right now, each using the allotted 100 kbps. 10 audio sessions times 100 kbps equals 1000 kbps, the total amount of bandwidth allocated for audio. Suppose that user no. 11 now tries to make an audio call. Is that call going to go through? Nope; there's no bandwidth available for audio sessions. User no. 11 is going to have to wait for an existing session to end before he or she can place the call.

Make sense? We thought it would.

Bandwidth policies are assigned to your network sites; for example, this command assigns the policy LowBWLimits to the Vancouver site:

Set-CsNetworkSite -Identity Vancouver - BWPolicyProfileID LowBWLimits

And how did we create that bandwidth policy in the first place? Like this:

New-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2000 -AudioBWSessionLimit 200 -VideoBWLimit 1400 -VideoBWSessionLimit 500

As you can see, we simply called the New-CsNetworkBandwidthPolicyProfile cmdlet, gave our new policy an identity (LowBWLimits), and then assigned values to the individual session and total session parameters for both audio and video. If we now run the command Get-CsNetworkBandwidthPolicyProfile, we should see the following:

Identity          : LowBWLimits

BWPolicy          : {BWLimit=2000;BWSessionLimit=200;BWPolicyModality=Audio,

                    BWLimit=1400;BWSessionLimit=500;BWPolicyModality=Video}

BWPolicyProfileID : LowBWLimits

Description       :

Actually, that is kind of hard to read, isn't it? OK, try this command instead:

Get-CsNetworkBandwidthPolicyProfile | Select-Object –ExpandProperty BWPolicy

That will give you output that looks like this:

BWLimit          : 2000

BWSessionLimit   : 200

BWPolicyModality : Audio

BWLimit          : 1400

BWSessionLimit   : 500

BWPolicyModality : Video

Much better. Right, Mom?

That's actually pretty straightforward. Unfortunately, it now starts to get a little bit tricky. Why? Well, suppose you want to change the audio bandwidth to 2200, but want to leave everything else exactly as-is. Logically enough, you'd probably run this command:

Set-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2200

Is that going to work? Well, it depends on your definition of "work." Here's what your bandwidth policy profile will look like now:

Identity          : LowBWLimits

BWPolicy          : {BWLimit=2200;BWSessionLimit=175;BWPolicyModality=Audio}

BWPolicyProfileID : LowBWLimits

Description       :

Uh-oh. As you can see, the audio bandwidth limit got bumped up to 2200, just like we wanted. However, the audio session limit got switched to 175, and the video settings disappeared altogether. What's the deal here?

Well, the deal here is that the Set-CsNetworkBandwidthPolicyProfile cmdlet always replaces the entire policy with whatever parameters you gave it. We gave Set-CsNetworkBandwidthPolicyProfile just one parameter: AudioBWLimit. Therefore, it essentially created a brand-new policy, one with a limit of 2200 (as we asked) and a session limit of 175 (the default value, which is used because we didn't specify a session limit). And what happened to the video settings? Well, we didn't include any video settings, so Set-CsNetworkBandwidthPolicyProfile … helpfully … removed all those settings from the policy.

Thanks, Set-CsNetworkBandwidthPolicyProfile.

So is there a way to work around that? To the best of our knowledge, no, there isn't. If you want to make one little change to an existing policy you have to be sure to also include all the settings and values that you don't want changed:

Set-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2200 -AudioBWSessionLimit 200 -VideoBWLimit 1400 -VideoBWSessionLimit 500

Is that a hassle? Yes. But, then again, you probably won't be changing your bandwidth policy profiles very often, so ….

If you decide you don't need a bandwidth policy profile after all, you can simply delete that profile by using Remove-CsNetworkBandwidthPolicyProfile:

Remove-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits

And if you have a desire to do something really weird, try these commands:

$x = Get-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits

$x.BWPolicy.RemoveAt(1)

$x.BWPolicy.RemoveAt(0)

Set-CsNetworkBandwidthPolicyProfile –Instance $x

What do those commands do? Well, after creating an object reference ($x) to the policy profile LowBWLimits, they then use the RemoveAt method to remove the second policy in the profile (the video settings) and then the first policy in the profile (the audio settings).

That will give you an "empty" policy profile:

Identity          : LowBWLimits

BWPolicy          : {}

BWPolicyProfileID : LowBWLimits

Description       :

Why would you ever want to do that? We have no idea; we just wanted to show off for Mom. Mom, did you see what we did? Mom? Mom, are you watching?

Dang.

Oh, one other note: we also recommend that you use the CsNetworkBandwidthPolicyProfile cmdlets instead of the New-CsNetworkBWPolicy cmdlet. You can pretty much do the same thing with either the CsNetworkBandwidthPolicyProfile cmdlets or the New-CsNetworkBWPolicy cmdlet. But, for the most part, the CsNetworkBandwidthPolicyProfile cmdlets are much easier to work with. (And, besides, the New-CsNetworkBWPolicy cmdlet is really intended for future use, when additional types of bandwidth policies might be available to you.)

That's pretty much all we have for today. A special thanks to Mom, Steve Ballmer, and everyone else for your words of … encouragement …. Keep those cards and letters coming in!