Hi Rob,

Thanks for your thoughts.  Suprising no one else has dealt with this?  NOT!  Managing DID is very simple as I said I do have a process in place, I am just looking for a way to make it all happen at once.  Today's IT professional is already taxed to the limit.  Optimizing time is a top priority.

Just curious do you use SOAP to export your data?  If not what method do you use?  Which database do you use?  I have discussed this with Netcraftsmen Bill Bell.  He has some excellent blogs on these type of things.  My objective (when ever I find the time) is to simplify things like Auditing, CAR/CDR, logs etc.  I hope they all don't end up as just enhancement requests!

I should look into a UC users group it would be useful to meet with other UC professionals and share ideas.

Saludos!

Mark

This is definitely an interesting topic and one that doesn't get a lot of emphasis to be honest.  Bill Bell and I have worked together for a long time.  At one of our previous companies with a very large deployment (15,000 users), we put together some simple manual processes for the operations team to follow. We actually kept all unassigned devices and unallocated numbers configured within the CCM (at the time it was 4x so there was no separate DN database).  Anyway, it was something like this:

1) Request to decommission existing phone came in

2) The phone was retrieved from the location it had been deployed

3) The Description on the Device level description was changed to "Unassigned Phone" and the Line Level settings were changed to "Unassigned DN" (where applicable).

4) When a new phone request came in, a phone was pulled from inventory and the Device Description as well as Line Level settings were reset to the new user's information.

In some cases, we had DN's that were not associated with existing phones.  So, we would BAT in "dummy" devices with addresses such SEPYYYYMMDDXXXX (i.e., SEP201008210001) and then assign those DN's to each phone.  We could then always just search for a description of "Unassigned Phone" and either be able to pull existing phones from inventory or allocate a new phone by setting the proper MAC.

Again, this was never perfect and we've come a long way in our thought process on this sort of thing since then...but just sharing an example of what worked "reasonably" well in the past for us.

Hailey

Please rate helpful posts!

Very interesting Hailey.

You boys at Netcraftsmen really have it together I enjoy all the Netcraftsmen blogs and all your comments in the forums not only Bill's.

Just a point of clarification for anyone I've confused with my terminology:

DID = Direct Inward Dial (Telco/PSTN 10 digit number to route calls to you)

DN  = Directory Number (endpoint can be a phone, fax, etc. etc. in this case for CUCM to route to the phone)

Telco drops the last 4 digits of our 10 digit DID's to most of our locations sometimes 3 (Whole other discussion about dial plans!)  It is these last 4 digits that we then point to the CUCM DN's that I'm speaking of controlling.   Some sights the CUCM has to translate the digits to route them to the correct DN some we don't.

Point is without Admins (operations) knowing what the DID are for that sight assigning the DN is a guessing game.  If they assign a DN that doesn't have a corresponding DID the phone can't receive calls directly from the PSTN.  If they assign a DN that already has a DID (this is where it gets even more sticky) let's say to an endpoint that doesn't connect to an FXO, FXS or a Voice Gateway (this has happened to me) it connects directly from the dmarcation point to the device you may have users complaining of hearing whistling sounds in their headsets.  You think you have everything documented but some of these faxes, modems, security systems etc.. have been around for ages long before you ever came around.

My thinking was to just create these unassigned DN's which would have corresponding DID preloaded w/o phones and have them sitting there.  I could put your idea of unassigned phone with dummy MAC and an unassigned DN for those devices that I mentioned previously that aren't in the system but need to be accounted for.  That way when the Admin comes along to assign a new phone they choose a DN from the unassigned DN list.  Now the DID/DN  is attached to the phone and is in use and won't be listed in the unassigned DN report the next time they run it.  They don't have to come out of CUCM and update another DB but yes they have to run a new report.  Lot's of things to think about to control this whole process.  To automate it even more complex.  Like Rob says a bit scary if they get deleted and maybe some lose ends hanging around in the CUCM DB eating however much resources. Is it worth the risk?  How could you recover is there an easy way?

My original idea was along the lines of what we currenlty do only to automate it more. Export the data using SOAP into an external DB.  One of the Admins and I were talking about this process and he mentioned an old PBX he worked on that had all the DID/DN preloaded.  That's when I thought of the unused DN's which I normally delete. 

very interesting indeed!  Now for a lap at the original Monaco GP!

Mark