Moving from Mxe controller to Mxe server

[Virtualman9000]

What would be the best way to move about 900 phones from the Mxe controller to the Mxe server? Would I be able to just export the relevant forms from one to the other? Or will a backup/restore work fine, discarding the incompatible forms (trunks,peripherals, etc.)?

 

[Lundah]

Assuming you have OpsManager, I think the easiest would be to add the MXe Server as a new node to the cluster, then use OpsManager to move the users over to the new box.

 

[Virtualman9000]

Are you speaking of the mighty TASMAC? I haven't used it before...

I was being lazy and hoping for a shortcut since there will be about 900 moves total over a weekend.

 

[MitelInMyBlood]

I think Lundah is right. We're getting ready to do the same thing and have thought about it long and hard. The way that we KNOW works is to add the new box to the cluster and move them over. It's a big job, yes, but with any shortcut I think you're going to be taking a risk and possibly create more work for yourself.

 

[Lundah]

TASMAC isn't that tricky. And, to be honest, since all you're going to change here is the Home Element, you don't even have to use the TASMAC tool, just the regular Scheduled MAC feature of OpsMan.

Just export the users to a CSV, add a column at the front (Column A) for the "Modify" flag, and just include the name, DN, and Home Element columns.

 

[kwbMitel]

I had the same task recently and TASMAC does not have a move option sorry to say.

If you use OPSMan to move the sets there is some information loss (Especially with 5330 or 5340 sets)

There are also many ways that it can fail:
- set in use at time of move
- Set has remote Busy lamp
- Set has unique or resilient key appearances
- Set has busy lamps or appears on other sets (info loss)

If you like to live on the wild side and you want to move the sets with the least grief I suggest the following.

Enable SDS and all options associated with resiliency between the 2 systems.

Use TASMAC to make the phones resilient with the Server

Once the set is resilient you can manually manipulate the remote directory form (Requires deletion and creation) to reverse the Master/Slave relationship.

Then Synchronise the systems using OPS

The set will magically detect the change and do a courtesy switchover to the new Master.



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

 

[TheInstaller]

Your Better off exporting the relevant forms and loading them back in again. Much Quicker and you can check relevant info off in stages.

Less Likey to go wrong!!

Have Fun!

 

[Virtualman9000]

kwb has a good point with the failures - most of the sets have appearances of other phones, others have unique second line DID's. Experience has shown that moving a phone with an appearance of a not-yet-moved-DN will cause a failure. I like his method, except for the word "magically"

What would be the pros/cons of using TheInstaller's method?

 

[TheInstaller]

We did a move recently similar and used Ops Man to move the users over to the newly configured switch. Ops Man took the best part of 12 hours to shift 800+ extensions. It is much easier using export/import and you can check the database at each stage.

Your choice but the latter is the safest, enjoy!

 

[Lundah]

Nice to hear from someone who's actually done this. I may have about 2,500 hundred users to migrate soon, good to know what works from guys who've actually done it!

 

[MitelInMyBlood]

I would think even with scripting the job that it's still a serial task and would risk losing key appearances, etc.

Please help me to better understand... we'll be doing a good sized one ourselves later this year or early next, going from a 2K w/18 PER nodes over to resilient MXe servers + 4 gateways and an AX. Total of 1490 multiline sets with 1651 broadcast groups + 80 hunt groups, ACD-II, etc. I sure don't want to have to rebuild all that.

 

[Mitelpassion]

you're in luck. done this for around 1500 users. ALL of kwb's observations are true. in fact one more and the worst is pickup groups unless off course you conifgure clustered groups so as to have the group on your new controller ready to accept dn's.

anyway using schedule macs is time consuming but works. BIG BIG issue for me is when you use macs to move a phone it deletes the pin on the phone making it want to register again. not sure if i did something wrong but rebooting the phone didn't get it back to a registered state. only way was to have the phone disconnected whilst mac move was happening.

