Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: wobbly_head_bob on January 24, 2014, 08:23:40 AM
-
We've recently upgraded our Mitel PBXs to MCD 6.0 from MCD 4. We had been using Mitel's Ops Manager tool to perform MAC operations. However, now with Enterprise Manager 8.0, Ops Manager is no more. So that means that we no longer have access to Ops Man's MAC worksheets that made moving users pretty simple.
This morning we attempted to use the "Move Sawp xxxx with xxxx" command to swap two DNIC phones.
Our database crapped all over itself. Now it shows one of the extensions as existing on two PLIDs, the switch is all sorts of confused and apparently the only way out of this is a database restore.
So I'm here to ask you guys: Is it Mitel's procedure now that when moving extensions of the same type, on the same switch, that you must completely delete them and recreate them manually? (I say manually knowing full well I can export and import Multiline Key assignments, but you get my drift) Swapping Pre-MCD 4 was easy peasy. Swapping in Ops Man was easy peasy. Why is swapping in MCD 6 not possible? Moreover, why is it still a supported command?!
-
I feel that should have worked. Do a DBMS check full and see if any errors.
-
Did that first thing, the Check Full revealed 6 table errors. Reading the software logs was relatively pointless as I don't read Mitel'ese. What I thought I could do was to back out all the programming on both extensions. However, the same extension showed up on both PLIDs...I could not remove the Multiline Key Appearances, this threw errors back at me.
-
Another question too would be:
If I get a backup of the database right now in its current and corrupt form, can I restore with it just fine?
Or should I just restore with last week's data?
-
You can do a new one. The beauty of the restore is it ignores the bad stuff and that will be left behind.
-
It'll be interesting to see how it handles that bad stuff.. With the same extension currently reporting on two PLIDs how is the restore going to determine which is bad and which is good?
No matter, looks like I'm coming in on my day off tomorrow to do this restore, so I'll try a restore with a new back-up to see if it works, if not then I'll use last week's database and hope that everything syncs up without puking everywhere.
-
It'll be interesting to see how it handles that bad stuff..
It will take the first entry (I think it will populate them in the order of the PLID's), and refuse to restore the 2nd. If you watch the RTC shell, you'll see it spit out an error on whatever it can't restore.
-
Well, the backup has been running now for almost half an hour....can't, obviously, log in to the ESM. I can telnet to the controller, but after entering the login credentials it just sits there. CNTRL+W not refreshing it.
Hosed. FML today. It's been pretty awesome here.
-
If the command is still there it should then be possible to use. However you can as always get weird things happening depending on what features are programmed against a set. Might be best practices to remove sets from page groups, rings groups, take ACD programming away and deleting any keys before using move swap. Lot of extra work I know.
-
Loopy, yeah you're right (no ring groups, no page groups, no ACD here). Still "Move Swap" is there to preserve settings on phones, including keys, so removing all settings from the sets then using Move Swap....if that works the only saved step is deleting and recreating the extensions on the desired PLIDs. Basically, it all but defeats the purpose of move swap.
-
Just a note about watching the system when backing up.
I have seen backups go on for a very long time.
I like to monitor it via the vxworks shell. You can watch it do the backup.
Without it, you don't know if the backup is still working or it failed already.
Ralph
-
Mitel was able to reproduce our database funkifying move swap condition in their own lab setup with our databases. (We just moved to MCD 6 from 4 and Mitel did the migrations for us remotely) So, they've confirmed that the command was issued correctly with requisite conditions met and the database corrupting.
Aside from a successful reproduction of the error, nothing has as of yet been discovered. A support ticket we had open with Mitel should be working it's way through their internal escalations. I'll keep you all posted if/when I hear anything.
-
An update in case any of you were curious:
(This is early info and remains a work in progress with Mitel)
Mitel identified the problem:
According to design:
"The cause of the problem is that XXXX is programmed in the Associated Directory Numbers form with an associated number of type CPN Substitution.
When the CPN Substitution feature was implemented its interaction with the move swap command was missed. A work around is to delete the entry in the Associated Directory Numbers form before doing the move swap."
No date for an official fix as of yet.
-
Its often ancillary programming like this that can cause issues. Nobody can test every possbile senario.