I recently learnt to my combined irritation and eventual delight that even if your phone numbers are perfectly formatted as E.164 in AD, you still need a rule in “Company_Phone_Number_Normalization_Rules.txt” that (effectively) normalises them – even though they already are. (Read that saga here).

But it dawned on me shortly thereafter that if Lync’s filtering ALL numbers in AD – and even your msRTCSIPLine – through “Company_Phone_Number_Normalization_Rules.txt”, perhaps I can turn the rules to my benefit?

I’ve long lamented the user confusion that arises from Lync offering you “Lync Call” and the user’s desk phone number (“Work”) as apparently separate ways to call someone when they’re in fact the same thing (to a fully Enterprise Voice deployment). Can’t we turn one of them off?

So I experimented and found that yes, the judicious application of some rules to the file actually lets you “hide” numbers in your Indial range from view. Here’s the relevant extract from my Lab’s file, with my fake hundred-number indial range now invisible to Lync clients:

## AU Number in VALID international format: +61 2 1234 5678
## Addresses all but NSW/ACT
\+61([3-8])(\d{8})
+61$1$2

## AU Number in VALID international format: +61 3 1234 5678
## NSW/ACT addresses - all but "MY" prefix
\+612(?!(700012\d\d))(\d{8})
+612$2

The end result of the above is that all other numbers in Australia pass the test and end up in the Address Book, EXCEPT those for “+612700012xx”. [NB: I have refined this rule since the initial post. It works even better now].

Now I’m not sure if this is going to work out in the end, or break something. (Call transfers?) But I thought it’s an interesting solution. I’ll take it for a test drive on my next 100% EV deployment and report back on the wisdom or folly of this venture. :-)

– G.