Under Exchange 2010 we were never able to get 4 digit extensions in auto attendant menus to transfer - we would get the "the call could not be transferred - returning to main menu" message.  We specified the whole 11 digit DID instead and transfers worked, so we stuck with that for the last couple of years. I now realize the latter worked because our Global Dial Plan in Lync had a normalization rule for 11 digits (but not for 4). It never occurred to me before because we only use User Dial Plans and the fact that Exchange normalizes via the Global Dial Plan in Lync doesn't appear to be well documented.

Fast forward to our Exchange 2013 migration, which is now complete, and all the AA settings came over as they were before and still work.  BUT we have our first changes to be made now that the holidays are approaching, and we've discovered that in 2013 the gui forces you to use the number of digits your dial plan extensions are set for (in our case 4) - it won't accept the 11 digit workaround any more (existing 11 digit values continue to transfer properly).

The problem with using the Global Dial Plan in Lync to normalize is that we have 3 different user dial plans, and there are some overlapping extensions between them - so the global dial plan won't work for us.

My understanding is that Exchange dialing rules should be used to normalize the numbers before they get passed to Lync - but it doesn't seem to work.  I created a dialing rule for number pattern xxxx with +1619683xxxx as the
dialed number, but it doesn't work.  Snooper shows that the plain 4 digits are still getting passed directly to Lync with no normalization, and fail.

Anyone know how to get the dialing rules to normalize properly?

Thank you!

Unfortunately, I think you may be stuck creating a new dial plan with the full amount of digits and migrating users over to it.

Did you find another solution?

That isn't workable because then callers won't be able to dial users via their 4 digits extension.

PSS has confirmed that this functionality was changed in a CU (most likely the most recent CU3) so we'll see if the team will consider reverting that pointless (aesthetic) change.

In the meantime we have to use ADSIedit to manually edit the XML that makes up the AA menu navigation configuration.

How is the ADSI edit working for you?  I'm interested in that and I would expect others would be as well.  What are the steps you take?

PSS confirmed it's CU3 that introduced this change.  Hopefully the team will reconsider and revert with SP1.

use adsiedit.msc to find this DN (CN=lync2013_AA,CN=UM AutoAttendant Container,Cn=SHECS,CN=Microsoft Exchange,CN=Services,Cn=Configuration,DC=marry,DC=com)

Then find attribute MsExchUMAutoAttendantBusinessHourFeatures

This attribute is an XML file that you can copy into notepad and then edit the phone number you'd like to change... then copy and paste back into the attribute.

Received this gem from PSS:

"You opened a professional case. For professional case, we are not able to open DCR to product team.

Please open a premier case to us so that I can raise DCR as per your request.

I am sorry for that . But this is our policy and hoping you can understand.

If you can not open premier case, I suggest you can use my suggested workaround to use adsiedit.msc to modify the AA transfer menu to bypass this limitation in GUI."

PSS case # is 113122011043395 in case anyone here has any ideas on how to get this in front of the team. This policy is ridiculous - we can't afford a premier case.

Try to get phone context of UM dial plan (get-umdialplan dialplanname).phonecontext, then take this string and add dialplan in Lync with Simple Name equal to this string.  This way you will link two dial plans.