VM Port Status unavailable 100% 1

[RDECIT]

I have a minor alarm on a CXi 3300, showing that all 20 of my VMports are unavailable. The CXi has a T1/E1 combo and BRI card installed so that should at least give me 16 ports.

The vm hunt group (6000) has 20 ports assigned (6001-6020) each one has a COS of 80. This COS has the setting COV/ONS vm port set to YES.

Is there any other troubleshooting tips people can offer.

The CXi is running the latest V9 software.

 

[kwbMitel]

This is probably related to your DB Error in the other post. The portion of the DB that was corrupt was undoubtably associated with voicemail and when it was removed the VM ports ceased functioning.

You need to recheck all voicemail programming (Start with licensing).

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

 

[IrwinMFletcher]

The CX (in any configuration) supports a max of 16 voicemail ports. I would first drop it to 16 then see what happens.

 

[kwbMitel]

Good point Irwin and I think you have now answered both issues.

Rob, I suspect that when you built this CXi you uploaded an existing database that had been backed up from a system that supports 20 voicemail ports. This is what was causing your DB issue.

The CXi only supports 16 as Irwin states and this would be the part of the DB that was removed by the restore.


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

 

[RDECIT]

Spot on guys, I removed the last 4 ports from the 20 VM ports. I then reduced the VM Capacity to 16 and rebooted. All alarms have gone. Cheers.

 

[kwbMitel]

Was I correct in the way you used a backup from a different system type?

If so, you should not be doing that.

The only db that I know that can span system types without modification is going from an older LX model to an MXe.

Any other combination will cause issues.

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

 

[Mitelmatt]

KWB

No i don;t think that's right. Done loads of CX/i to MXE upgrades for example with the database transferring fine.

The system converts to fit on restore.

I think having defalt databases is a god send! Just my opionion

 

[RDECIT]

This was the same system. However I'm was interested to know if backups could be restored to other models.

 

[kwbMitel]

MitelMatt,

Backups can only be restored between models as long as the parts that are different are removed first.

There are significant risks of corruption by following this path.

A much better process is to create and maintain import spreadsheets for specific forms. I have about 20 forms that I program via import on each install. With each new Release of software, these forms are compared and modified to take advantage of new features. It takes about 20 minutes to import the forms which is about the same time as a restore and reboot.

If you want definitive advice on using DB's between platforms, find the process document on MOL for upgrading to an MXe from other platforms.

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

 

[IrwinMFletcher]

Restoring onto a system of 'greater capacity' shouldn't be a problem. i.e. CX->MXe, it's when you go the other way that there are issues. The system dimensioning is based on the platform type, then when you try to restore data that exceeds those boundaries that you get into trouble.

 

[kwbMitel]

Irwin,

It's not only the system size that is the issue. It's mainly the configuration of the daughter boards (Analog Main or Option board) but it's not limited to that.

Before import forms became available I was burned several times using backups from other hardware types. It is telling that the first question that the people at Mitel TAC were asking was whether a restore had been done from another system type.

Using import forms is vastly superior and far more flexible for the same time investment. Easier to maintain as well.

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

 

[IrwinMFletcher]

Agreed, I was making the assumption that they have the same underlying hardware modules. Any differences should be deprogrammed before moving to the new platform.