Cisco Unity Connection 10.5.2 Clustering Over the WAN Requirements **SAME TIMEZONE**

[kgraz1987]

According to Cisco documentation:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/requirements/10xcucsysreqs.html#pgfId-613757

Under ->Unity Connection Cluster Requirements When the Servers are in Separate Buildings or Sites

This statement is what is alarming to me:

**Both Unity Connection servers must be configured to be in the same time zone.**

I also reviewed a support community post where this question was addressed for Unity Connection 8.X.  Is it true that there has been no change to this?

My scenario, Customer has two datacenters, one datacenter in LA and one datacenter in NYC.  They would like the Unity Connection publisher in the NYC datacenter and the Unity Connection subscriber in the LA datacenter.  How is it possible that this is not a valid topology?  Each server would be in a different timezone.  Is there some sort of trick or workaround for this?  I am not concerned about latency or bandwidth as the customer has sufficient resources to handle this type of layout. 

[Brandon Buffin]

This has not changed for 10.x - http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/requirements/10xcucsysreqs.html#pgfId-613757

However, keep in mind that only the servers have to be in the same timezone. User mailboxes can be in a different timezone.

Brandon

[kgraz1987]

Thank you all for the great information.  I wanted to follow up on this inquiry as I have received the following official word from the Cisco BU team:

BU RESPONSE: As you found, installing across time zones should be fine, we have customers do this all the time in the US (east/west coast).

I have successfully installed both servers each in a different timezone and have not found any negative impact from doing so.

[Chris Deren]

It is still required and makes alot of sense for all servers to be defined in the same time zone for troubleshooting purposes as time stamps in the logs are consistent.  There is abolsutely no advantage of putting them into seperate timezones as time staps on phone displays, voicemails, etc are driven by configuration. 

[Rob Huffman]

Hi there,

In addition to the great info from my friends Brandon & Chris (+5 each!) I thought you might want to read the related notes on this bug;

https://tools.cisco.com/bugsearch/bug/CSCth78247

UC 8.x - Unwanted Time Zone Offset w/ Cluster-Over-WAN - Need Document

CSCth78247

Symptom:
set timezone command needs best practice documentation and/or recommendation for cluster over WAN implementations.

The problem is that this command can be run on both the publisher and the subscriber, thus allowing each server to be in different time zones.

1. Is this working as designed? Should we allow pub and sub to be in different time zones?
2. When you open General Configuration>System Settings page in the SA on both publisher and subscriber, you will see that the time zone matches whatever is set on the publisher. However, the subscriber reports a different timezone with the CLI command "show timezone config" that was set on the subscriber using 'set timezone'

Example:

Pub: SA page timezone: MDT
CLI command timezone: MDT
Sub - SA page timezone: MDT
CLI command timezone: CDT

It appears that the time zone does not replicate between pub and sub according to the CLI output by design. The impacts of this are not cosmetic either, when calls are presented to the subscriber, times are off by one hour. It could go the other way too depending on which server is taking the calls. If we tell the subscriber to stop taking calls in this scenario and present the calls to the publisher, the message timestamps are correct.

Conditions:
UC 8.x with publisher and subscriber each in different time zones

Workaround:
Set publisher and subscriber both to the same timezone until best practices/recommendations documentation is published for this type of deployment.