Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
GoogleCodeExporter opened this issue Aug 26, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link

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 [email protected] on 13 Apr 2011 at 2:36

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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 [email protected] on 13 Apr 2011 at 3:59

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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 [email protected] on 13 Apr 2011 at 5:34

@GoogleCodeExporter
Copy link
Author

Windows 7 Professional x64

Original comment by [email protected] on 13 Apr 2011 at 5:36

@GoogleCodeExporter
Copy link
Author

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

  • Changed title: idle time for server 2008 x64 is reported with 4.31 additional minutes

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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 [email protected] on 14 Apr 2011 at 6:22

@GoogleCodeExporter
Copy link
Author

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

  • Changed title: Idle time not accurate when Windows 7 client system time not synchronized with Windows Server 2008 R2 server system time
  • Added labels: Priority-Low
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 17 Apr 2011 at 4:11

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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 [email protected] on 19 Apr 2011 at 2:13

@GoogleCodeExporter
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant