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.


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
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.


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.


By Jeff Schertz

Site Administrator

22 thoughts on “Lync Calls to Exchange Auto Attendant Fail”
    1. Thanks Harry, I'm glad the short articles are helpful too. It takes a LOT of time to put the long ones together; I don't know how many more of those I have left in me this year. The Lync launch is keeping everyone a bit busy these days.

  1. I tried with the way, it does fix the issue with failed call. But the call end up in the same greeting like subscriber access. Did I do something wrong?

    1. Daniel, you were following the directions correcty. I've since updated and fixed this article as the root cause was identified and the resolution is now different. Sorry about that. 🙂

  2. Hi Jeff,

    You were right about the spaces in the AutoAttendant name, but even when you specify a dial plan name with spaces it will end up wrong. Just to know.

    With regards.

  3. Hi Jeff! I've found this article because I had the same issue twice. The first time, I've re-created my AA and it fixed the problem. The second time, we had – it appears – an invalid custom greeting. This is described in the following event: "The Unified Messaging server wasn't able to retrieve the custom prompt data for the UM auto attendant "CCS". Check the auto attendant configuration to ensure that all custom prompts have been configured correctly. ""."
    I understand it's totally a different issue. But, it may be misleading to actually recreate the AA just for that.

  4. Hey Jeff,

    First off thanks for all your articles they have been so helpful in my deployment! I am having an issue with getting the Exchange Auto attendant to pick up when the Lync Attendant Console is in DND. Any idea what i could be missing? It picks up in every other instance but DND goes to fast busy.

    Thanks for any insight you may have!

  5. Hi Jeff,

    I had high hopes that this would address my problem but, alas, it does not… In my case AA works but SA doesn't. Both contacts have alphanumeric only and no spaces. I'm wondering if the length of the names could be causing issues. Any credibility to that?


    1. I haven't looked into this in a long time, but it's possible there is a character limit. I would try testing the exact examples I've provided to see if that helps.

  6. Dear Jeff,
    did you have this issue:
    Lync 2013 Full Updates and Exchange 2007 SP2 Rollup 5
    Calls to All UM Services works, even call to AA works and if i try to find people by their name or dialing their extension works fine. but when AA confirms the transfer to Extension it takes about 3 minutes to transfer the call. currently name of Lync Dial Plan and Exchange UM name matches as this technet documentation offers this type of configuration:

    is there any idea?

  7. Thanks Jeff! Love your work and love that a 5+ year old post can still help a SFB & Exchange 2013 deployment.
    Your updated resolution saved me when I strayed from the cardinal rule. No_Spaces_in_the_IT_World

  8. I having the same issue as above but one thing that is different in my environment is I have no external numbers setup and no SBC
    what I want is to have Skype voicemail using unified messaging without the external number. is this possible

    so in essence i want voicemail for internal only with the option to add an external number later when we get the SBC and PSTN up and running

  9. Hello,
    We have exchange 2013 and Skype For Business configured and integrate. I am facing issue with Auto Attendant When I tried to call my number I am getting this on event viewer and call ended.
    Event ID: 1647 UMCallRouter
    The Microsoft Exchange Unified Messaging Call Router service rejected the call for the following reason: 15639;source=””;reason=”No Organization Mailbox was found with “UMGrammar” Capability.” Microsoft.Exchange.UM.UMCore.CallRejectedException: No organization mailbox for organization “” was found with the assigned capability of UMGrammar. Please make sure there are one or more organization mailboxes with this capability. If there isn’t at least one organization mailbox available, auto attendant and pilot number call routing won’t work correctly.
    at Microsoft.Exchange.UM.UMCore.RedirectionTarget.GetForNonUserSpecificCall(OrganizationId orgId, IRoutingContext context)
    at Microsoft.Exchange.UM.UMCore.AutoAttendantCallHandler.HandleCall(CafeRoutingContext context)
    at Microsoft.Exchange.UM.UMCore.RouterCallHandler.InternalHandle(ICallHandler[] handlers, CafeRoutingContext context)
    at Microsoft.Exchange.UM.UcmaPlatform.UcmaCallRouterPlatform.TryHandleIncomingCall(CallReceivedEventArgs`1 args, Exception& error, Boolean& isDiagnosticCall)
    at Microsoft.Exchange.UM.UcmaPlatform.UcmaUtils.c__DisplayClassf.b__d()
    Also my Voice subscriber working fine but i don’t what happend with auto attendant.
    Please help me

Leave a Reply

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