Campus Manager Home shows Device Discovery and Data Collection times to be SIX hours ahead of the (correct) Last Updated Time:
Auto Refresh Version : 4.0.9 Last Updated: 04 Jan 2008, 13:06:46 CST
Operation Last Completion Time Result Status Action
Device Discovery 04 Jan 2008, 19:01:15 CST 46 Devices Idle Start Device Discovery
Data Collection 04 Jan 2008, 19:04:32 CST 46 Devices Idle Start Data Collection
User Tracking Acquisition 04 Jan 2008, 12:39:14 CST 2191 End Hosts
0 IP Phones Idle Start UT Acquisition
No Forum postings or Tech Support items relating to this have been located. (Cannot add as attachment).
Yes, this completes the request, but it does not indicate why the timezone is not being properly read by Java. You should follow back up on your TAC services request as remote access will be needed.
Remote access is not possible -- can you please consult with Ken Viola to obtain a different workaround, or to arrange a Remote Access session on his server, or on a test device he may have in his network that might be accessible?
Joe: Was the other report of this you saw from an IRS device? Actually, not all of our servers have this issue, apparently, so we may need to perform some more advanced server diagnostics on our own. Thank you for assisting.
Yes, it was your service request. While you may have some registry corruption, I would expect to see it in the keys I've requested. As I said, getting Meeting Place access to this server would have to be our next step so we could run some more advanced diagnostics.
You could also rule out a Java problem by running the locale application in the following way:
NMSROOT\MDC\jre\bin\java -Duser.timezone=America/Chicago locale
If that returns the correct CST timezone, the problem lies on the Windows side in the registry.
Input and output: did this return the correct CST timezone? A bit at loss for how to tell:
java -Duser.timzone=America/Chicago locale
locale Locale = en_US Timezone =
Locale = en_US Timezone =
Avoiding duplication in the posting, as done, unfortunately, above:
locale Locale = en_US Timezone =
This is the correct output that I would expect to see without the -Duser.timezone argument. Therefore, the problem lies on the Windows side. Java is unable to map the Windows timezone, Central Standard Time, to the Java timezone, America/Chicago.
As a Meeting Place session is not possible (I prefer to keep my job), can you provide us with Registry items to compare between a server that is functioning correctly and one that is not? Thanks for any assistance you can provide. My e-mail is available through Ken Viola, whose contact information you should have.
I've already given you all of the registry keys that should be used by Java to obtain the timezone information. All of them check out.
The way it should work is the JVM reads through all of the keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones until it finds the timezone configured in the TimeZoneInformation key. Once it does, it uses the map value (36,37 in this case) to map that timezone to a Java timezone using the tzmappings file.
Something is not happening properly there, but without deep process inspection, I cannot say what that is.
Attached are the requested values and also a download message about the most recent Java loaded on the SErver (could that be the problem source?) and sample output from the Java Console (many duplicate messages removed to reduce repetition). Had to remove a screen capture of the Java download verification screen, but details of the most current Java as being loaded on the machine are transcribed.
Thanks for your efforts on this, Joe. Will follow up with Harold when I return on Jan. 22nd, meanwhile, will give Harold the e-mail addresses of some of our other specialists, if they have time to pursue this.