Voice Mail Time Stamp

[scooter817]

     Hi All

I have had users in the past couple of days tell me that the time stamp on their VM is ahead by one hour.

I was talking to a TAC egineer that told me since I have one server in CST and the other is in EST that's

the reason why they are an hour ahead.The publisher is CST and the Subscriber is EST and the Subcriber

has to be in the same timezone as the Publisher. He told me not to be concerned with what coast they are on

because you can configure the profiles to reflect the correct zone when you configure them.He told me that I would

have to reboot once I've made the change to make this take effect.I want to know what someone else things because

I don't want to have to reboot the server and this doesn't fix it because they have lead me down the wrong path before.

Thanks in advance have any help and have a great day.             

[lindborg]

Well, my first thought is that the time zone the servers are set for don't need to come into play here - all messages are stored in UDT and the timestamp is translated into local timezone based on the timezone of the client.  So if you're looking at a message in a desktop client the timezone that client is set for is what's used to display the time of the message.  Similarly if you're listening over the phone the timezone configured for that user's account is used by the conversation to translate UDT to local time as appropriate.

Now users CAN be (and are by default) set to default to the timezone of the local Connection server - however this can be set to a specific timezone instead - if there's a problem there you probably want to check a few of your users that are reporting the problem and ensure they are set to a specific timezone instead of defaulting - this would not require a reboot of course.  You can bulk set users to a specific timezone (and change the user template for this such that future users created get this by default) - if you do change the timezone of the server I do believe a reboot is required - I think that's loaded as the default fallback zone at startup.  Both will work but changing the timezone for users does not require a reboot and can be easily tested to be sure it's the source of the problem.

Aside from that making sure you're clocks are in synch is always a good idea (presuably you have them pointed at legit time zervers) - but I suspect you'll find users are set to default to the timezone on the server (at least some of them) and as such are experiencing different translation there.

[Brad Magnani]

Just to piggy back on Jeff's comments, here's the official stance in the System Requirements:

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/requirements/8xcucsysreqs.html#wp360300

Connection Cluster Requirements When the Servers Are in Separate Buildings or Sites

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

Hope that helps,

Brad

[Rob Huffman]

Hey Scooter,

WOW.... answers from two of the very BEST here This is why CSC works so well +10

Cheers!

Rob

"Everything is broken" - Bob Dylan