VM Pro/Lite fails to connect to control unit

[Techguy2009]

Hey Everyone,

I have an IPoffice500 voicemail pro 5.0(21) IPOffice500 [5.0(8)]. Today my auto-attendant stopped working all the sudden after months of working just fine. In my System status window it is saying "VMPro/Lite fils to connect to the control unit PC IP address xxx.xxx.xxx.xxx." The IP's are all the same and I double checked my DNS/DHCP server just to make sure that it didn't give out that IP for some odd reason. I've rebooted the control Unit and the server that VMpro is located on, restarted the VMpro services, still not working.

What is happening is when the system gets a call it would normally direct the incoming call route to "?attend" and it would pick up my menu and options. Now its sending the calls there, but its just dead air. Hitting 1,2 on the phone won't do the tranfer, then it drops the call after about 30seconds.

I have reinstalled VMpro and imported my module back in. Same issue. I decided to create a new module and try that out, no effect on this issue.

I can change it from offline mode to online mode, it logs in just fine and looks like everything is working. But still, its just dead air when my IPoffice routes the calls to the Auto-Attendant. I made sure I clicked save and make live as well.

I'm running this on a windows 2003 server, updates are turned off and there hasn't been any changes to the PC in over a month.. I checked the event logs on the server under application and saw this message:

Event Type: Error
Event Source: VMProDBService
Event Category: None
Event ID: 0
Date: 11/9/2009
Time: 9:52:14 AM
User: N/A
Computer: XXXX
Description:
Service cannot be started. System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at System.Net.Sockets.TcpListener.Start(Int32 backlog)
at System.Net.Sockets.TcpListener.Start()
at System.Runtime.Remoting.Channels.ExclusiveTcpListe ner.Start(Boolean exclusiveAddressUse)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChan nel.StartListening(Object data)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChan nel.SetupChannel()
at System.Runtime.Remoting.Channels.Tcp.TcpServerChan nel..ctor(Int32 port)
at System.Runtime.Remoting.Channels.Tcp.TcpChannel..c tor(Int32 port)
at VMPDBSvc.VMProDBService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMai nCallback(Object state)

So I decided to load the voicemail pro onto another pc and run my auto-attendant off of that. I did this and it worked just fine. I rebuilt the entire server (full reformat) that the VMpro was orginally on and reinstalled my VMPro software. I imported my module and tired set the IPoffice to point to that PC's IP address again. It failed with the same issues, same errors (no event logs showed was the only difference). After that failed I shut off the services, uninstalled VMpro and decided to run it off the other box that was working. Now that box is having the same exact issue. I get the same error, just the differnt IP address.

I've rebooted the entire IPoffice unit, no luck. I'm totally out of ideas, can anyone help?

can anyone help me with this?

 

[Techguy2009]

I read this post

http://www.tek-tips.com/viewthread.cfm?qid=1578363&page=1

and figured I'd add more to mine.

I can communicate via ping from the IPoffice to my PC.
My Server has Manger and Pro installed on the same box
the services are running
Announcemnts if off and I don't have 'queued and still queued' in the call flow.
I only use the main NIC.
I normally do use Remote desktop, but I will stop. IF that did cause the issue what is the fix. Would PCanywhere be better or do I have to be sitting at the box?
No network changes have been made and there are no software/hardware firewalls between the two devices.

We only have 8 phones and a real basic Auto-Attendant. nothing special or huge here.

Thanks everyone!

 

[tlpeter]

Just use the vmpro client on your pc
Do the vmpro install and choose for client only
Then make a user on the vmpro machine (just login localy)
When you have made that user then save and make live
Go to your pc and put in the server name or ip and use the login you made

And yes never use RDP on the vmpro machine, it will break it





ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[mattKnight]

Have you got an older version of manager installed on the voicemail server?

It would not suprise to find that you have a copy of voicemail lite running in a different session on that box.

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Techguy2009]

Hello,

I checked to see if any older versions were running, only the one. I will uninstall everything off of my server that runs it and install it fresh without using RDP and give that a shot.

Thanks for the tips, I'll keep you posted if it works.

 

[Techguy2009]

IT WORKS! Thank you both so much for helping me with this issue. It turns out that RDP was the cause. But now everything works!

I am curious to why RDP causes this still. I setup the entire phone server with RDP and it has been working for well over a year now with no issues at all.

One thing I still see is that I'm getting erros about voice networking license, is there a way to get rid of this error?

again, thanks you very much for the help. Now on to the next project!

 

[tlpeter]

If you see those errors in system status then just ignore them
SSA is still in development so it gives fake errors sometimes




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[alexdykes]

If you must use RDP, you need to remember to RDP to the console rather than using the standard RDP client.

Typically the RDP issues arise when you have the VMailPro client open locally and in the RDP window, and/or in multiple RDP sessions at once.

 

[Techguy2009]

Ok that makes sense. I think I'll just stick to standing and using the machine locally from now on. Thanks for the info!

 

[alexdykes]

You can neatly avoid the whole issue by using something like GoToMyPC or LogMeIn

 

[Techguy2009]

what about PCanywhere? Do we know if that works ok?

 

[alexdykes]

No problems with PCAnywhere, but why pay for that when you can use LogMeIn for free?

 

[Techguy2009]

We bought PCanywhere a long time ago and hardly use it. All of our PC's has it installed just as a backup. I'm not a fan of symantec anything to be honest with you, too many problems with them. Thanks for the info! My phones are working great and I'm a happy camper now. (so is the boss-man).

THANKS EVERYONE!

 

[Pepp77]

Whereever possible we try to install teamviewer on VM machines - saying that though Ive not had a single issue with using RDP and I RDP onto my office VM server at least twice a week.

 

[amriddle01]

Pepp77, you will find it ususally only causes corruption if you launch the VM client while using a RDP connection, and then you can do so for months and months with no issue, until it does then it's a re-install and rebuild of all modules (if you don't backup) after that I will bet you don't use RDP again, it has never happened to anybody until the first time it does, then it's too late

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[Techguy2009]

I can vouche for amriddle01, I used RDP for over a year and a half, did all my setups, even built all my modules using RDP. Then last monday it just stopped working totally. Crazy that its hit and miss like that but it is true! Take it from me

 

[alexdykes]

amriddle01, that's a perfect way to describe that situation, and exactly how we found out. I will still insert my caveat that if you connect via RDP to the console, (mstsc /v:SERVERNAME /console) then you'll be ok, but, it is kind of a pain.