Voicemails not saving after migrating from VMPro on Windows (R9) to Linux App Server (R10.1) 1

[b4btec]

I had our Avaya vendor upgrade us from R9 to R10.1 and at the same time migrate us to the Avaya Application server from our original WIndows server because I thought it would be better than trying it myself. They have screwed it up. I can see my old voicemails in my mailbox and when someone dials in they get the VM prompt, however when they leave a message it does not appear in the voicemail box. The WAV file also does not appear in the folder on the application server. I can listen to an "old" voicemail that was marked as new, but when the VMPro service has restarted the voicemail goes back to marked as new. Its like nothing is saving. I have them working on it but they don't seem to have any idea of what the problem is. Any help is appreciated since our voicemail system is down, and we already have an Avaya authorized vendor on it but they are not making progress.

 

[derfloh]

I guess the vmpro service has no write rights to the folders it needs.

 

[IPGuru]

sounds like copying the windows messages to the VM accounts has confused things

stop VM Pro Daemon (service to the non Linux Geeks )
delete (backup first) everything in /opt/vmpro/Accounts
Restart VM Pro


Do things on the cheap & it will cost you dear

 

[b4btec]

We actually just ended up rebuilding the new application server, this time just backing up the Windows VMPro database/config and importing it into the new application server. The vendor initially told me you couldn't just backup and restore to the new server. I think the Avaya tech didddled the linux permissions a little too much to get the voicemail files copied over the first time. I think this is the last time I enlist those guys for help.

 

[derfloh]

Please check if the files
/etc/vmpro_settings.ini and
/etc/vmpro_user_variables.ini
Exist and if the file owner and group are 'vmpro'.

You can check this with

ls -lah /etc | grep vmpro

 

[b4btec]

Thanks derfloh for your help, I was just updating this thread with our resolution which was just starting over with a clean install. The vendor we hired just didn't know what they were doing and I think did in fact screw up the permissions.