unable to delete pending change in OPS 2

[Mitelpassion]

Hi to all,

I'm unable to delete a pending user change, in this case it's a deletion of a user, in the directory utilities under OPS manager.

I've manually deleted the user from the element but I can't get rid of the references in the directory utility form. The error I get is an internal error has occured, please contact your administrator.

The user does not exist under the network element, nor under OPS telephone directory editor. Checking for it by using MACs also does not work. I've had problems with this extension and I'm trying to resolve that by deleting the extension.

any advice on this. I must admit I find OPS manager to be very complicated sometimes and once it has a problem, like the one I'm having now, it's almost impossible to fix.

thanks in advance

 

[Mitelpassion]

Mitelinmyblood, I'm with you 100%. In stead of just deleting the darn change rather find out why it's not propogating. This specific client have about 1500 users. not the biggest on the planet but over here in south africa, one of the bigger ones.

Their previous admin guy, never had these problems. He was admin for over a year. I vividly remember ephasising NEVER to delete these changes rather fix them. I think he failed to pass the bit of info onto the next dude.

Having said this though, I have no choice but to 'get rid' of the changes because the user is just making a bigger mess and right now he says OPS is broken cause he's to lasy to fix the issues. I don't think they want me spending 4 hours on site at my rates.

anyway thanks for the help. I think i'll just probably have to reinstall and restore.

 

[Mitelpassion]

third line have confirmed that I'd need to do a reinstall, create new and restore a backup

 

[slapin]

Did you check the Event Log on OPS Man box? In most cases it will tell exactly why it cannot propogate. And ICP will issue some records as well. So, check the logs first.

 

[Mitelpassion]

did check the logs on server, no indication as to why not.
3300 also not givng a reason. just says unrecoverable error

 

[Mitelpassion]

ok tried this again today.

here's what I missed on the 3300 logs

Software 432 Warning 2007/Oct/11 15:40:51 Call Control - Software DBNETSX: The Name - Telephone Number combination must be unique. applic=DB msg_type=Reply view= 1 action=Add Call Control - Software log_outputs_util_en.c;2089


Software 431 Warning 2007/Oct/11 15:40:35 Call Control - Software DBNETSX: system_is_busy - Protocol Err= 2

clearly something wrong on the controller then. Out of 4 controllers 3 are behaving like this. Only 1 allows updates to go through..

 

[MitelInMyBlood]

It's telling you that you have a conflict with the name & telephone number you are trying to assign. OPS is telling you that it's not unique, meaning that the telephone number (or the same digits) are already in use elsewhere in the cluster.

It could be another identical extension, or
the extn could have already been manually programmed outside of OPS, i.e. directly onto the machine and someone deleted the pending change delta on the pbx itself,
OR
the number could exist in a system speed call table
or
a feature access code,
or
a dataset number
or
a line key appearance on another phone
ANYWHERE IN THE CLUSTER.

Check every machine in the cluster....
from the maint and diag screen enter the command,
LOC NUM #### (where #### = the ext you're trying to assign)

Also try digit trace:
DGT TR ####
that might help identifying the cluster element it is on.

 

[Mitelpassion]

i've checked for those numbers on the elements. They don't exist!

I'm also checking a few things as I've logged the call with 3rd line. Not really making any progress though...

 

[MitelInMyBlood]

Is it possible that the DN you're trying to add happens to have the same digit string as the route prefix for one of your cluster elements?

 

[slapin]

try to use
dgt tr <number>

for extensions which don't do through. It will tell you what does it see.

 

[Mitelpassion]

no not route prefix for elements but maybe digits in ars. Will check.

 

[MitelInMyBlood]

I would have thought the dgt tr command would have revealed that

 

[Mitelpassion]

haven't done the dgt trace command yet. I know the element route ids - don't need to do dgt trace for that.

 

[NISD3300]

Have you tried a re-boot on the OPS server. I have gotten the same error before "internal error occured" when trying to add an entry or any other action I tried and after a re-boot it starts working fine. I have had this error several times and a re-boot seems to always fix whatever the problem is.

 

[Mitelpassion]

yes, have tried the reboot option...no luck
I'm pretty ok on OPS/Ent manager in terms of knowledge. Wouldn't say I'm a boffin but can hold my own for the most part...

I too have had instances where a reboot fixed the problem, but in this case not to be

 

[MitelInMyBlood]

Is the ext you're trying to add ext 2089?

How many elements in the cluster?

Do you have an attendant console in the cluster? If so, use the console to dial the digits of the ext you're trying to add and watch the console display screen for what it says about the reason for the call having failed. Such as "Out of Service" or "invalid" etc. Those digits are being used somewhere for something.
Multiline group assignment
Hunt group assignment
Attendant softkey
feature access code
ars digits
system speed call
Independent account code
dataset assignment
Associated dir no. assignment
Path assignment
Agent group assignment
Agent ID assignment
Don't forget to check the Miscellaneous assignment form too
Remote directory number assignment

 

[Mitelpassion]

the loc number command should tell me if it's been used, shouldn't it? I've run this command

 

[Lundah]

yes "loc num" should tell you where the existing number lies. However, run that on each incremental step of the DN you are trying to assign so that you catch all possible conficts. Example: you may have a speed call for "88" but the system will let you assign "8888" as a Prime DN. So for the case of 2089, you'd need to run:
loc num 2
loc num 20
loc num 208
loc num 2089

Unless ALL of these come back "not in use", you have a conflict.

 

[Mitelpassion]

ok so here's an update.

problem was a multiple one. basically one entry in ops was not propgating to the elements. any subsequent entries to this one just backed up as the propogation would go no further than this one specific entry.

once this entry was cleared the rest of the entries could be resolved. subsequent entries didn't sync as the dn and a different name for the entries in question already existed on the elements.

the entry that cause this hold up had some invalid characters in it. in this case a / was the problem. I was advised by 3rd line not to use these characters although there are others that didn't cause any hassles. having said this though, there's some more history behind this rogue entry. I'm still trying to backtrack all the activities on this entry so have no answer as to excately what the cause was.

The client also added to the frustration for just deleting some changes that didn't propgate without actually tryin to fix them.

the only way to get rid of this entry was to recreate the db and restore a backup. thanks to the person that suggested this. Also the errors I listed here is a bug it seems as there's a dpar raised for this. if you get this error and the sync still works you can ignore these errors.

The error logs is: Software 431 Warning 2007/Oct/11 15:40:35 Call Control - Software DBNETSX: system_is_busy - Protocol Err= 2

anyway thanks for the responses and suggestions.