Smile! After all, you

(And Hugh) can run the User

Server cmdlets.

So it turns out that there was a monastery in this one town where something weird happened and the monks all went crazy; as a result, they started growing these man-eating flowers that began terrorizing the town. The townspeople tried everything they could to stop these ferocious flowers, but nothing they tried worked: the flowers just kept eating all the town folk, one-by-one. Just when things looked hopeless, however, a man named Hugh approached the monks. "Leave our little village right now," he commanded, and the monks immediately grabbed all their man-eating flowers and took off for parts unknown, never to be heard from again.

The moral of the story? Only Hugh can prevent florist friars.

Ha! Get it? You know, because Smokey the Bear always says that only you can prevent forest fires, except that in this case we're saying that only Hugh can prevent – well, never mind. We apologize, but, sadly, that's pretty much the only joke that the author of today's haiku knows.

As you might have guessed it's already been one of those days: despite having been to work for over two hours now, the author of today's haiku hasn't managed to get any work done whatsoever.

Instead of working, the author of today's haiku has spent his morning trying to help people who are experiencing issues with, or have questions about, Lync Server. Not necessarily Lync Server PowerShell, mind you, but Lync Server in general. Apparently anyone who runs into a problem with Lync Server thinks, "Who would be the best possible person to try and answer this question for me? Oh, I know: what about that guy who writes haikus?"

When in doubt, go with the obvious choice, right?

At any rate, the author of today's haiku actually enjoys trying to help people; he's just not always very good at helping people. If someone has a question about Lync Server PowerShell he can usually help them. However, sometimes people have questions like this:

"I'm trying to configure a 9 double camulator load balancer to talk to a 64-bit hotzenjammer in server emulation mode, but I don't want to enable ABC-QDR 5 unless I absolutely have to. (Our company policy is to only use thread-nine compliant protocols.) Am I going to have a problem if I allow RDPPP traffic throw my half-duplexing firewall?"

If he was a betting man, the author of today's haiku would be willing to bet that yes, you definitely are going to have a problem in that situation. But because he isn't a betting man, and has no idea what that question even means, he ends up trying to track down someone on the product team who can help, and then serves as a go-between between the person who asked the question and that someone on the product team who can answer the question.

And that's pretty much how the author of today's haiku has spent his entire morning, which explains why he thought it would be a good idea to lighten things up by telling a funny joke.

And yes, as soon as actually learns a funny joke, he'll do just that.

In the meantime, another good way to lighten the mood is to talk about the Set-CsUserServer cmdlet. The Set-CsUserServer cmdlet is used to – oh, you guessed it, didn't you? Well, you're right: the Set-UserServer cmdlet is used to manage the User Servers employed by Microsoft Lync Server 2010. If you aren't familiar with User Servers, this server role is a sort of catch-all component that performs a number of useful management tasks. For example, User Servers provide presence information; they help manage conferences (through the Focus and Focus Factory); they assist with user authorization and user-level routing; and they serve as the primary interface to the back-end database.

You say that's not enough? OK; User Servers also assist with provisioning user accounts.

We thought you'd be impressed by that.

At any rate, the Set-CsUserServer cmdlet lets you manage three key properties of your User Servers:

·         ConferenceServer – Obviously this is the Conferencing server associated with the User Services pool. To set this, just specify the service Identity of the Conferencing server; for example:

-ConferenceServer "ConferenceServer:atl-cs-001.litwareinc.com"

·         McuFactorySipPort – The port used for connecting to the Focus Factory (McuFactory). The Focus Factory allocates media control units (MCUs) in order to add specific media types such as audio to conferences.

·         UserDatabase – Another obvious one: the user database associated with the User Services pool. Again, just specify the service Identity of the database; for example:

-UserDatabase "UserDatabase:atl-cs-001.litwareinc.com"

And that's really it. How do you actually use the Set-CsUserServer cmdlet to change one of these property values? Well, here's one example:

Set-CsUserServer -Identity "UserServer:atl-cs-001.litwareinc.com" -McuFactorySipPort 445

And here's another:

Set-CsUserServer -Identity "UserServer:atl-cs-001.litwareinc.com" –ConferenceServer "ConferenceServer:atl-cs-001.litwareinc.com"