also issue with voicemail. if you're phones were created with voicemail through ops then scheduled mac will fail as it will complain saying your mailbox needs to reside on the phone's home element. we all know the mxe servers don't support voicemail. my workaround was to re collect the telephone directory entries from controllers and re-propogate info. this essentially make ops unaware of voicemail so it doesn't have an issue. off course getting ops back to the realizing that an extension has voicemail is an entirely different and challenging issue.

my suggestion is to make sure all your pickup groups are pre-programmed and also your hunt groups. i doubt if you'll be able to do a move without issue.

one more thing, what subnet is your mxe server going to have? will it be part of subnet that also hosts all of your 2000 odd phones?

 

[LoopyLou]

What the heck is TASMAC?

 

[MitelInMyBlood]

Everything is on the 218 subnet - thank goodness

 

[Virtualman9000]

kwb - is this the method you used? when you say "the least amount of grief", what grief remains?

Phones losing their pins after a move would be a deal breaker for us. The phones are spread out over several miles in different buildings, some of which are VERY difficult to get in over a weekend. I guess I never moved a phone between 3300's, but I assumed the MAC followed the move since it shows in the Move form.

Voicemail and pickup groups would not be an issue, but Hunt Groups are. I had planned to program them in advance.

I think I am going to try some different methods before the actual move. I only have two weeks left!

LoopyLou, TASMAC is The Amazing Spreadsheet of Moves, Adds and Changes (i think).

 

[Virtualman9000]

Mitelpassion - did you use kwb's method?

 

[MitelInMyBlood]

Also voice mail is today and will remain external. Presently on an Octel Overture 250 and likely (not yet sure) moving to NP. There's a major $$$ incentive out there for the cust to do the Octel trade-in/trade-up, but now Avaya told them they'll match whatever voicemail deal we offer them, short of giving it to them. Maybe that's what we do, bury the cost somewhere & give it to them. In the big picture w/the trade in incentives, the VM becomes almost an insignificant amount anyway

 

[kwbMitel]

Virtualman9000,

By least grief I meant less than any other method I know of. Any method that requires the deletion of the set will cause information loss that needs to be identified and recovered.

What grief remains is in circumventing the resilient Keylines and Busylamps. My site had lamps for all users for 5550 console use and I made my extensions with the lamps resilient first to avoid losing any of that data. I also made temporary duplicate resilient keylines prior to "moving sets".

I have found no issues at all with my method.

As for TASMAC (That Amazing Scheduled Moves Adds and Changes) application. I could not figure out how to use it for a move. The 4 Actions allowed are UPDATE, ADD, DELETE and SWAP none of which allow the use of a move template. Any insight from someone successful in it's use to move between elements would be appreciated.

As for the PIN being lost when using OPS to move the phone, I do not believe that is entirely accurate. The set requires a reset only as when the original extension is deleted by OPS the phone defaults to requesting a pin. The reset allows the phone to find its new home element. The sets can be reset remotely if you can cycle the power on the DATA Switches remotely. If not, you'll have to reset manually.

Using the Export and Import method is viable as long as the 2 controllers in question are not clustered or sharing data in any way as you are creating duplicates that will create issues otherwise. In my case the systems were already clustered so creating duplicates was not possible due to the TEL DIR and REM DIR.

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

 

[Mitelpassion]

virtualman9000,

I did not use Kwb's method. used TASMAC (Scheduled moves adds and changes) and worked. That spreadsheet aint cool but figured it out.

KWB, If you do a move on an extension using OPS, the set does NOT come back even after resetting. I wouldn't put it past myself that I may have missed something but I would like if someone can point this out. would make my life a heck of a lot easier truth be told. Have you tried this before?

Update can be used for move. merely update the home element to something else and Bob's your Uncle

For what it's worth it seems like KWB has figured out the easier way of doing this. Too much that OPS move will 'break'. if you can test his method then all the better. BLF's in my case was a huge issue. had to do those manually. Off course different strokes for different folks.

I'm doing a similar move to the Mxe servers again soon. I would love to iron out all my issues with my previous attempts. BTW I've had to roll back my previous attempts due to the instability when having over a thousand phones on the MXe server running on the class B subnet.

So guys keep the ideas flowing...