Can I configure CUCM to ignore orphaned extensions?

[kylebrogers]

Let's say I have extension 1500/DN.  Even if it's not assigned to a device like a phone, CTI Route Point, etc. calls still get routed to it.  Is there a service parameter that I can set that would tell the phone system to ignore orphaned extensions and continue looking for another match?  So that if 1500 is orphaned, a less specific 1[3-5]XX/DN route pattern would pick it up?  

[Jaime Valencia]

No, if it's in the DB, it will try to route to it.

The only option is to delete them, and make sure they don't remain under unassigned DNs.

[kylebrogers]

Deletion won't be an option for me.  To make a long story short, I have a new CUCM and an old Avaya system connected to each other as I do a long migration of users from Avaya to Cisco.  I want to have the Cisco system LDAP integrated so it's assigning every LDAP user their primary extension (and creating it in the system) as soon as they're pulled in.  The problem is that as soon as their extension is in the CUCM system, Cisco phones trying to call their Avaya phones (through the wild card route pattern) are hitting the orphaned extension instead.  It looks like I'm going to have to give up on LDAP integration until the end of the project and go back to using BAT instead of self provisioning.  Requiring the Primary Extension is a serious flaw in the new Self Provisioning system - at least for your typical migration scenario.   

[Jaime Valencia]

Your only other option would be to create the exact same DN in another partition, make sure it's above the one created by self-provisioning in the CSS, and then choose what to do. The wildcard will never work if the device has both available in their CSS, best match will always be used.