Haiku #44

  • Article

Please hold: your call is –

Hey, wait: didn't we just do

This one yesterday?

All of us here at the Lync Server PowerShell blog have been greatly influenced by television, not so much because of the quality of the product (after all, this is the medium that brought us The Bachelor) but because the TV industry has mastered the art of doing less and less work each and every year. (We like that idea.) For example, the summer months used to be known as the "summer rerun season," because that was the only time of year when reruns were shown; from September to June you saw new, original episodes of your favorite shows. Nowadays, the typical TV series shows 20-22 episodes per season, meaning that most of the shows you see during the course of the season are reruns. You work for 20 weeks, and get paid for the whole year.

See why we like TV so much?

But it gets even better. Sometimes you'll see a new episode this week and then, next week, you'll see the very same episode all over again. A rerun after just one week? Of course not. That's not a rerun, that's an "encore presentation." And because an encore is an additional performance put on because of audience demand, that can only mean that people want to see the exact same thing over and over and over again. Which, in turn, means that TV is fully justified in showing you the same thing you just saw a week ago.

That also means that you should consider this an encore presentation of yesterday's haiku. Hey, we just have to give the people what they want, right?

OK, it's not quite that bad. After all, this isn't actually a reprint of yesterday's haiku; instead, we're just covering similar ground. Yesterday we talked about the Set-CsCpsCallParkMusicOnHold cmdlet, which enables you to assign an audio file to be played any time a call is parked. (See yesterday's haiku for more details.) As it turns out, though, there are other Microsoft Lync Server 2010 components that can play audio files, including the Announcement service and the Response Group application. However, these components use a different set of cmdlets to import and configure those audio files. Seeing as how we have yet to come down from that emotional high we got from discussing Set-CsCpsCallParkMusicOnHold, we thought we'd just keep going today and talk about the Import-CsRgsAudioFile cmdlet.

Import-CsRgsAudioFile is the cmdlet used to import and assign audio files used with the Response Group application. As we saw yesterday, the Call Park application handles audio files using a two-step process:

1. The audio file is imported by using the Get-Content cmdlet.

2. The imported audio file is assigned to the Call Park application by using the Set-CsCpsCallParkMusicOnHold cmdlet.

The Response Group application also uses a two-step process when working with audio files, but the two steps are slightly different:

1. The audio file is imported by using the Import-CsRgsAudioFile cmdlet.

2. The imported audio file is assigned to the Response Group application by using … well, it depends on what you actually want to do with that file. But we'll show you a couple of examples before we go.

First, though, we should show you how the Import-CsRgsAudioFile works. It works like this:

$audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "WhileYouWait.wav" -Content (Get-Content C:\Media\WhileYouWait.wav -Encoding byte -ReadCount 0)

As you can see, it's similar to what we saw yesterday, only different.

Note. Sort of like the new Hawaii 5-0 show, which uses the same character names and locations and the old Hawaii 5-0 show (which went off the air in 1980), but otherwise doesn't resemble the old show in the least. So why didn't they just create a new detective show rather than resurrecting (sort of) the old one? That's TV for you.

Incidentally, when we stop doing the daily Lync Server PowerShell haiku (perish the thought!) we intend to immediately start doing a brand-new Lync Server PowerShell haiku, except that it won't have anything to do with Lync Server PowerShell and won't include any haikus. That's the way TV would do it.

Now, where were we? Oh right: it's similar to what we saw yesterday, only different. In this command, we call Import-CsRgsAudioFile and specify the following parameters:

· Identity – The Identity of the Application Server that hosts the Response Group application.

· FileName – The actual file name and file extension (e.g., WhileYouWait.wav) of the file being imported.

· Content – A call to the Get-Content cmdlet, which we use to actually import the file. This part of the command looks exactly like what we saw yesterday. In fact, it's the same as step 1 we saw yesterday only embedded within a call to Import-CsRgsAudioFile.

Confusing? Well, yes, a little bit. But that's the way the system works. We can't just call Get-Content and import the audio file into a variable, the way we did yesterday. Instead, we have to call Import-CsRgsAudioFile and then, as part of that call, use Get-Content to import the audio file into a variable. Strange, but true!

Note. Here's another difference: With the Call Park application you can only use .WMA files. The Response Group application is a little more flexible: it accepts either .WMA or .WAV files.

So what do you do with this file after it's been imported? Well, that depends: when it comes to the Response Group application, there are a number of different things you can do with an audio file. For example, you can configure the default music on hold for an instance of the Response Group application:

 $audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "WhileYouWait.wav" -Content (Get-Content C:\Media\WhileYouWait.wav -Encoding byte -ReadCount 0)

  

 Set-CsRgsConfiguration -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -DefaultMusicOnHoldFile $audioFile

This is pretty easy: you simply call the Set-CsRgsConfiguration cmdlet, and assign the imported file (the variable $audioFile) to the DefaultMusicOnHoldFile parameter.

Here's another example:

 $audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "WhileYouWait.wav" -Content (Get-Content C:\Media\WhileYouWait.wav -Encoding byte -ReadCount 0)

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

$workflow.CustomMusicOnHoldFile = $audioFile

Set-CsRgsWorkflow -Instance $workflow

You're right: that one's not so clean and neat, is it? In this one, we're configuring custom music on hold for an individual workflow. To do that, we start out by importing our audio file; no problem there. However, at this point we can't just call Set-CsRgsWorkflow to assign the audio file as the music on hold file; the CsRgsWorkflow cmdlets don't work that way. Instead, we need to use this line of code to create an object reference to the workflow of interest (Help Desk):

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

After that, we can assign $audioFile to the object reference, and then use Set-CsRgsWorkflow to save those changes to the actual Help Desk workflow:

$workflow.CustomMusicOnHoldFile = $audioFile

Set-CsRgsWorkflow -Instance $workflow

In other words, we have to make all our changes on a copy of the workflow object, then write those changes back to the real workflow object. Why? That's just the way the Response Group cmdlets work.

Now, we're the first to admit that a command like this one is a bit gnarly looking, to say the least:

 $audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "WhileYouWait.wav" -Content (Get-Content C:\Media\WhileYouWait.wav -Encoding byte -ReadCount 0)

If you don't like gnarly looking commands, you can also import the file using this command:

 $audioFile = Get-Content -ReadCount 0 -Encoding Byte C:\MediaFiles\WhileYouWait.wav | Import-CsRgsAudioFile -Identity Service:ApplicationServer:atl-cs-001.litwareinc.com -FileName "WhileYouWait.wav"

What's the difference here? Well, the difference is that, instead of using the call to Get-Content as the value for the Content parameter, we're calling Get-Content first, thus retrieving the audio file. We then pipe that audio file object to Import-CsRgsAudioFile. The net result is the same: we end up with an audio file object ($audioFile) that can be used with the Response Group application. It's just a slightly different way of doing things, a way that might be a little cleaner and a little easier to follow.

But that's entirely up to you.

We should also note that you always have to import the audio file, even if you used that same exact file elsewhere. For example, pleased with the way WhileYouWait.wav is working as custom music on hold for the Help desk workflow, you might think, "Hey, I'd like to use that as the custom music on hold for my Customer Support workflow as well." That's fine; just remember that you'll have to go through the entire process, including importing the file that you've already imported:

 $audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "WhileYouWait.wav" -Content (Get-Content C:\Media\WhileYouWait.wav -Encoding byte -ReadCount 0)

$workflow = Get-CsRgsWorkflow -Identity Service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Customer Support"

$workflow.CustomMusicOnHoldFile = $audioFile

Set-CsRgsWorkflow -Instance $workflow

We'd tell you that this is just the way that the Response Group cmdlets work, but you've probably figured that out on your own.

So is that it for importing audio files? You bet it is. Well, except for the Import-CsAnnouncementFile cmdlet. But we probably won't talk about that cmdlet, at least not for a while. Even TV won't show "encore presentations" on back-to-back days.

Well, usually.