This is interesting. I actually thought Chris was on to something because I recall seeing something similar to your issue when we enabled EM on the device. You don't have to have the EM service running for the issue to present itself.
It has been a while since I mucked with 4.1. So, I am going from memory. One of the first things I would attempt is seeing if I could find the redundant records by using Dependency Records.
If that didn't bear any fruit, I would go to the database. On a 4.1 system, you can RDP to the console and launch SQL Query Analyzer. I don't recall the sequence but possibly Start > Program Files > Enterprise SQL ?? > SQL Query Analyzer. Once loaded, you need to attach to your DB. Should be in a drop down or something. Maybe there is a tree rendered in the left hand pane? (That could be Enterprise Manager?). Anyway, connect to your DB somehow.
Then you can a query like the following:
SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid inner join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name
The result should give you a list of DNs in numeric order and a device should be listed next to the DN. The query above just focuses on one DN. So, use a DN that your CM is reporting as a shared line. All you are looking for is more than one instance of the DN. To clarify, CUCM (and CM) store all numbers in a table called "Numplan". Entries are unique. Associations to devices are made by way of "DeviceNumPlanMap". When a DN is shared, there will be more than one reference to it in the "DeviceNumplanMap" table.
If you only see a single occurence then we can try this query:
SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid left join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name
The above query is just checking for entries in DMAP and is not constraining the output by requiring an association with a particular device. If the first query only showed one entry and the second shows 2 then I expect that the second entry also shows a row where the value for device is blank. This would be a problem.
If you still don't see two entries then I would jump on a subscriber node and repeat the queries.
I'd also probably check replicaiton "just to be sure".
If the SQL queries are coming up "clean" (meaning, you don't see a shared line appearance) then it isn't coming from the DB and it is something else that is suspect. Perhaps RIS or DBLHelper. Though, I am not sure how likely that would be. On 4.1 I recall issues with CFA getting stuck (a DBLHelper issue) and with IP addresses/registration status missing (a RIS issue) but nothing related to erroneously reporting shared line appearances. Anyway, to clear it up you may need to restart some services (or the nodes themselves). Then you can do some bug searching to see if you can find root cause.
Now, if you find that the second query kicks out duplicate entries without a device association then the only way to remediate that is to clean up the devicenumplanmap table. Now that I think about it, I think that the schema requires a fkdevice entry but I would have to look at the data dictionary to be sure it is enforced. We can cross that bridge if you determine this is your issue.
HTH.
-Bill (http://ucguerrilla.com)