That's pretty much all you have to do. And, for that matter, pretty much all that you can do.

Just a couple quick notes about the Set-CsUserServer cmdlet before we call it a day. First, you might have noticed that this is the only cmdlet in the CsUserServer family: there is no Get-CsUserServer cmdlet. So how do you get information about your User Servers? Well, like many of the service/server roles in Lync Server, you need to use the Get-CsService cmdlet to retrieve information. For example, this command returns information about all your User Servers:

Get-CsService –UserServer

To get back information for a specific server, use a command like this one, which specifies the server Identity:

Get-CsService –Identity "UserServer:atl-cs-001.litwareinc.com"

And, in keeping with our light-hearted and carefree mood, here's a command that finds all the User Servers that have their MCU Focus Factory SIP port set to something other than the default port 444:

Get-CsService –UserServer | Where-Object {$_.McuFactorySipPort –ne 444}

Here's another thing to keep in mind: you can't pipe information directly to the Set-CsUserServer cmdlet. For example, suppose you want to set all your Focus Factory SIP ports to 445; with that in mind, you try running this command:

Get-CsService –UserServer | Set-CsUserServer -McuFactorySipPort 445

Is that going to work? Well, not exactly:

Set-CsUserServer : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.

So what does that mean? That means that you need to use a command like this one, which pipes the data to the ForEach-Object cmdlet instead of the Set-CsUserServer cmdlet:

Get-CsService -UserServer | ForEach-Object {Set-CsUserServer -Identity $_.Identity -McuFactorySipPort 445}

As you can see, that's no big deal. It's just something you need to be aware of.

Is there anything else you need to be aware of? Just this: a group of chess players were standing in the lobby of a hotel, bragging about all their recent victories and accomplishments. After a few minutes the hotel manager came out and told them they'd have to leave. "But why?" asked one of the chess enthusiasts. "I'll tell you why," said the hotel manager. "Because I don't like chess nuts boasting in an open foyer."

You see, because of the Christmas song, the one about chestnuts roasting on an– well, never mind. Here's something that is guaranteed to lighten your mood and bring a smile to your face: that's all we have for today. See you tomorrow.

Somewhere, a dog howled.

Would you stop if we explain

Response Group settings?

It's a conspiracy, that's what it is.

That's right: a conspiracy. As it turns out, the entire world – or at least the animal world – is out to get the author of today's haiku.

For three weeks the author of today's haiku experienced the … joy … of cat-sitting a cat. To be honest, the cat was actually a pretty decent little cat, except for her somewhat-annoying habit getting up at 4:30 every morning and, in the process, waking up everyone else in the house as well. The cat has now been returned to its rightful owners, but the conspiracy lives on. Now the dogs have gotten involved.

As it turns out, the people who live next door to the author of today's haiku have three gigantic dogs. (Or maybe it's two gigantic dogs and a medium-sized hippopotamus; to be honest, it's kind of hard to tell.) For the most part these dogs seem pretty laid-back, and pretty much oblivious to the world. For example, one afternoon the three dogs were outside when the author of today's haiku went out to work in the yard. He was working right in front of the dogs for about half an hour or so before one of them suddenly realized, "Oh, shoot, there's someone out here with us. I think I'm supposed to bark or something!" and immediately started barking at him. But then, having done his duty for 10 seconds or so, he immediately laid down and went to sleep.

Which, come to think of it, sounds an awful lot like the typical work day for the author of today's haiku.

At any rate, the people next door have been out of town for a few days, and they left the dogs in the care of a dog sitter. However, this isn't a live-in dog sitter; instead, it's just someone who comes by periodically to check in on the dogs. Unfortunately, the dog sitter doesn't come by at 2:00 in the morning, or 5:00 in the morning, which turns out to be right about the time these three gigantic dogs (or two gigantic dogs and a medium-sized hippopotamus) start barking.

And then continue barking for a good half hour to 45 minutes.

Wait, scratch the word good from that last sentence: And then continue barking for a half hour to 45 minutes.

