. . . why the duplicates?
I started on 3.08, then 3.09 and both had the duplication issue. Now, I am running CM 3.12c and still have the duplication issue crop up periodically.
I have found that what you do in the CM System Administration screens (when deleting extensions) isn't always reflected in the tables due to other devices (hunt groups for example) pointing to the deleted extension.
Given:
A device with x5108.
A Pilot Point configured with a Hunt Group pointing to x5108.
Procedure (to create the problem):
1. Delete x5108 and update.
2. Delete the device that used x5108.
At this point, the Phone Administrator (person) thinks all is well because the System Administrator interface reports no errors, but the DBA would see something different. But if you would look at the NumPlan table, you would find that the x5108 record still exists . . . because the Hunt Group is still pointing to that record. Somehow, SQL knows about the reference and DOES NOT delete the record, even though the System Administration utility goes happily on its merry way. Even if you delete the Hunt Group's reference to the deleted extension AFTER deleting the phone, the record still stays in the table.
To resolve use the following (same process from my previous post):
1. Look at the NumPlan table, look for duplicate extensions and their corresponding "fkRoutePartition" field values.
2. Look at the RoutePartition table and match the NumPlan's "fkRoutePartition" values to the RoutePartition's "pkid" values for the corresponding Partition. Make a note of the "name" values.
3. Go into the CM SA web utility, go to the phone device and delete the existing extension (this should delete one of the duplicates, or triplicates, etc, in the NumPlan table).
4. Click on "Line X", key in the same extension and the duplicate's partition Name. At this point (since the row is already in the table), the other values should auto-populate (like the CFNA, CFB, CS's, etc).
5. Click on Update and Close, then Update at the device level.
6. Go back into the problem extension, click on delete.
7. Check the NumPlan table and that duplicate extension should be removed.
8. Repeat for additional duplicates.
Further research (from an illiterate), shows that CSCdt27581 (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdt27581) says to manually delete the record from the NumPlan table . . . my question to this solution is:
What is the state of the Hunt Group at this point?
Would it be pointing to an invalid "pkID" after the record deletion? Then what would happen? (according to one of the previous posts, this record couldn't be deleted, so this question is probably moot)
Could it be that some of these (and possibly other) issues are because the System Administrator doesn't seem to enforce table integrity as well as what the SQL does?
Any more, when I delete an extension, I run Enterprise Manager in parallel to make sure what I did in SA really happened in SQL. I also periodically open the NumPlan table and check for duplicates.
