Haiku #142
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.
Note. In case you're wondering, the loudest animal in the world is – and we kid you not – the Tiger Pistol Shrimp, which is capable of making a sound that exceeds 200 decibels; that's louder than a jet engine, which checks in at around 140 decibels. And yes, that's what we said, too. But you can look it up for yourself. The loudest land animal is the howler monkey, whose screeching can be heard as far as 10 miles away.
But we think that the dogs next door can give the howler monkey a run for its money.
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?
Note. Well, he did step on an ant the other day, and his wife is always making him kill spiders. But who hasn't stepped on an ant or killed a spider during his or her lifetime?
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.
Note. And yes, he is willing to discuss all three cmdlets: Get-CsRgsConfiguration, Move-CsRgsConfiguration, and Set-CsRgsConfiguration.
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.
One important note. If Office Communications Server is running Microsoft SQL Server 2005 then you must also install the Microsoft SQL Server 2005 Native Client on the computer where you will be running the Move-CsRgsConfiguration cmdlet. If the Native Client is not installed you will receive the error message "Cannot access WMI settings" when you call Move-CsRgsConfiguration.
Oh: and the migration attempt will fail.
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?