So what did the author of today's haiku do to deserve all of this? Well, he's not sure. If the people in the world organized a conspiracy against him well, that he could understand: he's probably offended several million people this year alone. But animals? What did he ever do to animals?

But it doesn't really matter who's at fault here. All that really matters is that the author of today's haiku is willing to make a deal: if the dogs next door are willing to stop barking, then he's willing to explain to them what the CsRgsConfiguration cmdlets are for.

As you might have guessed, the CsRgsConfiguration cmdlets provide a way for you to manage configuration settings for each instance of the Response Group application running in your organization. As it turns out, that only means three settings you need to worry about:

·         AgentRingbackGracePeriod – If an agent declines a call, the AgentRingbackGracePeriod represents the amount of time (in seconds) that can elapse before the call returns to the same agent.

·         DefaulltMusicOnHoldFile – The music that, by default, will be played any time a caller is placed on hold.

·         DisableCallContext – Indicates whether each agent is able to see the call context (information such as caller wait time as well as workflow questions and answers) whenever a call is received.

So does that mean that the CsRgsConfiguration cmdlets are really easy and straightforward to use? Yes it does.

Except for the tricky parts.

Let's start with the Get-CsRgsConfiguration cmdlet. As you probably know, you can have multiple instances of the Response Group application running in your organization; for example, you could have one instance for each of your Application servers. With that in mind, you might think you could use a command like this to return information about each of those instances:

Get-CsRgsConfiguration

Unfortunately, however, that command won't return anything; instead, you'll be prompted to enter the instance Identity. In fact, you always have to specify an Identity when using Get-CsRgsConfiguration. To return information about a single instance, you need to use a command like this one:

Get-CsRgsConfiguration -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com"

And what if you want to return information about all your instances? Well, that's fine; you just have to use this approach:

Get-CsService -ApplicationServer | Where-Object {$_.Applications -contains "urn:application:RGS"} | ForEach-Object {Get-CsRgsConfiguration -Identity $_.Identity}

Please don't start barking; we're going to explain how this command works. As you can see, we start out by using the Get-CsService cmdlet to return a collection of all our Application servers. (Why? Because the Response Group application can only be run on an Application server.) We then pipe this collection to the Where-Object cmdlet, which looks for any Application servers that have an application name urn:application:RGS. That, needless to say, means that the Application server is running the Response Group application. Any relevant Application servers are then piped to the ForEach-Object cmdlet, which – at long last – uses Get-CsRgsConfiguration to return setting information for each instance of the Response Group application.

Whew!

You have to take a similar approach when using the Set-CsRgsConfiguration cmdlet. For example, suppose you want to set the ringback period to 30 seconds for a particular instance of the Response Group application. That's reasonably easy:

Set-CsRgsConfiguration -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -AgentRingbackGracePeriod 30

So what happens if you want to set the ringback period for all your response Group instances to 30 seconds? You got it: you'll have to first look for all the Application servers running the urn:application:RGS application. In other words:

Get-CsService -ApplicationServer | Where-Object {$_.Applications -contains "urn:application:RGS"} | ForEach-Object {Set-CsRgsConfiguration -Identity $_.Identity -AgentRingbackGracePeriod 30}

Is that the easiest thing in the world to do? Well, no, not really. But it works. And, fortunately, you won't need to modify your Response Group applications on a daily basis anyway.

We hear some growling out there, but don't worry: we haven't forgotten about the Move-CsRgsConfiguration cmdlet. The Move-CsRgsConfiguration cmdlet has only one purpose in life: it moves your Response Group application from Office Communications Server 2007 R2 to Microsoft Lync Server 2010. If you aren't running the Response Group application of Office Communications Server 2007 R2, or if you aren't ready to move that application to Lync Server, well, then you don't have much use for the Move-CsRgsConfiguration cmdlet.

If you do need to make this migration, then the first thing you have to do is install the Windows Management Instrumentation (WMI) Backward Compatibility interfaces package; this application is installed by running OCSWMIBC.msi. (The file OCSWMIBC.msi can be found in the installation package in the Setup folder.) If you don't do that, migration will fail and you'll get this error message:

Move-CsRgsConfiguration : WMI provider is not installed. Install it using OCSWMIBC installer.

