cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1627
Views
0
Helpful
29
Replies

Campus Manager 4.0.9 Time Discrepancies LMS 2.6

DOUG REISS
Level 1
Level 1

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

System Status

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).

29 Replies 29

#2 of 3 items.

#3 of 3 items. Completed request, hopefully!

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:

Input:

d:/CSCOpx/MDC/jre/bin

java -Duser.timzone=America/Chicago locale

Output results:

D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago

locale Locale = en_US Timezone =

D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago

locale

Locale = en_US Timezone =

java.util.SimpleTimeZone[id=America/Chicago,offset=-2160000

0,dstSavin

gs=3600000,useDaylight=true,startYear=0,startMode=3,startMo

nth=2,startDay=8,star

tDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,en

dMonth=10,endDay=1,en

dDayOfWeek=1,endTime=7200000,endTimeMode=0]

Avoiding duplication in the posting, as done, unfortunately, above:

Output results:

D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago

locale Locale = en_US Timezone =

java.util.SimpleTimeZone[id=America/Chicago,offset=-2160000

0,dstSavin

gs=3600000,useDaylight=true,startYear=0,startMode=3,startMo

nth=2,startDay=8,star

tDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,en

dMonth=10,endDay=1,en

dDayOfWeek=1,endTime=7200000,endTimeMode=0]

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.

There is one other key that may be of interest. What are the values at HKLM\SYSTEM\Select?

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco