Nine million turkeys

Can be wrong: Make use of the

TimeRange cmdlet.

Yesterday evening, when the author of today's haiku got out of his car, he glanced up at the sky and had a raindrop fall into his half-opened mouth. (Yes, those of us who work here at Microsoft do lead interesting lives, don't we?)

To be honest, that wasn't a big deal, nor was it the worst thing he ever had fall into his mouth (for now we'll ignore the okra that he … willingly … ate). A few years ago, he was riding his bike, mouth half-opened again, when a bee flew through the opening and stung him on the inside of the mouth. That was not a whole heck of a lot of fun although, truth be told, it was still better than the okra.

At any rate, when the raindrop fell into his mouth, the first thing the author of today's haiku thought about was turkeys. According to American folklore, turkeys are so dumb that, when it starts to rain, they stare up at the sky, mouths half-open in fascination. In fact, turkeys are so fascinated by the rain that they continue to stare up at the sky, their mouths fill up with water, and they drown.

So do turkeys really drown in the rain? According to "scientists," no, they don't. However, the author of today's haiku wasn't going to take any chances, so he stopped staring at the sky and immediately went inside.

Although the notion that turkeys can actually drown in the rain is still being debated, there's no doubt that turkeys are incredibly dumb animals. How can the author of today's haiku say that? Because of this: even scientists agree that no turkey has ever (ever) used the New-CsRgsTimeRange cmdlet.

We kid you not.

So why don't turkeys use the New-CsRgsTimeRange cmdlet? That's a good question, and one that even our crack research team here at the Lync Server PowerShell blog has been unable to answer. About all we can tell you at this point in time is that New-CsRgsTimeRange is a must-have cmdlet when you are configuring hours of business for a Response Group workflow. If you aren't familiar with hours of business, those are simply, uh, the hours of business for a workflow, the days and times when agents are available to answer calls. For example, suppose your help desk is staffed from 9:00 AM to 5:00 PM Monday through Friday. In that case, you need to assign those days and times to the workflow.

And you can't assign those days and times without first using the New-CsRgsTimeRange cmdlet. Fortunately, New-CsRgsTimeRange is a pretty simple little cmdlet to use: all you have to do is specify an opening time and a closing time, like so:

$weekdayHours = New-CsRgsTimeRange –OpenTime "9:00" -CloseTime "17:00"

Two things to note here. First, you do need to use the 24-hour clock when setting opening and closing times; as you can see, we set the OpenTime to 9:00 and the CloseTime to 17:00. Suppose we tried using US time settings instead:

$weekdayHours = New-CsRgsTimeRange –OpenTime "9:00 AM" -CloseTime "5:00 PM"

If we do that, our command will fail and we'll get back this error message:

New-CsRgsTimeRange : Cannot bind parameter 'OpenTime', Cannot convert value "9:00 AM" to type "System.TimeSpan". Error: "Input string was not in a correct format."

Second, notice that we save the results of running New-CsRgsTimeSpan to a variable ($weekdayHours). Why? Because if we didn't, that time range would disappear as soon as the command finished running. That's important to note: you can't permanently save a time range. That means that every time you create new hours of business you'll need to create a time range to use with those new hours.

After you've created your new time range you can then use that range with either the New-CsRgsHoursOfBusiness or the Set-CsRgsHoursOfBusiness cmdlet to configure actual hours of business; after that, those business hours can then be assigned to a workflow. Without going into any detail, here's a command that sets up a new set of business hours called the Help Desk Business Hours:

New-CsRgsHoursOfBusiness -Parent Service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Business Hours" -MondayHours1 $weekdayHours -TuesdayHours1 $weekdayHours -WednesdayHours1 $weekdayHours  -ThursdayHours1 $weekdayHours  -FridayHours1 $weekdayHours

If you take a minute to look at that command, you'll see that we have a parameter for each weekday, Monday through Friday. For each of those weekdays, we've then set the hours to the variable $weekdayHours, the variable we created using New-CsRgsTimeRange. And then, just to ensure we have a happy ending today, we could then assign these business hours to a workflow:

$businessHours = Get-CsRgsHoursOfBusiness service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Business Hours"

$y = Get-CsRgsWorkflow Service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Workflow"

$y.BusinessHoursId = $businessHours.Identity

