Centralized VM pro SCN Multiple time zones 1

[Greybeard191]

I'm doing my first install in this scenario:

Centralized VM Pro
3 - IPO500V2, all in different time zones, one of them is in a time zone that doesn't use daylight saving time. R7 software

Question - Does the IPO time server IP address and associated time offset allow the remote sites to:

a) correctly keep envelope information on VM (time received etc)... I suspect the answer to this is yes, but I've never actually tried it.

and

b) correctly run time conditions so that the remote offices would open and close correctly based on the hours set in the VM Pro server... I suspect the answer to this is No, but again never tried it.

Don't currently have all this kit in prestage area, so I'm wondering if anyone has tried this.

Particular to part B of the question, looking for a scenario like this:

Remote IPO "C" is in a time zone that is either 1 hour or 2 hours offset of VMP time, depending on whether VMP is running daylight saving time or not, as IPO "C" is in a timezone without daylight saving time (Saskatchewan). If Office "C" runs 9-5 M-F, and I set working hours in VM Pro for that set of time conditions to that (literally displaying 9-5 M-F in condition editor), and then set IPO "C" offset to either -1 hr or - 2 hours from VM Pro time (this would have to be manually manipulated twice a year), would the IPO "C" callflow act correctly?

I think there might be something coming in R8 that will deal with this better, and I can probably work around it by using IPO time conditions in office 'C" to simply point to the correct modules in the meantime, but looking for a tidier way to do it, if it might work.

thanks in advance

GB

 

[kholladay]

R8 will address this but until then you will need to base your check conditions off of the time that is local to the server running VMP.

Kyle Holladay / IPOfficeHelp.com
ACSS & APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[Greybeard191]

meaning that the only way i could currently achieve correct callflow for the two remote IPO's would be to either:

a) actually fudge the time conditions for those two offices in the condition editor itself

or

b) do time profiles on the two IPO's and simply point to appropraite modules

Is this right? If so, R8 will be an easy sell for this customer.

 

[kholladay]

I would adjust the times for the check conditions on the call flow compensating for the difference in time zones myself but then again that is just me.

Kyle Holladay / IPOfficeHelp.com
ACSS & APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford