devocity-us / cassia

Automatically exported from code.google.com/p/cassia
0 stars 0 forks source link

Idle time not accurate when Windows 7 client system time not synchronized with Windows Server 2008 R2 server system time #42

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I'm using the TimeSpan IdleTime.TotalMinutes to get remote servers sessions 
idle times.

1. on any version of server 2008 x64 the reported idle time is adding 4.31 
seconds to the actual idle time.
for example: if the actual idle time is 0, the reported idle time using 
IdleTime.TotalMinutes is 4.31.

2. no problem with server 2003.
3. I didn't test on server 2008 x86 platform.
4. the test was made from Windows 7 x64 using Cassia version 2.0.0.60.
5. no problem when running the solution locally on the remote server.

Original issue reported on code.google.com by orenro...@gmail.com on 13 Apr 2011 at 2:36

GoogleCodeExporter commented 8 years ago
Thanks for reporting this issue. This is for 2008, not 2008 R2, right? Did you 
mean 4.31 seconds or 4.31 minutes? Can you download the latest build from the 
build server (http://teamcity.codebetter.com/project.html?projectId=project51 
-- login as a guest and use the artifacts link) and let me know whether the 
issue still exists in that version?

Original comment by danports on 13 Apr 2011 at 3:17

GoogleCodeExporter commented 8 years ago
1. sorry, its 4.31 minutes.
2. Cassia version 2.1.0.109 didn't solve the issue.
2. the tested remote servers versions are:

- 2008 SP2 x64
- 2008 R2

but I don't have the problem when running the test locally on those servers.

Also, I didn't check on 2008 x86.

Original comment by orenro...@gmail.com on 13 Apr 2011 at 3:59

GoogleCodeExporter commented 8 years ago
OK, thanks. What Windows version is the client (the one running the Cassia code 
and calling GetRemoteServer) running?

Original comment by danports on 13 Apr 2011 at 4:54

GoogleCodeExporter commented 8 years ago
1. sorry, its 4.31 minutes.
2. Cassia version 2.1.0.109 didn't solve the issue.
2. the tested remote servers versions are:

- 2008 SP2 x64
- 2008 R2

but I don't have the problem when running the test locally on those servers.

Also, I didn't check on 2008 x86.

Original comment by orenro...@gmail.com on 13 Apr 2011 at 5:34

GoogleCodeExporter commented 8 years ago
Windows 7 Professional x64

Original comment by orenro...@gmail.com on 13 Apr 2011 at 5:36

GoogleCodeExporter commented 8 years ago
OK, I'll try to reproduce the issue on a Windows 7 x64 client + Windows Server 
2008 R2 x64 server.

Original comment by danports on 14 Apr 2011 at 1:15

GoogleCodeExporter commented 8 years ago
I was not able to reproduce this issue on the Win7/2008R2 combination that I 
mentioned. Could you provide a sample program that reproduces this issue for 
you? Also, are the client and server systems' clocks synchronized?

Original comment by danports on 14 Apr 2011 at 1:26

GoogleCodeExporter commented 8 years ago
You are correct. The issue was the time sync between the machines.

But when checking, the time was off also between the client (win7) and the 
server (2003), and the reported idle time in this case was correct (despite the 
offset).

Original comment by orenro...@gmail.com on 14 Apr 2011 at 6:22

GoogleCodeExporter commented 8 years ago
Hm, interesting. Not sure whether there is anything that can be done about 
that, but I'll see if I can reproduce it.

Original comment by danports on 17 Apr 2011 at 12:21

GoogleCodeExporter commented 8 years ago
well, as you gave me the direction the issue is time sync and I know what to 
look for, I've made a workaround.

with the idle time I also get the time of the remote machine and showing the 
idle with consideration of the offset (if detected).

Thanks.

Original comment by orenro...@gmail.com on 17 Apr 2011 at 4:11

GoogleCodeExporter commented 8 years ago
How are you fetching the time on the remote machine? 
ITerminalServicesSession.CurrentTime? Just wondering if your workaround is one 
that would make sense to include in Cassia.

Another approach would be to ensure that all of your systems are synced to an 
authoritative time source (assuming you have administrative control over them).

Original comment by danports on 19 Apr 2011 at 1:14

GoogleCodeExporter commented 8 years ago
I'm using NetRemoteTOD Function to get the remote machines time
http://msdn.microsoft.com/en-us/library/aa370612%28v=vs.85%29.aspx

//////////////the following code is for C#

        private const int NERR_Success = 0;

        [DllImport("netapi32.dll", SetLastError=false)]
        private static extern uint NetApiBufferFree ( IntPtr Buffer );

        [DllImport ( "netapi32.dll", CharSet = CharSet.Unicode,
        SetLastError = false )]
        private static extern uint NetRemoteTOD ( string
        UncServerName, ref IntPtr BufferPtr );

        [StructLayout(LayoutKind.Sequential)]
        private struct TIME_OF_DAY_INFO
        {
            public uint tod_elapsedt;
            public uint tod_msecs;
            public uint tod_hours;
            public uint tod_mins;
            public uint tod_secs;
            public uint tod_hunds;
            public uint tod_timezone;
            public uint tod_tinterval;
            public uint tod_day;
            public uint tod_month;
            public uint tod_year;
            public uint tod_weekday;
        }

//////////////end code

Original comment by orenro...@gmail.com on 19 Apr 2011 at 2:13

GoogleCodeExporter commented 8 years ago
I see. I'd rather avoid bringing in an unrelated API to work around what is 
likely an issue with the WTS API, but it is something to consider. Thanks.

Original comment by danports on 19 Apr 2011 at 2:32