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).
I have seen one other report of this, but have not had a chance to fully analyze why it is happening. I suspect a problem with some Registry entries related to timezone information. The other user was also having problems with the CST timezone.
Please provide the registry keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Standard Time.
Found and transcribed all keys in text file, which I will attempt to attach. Successfully attached and will also attach Word document with screen-shot previously unable to attach for some reason. Thanks for the speedy reply, Joe!---Doug
This symptom is actually occurring on about 20 CiscoWorks servers (Windows) deployed in our network. Just wanted to let you know that my instance of this problem is the "tip of the iceberg", and that I'm acting as a representative for our group-- D. Reiss
Next things to get are the keys under HKLM\System\CurrentControlSet\Control\TimeZoneInformation, as well as the same key under all available control sets (e.g. ControlSet001). Then post the NMSROOT\MDC\jre\lib\tzmappings file.
Thanks again for the speedy reply---I will have to follow through on this on Monday. Have a good weekend!
Could not fulfill this request until today...Attached are 3 .doc files with Registry Screen Captures and 1 tzmappings file (no file extension) as requested 1/4/2008. TZmappings was previously shared with Harold Mendez, but is posted in a reply to my next posting below due to number of attachment limitations.
None of the ControlSet screenshots shows any values. I need to compare the values from the CurrentControlSet with those in the other ControlSets.
Joe: If you examine the bottom line of the screen frame, you will see that ONE of them satisfies the request made in detail. None of the others were UNDER Current Control Set as there were none found except UP one level in the registry---I supplied what looked close to your request as possible---our inability to communicate directly is perhaps creating issues here. Please re-examine the posting that does not show Control00x, where x = 1 or 3. I connot control what the results are, so if no values were shown, you need to tell me what kind of values are needed or expected for this to be of use for us, if possible in advance. I appreciate that it is difficult for you to specify an exact Registry item you need to examine without access to the device, so I've consulted with Ken Viola and he is requesting further information on this or that you contact him directly, if at all possible.
By values I mean you need to scroll to the far right in the Window of the registry keys so that I can see the values for those keys. I suspect the key values for CurrentControlSet differ from those of ControlSet001. But with this current set of screenshots, I cannot tell.
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.
This doesn't shed any new light on the problem. I gave more details to Harold. Follow up with him on your SR.
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.