Haiku #190

[NextHop_Team]

First published on TECHNET on Sep 15, 2011

Hit 600 home

Runs? Create new workflows? But

What else have you done?

This is bound to stir up a hornet's nest of controversy, but here it is: the author of today's haiku does not believe that Jim Thome should be in the Baseball Hall of Fame.

There, he said it.

Now, many of you who read that first paragraph are probably thinking, "Who the heck is Jim Thome and what does he have to do with Lync Server PowerShell?" (And many more of you who have read that first paragraph are probably no longer around to read this third paragraph.) Jim Thome is a professional baseball player (now playing for the Cleveland Indians) who, by all accounts, is a wonderful human being. He's also been a pretty good baseball player: he recently hit his 600 ^th home run, putting him in very rarefied company indeed.

Note . The only other players with 600 career home runs? Barry Bonds, Hank Aaron, Babe Ruth, Willie Mays, Ken Griffey, Jr., Sammy Sosa, and Alex Rodriguez. During his baseball career, spanning Little League through high school, the author of today's haiku missed joining the 600 home runs club by a mere 600 home runs. So near and yet so far!

At any rate, you obviously have to have a considerable amount of talent in order to hit 600 home runs. But does that mean you have Hall of Fame talent? The author of today's haiku would argue that no, you don't. Jim Thome has always been a very good ball player, but even in his prime no one considered him to be the best ball player: he never struck fear into the opposition the way a Barry Bonds or a Tony Gwynn or a Ken Griffey, Jr. did. Good ball player? Yes. Hall of Famer? No.

As good as Jim Thome might have been at hitting home runs (and he was, and is, less adept at running, fielding, throwing, or hitting for average) what he is really good at is playing for a long time: Thome is now in his 21 ^st season in the big leagues. Unfortunately, baseball is now in the habit of rewarding people not so much for how good they were, but for how old they were when they retired. Craig Biggio was another nice guy who had a long and fruitful career. But a Hall of Famer? Everyone says yes, because he played for 20 seasons and got over 3,000 hits. But here's a look at Craig Biggio's batting averages for the last 6 years of his career:

· .253

· .264

· .281

· .264

· .246

· .251

That doesn't sound like Hall of Fame material. The author of today's haiku does not believe you should be applauded just because you performed at a mediocre level for a long time.

Note . Which reminds us: today's in the 190 ^th Lync Server PowerShell haiku.

So what does any of that have to do with Lync Server PowerShell? As far as we know, absolutely nothing. It's just something that had to be said.

And here's something else that has to be said: we really should talk about Lync Server PowerShell today. And, believe it or not, we were just about to do that: we were just about to talk about the CsRgsWorkflow cmdlets ( Get-CsRgsWorkflow , New-CsRgsWorkflow , Remove-CsRgsWorkflow , and Set-CsRgsWorkflow ).

Before we talk about the CsRgsWorkflow cmdlets (and whether or not these cmdlets should be in the PowerShell Cmdlet Hall of Fame), let's take a second to talk about the Response Group service and about Response Group workflows. As you probably know, the Response Group service enables you to automatically respond to incoming phone calls. For example, if someone calls your help desk, you can configure the Response Group to simultaneously transfer that call to a group of "agents," any one of whom can answer that call. If you want to get fancier, you program the service so that it prompts the user for additional information: "Press 1 if you are experiencing a hardware-related problem. Press 2 if you are experiencing a software-related problem." By gleaning a little information up front, the service can then transfer the call to a support person who might be best-suited to deal with the problem.

And yes, now that you mention it, that is a really nice little feature, isn't it?

So then what's a Response Group workflow? Well, basically a workflow is a Response Group. If you want to use the Response Group service to handle incoming calls to your help desk, you need to set up a workflow for that help desk, a workflow uniquely associated with the SIP address and the telephone number for the help desk. And one of the best ways to set up and then manage a Response Group workflow? You got it: by using the CsRgsWorkflow cmdlets.

Note . See? Every now and then we do talk about something related to Lync Server PowerShell.

So does that mean that we do think that the CsRgsWorkflow cmdlets should be in the PowerShell Cmdlet Hall of Fame? To be honest, we have mixed emotions about that. There's no doubt that the CsRgsWorkflow cmdlets are incredibly powerful and incredibly useful; at the same time, however, these cmdlets can be a bit … quirky …. And that's something you need to be aware of before you start working with them.

So what do we mean when we say that these cmdlets can be "quirky?" Well, let's start with this fact: it's basically impossible to create a Response Group workflow (or at least a workflow that actually does something) without using a bunch of other cmdlets as well. Why? Because many of the properties of a Response Group workflow only accept objects created by other Response Group cmdlets. (This, by the way, is just the way the Response Group object model works: you tend to create objects which are assigned as properties to other objects.)