Assuming that you have installed the Backward Compatibility interfaces package, you can migrate the response Group application using one simple command, where the Source parameter specifies the 2007 R2 pool where the Response Group application is currently installed and the Destination parameter represents the Lync Server pool where the application is to be moved to:

Move-CsRgsConfiguration -Source atl-ocsrgs-001.litwareinc.com -Destination redmond-lyncrgs-001.litwareinc.com

Move-CsRgsConfiguration will move all the configuration settings, audio files, and contact objects from Office Communications Server 2007 R2 to Lync Server. After that, all calls to a Response Group phone number will be handled by Lync Server, meaning that calls will no longer be handled by the Office Communications Server 2007 R2 version of the service.

That's all we have time for today. For all the cats, dogs, hippopotamuses, howler monkeys, and Tiger Pistol Shrimp who are reading today's haiku, well, the author has done his part. Truce?

If I call, how do

I know you will be there? Test

Dial-in conferencing.

So last night the author of today's haiku had the chance of a lifetime, and he let it slip through his fingers.

Which, come to think of it, is pretty much the story of his life, isn't it?

At any rate, when the author of today's haiku went to the gym last night he started to climb on to the StairMaster and was practically thrown off when the machine started up at a surprisingly high rate of speed. (Yes, usually the stairs start moving a little any time you climb on, but nowhere near as fast as those stairs were moving last night.) He tried again, almost fell off again, then tried a third time and managed to get up on the machine. At that point he pressed the Stop button thinking he would stop and reset the crazy thing. The StairMaster refused to stop; the stairs just kept flying along. Not only that, but at that point the author of today's haiku realized that, instead of marking time second-by-second, the machine was marking time minute-by-minute. That was weird. On the other hand, that also meant that if he was willing to play along, he could complete his 45-minute workout in just 45 seconds. Leaving plenty of time for him to go home, eat a couple pieces of cheesecake, and lie around watching Baseball Tonight.

Unfortunately, though, doing a 45-minute workout in 45 seconds would have been cheating, and while the author of today's haiku currently holds the world's record for most flaws in a single human being, he usually doesn't cheat. (As we all know, you can't do a workout in just 45 seconds; a real workout requires at least 4 minutes to complete.) Being too honest for his own good, he went over to a different StairMaster and put in a full 45 minutes on the stairs.

And then went home to eat a couple pieces of cheesecake, and watch Baseball Tonight.

As you might expect, his only regret is that the broken time clock had to happen at the gym rather than at work. If that had happened at work then, when someone asked if he put in 45 minutes of Project X like he promised he would, he could truthfully say, "Hey, just look at the time clock. It says 45 minutes, doesn't it?"

The important thing is that the author of today's haiku learned that there are no shortcuts in life: if you want something done, and want that something done right, then you need to put in the required time and effort. And then, he came in to work this morning, started up the Lync Server Management Shell, and realized that Lync Server PowerShell offers nothing but shortcuts.

What kind of shortcuts, you ask? Well, take dial-in conferencing, to name one. How are you supposed to know if dial-in conferencing is working in your organization? Well, what you could do is create and start a new conference, dutifully write down the dial-in conferencing access number and the meeting code, haul out your cell phone, dial in to the conference, enter the meeting code and your PIN number, and verify that you were able to join the conference. We estimated that would take you approximately 45 minutes.

Or, alternatively, you could simply run the following Lync Server PowerShell command, which we estimate would take approximately 45 seconds:

Test-CsDialInConferencing –TargetFqdn atl-cs-001.litwareinc.com

That's all you have to do, assuming that: 1) you've set up a couple of health monitoring test accounts for the Registrar pool atl-cs-001.litwareinc.com; and, 2) you have at least one dial-in conferencing access number configured for that pool. If all of that is true, then the Test-CsDialInConferencing cmdlet will attempt to log on the Lync Server using one of your health monitoring test accounts. If logon is successful, the system will then try to make a call to the first dial-in conferencing access number configured for the specified pool. If the call is established, the cmdlet will join the test user to the "conference," exit the conference, and terminate the call. Test-CsDialInConferencing will then proceed to try the same procedure with the next dial-in conferencing access number configured for the pool.

