moving IP telephony from an overloaded MXE to a vmcd and create a cluster 2

[brewski6666]

We plan to convert an overloaded MXE standalone release: MiVB7.1 (300 IP phones + 300 analog and digital phones) into one vMCD (for the 300 IP phones) and one MXE (for the 300 analog and digital phones), we think to do it by following these steps :
A: take a backup of the current MXE, restore on a spare MXE, clear everything that is TDM (PRI, hardware, Analog and digital phones, ..) and leave only the IP telephony, take a new backup and do a restore on the vMCD.
B: format the MXE spare, take a backup of the current MXE again, restore to the MXE spare, clear all that is IP (to leave only the TDM, analogue and digital) and take a new backup
C: format the current MXE, reinstall the software, convert the licenses to Enterprise and restore the backup taken at the end of step B
D: create a cluster in the vMCD, add the MXE (step C) to the cluster and synchronize, then complete the programming (ARS, ..).
I'm not sure of step B, because I read in some posts that since I restore in the vMCD part of the MXE data, I have to format it before I can put it in the cluster.
My question is: are all my steps correct, or from step B, I need to format the current MXE and manually reprogram all the TDM (PRI, analog phones, digital phones) after that, add it to the cluster with the vMCD ?
Thanks for your precious advice (especially KwbMitel)

 

[brewski6666]

Can someone help please? thank you

 

[kwbMitel]

A: take a backup of the current MXE, restore on a spare MXE, clear everything that is TDM (PRI, hardware, Analog and digital phones, ..) and leave only the IP telephony, take a new backup and do a restore on the vMCD.

No problems with Step A, assuming you have a new Application Record for the vMCD​

B: format the MXE spare, take a backup of the current MXE again, restore to the MXE spare, clear all that is IP (to leave only the TDM, analogue and digital) and take a new backup

No Need to format or new backup, just restore the same backup from step A and continue.​

C: format the current MXE, reinstall the software, convert the licenses to Enterprise and restore the backup taken at the end of step B

Before Step C you should have your vMCD active and running the IP Phones. The vMCD and the MXe would NOT be clustered or sharing. You can use ARS Networking over IP trunks to route the Inbound and outbound calls. At this point. The IP phones would be duplicated on both systems. This requires you to move the IP licensing from the MXe to the vMCD and DO NOT resysnc the MXe.​

D: create a cluster in the vMCD, add the MXE (step C) to the cluster and synchronize, then complete the programming (ARS, ..).

Once all IP Phones have been removed from the MXe and all phones migrated to the vMCD then you create the cluster and start sharing.​

For the record, I am in the process of doing this myself. I'm consolidating 7 MCd's REL 5.0 into 1 vMCD for 800+ IP phones. You need to be really careful not to sync the old systems after the licenses have been moved. I recommend you spoof the HWID on the AMC to ensure it cannot happen. If you end up with a License violation you have 30 days to move everything off of the controller before it gets locked down.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[brewski6666]

As usual, always so dedicated and so accurate.
Thank you Kwb, you deserve a star

 

[Billz66]

I agree well written kwb

I have done that procedure as well

We asked mitel for the correcvt method and they told us that this method would work and we could migrate all user licenses from the Physical to the virtual after it had been converted to enterprise.

for mine i added the amc ip to the local switch that the CX was connected to so it wouldnt connect to AMC.
I had some issues with moving all the licenses as well - some of them wouldnt move even with AMC assistance and Mitel had to give us some additioanl free licenses for teh vmcd ( from memory it was acd active licenses)


If I never did anything I'd never done before , I'd never do anything.....

 

[kwbMitel]

@Billz66 - good point about some licenses having issues being moved.

Some ACD Licenses were bundled in way back when.

In my case where I was coming from Rel 5.0 systems I still had a variety of IP User, IP Device and IP Phone licenses that could not be moved. Only Enterprise Licenses could be moved.

What I did is I used a spare MXe at the latest SW version to register against the original ARID. This upgraded the licenses to release 8.0

There is a button the the application record to Convert licenses to 7.2 and higher format.

Once all the licenses were converted, I had no issues moving them all (except for the base licenses of 16)

I then cleared the HWID and set it to a value that could not sync. e.g. instead of 000000123abc I set it to FFFFFF123abc

I did encounter a couple of systems were some licenses were locked due to being downloaded in the past but a quick email to the AMC resolves that as long as the system currently has an online sync active.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[tlpeter]

I will mention starting all over again with the programming as an option.
Why? because you then can have some leftover rubbish from the past which can now be removed easier.


BAZINGA!

I'm not insane, my mother had me tested!

 

[kwbMitel]

An interesting happy accident

We were testing a proof of concept to move phones over to the new system.

The phones were self reregistering on the new system via the stored PIN in the handset.

No Need to program MAC addresses - Yay!

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Billz66]

On mine i didnt do backups and restores for My Mivb's

I converted physical standalone to enterprise so tha the licenses were Migratable
then exported forms and cleaned them and imported what i wanted to the vMIVB
used xnet to route between the systems during migration (no sharing)
then we re-registered the handsets to the vMiVB
then we deleted all the data from the CX controller
- they didnt want it as a resilient so it was a good time for a clean up
ended up with just some analog phones on it


If I never did anything I'd never done before , I'd never do anything.....