Migrating to Virtual from MCD-III rel 8 1

[kwbMitel]

My sales team sold a new Virtual Base License for this project and I don't think I can use it due to the complexity of the site.

3 Clustered MCD's, 1 Primary and 2 failover sites
Licenses are Shared via DLM
ULM/UCC Licensing
Micollab with Nupoint
ACD Applications (10 paths / 30 agents)
SIP Trunking
MiCC reporting

I can't see any way to prepare the new system such that I can simply restore the TDM free database and bring it into service.

I want to virtualize the existing ARID and then replace with a new non-virtual Base license. This upgrade path seems perfectly clear to me.

Has anyone tried the first way above and if so how?

 

[Billz66]

virtualize the existing ARID and then replace with a new non-virtual Base license."

I'm I bit confused (but happy that this isn't a project for me as i can see its going to be a brain twister).

whats the end result , is just the main site going to remain virtualised
is there much to prepare (much TDM stuff to remove?)
will you go to Virtual R9 (single IP)


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

 

[Valamagules]

There is an uplift license that will allow you to convert your Physical Base to Virtual.
This way you will not have to dissolve DLM.
Part # 54005366: Convert MiVoice Business to Virtual

Below are some steps that can help to move your DB to Virtual.
Assuming here that TDM will no longer be required as not supported in Virtual MiVB.

Easiest way is to upgrade your Physical System (DB) to be in the same release as the Virtual you would like to upgrade to.
For this you will need another physical controller to make DB changes on as you don't want disturb existing.
1)Backup Existing Controller
2)Break DNS so it does not sync back to MOL. (license violation may kick in due to DLM but it's OK if not more than 30 days)
3)Clear Hardware ID of ARID
4)Sync ARID to spare controller (now spare controller has the licenses for DB)
5)Restore Backup to Spare controller (use dimension selection from Backup)
6)Follow upgrade path in MOL to upgrade physical to the latest (at least be the same as virtual)
7)Remove all TDM configuration (analogue line, ISDN, analogue extns) -
8)Backup DB
9)Add Conversion License to ARID
10) Clear Hardware ID and sync to Virtual
11) Restore DB to Virtual (use dimension selection from Backup)
12) Resync DLM, license violation should disappear.

Done this many time - works like a treat.


Clever men learns what Wise men shares!

 

[nytalkin]

don't forget to break up the cluster BEFORE adding the vMCD. We've seen many difficult to repair SDS errors if the vMCD is introduced prior to breaking the cluster. Val's process is spot on for the migration.

I suppose you're entitled to your opinion, I'm just not going to suppose very hard.

 

[kwbMitel]

Thanks everyone,

Yes, the process outlined by Valamagules is what I WANT to do.

Unfortunately sales sold a new Virtual Base System instead on a Virtual Uplift Licence.

I need to retain the physical system for analog services so I want to simply add it with a new ARID after the fact as a new system.

Adding the Virtual as a new system can't work as far as I can figure.

 

[Valamagules]

You can add the Virtual Controller as a new member of the cluster & DLM.
Once added, and clustered, Export below forms and delete analog extensions , only to retain IP devices to Import to Virtual.
- User & Services
- Multiline keys (delete unassigned keys , will save import time)

Delete the IP users from the existing system to free up the IP user licenses and extension numbers
GDM check & repair any SDS errors
I would also give the analogue extensions different numbering plan (your choice)

Move IP licenses back into DLM, and add to virtual, now you have your IP licenses
Import the Exported forms

GDM check & repair any SDS errors

Hope this helps




Clever men learns what Wise men shares!

 

[kwbMitel]

@Valamagules - In other words, hand punch from scratch. no thank you. Not with MiCollab and MiCC and ACD all involved.

 

[Valamagules]

@kwbMitel - Not really, export and import user data
The pain will be replicating ACD - but that's half the work done already, no pain no gain they say.

Clever men learns what Wise men shares!

 

[V3RTechNP]

My two cents since I went through the exact same process for a customer with a very similar setup. The goal was to virtualize MCD #2 of the cluster as a first phase (about 200 sets in that one).
The best way is really with the uplift license but it takes down the controller for a very long period of time, more than a standard upgrade, due to time it takes for removing all the physical stuff in the controller (analog extensions, PRIs, etc.), and the system had some very important physical lines in there that had to be removed beforehand. It looked quite inconvient for the customer and required some important work like converting PRIs to SIP trunks or converting analog extensions to IP.
While that work was going on, we decided to take the same route your sales team went : buying a new full virtual MCD to make things go forward faster.

To cut it short, the end result is that we had to move each IP set one by one from the physical controller to the virtual one. Export/import works but some things are lost inbetween, like user speedcalls per example. You need to write those down. BLFs are a pain in the ass if your setup heavily uses them. If you want to make sure to not corrupt anything you have to remove them manually from Remote BLF and Multiline Set Keys. You need to make sure everything is clean for any IP set to be deleted with the DN REF command on each controller of the resilient pair. If you delete the IP sets and you have MiCollab, you need to move the mailboxes before deleting the extension or you lose the mailbox since deleting an extension remove all MiCollab services because of flow-through provisioning. A lot of little nitpicky things like this. Actually, the problem isn't export/import, it's deleting the stuff.

So really, put pressure on your sales dept. if you can to get a virtual uplift license. Something could probably be done with your Mitel representative to swap your full new virtual for a uplift, otherwise you will eat your profit with installation time.

 

[Valamagules]

@V3RTechNP - that is painful, has always worked for me on Export and Import.

Important note for Export and Import method is to make sure the controllers are on the same release/version.
Export and Import will not work, or you will have issues if controllers are not on the same release.

I agree you can do delete and recreate one at a time, but the time that consumes is humongous.

MiVB to MiCOllab for VM can be addressed by changing the sync password between the two so they don't sync.
Deleting then will not be an issue, as long as the end result the IP is retained. You can then resync and VM will be retained.

Anyways, goodluck - hope it all works out.

Clever men learns what Wise men shares!

 

[V3RTechNP]

Well we could have deleted them one by one and then imported them all together but we were upgrading from 52XX to 69XX at the same time so we figured that we should go one by one to cut on downtime. Otherwise it would have been a straight import.

It takes about 15 min. per user on average. Including physically swapping sets for 69XX. Not including user training for the new phones.

If you move all your users in a one time operation, disabling the sync password sure, but if the operation is for only, let's say, 20% of the user base, can't disabling the sync be a problem for the live users?

 

[Valamagules]

I believe the post was for like-4-like migration of the whole controller from physical to virtual, and not partially.
And yes, I agree with you in the sense where only certain user will be migrated and phone change, it will require lot more planning due to the complexity introduced.

Clever men learns what Wise men shares!

 

[V3RTechNP]

Yes, you're right. The original post was different in that regard. It certainly seemed more adequate for a global one shot deal kind of operation.