But what if you don't have test accounts configured for a pool, or what if you need to determine if a specific user can use dial-in conferencing (e.g., someone who just called in and complained that they were unable to use dial-in conferencing)? No problem. All you need to do us include the user's logon credentials and SIP address in the command:

$cred1 = Get-Credential "litwareinc\pilar"

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

If all goes well, you'll get back a report that looks like this:

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Success

Latency    : 00:00:00

Error      :

Diagnosis  :

And if all doesn't go well? Well, in that case you'll get back at least some information concerning the problem that Test-CsDialInConferencing ran into. Here's the report we got back when we ran this test using an invalid dial-in access number:

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Failure

Latency    : 00:00:00

Error      : 404, Not Found

Diagnosis  : ErrorCode=33034,Source=atl-cs-001.litwareinc.com.Reason=Ms-Application-Aor header is not valid. Microsoft.Rtc.Signaling.DiagnosticHeader

OK, granted, that might not be the most intuitive error message and diagnosis you've ever received. Because of that, you might want to include the Verbose parameter any time you run the Test-CsDialInConferencing cmdlet (or any of the Test-Cs cmdlets, for that matter):

Test-CsDialInConferencing –TargetFqdn atl-cs-001.litwareinc.com -Verbose

That command will give you a blow-by-blow account of everything the cmdlet does; for example:

VERBOSE: 'Register' activity started.

Sending Registration request:

  Target Fqdn      = atl-cs-001.litwareinc.com

  User Sip Address = sip:kmyer@litwareinc.com

  Registrar Port = 5061

Auth Type 'Trusted' is selected.

'Register' activity completed in '0.094552' secs.

Etc., etc.

And there you have it. The most important thing to take away from today's column is that – oops, sorry but, according to the time clock, our 45 minutes is up. See you tomorrow!

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?

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.

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.

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

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.

Is there a problem?

Then maybe diagnostic

Headers should be on.

