Understanding Exchange UM Name Lookups

Unified Messaging uses two data sources to receive information about the calling party and to map it to the name of the caller: Active Directory and personal Contacts. When the name lookup process is successful, the name of the calling party will be inserted into voice mail messages and missed call notifications if they’ve been enabled for the called party. When an incoming call is received, the calling party information is passed to a Unified Messaging server.

In Exchange 2007, name lookups for voice mail messages are done by using information about a caller who’s in the same dial plan as the user being called in one of the following ways:

  1. Using an EUM proxy address.
  2. From the personal Contacts of the user receiving the call.
  3. Using the msRTCSIP-Line attribute in Active Directory if Service Pack 1 (SP1) for Exchange 2007 was installed and Exchange 2007 was integrated with Microsoft Office Communications Server 2007 or Office Communications Server 2007 R2.

In Microsoft Exchange Server 2010, the name lookup methods differ from those used in Exchange 2007. The following steps are used in Exchange 2010 to look up a name from the calling party’s information:

  1. The caller’s name is used if the caller signed in to their mailbox from Outlook Voice Access or if they use a Microsoft Unified Communications client such as Microsoft Office Communicator 2007 or Communicator Phone Edition to place the call. The caller’s identity is known because they’ve been authenticated when they use Outlook Voice Access, Office Communicator 2007, or Communicator Phone Edition.
  2. The EUM proxy address or addresses in Active Directory are used. If the proxy address contains an ‘@’ sign, it’s considered a SIP URI. If the proxy address begins with a ‘+’ character, it’s considered to be an E.164 number. If neither of these characters is present, the proxy address is considered an extension within the same dial plan as the called party or an equivalent dial plan.
  3. If the caller ID is a valid SIP URI, Active Directory is used to resolve the SIP URI using the EUM proxy address or addresses.
  4. If the caller ID is a valid E.164 number, Active Directory is used to resolve the number to the calling party’s name. For this to work correctly, you must have manually configured the UMCallingLineIds parameter on the UM-enabled mailbox for the called party. This configuration is useful when you don’t want to publish a telephone number, such as a personal mobile phone number, in Active Directory, but still want to resolve the calling party’s name by using this phone number.
  5. Active Directory heuristic matching is used, if it’s enabled, to resolve the number to the calling party’s name. Active Directory heuristic matching must be enabled on the dial plan, and the user’s account in Active Directory must be populated with one or more of the fields, such as telephone number, home, or mobile, for this to work correctly.
  6. The personal Contacts of the called party are used to resolve the number to the calling party’s name.

 

Improved E.164 Number Resolution
In Exchange 2010 Unified Messaging, four new methods are used to improve resolution of the caller ID to the calling party’s name.

  1. Calling Line ID’sIn Exchange 2010, a multivalued attribute named msExchUMCallingLineIDs was added to the Active Directory schema. This attribute enables a UM server to take an E.164 number or set of numbers, convert the number or numbers, and then perform a name lookup. This attribute can contain a list of numbers that are mapped to a specific user and can be configured on the user’s Active Directory object. For example, you could add the numbers, 4255551010, 14255551010, and +14255551010 to the msExchUMCallingLineIDs attribute for a specific user. Although the last number in this list is an E.164 number, a correctly formatted E.164 number isn’t required. You can add any phone number that looks like a valid phone number that contains digits, and those digits can, optionally, begin with a plus (+) sign.
  2. Number Plan Formats for Dial PlansThis is a form of number normalisation so the Exchange can correctly match a caller ID to an AD user. When a UM server answers an incoming call, it reads the caller ID. The UM server will parse the list of configured number plan formats from the top down until a match is not found or there’s a conflict in the digits where x in the number mask is treated as a wild-card. When this happens, the UM server will try to back fill the caller ID for the incoming call into each number mask.For each UM dial plan, there’s an msExchangeUMCallingLineIDFormats attribute that can be configured using the NumberPlanFormats parameter to specify one or more phone number masks that can resolve caller IDs to names in Active Directory. The following figure shows this attribute and the numbering plan formats.

  3. Active Directory HeuristicsExchange UM can use the phone number fields, such as telephone number, home, or mobile, that are configured for a user who’s in Active Directory. However, there’s no way to select which of the phone fields to include. The following telephone attributes for a user in Active Directory will be used to resolve a caller ID to a name:
    • telephoneNumber
    • homePhone
    • mobile
    • facsimileTelephoneNumber
    • otherTelephone
    • otherHomePhone
    • otherMobile
    • otherFacsimileTelephoneNumber

    This is controled by the msExchAllowHeuristicADCallingLineIDResolution attribute on each dial plan, and is set to true by default.

    Potential issues that prevent resolution of a caller ID to a name:

    • The administrator didn’t enter a number in the Telephone number field.
    • The administrator doesn’t use the Telephones tab at all for phone numbers.
    • E.164 numbers are entered without any parentheses, hyphens, or the correct spaces.
    • The numbers aren’t in the correct E.164 format. Examples of the correct format include the following:
      • (425) 555-1010
      • (425) 555-1234 x51010
      • (425) 555-1234 ext. 51010
      • 425-555-1010
      • 425.555.1010
      • 425/555-1010
      • 1425-555-1010
    • Both extensions and international numbers are used. Examples that show both extensions and international numbers used together include the following:
      • +7890
      • +441234567890
      • +44(1)234567890
      • +44 (0)1 2345 6789
  4. Equivalent Dial Plan GroupsThe concept of an equivalent dial plan has been added in Exchange 2010 Unified Messaging to allow UM administrators to connect two dial plans that are in the same PBX numbering plan but are broken into two dial plans. Two dial plans might be contained in a single PBX numbering plan, for example, when users in the two separate dial plans sit next to each other and can dial each other using an extension number but exist in different dial plans for reasons unrelated to the telephony infrastructure.For every dial plan, there can be an equivalent dial plan phone context for two or more dial plans that should be one dial plan but have been separate. You can add names for other dial plans and link to other dial plans. The dial plans you enter names for or link to can be in the same Active Directory forest or in different forests. When you add an equivalent dial plan, the dial plan’s phone context will be automatically added to the equivalent dial plan group.

Voicemail and Missed Call Notifications

When Exchange UM processes a missed call or voice mail, it saves the metadata to a text file on the local disk prior to sending an email to the hub transport. If the hub transport is not available, the files remain on the local disk. By default, the files are stored in the %ProgramFiles%MicrosoftExchange Serverv14UnifiedMessagingvoicemail folder.
Missed Call Metadata

 

Voicemail Metadata
Andrew Morpeth
Andrew Morpethhttps://ucgeek.co/author/amorpeth/
Andrew is a Modern Workplace Consultant specialising in Microsoft technologies based in Auckland, New Zealand; Andrew is a Director and Professional Services Manager at Lucidity Cloud Services and a Microsoft MVP.

Related Articles

1 COMMENT

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Andrew Morpeth
Andrew Morpethhttps://ucgeek.co/author/amorpeth/
Andrew is a Modern Workplace Consultant specialising in Microsoft technologies based in Auckland, New Zealand; Andrew is a Director and Professional Services Manager at Lucidity Cloud Services and a Microsoft MVP.

Latest Articles