Good idea: maybe we should show you what we're talking about here. Let's take business hours, for example. Business hours define the days and times when agents are available to answer the phone; the idea is that, during business hours, calls to the help desk will be transferred to the help desk agents, while calls outside of business hours might be sent directly to voice mail. So how do you assign business hours to a workflow? Well, to be honest, you have to do something a little crazy, like this:

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

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

$x.BusinessHoursId = $businessHours.Identity

Set-CsRgsWorkflow -Instance $x

As it turns out, business hours are a totally separate object, created and maintained by the CsRgsHoursOfBusiness cmdlets. To assign business hours to a workflow, you either have to create those business hours using New-CsRgsHoursOfBusiness or, as we've done here, retrieve a collection of existing business hours using Get-CsRgsHoursOfBusiness. After retrieving the business hours, you next need to retrieve an object reference to your Response Group workflow; that's what we do here:

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

After we run the previous command, we'll have a "virtual" instance of the Help Desk workflow that exists only in memory (and is stored in the variable $x). We update the value of the BusinessHoursId property for $x, then use this command to write the changes back to the real Help Desk workflow:

Set-CsRgsWorkflow -Instance $x

We see you're confused by all this; why didn't we just use a command like this one to set the business hours:

Set-CsRgsWorkflow –Identity "Help Desk" –BusinessHoursId $businessHours

Well, the main reason we didn't use a command like that is because it wouldn't work. The Response Group cmdlets are somewhat unique in the fact that (in most cases) you can't directly modify the property values of an object. Instead, you need to create a virtual copy of the object, change the property values of that virtual copy, then use the appropriate Set-CsRgs cmdlet and the Instance parameter to change the real object. You can make a case that this isn't the most intuitive way of doing things, but that's just the way the Response Group cmdlets work.

History lesson . When Lync Server was first being developed, pretty much all the cmdlets worked that same way; it was only a bit later in the development cycle when the Set-Cs cmdlets were changed so that they could directly modify property values. That was fine for most cmdlets: the majority of them didn't even exist at the time. However, the Response Group team was different: most of their cmdlets were done at the time the change was made. Because the cmdlets were done, and because they all worked, the decision was made to leave them as-is. If it ain't broke, don't fix it.

If you’re been wondering why the Response Group cmdlets seem a little different from the other Lync Server cmdlets, well, now you know.

Incidentally, this same approach is going to be true for a bunch of other workflow properties: CustomMusicOnHoldFile; DefaultAction; HolidayAction; HolidaySetListId; NonBusinessHoursAction; and so on. We can't go through all the possibilities and permutations in today's haiku; that would take us 20 years or more, and we just don't have the time for that. (Although it probably would get us into the Baseball Hall of Fall.) For more information, see the help topic for New-CsRgsWorkflow . Better yet, take a peek at the Response Group scripts written by Frédéric Dubut:

· Create a Response Group with a Hunt Group

· Create a Response Group with an IVR

These scripts show how to use the CsRgs cmdlets to create different types of Response Group workflows and are definitely worth looking into.

One other quirky thing about the CsRgsWorkflow cmdlets. In Lync Server PowerShell, you're used to working with the Identity of an object. You can do that with workflow objects, too, except that workflow objects tend to have Identities that look like this:

service:ApplicationServer:atl-cs-001.litwareinc.com/1987d3c2-4544-489d-bbe3-59f79f530a83

So what does that mean? Well, it means that you can delete a workflow by using a command similar to this:

Remove-CsRgsWorkflow –Identity "service:ApplicationServer:atl-cs-001.litwareinc.com/1987d3c2-4544-489d-bbe3-59f79f530a83"

That's what we said. Therefore, you might want to retrieve the workflow using Get-CsRgsWorkflow (and the Name parameter), then pipe that retrieved object to Remove-CsRgsWorkflow:

Get-CsRgsWorkflow –Name "Help Desk" | Remove-CsRgsWorkflow

Just something to keep in mind.

Oh, and here's something else to keep in mind: Ray Schalk is in the Baseball Hall of Fame, the same Ray Schalk who had a lifetime batting average of .253 and 11 career home runs. (That's only 11 more than the author of today's haiku!) George Kelly never received more than 5 votes on any Hall of Fame ballot (for comparison purposes, neither has the author of today's haiku), yet 40 years after he was retired the Veteran's Committee (chaired by two of his former teammates) put him into the Hall of Fame anyway. Wilbert Robinson, former manager of the Brooklyn Dodgers, is in the Hall of Fame, even though he never won a World Series and had 10 losing seasons in his 18 years as the Dodger manager.

Which simply means this: Jim Thome, we owe you an apology. Enjoy the Hall of Fame!

See you tomorrow.