Unity DST problems

Answered Question

Running Unity 4.1(1). Servers all changed over correctly. Voicemail time stamps still 1 hour behind. Running Server 2000 on Unity servers, Exchange 2003 on Windows 2003 server. Outlook Web Access showing correct time stamps.

Logging in to the TUI, prompt is an hour behind.

What did I miss?


I have this problem too.
0 votes
Correct Answer by MikeTomasko about 9 years 7 months ago

NICE! Do I get a rating for my Mar 12, 2007, 5:35pm PST post with that suggestion? Ha!!

Correct Answer by rpsunbeam about 9 years 7 months ago

rebooting unity didn't do a thing.. but what did work was shutting down unity, changing the time zone to anything else.. then setting it back properly to the right time zone and restarting unity.. everything worked properly after that.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
williamka Sun, 03/11/2007 - 10:53

Same thing for me..... except running 4.2(1). Ran the Unity patches DC/Exchange and Unity timestamps correct...

Anyone else?

williamka Sun, 03/11/2007 - 13:51


I was able to get this to work by manually disabling in time zone to do not update automatically on both exchange server and unity.

Just finished testing successfully and voicemail timestamps are correct. Hope this helps


Updating the clocks manually seems to break something along the way.

First Unity box unregistered its ports with our Call Manager and went into failover mode.

I wonder if the clocks are trying to sync with our domain controllers which are correct.

I put everything back to auto and the correct time. The prompts are an hour behind but at least it all works.

rpsunbeam Mon, 03/12/2007 - 06:15

same thing here..

everything shows the proper time but voicemail prompts are an hour behind.

MikeTomasko Mon, 03/12/2007 - 07:16

Did you install the JRE Time Zone Update in addition to the Windows update?

Unity 4.2 also has ES59 that needs installed.

Unity 4.1(1) also has additional updates:


These instructions are for patching the time zone information used by the Unity Inbox in Unity 4.1(1) only if 4.1(1)ES34 is also present.

Pre-requisite: This update applies if the following two conditions on your Unity system are true:

1) Unity 4.1(1) is installed

2) Unity 4.1(1) ES34 is present

To determine if Unity 4.1(1) ES34 is installed, run the Gather Unity System Information (GUSI) tools from Tools Depot.

The report generated will list the Engineering Specials (ES) present on your system

If your Unity system does not meet the two pre-requisites above, do not proceed with this Engineering Special (ES) as it does not apply to your system.

Installation Steps:

Step 1: Open the Services MMC (type "services.msc" from Start -> Run) and stop the Tomcat service

Step 2: Make a backup of the following file found in path :\CommServer\cscoserv\ciscopca\WEB-INF\classes

Current File Name: TimeZoneData.properties

New File Name: TimeZoneData.properties.org

Step 3: In the folder containing this ReadMe.txt, copy the file TimeZoneData.properties to path


Step 4: Open the Services MMC (type "services.msc" from Start -> Run) and start the Tomcat service

Yes, the JRE Time Zone Update WAS applied to both of our Unity boxes in addition to the Windows patch.

The ES patch was NOT installed as we didn't meet the pre-requisite to install it. We don't have ES34 installed:

Unity Install Information:

Unity server name = UNITY1

Unity version = 4.1(1.0)

No Engineering Specials installed

Logging diagnostics and data files to= d:\CommServer\Logs\

Total capacity (megs)= 67142.93

Megs free= 50797.2

% free space= 75.66

UMR repository location= d:\CommServer\UnityMTA\

Total capacity (megs)= 67142.93

Megs free= 50797.2

% free space= 75.66

Cisco Unity TSP version = 8.0(2)

CSAgent = -not installed-

Switch 1 = IPCM1

Switch 2 = Not installed

Ports configured = 72

Default recording codec = 8K Mu-Law

TUI Languages loaded = ENU

Default TUI Language = ENU

GUI Languages loaded = ENU

Default GUI Language = ENU

Default TTS Language = ENU

TTS Default Engine =

Standard Unity conversation in use

MikeTomasko Mon, 03/12/2007 - 07:31

Did you try running the JRE update again to make sure it says it was installed?

To verify the update was successful, issue the same command:

"X:\CommServer\cscoserv\Java2SDK\jre\bin\java -jar tzupdater.jar -u -v"

and verify the returned text contains this statement:

"You have the same version as the embedded one."

Is this a Unified or VM only installation?

MikeTomasko Mon, 03/12/2007 - 07:45

Wow...really running out of options!

Did you run Microsoft's TZEDIT just to verify the time zone was correctly edited?

Did you try stopping and restarting the Tomcat service?

rpsunbeam Mon, 03/12/2007 - 07:46

