Calls to SfB RGS drop instantly – FE logs event 31140

If you’ve ever created a Lync or Skype for Business Response Group Workflow using PowerShell you really appreciate how quick and easy it is to do from the Response Group browser interface, the “Response Group Configuration Tool”.

Unfortunately sometimes the PowerShell path is unavoidable: if you have more than 4 options in an IVR menu, need to burrow more than 2 levels deep or want to add no-response actions or “please hold while we transfer you” messages, those can only be done through PowerShell.

And so it was that I found myself struggling with *several* brand new Hunt Groups and IVRs that all hung up on me straight after I called them, or dropped to music, skipping the greeting altogether. The only common pattern here was that the faulty ones all used a WAV file as a greeting, whilst those with a Text-To-Speech (TTS) greeting were fine.

Here’s an example of creating one of my broken ones. It’s a faithful reproduction of all of the P$ tips you’ll find online, so I was struggling to understand the problem:

$serviceID = "service:ApplicationServer:mySfBFE.blah.local"
$GreetingAudioFile = Import-CsRgsAudioFile -Identity $ServiceId -FileName "TestRgsGreeting.wav" -Content (Get-Content "C:\TestRgsGreeting.wav" -Encoding byte -ReadCount 0)
$PromptWM = New-CsRgsPrompt -AudioFilePrompt $GreetingAudioFile 
$Queue = get-csrgsQueue $serviceID -Name "TestSfB-Queue"
$DefaultActionWM = New-CsRgsCallAction -Prompt $PromptWM -Action TransferToQueue -QueueID $Queue.Identity
$Workflow = New-CsRgsWorkflow -Parent $ServiceId -Active $true -Anonymous $false -Language "en-AU" -EnabledForFederation $false `
-Name "Broken SfB Workflow" `
-Description "Broken SfB Workflow" `
-PrimaryUri "" `
-DefaultAction $DefaultActionWM
Set-CsRgsWorkflow -instance $workflow

This (and all the others like it) went in fine, presenting no errors at all.

Tracing on the client or FE didn’t give me any clues – the Workflow answered, the Workflow instantly hung up on me. Have a nice day.

Logic told me that the issue was with the recording (all provided to me by the customer), and my tests appeared to confirm this: if I updated a Workflow to use a TTS greeting it worked fine. This meant I burnt far too much time re-saving audio files in a range of different formats & then re-importing in the hope of finding the one that was going to work.

I invested far too long in this futile endeavour before shopping the event logs on all my Front-Ends, and that revealed this gem on one (which was presumably the active RGS Match Maker at the time):


Event ID: 31140 LS Response Group Service
The workflow runtime encountered an error while playing an audio file or TTS.
Failure occurrences: 5, since 2/09/2017 12:55:02 AM.
The last encountered error was from a workflow with display name: Broken SfB Workflow, URI:, and GUID: 79d649f1-5ec1-4794-b0a9-d6d6ad12d417.
Exception: Value cannot be null.
Parameter name: alternateText

Alternate Text? Searches for where I might be able to add some “alternateText” to my workflows and prompts drew a blank:


I don’t know what inspired me, but I thought I’d try “tricking” it with an empty string for a TTS prompt, and that turned out to be the answer!

Here’s how I fixed the Workflow above:

$GreetingAudioFile = Import-CsRgsAudioFile -Identity $ServiceId -FileName "TestRgsGreeting.wav" -Content (Get-Content "C:\TestRgsGreeting.wav" -Encoding byte -ReadCount 0)
$PromptWM = New-CsRgsPrompt -AudioFilePrompt $GreetingAudioFile -TextToSpeechPrompt ""
$Queue = get-csrgsQueue $serviceID -Name "TestSfB-Queue"
$DefaultActionWM = New-CsRgsCallAction -Prompt $PromptWM -Action TransferToQueue -QueueID $Queue.Identity
$Workflow = Get-CsRgsWorkflow $ServiceId -Name "Broken SfB Workflow" 
$Workflow.DefaultAction =  $DefaultActionWM
Set-CsRgsWorkflow -instance $workflow


BTW, this issue has been duplicated on separate EE and SE pools, all running SfB2015 CU5, as well as an SE Lync 2013 pool running the latest CU (5.0.8308.992).

DON’T reinstall your speech server platform

KB3205116 comes up if you search for Event 31140, suggesting you need to uninstall and reinstall the speech server platform runtime. That may indeed be your problem, but I wasn’t convinced – TTS was working fine for me, it was the WAV (and eventually WMA) files it wasn’t liking. (OK, yes I might have eventually reached the point of trying this had I not had my brainwave).


There are lots of good posts out there that walk you through the RGS creation process using P$:

Interestingly enough, *I’ve* even blogged the process of changing recordings before using PowerShell, and I didn’t encounter this issue at the time. (I’ve since updated that post with a link back to here).

Revision History

2nd September 2017: This is the initial post.


– G.

Leave a Reply

Your email address will not be published. Required fields are marked *

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.