Hey, everyone. Today marks the 139^th in our series of daily Lync Server PowerShell haikus and in honor of the occasion (and because we couldn't think of anything else to write about) we decided to look up some interesting facts about the number 139. Here's what we found:

·         139 is the natural number following 138 and preceding 140.

OK, well, that's kind of interesting, though not totally unexpected. Let's see what else we can dig up:

·         One hundred [and] thirty-nine is the 34th prime number, so it is divisible only by itself and 1. It is a twin prime with 137. Because 141 is a semiprime, 139 is a Chen prime. 139 is the smallest prime before a prime gap of length 10

Hmmm …. Well, obviously we knew that 139 was a Chen prime (duh!), but we weren't aware that 141 was a semiprime. So that's pretty cool, right? Oh, and how about this:

·         [139] is the smallest factor of 64079, the smallest composite Lucas number with a prime index. It is also the smallest factor of the first nine terms of the Euclid–Mullin sequence, making it the tenth term.

We have to admit that we were a little skeptical about that: since when is 64079 a Lucas number in the first place? But it turns out that 64709 is a Lucas number:

2, 1, 3, 4, 7, 11, 18, 29, 47, 76, 123, 199, 322, 521, 843, 1364, 2207, 3571, 5778, 9349, 15127, 24476, 39603, 64079, 103682, 167761, 271443, 439204, 710647, 1149851, 1860498, 3010349, 4870847, 7881196, 12752043, 20633239, 33385282

We stand corrected.

Other than that, well, 139 happens to be the atomic number of Untriennium, something that would be totally fascinating if Untriennium actually existed. (It remains a hypothetical and as-yet undiscovered element. Much like the author's bank account balance.)

Oh, and speaking of hypothetical elements, in researching this column, the author of today's haiku stumbled upon a Web site where you can ask homework questions like this one:

"Consider the hypothetical elements X and Y. Suppose the enthalpy of formation for the compound XY is 336 kJ/mol, the bond energy for X2 is 414 kJ/mol, and the bond energy for Y2 is 159 kJ/mol. Estimate the XY bond energy in units of kJ/mol."

OK, yes, that question is way too easy, but you get the idea. At any rate, the point is that you post the question and then indicate how much you're willing to pay for the answer (a minimum of $5). Experts (or at least so-called experts) in the field will read your question and, if you're willing to pay enough, will answer it for you.

Interesting, huh?

At any rate, we could go on and on and on about the number 139, except for one thing: we're more bored with this than you are. Therefore, let's switch gears and talk about something truly exciting: the CsDiagnosticHeaderConfiguration cmdlets!

So what's so interesting about the CsDiagnosticHeaderConfiguration cmdlets? Well, for one thing Remove-CsDiagnosticHeaderConfiguration has 38 characters in its name, which is sort of, kind of, vaguely related to that whole 139 thing we tried to use earlier. Perhaps slightly more important than that (hey, we said perhaps) is this: Lync Server can be configured so that each SIP message sent in your organization includes an ms-diagnostic header. This header contains information that might be useful in troubleshooting connection issues or in reporting errors. For example, the diagnostic header might contain error codes that enable the client application to take a predetermined course of action should a problem arise.

Useful, right? Yes. On the other hand, diagnostic headers do contain some information (such as the FQDNs of all your SIP servers) that maybe you would just as soon people in the outside world don't have access to. For example, a diagnostic header might look something like this (emphasis added):

Warning: 309 lcs.microsoft.com "Message contents not allowed by policy"

ms-diagnostics: 16002;reason="Message contents not allowed by policy";source="atl-cs-001.litwareinc.com";appName="IIMFilter" Server: IIMFilter/4.0.0.0

This is where the CsDiagnosticHeaderConfiguration cmdlets prove to be useful. With these cmdlets, you can decide whether or not you want these diagnostic headers included on messages sent to the following users:

Users on external networks. If you'd rather not have users outside your firewall have access to these diagnostic headers, then leave the SendToExternalNetworks property set to its default value of False. If you're OK with sending these headers to people outside the firewall then set SendToExternalNetworks to True. For example:

Set-CsDiagnosticHeaderConfiguration –Identity global –SendToExternalNetworks $True

Unauthenticated users. By default, diagnostic headers are not sent to users unless those users have logged on to, and been unauthenticated by, Lync Server.  You say you'd prefer that these users get diagnostic headers? No problem; just set the SendToOutsideUnauthenticatedUsers property to True:

Set-CsDiagnosticHeaderConfiguration –Identity global –SendToOutsideUnauthenticatedUsers $True

If you're wondering what else you can do with the CsDiagnosticHeaderConfiguration cmdlets, well, that's really about it: there are only two properties to manage. As you might expect, you can use the New-CsDiagnosticHeaderConfiguration cmdlet to create new diagnostic header settings at the site or the service scope (Edge Servers or Registrars only). Remove-CsDiagnosticHeaderConfiguration provides a way to remove any such settings you create at the site or the service scope, and Get-CsDiagnosticHeaderConfiguration lets you return information about your diagnostic header settings. For example, do you have any settings that allow you to send headers to external users? This command will tell you:

Get-CsDiagnosticHeaderConfiguration | Where-Object {$_.SendToExternalNetworks -eq $True}

What about sending headers to unauthenticated users? That's an easy one; that's what this command is for:

Get-CsDiagnosticHeaderConfiguration | Where-Object {$_.SendToOutsideUnauthenticatedUsers -eq $True}

And, of course, the pièce de résistance: a command that lets you know if you have settings that allow you to send headers to external users or unauthenticated users (or both). You know, a command like this one:

Get-CsDiagnosticHeaderConfiguration | Where-Object {$_.SendToExternalNetworks -eq $True -or $_.SendToOutsideUnauthenticatedUsers -eq $True}

Granted, some people won't find that half as exciting as the fact that 139 Juewa is a large and dark Main belt asteroid discovered in 1874. But we think it's pretty cool.

That's all for today. See you on Monday, when we explore number 140, an "… abundant number and a harmonic divisor number. It is the sum of the squares of the first seven integers, which makes it a square pyramidal number, and in base 10 it is divisible by the sum of its digits, which makes it a Harshad number."

OK, good point. In that case, we'll see most of you on Tuesday.