Haiku #149
Buy me some peanuts
And Crackerjack. Oh, and some
CS business hours.
Hey, everyone. Before we get started we thought we should note that today's Lync Server PowerShell haiku is being written by Reese McGwire. Now, before you get too excited about that ("Finally! Let's hope this Reese guy can actually write a haiku!), we should note that the new author of today's haiku is actually the old author of today's haiku; he's simply decided to adopt a new name, having heard the name "Reese McGwire" while watching a baseball tournament this weekend.
Why the new name? Well, unlike most American boys, the author of today's haiku didn't grow up dreaming about someday working for Microsoft and writing Lync Server PowerShell haikus; instead, he dreamed about growing up and someday playing centerfield for the New York Yankees.
Note. What's that? Why not dream about playing centerfield for Seattle's Major League baseball team? Well, for one thing, Seattle doesn't actually have a Major League baseball team. All we have is the Mariners.
At any rate, the author of today's haiku has yet to fulfill his dream, something he is now convinced is due to the fact that he doesn't have a good name for baseball. Reese McGwire, on the other hand, is a great name for baseball. (So is Zach McGwire, but Zach McGwire sounds more like a third baseman than a centerfielder.) The author of today's haiku is positive that, if he can get everyone to refer to him as Reese McGwire, then he'll have no problem getting a job as centerfielder for the Yankees.
Note. Shouldn't he also learn how to hit a cut fastball, how to throw the ball from centerfield without rolling it, and how to make it to first base in less than an hour and a half? Maybe. But first things first.
In addition to realizing that he needs to change his name, here are two more things that the author of today's haiku – sorry, that’s Reese McGwire – learned during this weekend's baseball tournament:
· Baseball is one of the greatest sports ever invented. However, even the author of today's haiku began to question that after sitting through a first inning that lasted one hour and seven minutes, and which the only batter who wasn't walked during that time was hit by a pitch.
· The Kennewick Bandits have a player who "Every time he's up, he either gets a hit or he doesn't." Having heard a couple of fans mention this, the author of today's haiku (aka Reese McGwire) watched this player very closely throughout the entire tournament. And guess what? The fans were right: every single time this player got up to bat, he either got a hit or he didn't. Strange, but true!
Having grown up in the days of Mordecai "Three Finger" Brown (hmmm, Mordecai McGwire? Nah.), the author of today's haiku also learned that today's baseball players are completely oblivious to the fundamentals of the game. Lay down a sacrifice bunt by simply holding the bat still and not lunging at the ball or even swinging at the ball? Apparently, that can no longer be done. With a runner on second and no outs, hit the ball to the right side of the field in order to move the runner to the third base? Forget about it; instead, swing as hard as you can and assume you'll probably hit the ball out of the park. Use the CsRgsHoursOfBusiness cmdlets to create business hours for Lync Server's Response Group application? Let's face it: the odds are pretty good that you won't see that in one of today's baseball games.
Believe it or not, today's modern baseball players (at least the 17- and 18-year olds) don't use any of the CsRgsHoursOfBusiness cmdlets: they don't use Get-CsRgsHoursOfBusiness, they don't use New-CsRgsHoursOfBusiness, they don't use Remove-CsRgsHoursOfBusiness, and they surely don't use Set-CsRgsHoursOfBusiness. Why not? Hey, who knows with kids these days? And it's a crying shame, too, because any time you set up a Response Group workflow you should specify the days of the week, and the hours of the day, when agents for that workflow are available to answer calls. For example, suppose you have a help desk that's open only from noon until 5:00 PM on Wednesdays. In that case, you need to configure the business hours for the workflow to indicate that calls should be transferred to an agent only from noon until 5:00 PM on Wednesdays. Calls received during any other time period (say, 9:00 AM on a Tuesday) should be sent to voice mail or maybe transferred to a different queue. Anything but transferred to the workflow agents, seeing as how those agents aren't available at 9:00 AM on a Tuesday.
So how do you configure business hours that can be assigned to a workflow? Well, back in the day, the author of today's haiku and his childhood friend, baseball legend Cap Anson, used to configure business hours using a command similar to this:
$hours = New-CsRgsTimeRange -Name "Weekday Hours" -OpenTime "12:00" -CloseTime "17:00"
New-CsRgsHoursOfBusiness -Parent "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" -WednesdayHours1 $hours
So what's going on here? Two things. First, we're using the New-CsRgsTimeRange cmdlet (which was always Cap Anson's favorite cmdlet) to configure opening and closing times for noon (12:00 on a 24-hour clock) and 5:00 PM (17:00 on a 24-hour clock). Those opening and closing times are stored in a variable named $hours. Once that's done, the New-CsRgsHoursOfBusiness cmdlet is used to create a collection of business hours that defines just time periods when Response Group agents are available: Wednesday from noon until 5:00 PM:
New-CsRgsHoursOfBusiness -Parent "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" -WednesdayHours1 $hours
A couple quick notes here about business hours. As you can see, in order to define business hours you first have to use the New-CsRgsTimeRange cmdlet to specify the opening and closing times for a time period. After you've done that, you then need to assign that time period to a day of the week (in this case Wednesday). That's what this little snippet of code is all about:
-WednesdayHours1 $hours
Ah, good point: why is the parameter named WednesdayHours1 and not just WednesdayHours? Well, as it turns out, each day of the week actually has two separate time periods: time period 1 (WednesdayHours1) and time period 2 (WednesdayHours2). Why two different time periods? Well, let's suppose that your help desk is open from 9:00 AM until noon, shuts down for lunch, and then is open again from 1:00 PM to 5:00 PM. At first glance, you might think that these commands would be the way to configure those business hours:
$hours = New-CsRgsTimeRange -Name "Weekday Hours" -OpenTime "9:00" -CloseTime "17:00"
New-CsRgsHoursOfBusiness -Parent "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" -WednesdayHours1 $hours
However, that command doesn't reflect your true business hours: it assumes that agents are available continuously from 9:00 AM to 5:00 PM, and that's not really the case. Instead, you need to configure business hours that reflect the fact that agents are not available between noon and 1:00 PM. In other words, you need to use a set of commands similar to these:
$hours1 = New-CsRgsTimeRange -Name "Morning Hours" -OpenTime "9:00" -CloseTime "12:00"
$hours2 = New-CsRgsTimeRange -Name "Afternoon Hours" -OpenTime "13:00" -CloseTime "17:00"
New-CsRgsHoursOfBusiness -Parent "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" -WednesdayHours1 $hours1 –WednesdayHours2 $hours2
See how that works? We defined one time period from 9:00 AM until noon ($hours1) and assigned that to WednesdayHours1. In addition to that, we defined a second time period from 1:00 PM until 5:00 PM ($hours2), which was assigned to WednesdayHours2. That's how the workflow knows not to transfer calls between noon and 1:00 PM on Wednesday.
Now, what happens if your help desk is open five days a week, Monday through Friday? That's fine; you just need to include the appropriate parameters, one for each day of the week. For example:
$weekday = New-CsRgsTimeRange -Name "Weekday Hours" -OpenTime "8:00" -CloseTime "18:00"
New-CsRgsHoursOfBusiness -Parent "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" -MondayHours1 $weekday -TuesdayHours1 $weekday -WednesdayHours1 $weekday -ThursdayHours1 $weekday -FridayHours1 $weekday
Etc., etc.
And after you've created these business hours how do you assign them to a workflow? Well, without bothering to go into the details, you need to do something similar to this:
$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"
$y.BusinessHoursId = $businessHours.Identity
Set-CsRgsWorkflow -Instance $y
What we've done here is use the Get-CsRgsHoursOfBusiness cmdlet to create an object reference to the Help Desk Business Hours collection; we then used the Get-CsRgsWorkflow cmdlet to create an object reference to the Help Desk workflow. After we have our two object references, we can then use these two commands to assign business hours and then save our changes back to the Response Group application:
$y.BusinessHoursId = $businessHours.Identity
Set-CsRgsWorkflow -Instance $y
Pretty easy, huh? If it doesn't seem pretty easy, then take a look at the help topic for the Set-CsRgsWorkflow cmdlet for a little more information.
As we saw just a second ago, the Get-CsRgsHoursOfBusiness cmdlet lets us retrieve information about all our existing collections of business hours. Likewise, Remove-CsRgsHoursOfBusiness lets us delete an existing collection of business hours. However, there's a little bit of a catch there. Business hour collections have Identities that look like this:
service:ApplicationServer:atl-cs-001.litwareinc.com/1987d3c2-4544-489d-bbe3-59f79f530a83
Does that matter? Well, when it comes to removing business hours, yes, it does; if you call Remove-CsRgsHoursOfBusiness all by itself that means you need to use a command similar to this:
Remove-CsRgsHoursOfBusiness –Identity "service:ApplicationServer:atl-cs-001.litwareinc.com/1987d3c2-4544-489d-bbe3-59f79f530a83"
Can you imagine Iron Man McGinnity using a command like that? We can't, either. Instead, Iron Man used to use the Get-CsRgsHoursOfBusiness cmdlet to retrieve the desired business hours collection, and then pipe that collection to Remove-CsRgsHoursOfBusiness:
Get-CsRgsHoursOfBusiness -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours" | Remove-CsRgsHoursOfBusiness
That approach lets you retrieve the business hours collection by name (Help Desk Business Hours) rather than by GUID (1987d3c2-4544-489d-bbe3-59f79f530a83).
As for Set-CsRgsHoursOfBusiness, that cmdlet is used to modify an existing business hours collection. Like most of the Response Group cmdlets, however, Set-CsRgsHoursOfBusiness doesn't have any parameters that can be used to directly changed data. Instead, you have to retrieve the desired business hours collection, make the changes in memory, and then write those changes back to the Response Group application. For example, if your help desk is no longer open on Saturdays, you could use these commands to set the Saturday business hours to null:
$x = Get-CsRgsHoursOfBusiness -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -Name "Help Desk Business Hours"
$x.SaturdayHours1 = $Null
$x.SaturdayHours2 = $Null
Set-CsRgsHoursOfBusiness -Instance $x
Is it a little cumbersome? Yeah. But it works.
In the meantime, the author of today's haiku has a lot of work to do. As it turns out, he's only been able to uncover one instance of someone named Reese making it to the Major Leagues: Reese Diggs, who played a grand total of 4 games for the Washington Senators in 1934. We're gonna have to put this whole Reese McGwire thing on hold and then get back to you. Admittedly, actress Reese Witherspoon did win an Academy Award. But that would be more useful if the author of today's haiku wanted to be a soccer player rather than a baseball player.