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

 

[kwbMitel]

When you select the pending change what does it tell you is the reason for failure?

If you have already deleted manually off the controller and it is failing because extension does not exist you can simply delete the pending change.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[T8keiteasy]

Hi,

It makes me remember a similar problem a friend had once...

He couldn't delete the last pending change.
When he had a new one (he manually deleted another extension, so a new pending change was shown) he could then delete the first one (The one he couldn't delete before). The one remaining was then impossible to delete ...and so on

Is that how your OPS behaves ?

In this case my friend was lucky, because customer he worked for was particulary skilled to modify SQL database...
They've noticed that a difference existed between remaining pending changes and what was found in SQL database...

They "just" delete the pending changes from SQL database, and it works fine...

I'm sorry to say that if your problem seems to be particular I don't know at all how they modify SQL database :-(

I would say, try to create a new user from element and check if you can delete your first pending change...

Keep in touch

Now, it's about French users too !!!

 

[Mitelpassion]

kwbmitel, the problem is that I did delete the 'problamatic' dn on the elements. they don't exist. I'm try to get rid of the pending changes. when I try and delete these then i get the internal error thing.

t8iteasy, my problem is similar but not excately. I'm thinking probably re-collect and re-propagate. I just hope whatever is on the controllers are up to date however I doubt it.

 

[kwbMitel]

I would not Propogate.

Where is this pending change?

If it is in the Telephone Directory Utility, you have the option to delete the change in that form.



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[Mitelpassion]

kw please explain "If it is in the Telephone Directory Utility, you have the option to delete the change in that form"

If I understand you correct then that's excately what I'm doing. Im trying to delete the pending change in the telephone directory utility form. It's not allowing me - just give an error internal error occured contact your system administrator

 

[kwbMitel]

Sorry to be so dense.

No idea's come to mind, never encountered this error.



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[Lundah]

Check the Event Logs on the server, the Application log should have a bit more information on the error. If it's a Java error, try rebooting the client PC and the server and re-try the operation that gave you the error.

 

[Mitelpassion]

not a java error. it's a ops manager error and the error in the event log is excately the same...

 

[Mitel100]

Are you getting this error message on any other part of the opsman, ie - telephone directory?

 

[Mitelpassion]

yes

 

[Mitel100]

The only way to get round this then is to do a full collect and prop. Sorry

 

[Mitelpassion]

I'm thinking the same thing but kwbmitel seems to have reservations about propogating again. kwbmitel can you elobrate a little on why?

 

[MitelInMyBlood]

One good reason I can think not to... Once you begin using OpsMan your telephone directory becomes your default routing table for internal calls (calls within the cluster). I'm not 100% sure of this, but I think once you start a full collect and repropagate I believe you temporarily lose your ability to route calls (to as yet unpropagated entries) between the elements until the full propagate is completed. In any event this is not a task I would ever chance doing during the business day.

Also, just to hear myself speak for a second, most of the OpsMan systems I've helped solve problems with got out of synch in the first place because of someones' misunderstanding of why something didn't propagate correctly and their own haste to get on with some other task. So rather than spend the few minutes it takes to figure out why it didn't propagate correctly some will go into the telephone directory form and manually enter it there (to force it to exist) or delete the pending change from Ops. Trust me, when OpsMan complains about an entry, there's usually a valid reason for it and if you just delete it then you get out of synch.

 

[kwbMitel]

Propogate will replace directory entries on the 3300 controllers based on the Data in OPSMan.

If, as you say, the OPSMan database appears to be suspect, you could be propogating the problem and making things worse.

Propogate would only really have a use in the event of a controller failure and manual rebuild.

I have never used propogate even once.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[Mitelmatt]

Hi there,

I've had this issue recently. It's because the delta (a delta is a move, add or change that sits in the sql database) has got stuck due to tooo many things happening to that particular ext at the same time.

What you need to do is make sure you have a backup of the config (OPS MAN config) and just restore it over the top.

If that doesn't work then re-load the ops man software (make sure you put the back-up file somewhere different than it's current location as it will get overridden) and when prompted select "crete new" which will load up a clean OPS Man, then go to restore and restore the back up (put the backup file back in the right directory)

Normally just the restore works

Hope that helps

 

[Mitelpassion]

mitelinmyblood, I agree with you 100% as to why this happened. The user that used to be in charge of this for over a year NEVER had a problem. He then gave it over to someone else and obviously never told him about changes that are not syncing should be figured out and fixed.

What about a full collect and then propogate? I believe a full collect overwrites OPS and then a propogate will put all the 'new' entries onto the elements in the cluster?? your views on this?

Mitelmatt, I have a backup but this problem's been around for a day or two and the backups run nightly. In this case restore will just restore the problems right?

Where does OPS ask to "create new"? I've reinstalled OPS once or twice but don't recall where it prompts for this? Again restoring from the backups that are available - would that not just restore the problems back?

thanks for the help guys.

 

[Mitel100]

A full collect will collect all data from the element that you will be collecting from and the prop will put these entries back into the element/s. before doing this it is good to think about the data on the switch, is it up to date.

With regards to the backup and restore, when restoring the database back to the opsman it will remove any outstanding utilities, but does also resolve this problem sometimes.

I have tried re-installing the ops software for this fault, but did not work.

 

[Mitelmatt]

Hi,

It doesn't matter which back-up you use, just by restoring gets rid of all currupt deltas as Mitelpassion says.

This is happen to me twice on different sites and reinstalling the ops software and using a back-up has always resolved the problem. Also confirmed this with Tech Support

 

[MitelInMyBlood]

If it's "happening" as you say, then you need to concentrate on finding out why. The ability to delete failed changes in ops IMO needs to be a password-controlled feature or in some way make it more difficult to do. FIX the dang thing rather than cheat the processes and dig yourself into a hole.

IMO troubleshooting failed directory upgrades is one of the processes that wasn't well taught in either the old stand-alone Ops 6.x or more recent EM training classes (leader-led). To me the best news I've heard is that thankfully Don Ouimet is no longer teaching it.

Here's the rule: OPS is going to flame-out every time the dn you're attempting to assign already exists in some other form, i.e., in system speed call, or in ARS, or as a key appearance, or as a feature code or dataset or an external number in the tel dir form or is otherwise a digit conflict anywhere else in the entire cluster. What makes it tempting to just delete the failed update is the fact that OPS is a little cryptic in stating the reason for the failure, plus you've got to know where to go find the log file. Though a powerful tool it can do an awful lot of damage in untrained or inadequately-trained hands.