The Mk-II Safety Net for Lync Gateway AD-Lookups

My August “Safety Net for Lync Gateway AD-Lookups” plugged a sometimes embarrassing hole in the AD-lookup process, but it still left a smaller one. Whilst it ensured a user was EnterpriseVoiceEnabled before the UX would send a call to them, it didn’t cater for those deployments where the user’s msRTCSIP-Line number was in the “;ext=” format. The fix (for those who twigged to this) were duplicate transformation tables and routing table entries for both the AD lookup and the Safety Net.

I wanted to do this all in one entry, but the UX firmware at the time wouldn’t permit it. Enter v2.2, and its new feature that permits multiple AD lookups in the same Transformation Table.

UX AD lookups (pre 2.2)

Prior to v2.2, you could only perform one AD query per pass through a Transformation Table:

The first AD lookup in each transformation table sets the result set for the remainder of that transformation table.

  • If the first AD lookup of a transformation table returns nothing, then all subsequent AD lookups in that transformation table will also return empty
  • If the first AD lookup of the transformation table is for John Doe, all the remainder AD lookups in that transformation table must also be for John Doe. A transformation table cannot contain AD lookups for more than one user.

This then forced us into two separate tables if we wanted to test for BOTH the raw number, and the same with the ;ext= suffix.

2.2’s new “==” Query Command

With 2.2 we can now force a fresh AD lookup by specifying a double-equals. This lets me query AD for an msRTCSIP-Line value of “blah”, then repeat in the same table for “blah;ext=yadda”. With the Match Type set as Optional, the table is true provided one of these matches.

The Mk-II AD Lookup

Here’s what the AD Lookup Transformation Table looks like now:


The first 3 lines (in red):

  1. format the Called number into E.164
  2. test it for a match in AD, and if found, pre-seed “User Value 1” with 385 (the flag that indicates we’re EV-enabled)
  3. which it then compares with the value of msRTCSIPLine-OptionFlags and stuffs the Called number in User Value 2 *if* the user is EV-enabled

The next 3 lines (in green) repeat the same test, having first changed the Called number to the “ext=” format.

The solitary line in blue reinstates the Called number from User Value 2. It will be in “;ext=” format if the second (green) tests passed, or have just the number if the first (red) tests passed. (It’s not possible for both tests to pass).

The final 2 lines in yellow format the Calling number.

Note that the Match Type pairs shown in orange are crucial for the correct operation of the table. One pair of these need to be true for the table to be true, and the logic inherent in the table prevents us matching on the top element in one orange box and the bottom one in the other.

The Mk-II Safety Net

The Safety Net follows the same structure as the AD Lookup Table:


The first 2 lines format and test the plain Called number for a match in AD, whilst the next two repeat this for the “ext=” version. Should either test be true, we stuff the Safety Net number into User Value 2. This makes the table true, and then User Value 2 is reinstated as the Called number.

The Routing Table

The routing table is unchanged from before, but repeated here for completeness:


Don’t Be Trapped by the AD Cache

To test your Safety Net, my recommendation is to use four test accounts, each configured with a different combination of LineURI and EnterpriseVoiceEnabled, rather than just changing one and watching the outcome. If you take the latter approach, you’ll have to wait for the “Lync Lag” with every change, and also manually refresh the UX’s AD cache. Throw in delays associated with AD replication and you might start to see my point.


The UX’s AD-lookup is NOT case-sensitive, which is a relief because Lync will let you specify a LineURI in any combination of case. With Active Directory / Configuration / Cache Settings / Normalize Cache set True the UX strips off “Tel:”, and our tests for a number in “ext=” format will match correctly, regardless of whether the user’s LineURI was stored as “ext=” or “Ext=”, etc.

Leave a Reply

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

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.