For anyone keeping score this now makes the third blog entry in as many days related to Exchange and Lync Unified Messaging integration.  If you followed the previous configuration article and ended up here because calls to the Subscriber Access are working but calls to the Exchange Auto Attendant fail, then here is a quick fix.

Problem

Calls placed to the Subscriber Access number or any calls to offline users which are forwarded to the Exchange attendant work normally.

But when placing calls from OCS or Lync clients to the Exchange Auto Attendant the call immediately fails and the following event log entry can be found on the Exchange UM server.

Log Name:      Application
Source:        MSExchange Unified Messaging
Event ID:      1021
Task Category: UMCore
Level:         Warning
Computer:      exch.schertz.local
Description:
The Unified Messaging server rejected an incoming call with the ID "5cf1ddf281595cefc56af46855fc95d3". Reason: "The Unified Messaging server can’t find a valid UM hunt group for "Auto Attendant.ExchangeUM" associated with UM IP gateway "lync.schertz.local"."

Regardless of how the Active Directory contact was named when created by the OCSUmUtil utility the incoming call will append the name of the contact to the Pilot Identifier string.  Calls to the Subscriber Access number will only use the Dial Plan name (e.g. ‘ExchangeUM’) which successfully match the Pilot Identifier string set on the UM Hunt Group which was automatically created by running the ExchUtil.ps1 script.

Resolution

Update:  Thanks to a recent comment it was brought to my attention that the original workaround in this article (which I have left in for posterity, but has been struck-through) was actually routing both calls to the Subscriber Access attendant.  I just verified the call completed and not listened to the greeting to notice this behavior.

So I revisited the original issue, and with the help of an extra set of eyes realized that the root cause was I had used a space in the name of the Exchange Auto Attendant (as seen in the Application log error above).  Doh. Spaces will get you every time.

To resolve the issue simply delete the existing auto attendant in Exchange and then recreate it using the same settings, but omitting any spaces (and probably avoid other non alpha-numeric characters for good measure).  The example below shows a supported AA name of AutoAttendant.

Although it may not have been necessary I also recreated the SA contact object in AD using OCSUmUtil.exe and then restarted the MSExchangeUM service on the Exchange UM server.  At this point calls to both the SA and the AA functioned correctly.

The simplest fix I found for this issue was to just create a second UM Hunt Group pointing to the same UM Dial Plan, but using the ‘missing’ string as its Pilot Identifier.  This way both ‘types’ of calls will be supported.

• Create a new UM Hunt Group and enter a unique Name.  Select the desired Dial Plan (e.g. ‘ExchangeUM’) and then enter for the Pilot Identifier the exact string shown in the 1021 warning event (e.g. ‘Auto Attendant.ExchangeUM’)

At this point there should be two unique Hunt Groups set on the same UM IP Gateway.