Set-CsRgsWorkflow -Instance $y

That's all there is to it.

Incidentally, the author of today's haiku has learned that a researcher at Oregon State University believes that turkeys really do occasionally stop and stare blankly into space for a minute or so. However, this isn't because they are dumb, but because they suffer from a genetic disorder known as tetanic torticollar spasms. In looking this up (hey, it's better than working right?) the author of today's haiku learned that torticollis (also known as "wry neck") is a malady in which the head is twisted to one side, with the chin pointing up; tetanic refers to a muscular contraction. So do tetanic torticollar spasms explain why the author of today's haiku often walks around with his mouth half-open, staring blankly into space? It does now!

By now we hope you've had the chance to try your hand at our initial contribution to Sporcle, the online site for "mentally stimulating diversions." If you managed to solve the puzzle, all we can say is this: Congratulations on a job well done! But what if you weren't able to solve the puzzle? What then?

Well, no doubt your mom would say something like, "Well, if you want to succeed at something you just need to try harder." And, to be perfectly honest, we tend to agree with mom on this one … well, except for the part about "trying harder," of course. After all, trying harder is, well, hard. Isn't there an easier way to solve this puzzle? Some way, like, say, cheating ….

Fortunately for all of us (or at least for those of us who don't want to try harder), it turns out that it is possible to cheat at the Lync Server Sporcle puzzle. If you haven't had a chance to glance at the puzzle just yet, the whole thing looks a lot like this:

See the letters listed in the First Letter column? As it turns out, there's at least one Lync Server PowerShell verb that starts with each of the letters that appear in that First Letter column. For example, you see the letter D listed under First Letter. Why? Because there's at least one Lync Server verb that starts with the letter D. So how come you don't see the letter Z listed anywhere? You got: because there aren’t any Lync Server verbs that start with the letter Z. In order to solve the puzzle you just have to start typing in verbs; if you get one correct that verb will be put in the appropriate spot:

OK, so all we need to do is start typing in verbs, huh? Well, we know that there's at least one verb that starts with the letter A. OK, let's see: Abrogate? Ascertain? Ascend?

Hmmm, this isn't as easy as it looks …. In fact, it would be a lot easier if I didn't have to think about this, but instead already had a list of the answers sitting right in front of me.

Apparently we were thinking the same thing:

$letters = "A","B","C","D","E","F","G","H","I","J", `

    "K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"

foreach ($x in $letters)

    {

        $verbs = Get-Command -Module Lync |

            Where-Object {$_.Verb -like "$x*"} | Select-Object Verb

        $count = ($verbs | Measure-Object).Count

        if ($count -ne 0)

            {

                $verbs | Get-Random -Count 1

            }

    }

The preceding script is designed to help you solve the Lync PowerShell Verbs puzzle. How does it do that? Well to begin with, the first line in the script creates an array named $letters; as the name implies, this array contains each of the 26 letters found in the English alphabet.

After we create the array, we set up a foreach loop that loops through each item in that array; that is, through each letter in the alphabet. Inside the foreach loop, the first thing we do is run this command:

$verbs = Get-Command -Module Lync | Where-Object {$_.Verb -like "$x*"} | Select-Object Verb

What we're doing here is using the Get-Command cmdlet to retrieve a collection of all the Lync Server cmdlets (the Module parameter enables us to limit the retrieved data to just the Lync Server cmdlets). That collection is then piped to the Where-Object cmdlet, which picks out only those cmdlets where the Verb property begins with a specific letter. Which specific letter? Well, as we noted, the foreach loop is iterating through all the items stored in the array $letters. That means that, the first time through the loop, the loop variable $x is set to the value of the first item in the array: A. As a result, the first time we run through the loop we'll be looking for Lync Server verbs that start with the letter A. The second time we run through the loop, we'll be looking for Lync Server verbs that start with the letter B. Etc., etc.

In other words, the first time we run through the loop we'll grab information for all the Lync Server cmdlets whose Verb starts with the letter A. We then pipe that data to the Select-Object cmdlet, which extracts just the Verb values from that huge mass of data.

OK, let's pretend that Abrogate, Ascertain, and Ascend really are Lync Server PowerShell verbs. In that case, the variable $verbs will contain three items:

·         Abrogate

·         Ascertain

·         Ascend

Got that? Good. Next, we use this line of code to count the number of items in the array $verbs:

$count = ($verbs | Measure-Object).Count

Why do we do that? Well, we already know that some letters don't have even one corresponding Verb; for example, there aren't any verbs that start with the letter X. Therefore, what we do with this line of code is count the number of verbs retrieved for the current letter. If the Count is 0, that means we don't have any verbs. Consequently, we skip that letter and go to the next item in the array. That's what will happen when we try the letter Q. There aren't any verbs that start with Q, which means that the Count will be 0. Which means, in turn, that we'll just drop the letter Q like a hot potato and then move on to the next letter in the array.

But what if the Count isn't 0? Well, that means that we have at least one verb that starts with the current letter. (For example, at least one verb that starts with the letter A.) If a letter has at least one corresponding verb we then run this command:

$verbs | Get-Random -Count 1

What's going on here? Here we're simply taking our collection of verbs (Abrogate, Ascertain, Ascend) and piping that collection to the Get-Random cmdlet. We're then asking Get-Random to randomly select one of those verbs (-Count 1) to display onscreen. As a result, we'll see something similar to this onscreen:

Ascertain

So what does that mean? That means that we can type Ascertain into the Sporcle puzzle and be sure of getting at least one answer correct. (We can’t, really. Ascertain was just an example. You’ll have to run the script to find the real answers.) After all, Ascertain won't show up onscreen unless it happens to be a valid Lync Server PowerShell verb.

See how much easier it is to cheat? Makes you wonder why people don't do it more often, doesn't it? Needless to say, we heartily condone, encourage, endorse, and otherwise recommend cheating whenever you think you can get away with it!

Anyway, after we've printed out a verb for the letter A (assuming that there is a verb for that letter) we then loop around and repeat the process for the letter B. By the time we're finished, we should see 14 verbs onscreen, 14 verbs that match up quite nicely with the answers needed to successfully solve the Lync PowerShell Verbs puzzle.

And here some of you thought that Windows PowerShell could never be put to any practical use. Now you know better!

The old saying is “March comes in like a lion, goes out like a lamb.” Well, that’s one ferocious lamb because April has been roaring away here in Redmond. Another saying is “April showers bring May flowers.” If that one’s true you’ll be able to spot the Seattle area from space – it’s that very colorful spot over there on the west coast of North America.

Has anyone ever counted the number of words Seattleites have for “rain?” Showers, mist, drizzle, …. Does anyone really know what the difference is between rain and showers?

Well, it’s been raining (or showering) haikus here at the Lync Server PowerShell blog. (How’s that for a segue?) And tomorrow, Friday, April 29, 2011, marks the publishing of the 100^th Lync Server PowerShell Haiku. To celebrate we’re going to…well, we’re going to publish the 100^th Lync Server PowerShell haiku.

Do we know how to party here or what?

And, in case you missed anything, here’s what else happened in April:

No Conferencing Policy is an Island: Per-Organizer Settings vs. Per-User Settings

Export to Excel

How to Export Lync Contacts to Excel

Export Lync Contacts to Excel (script only)

Simultaneously Assigning a Policy to Multiple Users

How to Cheat at Sporcle

And of course the One of These is Not Like the Others challenge is still going on. Plus, we didn’t get to 100 without doing to first 99: find all the haiku’s in the Haiku Archive.

There’s more coming in May, so stay tuned.

Thanks for joining us. We’re going to go watch all those flowers come up.

Cutting edge. On the

Edge. The edge of night. Edgewise.

CS AccessEdge.

A couple of years ago, when the author of today's haiku joined the Lync Server documentation team, he attended his first-ever team meeting. At that meeting, his manager said, "We need to do some more documentation on Edge servers. Would anyone like to volunteer to do that?" Silence filled the room, and no one moved a muscle lest that one involuntary movement be considered a sign that you were volunteering to try and explain the ins and outs of Edge servers to a waiting world.

Two years later, the author of today's haiku was sitting in a meeting of the Lync Server PowerShell blog team when he said, "We need a haiku on the CsAccessEdgeConfiguration cmdlets. Would anyone like to volunteer to do that?" Once again, silence filled the room.

Documenting Edge servers is one of those things that everyone agrees needs to be done – just as long as someone else does it. Edge servers can definitely be … interesting … to work with, and even more … interesting … to try to explain. Fortunately, though, there's one man in this world brave enough to tackle the CsAccessEdgeConfiguration cmdlets.

But then he phoned in sick this morning, which left it up to the author of today's haiku.

Now, at first glance, you might not think that discussing of the CsAccessEdgeConfiguration cmdlets would be all that difficult; after all, there are only two CsAccessEdgeConfiguration cmdlets: Get-CsAccessEdgeConfiguration and Set-CsAccessEdgeConfiguration. But as we're about to see, there's an unexpected plot twist involving Edge server configuration settings that will keep you on the "edge" of your seat!

To begin with, we should note that you can have only one global set of Edge server configuration settings: you don't see a New-CsAccessEdgeConfiguration cmdlet because you're not allowed to create any new Edge server configuration settings. Instead, you get one collection of global settings, and all your Edge servers must abide by those settings.

One nice thing about being limited to a single collection of Edge server configuration settings is this: it makes it really easy to run the Get-CsAccessEdgeConfiguration cmdlet. Need information about all your Edge server configuration settings? We can help you with that:

Get-CsAccessEdgeConfiguration

That's not only all you need to do with the Get-CsAccessEdgeConfiguration cmdlet, that's pretty much all you can do with the Get-CsAccessEdgeConfiguration cmdlet.

Things get a little trickier when it comes to the Set-CsAccessEdgeConfiguration cmdlet. Why is that? Well, as it turns out, there are two different ways to configure your Edge servers, with both of the ways based on the routing method you use:

·         DNS server routing, in which Edge servers rely on DNS records when handling sending and receiving federation requests.

·         Default routing, in which you must specify the fully qualified domain name (FQDN) of the server used for federation requests.

Neither of those options are particularly hard; the tricky part is recognizing that the parameters and the settings that are available to you will vary depending on which routing method you choose. For example, if you decide to switch to default routing, you absolutely must include the DefaultRouteFqdn parameter, which specifies the FQDN of the server that handles your federation requests. For example:

Set-CsAccessEdgeConfiguration -UseDefaultRouting -DefaultRouteFqdn "atl-edge-001.litwareinc.com"

Likewise, if you decide to use DNS server routing you are required to use the EnablePartnerDiscovery parameter, a parameter that specifies whether Lync Server will use DNS records to try to discover partner domains not listed in the AllowedDomains list. (If you set this parameter to False then you will only be only be able to federate with domains included on your Allowed Domains list.) In other words:

Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $True

Again, not too terribly difficult; you just need to keep track of which parameters are required with which routing method. Fortunately, there aren't too many of these parameters too worry about:

What happens if you mix and match these parameters? For example, what happens if you run a command like this one that uses the VerificationLevel parameter along with the UseDnsSrvRouting parameter:

Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $True –VerificationLevel AlwaysVerifiable

Here's what's going to happen: the command will fail, and you'll get the following error message:

Set-CsAccessEdgeConfiguration : Parameter cannot be resolved using the specified named parameters.

Oh, and just to make things even more interesting, there are also two parameters that you should never use (unless someone from  Microsoft, and we mean someone who knows what they're doing, not someone from the Lync Server PowerShell blog tells you to use them): BeClearinghouse and OutgoingTlsCountForFederatedPartner. What happens if you do use them? Well, to tell you the truth, we don't know. The last tester who tried using them was never heard from again.

Incidentally, Set-CsAccessEdgeConfiguration does have a number of other parameters that can be used with either routing method. Those parameters include the following:

·         AllowAnonymousUsers. Indicates whether or not anonymous users are allowed to join meetings and conferences.

·         AllowFederatedUsers. Indicates whether internal users are allowed to communicate with users from federated domains, and whether internal users can communicate with users in a split domain scenario.

·         AllowOutsideUsers. Indicates whether users can access Lync Server from outside the firewall and across the Internet.

So, see, it's not all doom-and-gloom; in fact, the CsAccessEdgeConfiguration cmdlets are actually incredibly useful, especially for anyone who wants to extend the range of Lync Server 2010 beyond their internal corporate network.

So was writing this article about Edge servers really the bravest, most daring and death-defying thing the author of today's haiku has ever done? You know, now that we think about it, it is. Hmmm ….