just got off with cisco tac, and they suggested (altho there are no notes about it) that the Unity box needs to be reloaded, and possible exchange server for the dst patches to take effect.

obviously can't do that in the middle of the day, so will update later if that solves it.

the server correctly rolls to DST, but tac said that rebooting seems to be the trick..

windows.. when in doubt.. reboot.

MikeTomasko Mon, 03/12/2007 - 07:48

I'd still give stopping and restarting the Tomcat service a shot. Might save you a reboot.

rpsunbeam Mon, 03/12/2007 - 07:48

per cisco tac, jre is only for the pca interface.. would have nothing to do with time stamping on msg's,thats between exchange and unity.

I'm off to the reboot fairy tonight. see if that solves the issue.

jilundain Mon, 03/12/2007 - 08:24

Certain Windows systems are showing the wrong time even though the DST patch has been applied to the system: Simply change the time zone to some other time zone manually on the affected system, apply it, and then change it back to the correct time zone.

Here are some details on this:


thisisshanky Mon, 03/12/2007 - 09:25


I am running 4.2(1) for a client, the server not in production yet, so no worries here about the DST changes. I had applied ES59 and JRE updates as required last week. I tested over the weekend, changed the time to 1.59 am and the time did change succesfully to 3.00 am. So I was hoping things should work properly on Monday. I see on Monday that the time never changed properly at all over the weekend. The server clock and timestamps were an hour off. I had to manually change the time on the server today..

Rebooting the Exchange message store did not do a darn thing to the time stamps. They are still an hour behind.

The only thing we have not applied was the Exchange patch described in the link above. I'm reluctant to apply it due to the fact that messages may stop flowing.

Has anyone applied this Microsoft Exchange patch and if so did you run into any problems with Unity?


Correct Answer
rpsunbeam Tue, 03/13/2007 - 06:59

rebooting unity didn't do a thing.. but what did work was shutting down unity, changing the time zone to anything else.. then setting it back properly to the right time zone and restarting unity.. everything worked properly after that.

Correct Answer
MikeTomasko Tue, 03/13/2007 - 07:01

NICE! Do I get a rating for my Mar 12, 2007, 5:35pm PST post with that suggestion? Ha!!

k6lw Tue, 03/13/2007 - 09:01

Unity 4.2.1. Server is set for no auto DST.

Time sone is set for Arizona. Time stamps in Exchange for left messages show correct time. Phones show correct time. TUI readback of messages are an hour off. Will try rebooting server.

jalston45 Thu, 03/15/2007 - 07:23

Has anyone gotten this issue resolved. I didn't have this problem going into Tuesday, however now I do. My Unity VM's are 1 hour behind, but the system clock is fine.

The easiest fix providing you have applied the DST patches to the OS is (at least for me):

1. On your Unity server stop Unity but don't shutdown the entire server.

2. Once Unity has stopped, go to the date / time control panel applet and change your time zone to something different. CLICK APPLY.

3. In the same applet, change your timezone back to your normal time zone. CLICK OK.

4. Start Unity.

Do the same on the failover if you have one.

Hope this helps.


Tommer Catlin Mon, 03/12/2007 - 15:44

I thought I had heard that the Exchange patch from MS did not work as well as they thought it would. I have been hearing rumbles about Outlook not working right for appointments.

If you have failover running with Unity, I think that if the Primary's time is different than the failover server, the SQL database will come off it's rocker for replication cause a failover trigger to happen. This drops the TSP ports and may trigger the "flipping" failover from primary to secondary and vice versa.

MikeTomasko Mon, 03/12/2007 - 17:35

What OS on the servers? Did you apply KBs or use TZEDIT? I heard of people having problems with TZEDIT. It lets you go in and edit the Time Zone and saves the changes, but it doesn't apply them till you go back into TZEDIT, pick another Time Zone then switch back to your correct Time Zone.

MikeTomasko Mon, 03/12/2007 - 19:39

Has anyone just tried disabling "Automatically adjust clock for daylight saving changes" in Windows and manually setting the time?

Where does Unity get the time for the time stamps on the TUI?

The Windows API knows the correct time on all my servers including two Unity boxes and an Exchange box. If I log in to OWA and send myself an email message, it is stamped with the correct time.

This tells me that the Exchange piece is OK. So where does Unity pull the time from?

k6lw Tue, 03/13/2007 - 09:32

If you're in California, (Or Pacific Coast),

just turn off the Auto set DST in the windows clock, set your time zone to Arizona (which doesn't recognize DST) and then reboot Unity.

I have a VM only configuration with Exhcange on box. All of the time settings were correct yet the TUI reported the time stamps as an hour off. I rebooted Unity just now, and now it's reporting the same message with the correct time. NO PATCHES REQUIRED!!!


This Discussion