Reverse Name Lookup failing between dialplans after migrating to Exchange UM 2010

Let's imagine the following scenario: You have an Exchange 2007 UM deployment with a couple of dialplans and just added a 2010 UM server in the domain.

You create a new dialplan on the new server and migrate a test user both to the new server and the new dialplan. This is a common scenario if you have OCS integration: for PBX integration, you would just add the new server to the existing dialplan and voilà, it works; for OCS, though, you need to have a new dialplan on the new server. Let's also suppose you are using extensions on your server and that you have disabled the heuristic AD search on the dialplans (AllowHeuristicADCallingLineIdResolution=$False). The server should still identify the callers based on their proxyAddresses or msRTCSIP-Line, right? (https://technet.microsoft.com/en-us/library/dd351203.aspx) Well, yes, but not quite, and this is why:

0. If your normalization works or the caller ID is E.164 compliant and if the msRTCSIP-Line attribute is correctly configured, then you're good to go.

1. If the caller is from the same dialplan as the callee, then no problem, he/she will be identified immediately: the server searches the AD for users with the attribute proxyAddresses set to "eum:<caller extension>;phone-context=<currentdialplan.domain.com>".

2. If the caller is from another dialplan, then the key word in 2010 is "equivalent dial plan" - in Exchange 2010 the property "EquivalentDialplanPhoneContexts" is introduced. What this does is simply tell the server to append "phone-context=<dialplan.fqdn>" (with each of the FQDNs specified in this list) to the caller's phone number when searching for the caller in the AD usign the proxyAddresses attribute. The catch here is that setting a single dialplan (e.g. your new Exchange 2010 dialplan) with this setting won't do anything - for the equivalence to work, two equivalent dialplans need to be paired by putting each of them in the other's EquivalentDialplanPhoneContexts list. For the 2007 server, this means upgrading the dialplan (to upgrade a dialplan simply perform a modification on it from an Exchange 2010 console or shell).

There are a couple of downsides in upgrading the dialplan, but depending on your environment they may not be a problem:

- Once upgraded, you can no longer edit the object from an Exchange 2007 console/management shell (you can only do it from Exchange 2010).

- All calls must be routed to the Exchange 2010 server, which will handle redirection if the user is still on a 2007 server. This should present no problem if the 2007 servers are at least SP2 and the calls comes from the PBX, but it will be a problem (will stop working) if the dialplan accepts calls from an OCS environment.

Regarding this last point, the behavior with the OCS dialplans is the following: when migrating from Exchange 2007 to 2010, you need to have two dialplans - one on the 2007 server and one on the 2010 server, with the calls to the 2007 users sent through the 2007 server and the calls to the 2010 users sent to the 2010 server. This is because the OCS server will not accept the redirection done by Exchange 2010, so upgrading the dialplan and routing the calls to the 2010 server is not an option in this scenario. As a consequence, the 2007 dialplan handling the calls from OCS will need to rely on the other RNL options (msRTCSIP-Line or heuristic search) and not on the proxyAddresses for resolving caller names from the other dialplans.

Sorin