For several years we have had ADP Handpunch time clocks for hourly workers to clock in and out. Several weeks ago they stopped working. The payroll person could not retrieve the data for the clocks. I kept getting ask if there was any network changes that would affect the clocks. No changes had been made, or so I thought. ADP tech support said it's a network issue, I said nothing had change these have been working for 4 or 5 years. Resetting the clocks would resolve the issue for a day or two. Al the while you can still ping the handpunch units.
During this time I was really trying to get a new Avaya IP Office unit ready to go out too one of our small offices. I had racked it in my test rack, hooked it to the network and went back to my desk to configure. This is about my 9 IP Office unit being deployed. If you are not familiar with IP Office units, configuration happens by pulling the configuration file and then pushing the changes back. So back at my desk I open the Manager software and discover the new unit.
No problems finding the unit and going about my day...
Back to the Handpunch issues, my coworker had been coordinating between the payroll person and getting a call setup with a higher level ADP tech support person. So we get the call with the tech and he starts running though all the same tests, Ping, trace route, handpunch diagnostics, etc. Out of the blue the tech asks do you happen to have an Avaya IP phone system. I hesitantly say " Yeah, why?" He explains that there is a UDP discovery method that Avaya uses which takes the handpunch clocks offline. I say well send me a document to show this. Which he did.
So by unchecking the UDP Discovery on my copy of Manager, I was able to stop this behavior to the time clocks. Reset the time clocks and I haven't had this problem again.
So why did this cause a problem this time and not the hundreds of other times I have used the software to configure the units? When I racked it into my test rack and hooked it up, I connected it to the same vary large flat network in which most other administration machines and services are on. All my other phone equipment is on different vlans.
I hope that others that may run into this can find this information usefully, since I didn't find much when I searched on my own.
During this time I was really trying to get a new Avaya IP Office unit ready to go out too one of our small offices. I had racked it in my test rack, hooked it to the network and went back to my desk to configure. This is about my 9 IP Office unit being deployed. If you are not familiar with IP Office units, configuration happens by pulling the configuration file and then pushing the changes back. So back at my desk I open the Manager software and discover the new unit.
No problems finding the unit and going about my day...
Back to the Handpunch issues, my coworker had been coordinating between the payroll person and getting a call setup with a higher level ADP tech support person. So we get the call with the tech and he starts running though all the same tests, Ping, trace route, handpunch diagnostics, etc. Out of the blue the tech asks do you happen to have an Avaya IP phone system. I hesitantly say " Yeah, why?" He explains that there is a UDP discovery method that Avaya uses which takes the handpunch clocks offline. I say well send me a document to show this. Which he did.
From Avaya IP Office Manager documentation |
Preferences in IP Office Manager |
So by unchecking the UDP Discovery on my copy of Manager, I was able to stop this behavior to the time clocks. Reset the time clocks and I haven't had this problem again.
So why did this cause a problem this time and not the hundreds of other times I have used the software to configure the units? When I racked it into my test rack and hooked it up, I connected it to the same vary large flat network in which most other administration machines and services are on. All my other phone equipment is on different vlans.
I hope that others that may run into this can find this information usefully, since I didn't find much when I searched on my own.
Thanks! We've been having this problem at a remote site and this fixed it.
ReplyDeleteThanks for sharing it. houston telephone systems
ReplyDeleteThanks! I wish I saw this months ago...although, I wouldn't have known to search for "avaya". Like you said, finally got a higher level tech support who knew about this issue. I'm glad this will fix our issue.
ReplyDelete