Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Very large Mitel system - not able to assign multi keys if on different users! ridiculous!

Status
Not open for further replies.
May 22, 2021
13
0
0
CA
Hi All,

I work on a very large Mitel system. Has multiple MIVB's (systems) (ie - user 1, user 2, user 3) Each with hundreds/thousands of users. But all essentially are on the same system. Basically just divided into different users as mentioned above.

If a user on user 1 wants an appearance of a phone (multi) that is on user 2 for example, I have delete the user on user 2 and recreate it on user 1 (or vise versa) in order to accomplish this.

Is it me or does that seem ridiculous!

Can Mitel not put in a patch so this doesn't have to be done? Seems like a lot of work to accomplish a simple task of a line appearance even though they are different users. In my opinion this simple task should not matter if phones are on different users.

Crazy to me!

Regards,

 
I feel your pain
the method used to create a large 3300 ( by clustering) is a source of endless pain.
We had a few multi pabx instances with acd agents on one mivb ,general users on another and trunks and acd paths on a third ( each with resilient pairs).

add in IVR and Mivoice business console and it was one work around after another to get the call flows to work.
then we had to redimension it to allow dss keys
only to then discover that the SMDR has a fixed length and due to 4 digit ceid digits it was being filled to the point where it would no longer show ring group overflow.....

its about time they could create the code to allow it all to fit on one MIVB or if clustering is to be used it should be transparent to the features


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

 
1000000 Percent!!!

Cannot believe it!!

Thank you for your input!

Wish they would do something about it yesterday!!!
 
There's a very simple solution to this.
Consolidate all the systems into 1 with all IP devices resilient to a 2nd controller.
When all devices are configured to 1 controller, you can set multicall, key-line, or DSS/BLF without the restriction you've encountered. There's other restrictions, but you will find them in the help docs.

I've done this with several of our larger customers and it's worked well.
 
Why are the users spread across multiple primary MiVB's? The best practice for this, as far as I'm aware, is to put all users on the same primary MiVB and spread out the secondary controller to the closest MiVB to the user.

Also, you can use a ringing remote DSS key to replicate a Multicall for a DN on another controller.
 
Thank you for the input AH64Armament and Lundah,

Cant' consolidate into 1 controller. This is a massive system. Divided into different MIVB's for resilience/resource/capacity restraints.

Yes, I actually tried this part yesterday and may work as a possible solution/replacement instead of deleting and recreating a user in order to have a "mulitkey" on the phone from a phone that is on a different user....."Also, you can use a ringing remote DSS key to replicate a Multicall for a DN on another controller."

Still think it's absolutely crazy for something so simple. But, it is what it is I guess.

Regards,



 
Are you using MiCollab?

I suppose you're entitled to your opinion, I'm just not going to suppose very hard.
 
Can you define massive, that's a moving target. How many sets total are we talking about?

Also, physical servers or Virtual as the limits are different.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top