jpmuldoon1965
IS-IT--Management
Thank you all very much for all of the info over the years of very helpful and enjoyable posts.
I found something the other day after DST on Monday morning. One of my customers relies on the Week Planner in VM Pro for opening and closing of their Hunt Groups. They noticed that one hour early all of there hunt groups went to night. Time and Date on the phones was correct. After reviewing the logs in Monitor and the debugtrail.txt files we isolated the issue to the voicemail pro.
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: > IVRNodePlayer:
layIntro(Session: 000080b5, Main HG.Leave.Test Working Hours.1)
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: < IVRNodePlayer:
layIntro()
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: > IVRNodePlayer:
erformAction(Session = 000080b5, (key = ))
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: Session: 000080b5 - Action = TEST=Working Hours.Condition
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '2' Result: 1
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Time Compare '07:30 vs 17:00' DOW=[1,04/11/2013 17:40:59] Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '3' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '4' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '5' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '6' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Tested Condition 'Working Hours.Condition', result: 0
04/11 16:40:59.355 vmpro (02,6) 6595,037abb70,26059: Session: 000080b5, Substitute (False) -> (False)
IF you look in the bolded area you will see the time that the condition was comparing to was off by 1 hour.
We currently have a SR open with Avaya but we were able to temporarily address this using this procedure
Change time zone to non DST area US/Phoenix REBOOT. Change back to time zone desired REBOOT.
I did my Secondary Server then Primary
I hope this helps anyone else that comes across this
Thanks
JP
I found something the other day after DST on Monday morning. One of my customers relies on the Week Planner in VM Pro for opening and closing of their Hunt Groups. They noticed that one hour early all of there hunt groups went to night. Time and Date on the phones was correct. After reviewing the logs in Monitor and the debugtrail.txt files we isolated the issue to the voicemail pro.
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: > IVRNodePlayer:
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: < IVRNodePlayer:
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: > IVRNodePlayer:
04/11 16:40:59.355 vmpro (02,9) 6595,037abb70,26059: Session: 000080b5 - Action = TEST=Working Hours.Condition
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '2' Result: 1
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Time Compare '07:30 vs 17:00' DOW=[1,04/11/2013 17:40:59] Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '3' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '4' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '5' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Day Compare '6' Result: 0
04/11 16:40:59.355 vmpro (09,6) 6595,037abb70,26059: Session: 000080b5 - Tested Condition 'Working Hours.Condition', result: 0
04/11 16:40:59.355 vmpro (02,6) 6595,037abb70,26059: Session: 000080b5, Substitute (False) -> (False)
IF you look in the bolded area you will see the time that the condition was comparing to was off by 1 hour.
We currently have a SR open with Avaya but we were able to temporarily address this using this procedure
Change time zone to non DST area US/Phoenix REBOOT. Change back to time zone desired REBOOT.
I did my Secondary Server then Primary
I hope this helps anyone else that comes across this
Thanks
JP