Newly created Speech Enabled Auto Attendant announces: “Please call back later. Goodbye.” with event ID: 1086 warnings in the event logs

I’ve been working on a project for a client with Exchange 2007 Unified Messaging for the past 2 days as they prepare for two remote office deployments next week. Other than getting the NET VX1200 gateway and Polycom SIP phones configured and tested, I also had to create new Exchange UM auto attendants configured for the remote offices. I always find that no matter how simply the deployment may appear to be, it almost never goes smoothly and this one is no exception as I ran into a strange problem with getting these new speech enabled AAs to work.

Problem

You create a new Exchange 2007 Auto Attendant in the Exchange Management Console as such:

You make an attempt to call 5979 to reach the AA greeting and all you hear is:

“Please call back later. Goodbye”

This AA response is typically presented if there was something wrong with the prompt’s speech recognition so I went into the event logs to see if I could find more information and by reviewing the Application logs on the Exchange server, I found the following warning logged:

Automatic Speech Recognition (ASR) has been enabled on the UM auto attendant “MainAA”. However, the speech grammar file “C:Program FilesMicrosoftExchange ServerUnifiedMessaginggrammarsen2d45da8d-6bb5-40c8-a79a-6d59911369de.cfg” cannot be found. Until this problem is corrected, ASR will be disabled for this auto attendant.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Just so I was sure that there was something wrong with this prompt, I went ahead to create a DTMF fallback prompt as such:

… to see what would happen and as expected, calling into the speech enabled prompt immediately played the message:

“Let me transfer you to our touch tone service.”

Analyzing the Problem

The warning message gave a pretty good explanation of what was causing this so I went ahead and navigated to the directory:

C:Program FilesMicrosoftExchange ServerUnifiedMessaginggrammarsen

… to see if the .cfg file:

2d45da8d-6bb5-40c8-a79a-6d59911369de.cfg

… actually existed and not surprisingly, that file wasn’t there.

So after searching this specific warning on the internet, I found that there was a 30 minute interval schedule that the generator rules on so I went ahead to use PowerShell to check and got the following output:

GrammarGenerationSchedule : {Sun.2:00 AM-Sun.2:30 AM, Mon.2:00 AM-Mon.2:30 AM,
Tue.2:00 AM-Tue.2:30 AM, Wed.2:00 AM-Wed.2:30 AM, T
hu.2:00 AM-Thu.2:30 AM, Fri.2:00 AM-Fri.2:30 AM, Sa
t.2:00 AM-Sat.2:30 AM}
IsValid : True

Seeing how the scheduling wasn’t the problem, a bit more digging revealed that you could force Exchange to regenerate this file with galgrammargenerator.exe. Since I was familiar with this executable, I figure I give it a shot but after executing every single switch I could find, the cfg file wasn’t created.

Since it was getting late in the day and this didn’t have to be resolved, I went ahead and posted the question on our Microsoft Partner Forum to see if I would get a resolution the next day.

Solution

So the Microsoft Partner Support Engineer wasn’t really able to help out as the response I got back was to send him some more information and since it was semi-important to get this resolved the next day, I went back to troubleshooting it myself. I think starting fresh in the morning really helped because as I continued to run galgrammargenerator.exe and fiddle with the dial plan and users, I somehow got another cfg created:

While this was generated for another AA, it ended up leading me to figure out what was the cause of my problem.

So what happened? What happened was that Exchange 2007 WILL NOT be able to generate the cfg file if you do not have anyone enabled for Unified Messaging in the dial plan. I got lucky in the morning because I was also testing subscriber access so I had to enable myself for Unified Messaging for another dial plan and ended up creating the new cfg file when I reran galgrammargenerator.exe.

The following is essentially what you need to do if you run into this situation:

1. Make sure you have someone enabled for Unified Messaging in this dial plan.

2. Navigate to C:Program FilesMicrosoftExchange ServerBin> and execute GALGRAMMARGENERATOR.exe -s exchServerName.

C:Program FilesMicrosoftExchange ServerBin>GALGRAMMARGENERATOR.exe -s exchca

s2

======================

GalGrammarGenerator started. Time: 19/11/2010 9:39:01 AM

GalGrammarGenerator finished. Time: 19/11/2010 9:39:02 AM

3. Open up Windows Explorer and navigate to the folder: C:Program FilesMicrosoftExchange ServerUnifiedMessaginggrammarsen and check to see if the cfg file has been created. You can also check in the event log for the information event ID: 1140 and 1141 which will tell you it has successfully created the cfg file:

The Unified Messaging server has successfully generated a speech grammar file for UM dial plan “CA-OTT”.. The grammar file is named “C:Documents and SettingstlukLocal SettingsTemp12d45da8d-6bb5-40c8-a79a-6d59911369de.grxml”.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The Unified Messaging server has created a grammar file named “C:Documents and SettingstlukLocal SettingsTemp12d45da8d-6bb5-40c8-a79a-6d59911369de.grxml”. The grammar file was then compiled into a file named “C:Documents and SettingstlukLocal SettingsTemp12d45da8d-6bb5-40c8-a79a-6d59911369de.cfg”.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Nothing to it right? I guess it sort of makes sense for a speech enabled auto attendant to require having “users” or “a user” to be enabled for UM so it has something to put into that cfg file when doing name lookup.