One-X Voicemail provider component status failed

[biv343]

My head is sore from banging it against a wall. I hope I'm overlooking something simple.

Here is my scenario. New install, 500V2, 7.0.12, VM Pro 7.0.19, One-X portal. VMP/OneX on the same Windows 2008 R2 server, 6 GB RAM, crapload of drive space. Fresh load of server 2008, no applications on the server except Avaya apps.

I have UMS Web Voicemail installed and working. I can go to

http://serverip/voicemail

and log into my mailboxes. One-X is installed and running. Users can log in and do everything but play back messages via the browser. The customer wants to use visual voice so they can see message status in various hunt group mailboxes, and aren't too happy with the idea of having to put VXXXX in the source numbers to allow OXP to play back via the phone. They want the visual voice access to be password protected. I can't say I blame them.

When doing the initial OXP config I entered the server IP in the VMP server field, and I thought I'd be set. I can't play back messages via the browser, and I get a message about the voicemail server being unavailable when looking in the OXP user settings. In the OXP admin section, the voicemail provider status says "failed", with additional info of Provider Socket Exception. I verified the correct IP, but don't see anything in the docs about anything else that should be specified under the voicemail provider settings. From what I understand OXP on Windows uses the UMS web voicemail to retrieve messages. I've only done this before using the applications appliance and it just "worked" on that platform.

Does anyone have any ideas as to what might be wrong? I've got 90 users and 10 ports of mail, so per the docs this should work. I'm nearly ready to scrap OXP on the Windows side and set up a VM and run OXP on Linux, unless I'm missing something obvious that I've overlooked. The customer prefers to stick with Windows for the VM side, so that rules out running both VMP/OXP on Linux.

Sorry for the long post. It's been a long weekend.

 

[tlpeter]

I have seen this.
Do a reinstall but the the advanced version.
You then will have the option to enter the ip adrress of the vm server instead of later when it is installed.
This worked for me.

BAZINGA!

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

 

[biv343]

I will give that a shot and let you know the outcome.

 

[biv343]

Unfortunately I get the same thing. I uninstalled, rebooted, reinstalled. I checked "advanced" at the initial config, which is what I'd done before as well. I remember getting burned on my lab setup by having to go through and add the VM provider manually.

I'm getting these errors in the logs. It doesn't tell me much of anything except the voicemail provider is down, which makes zero sense to me since it's on the same box as the VM application.

2011-08-21 11:11:05,636 INFO ClassicRequest - put()request for Namespace.VOICEMAIL_PROVIDER_STATUS_UPDATE
2011-08-21 11:11:05,636 DEBUG ResourceDirectoryTableImpl - com.avaya.inkaba.dal.ResourceDirectoryTableImpl.getByID entering.
2011-08-21 11:11:05,637 INFO ClassicRequest - VOICEMAIL_PROVIDER_STATUS_UPDATE from izwi for Voicemail Server Ip:10.91.52.11 VM Mode: DOWN Embadded :false

 

[tlpeter]

When you used advaced, did you enter the vm server ipaddress during installation?
It is hidden in a tab on the end of the provider screen (i think)

BAZINGA!

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

 

[biv343]

Sure did. There's basic install and advanced. I clicked advanced, entered the vm ip address on the last tab and ran through the rest of the config. I did it again and tried 127.0.0.1 since they are on the same server and got the same result. That was a shot in the dark.

Everything in the docs about UMS webmail, direct metabase access and IIS6 compatibility mode is in place. I think I screwed myself when I got UMS webmail working and told myself I'd be done in another 30 minutes.

 

[biv343]

I ended up getting this working. I put OXP on its own virtual machine, the voicemail provider component started as it should. Still no idea why it wouldn't work properly when on the vm pro server, but that's life. I spent a bit of time farting around with IIS and handler mappings to get the messages to play, but at least its working and the customer is happy.