5

When I run psexec to the user desktop (xp pro) I get "There is a time and/or date difference between the client and the server." I also get "access denied" when I run the at \clientname time /interactive "net time \server /set /y" command. I cannot access the machine from my win2k3 server's AD Users and Computers utilities.

Is going to the machine the only way to remedy?

Clarify: Going to the machine and doing the net time command works, but I want a remote solution please.

POST SOLUTION DETAIL:

Thanks to Kyle for the local account psexec solution, I was able to achieve an all-remote fix. In my network, all pc's have the same local administrator account with the same password. Kyle's remote solution appeared to fail at first, but this was because we also had an active domain administrator account with the exact same login credentials. Once I disabled that account, I was able to psexec using the local admin credentials:

>psexec \\systemname -u Administrator cmd

Oddly, once I was in with psexec, I could not do time or net time no matter how hard I tried. I would even do net time remotely and it appeared to work, but when I looked reviewed the "at" commands locally it showed it "could not start."

However, I did notice that once I had made a successful remote connection using the local admin account, I was now able to do regular psexec using my personal domain account as well as entering the system name into explorer like this: alt text

Now that I could access scheduled tasks remotely, I simply made a net time scheduled task using my domain admin account credentials with this run line:

net time \\servername /set /yes

did a right-click>run and that was that. With this seeming so bizarre, I experimented on another desktop by setting the time off, duplicating the previous "There is a time and/or date difference between the client and server" condition and then applying the same fix described successfully!

Detritus Maximus
  • 336
  • 2
  • 4
  • 14

5 Answers5

4

You should fix the real problem instead of working around it: your clock is drifting (either your DC or your XP client).

What you should do is configure the windows time service (http://technet.microsoft.com/en-us/library/bb490605.aspx) to keep the clock in sync. This will resolve your issue indefinitely.

In direct answer to your question, whenever the clocks drift out of sync, all network based authentication/credentials between the two computers with differing clocks will fail. Local accounts will still be able to login. If you use something like psexec and instead of using your domain credentials, you specify valid administrative credentials on the local machine, it should connect just fine and allow you to fix the clock.

Still highly recommended to fix the actual problem instead of work around it, though.

Kyle Brantley
  • 1,331
  • 1
  • 11
  • 14
  • @Kyle: Thanks for this. When you say "all network authentication will fail," do you mean one desktop out of sync will prevent others from syncing? That is not what I've observed. In reading through that MS link, I'm beginning to wonder if my problem is that our operators sometimes are given the ability to change the clocks on their desktops in order to do backdated work. I had thought the logon scripts' sync command would fix, but maybe that is not enough. Next time it happens, I'll try the local credentials over psexec. If that works, that will be great. – Detritus Maximus Dec 28 '10 at 14:42
  • No, on that client only. Once the client is more than 5 minutes out of sync with the DC it is trying to authenticate against, all network based authentication for that specific client fails. If your operators can and are adjusting the clock, then they are borking their own ability to work. Local credentials will work out just fine in this situation. – Kyle Brantley Dec 28 '10 at 17:26
  • I've updated my answer to more directly answer your question. – Kyle Brantley Dec 29 '10 at 04:40
  • @Kyle: I was so hopeful. But, when I did psexec using the local account, I got the same error: "Couldn't access [blahblah]: There is a time and/or date difference between the client and server" Then I tried the -s switch (Run remote process in the System account) and that failed the same way. – Detritus Maximus Dec 29 '10 at 15:22
  • To confirm, when you specified the credentials, did you use HOSTNAME\Administrator of the remote machine? Note that your existing credentials may also interfere with the authentication -- try it from a locally authenticated account (no existing network credentials) and see if it helps at all. If it still doesn't work, I'll try it from my VMs tonight at home. – Kyle Brantley Dec 29 '10 at 17:16
  • @Kyle: I'm going to award you the bounty because your local credential solution is what led to my fix. I couldn't do net time or time once there oddly, but once I got in I was able to type the \\systemname into explorer from my remote desktop and drop a net time scheduled task in and right click run. I'll edit my question to provide full details. Thanks your help and for not just saying "it can't be done" as others implied. – Detritus Maximus Dec 30 '10 at 15:48
  • Once you've established an authenticated session with the box (via psexec, for example) then those credentials are cached and used whenever you access that machine. This is why you could access \\hostname after. And no problem. – Kyle Brantley Dec 30 '10 at 17:38
2

What about having the net time command not only at logon, but executed on a schedule (you could use task scheduler and have it executed every two hours?)

Matthieu Cartier
  • 171
  • 7
  • 1
    That would be dirty. Actually, I would still have to go to the machine to overcome the initial problem because as is I cannot remotely add the scheduled task. But, of all the solutions proposed so far, this is the one I like the best. No software required. – Detritus Maximus Dec 21 '10 at 18:00
  • It's not elegant, no, but it does at least overcome the problem with no additional requirements. :) – Matthieu Cartier Dec 21 '10 at 18:08
  • 1
    I use a variant of this command to do hundreds of machines: `schtasks.exe /create /F /S $RemoteHost /ru domain\User /rp password /tn Sync-Time /sc Once /st $NowPlusOneMinute /tr "w32tm /resync"` – AndyN Dec 27 '10 at 17:47
  • 1
    @Detritus - If you're really running into this problem that often, perhaps a dirty solution is what you need. It's not a normal problem in my experience. – mfinni Dec 27 '10 at 22:15
  • @mfinni: I run into it probably once every other month on average. There are about 25 desktops in my network. – Detritus Maximus Dec 28 '10 at 13:26
  • 1
    @mfinni: The operators frequently change the time on their desktops in order to do backdated work. I think this may be the root cause. – Detritus Maximus Dec 28 '10 at 14:36
  • @Detritus - WTF. You've definitely identified some problems in your environment. Take away those rights. That sounds like it might even be illegal, depending on what your company's business is. – mfinni Dec 28 '10 at 14:40
0

Have you read this from Microsoft regarding the issue?

You can try this on the XP machine. Login locally as the admin then from command promt type:

net time /Domain:DOMAINGOESHERE /Server:SERVERGOESHERE /SET /Y

See if that helps.

0

If this comes up more often, you could set up a different remote acces solution. Logmein and open/freessh + plink come to mind, altough you would have to access the xp machine once physically.

KutscheraIT
  • 203
  • 1
  • 6
  • I do want a solution that is entirely remote. VNC is what I would use if I were willing to go the software route. But for this I'd like to avoid installing software domain wide for an occasional problem that is random on my network. Under normal circumstances I can install a lot of software remotely, but not while this time problem exists. – Detritus Maximus Dec 21 '10 at 17:04
  • Have you tried to rdp to the client machine? – KutscheraIT Dec 21 '10 at 17:13
  • @Weltenwanderer: Yes, I can rdp to the client machine. I do not want to correct that way because I would have to and do not want to kick users off to fix. – Detritus Maximus Dec 21 '10 at 19:57
0

Could you add the Net Time command to a login script for the Domain? Then when ever a user logs in the time will be synced to the Domain's time controller, and the problem should not arise.

BillN
  • 1,503
  • 1
  • 13
  • 31
  • All our login scripts include the set time command already. The computers get left on all week and I figure either they are off just enough to drift out of the window during the week or there are occasional boottime network issues that prevent the command from completing. – Detritus Maximus Dec 21 '10 at 17:49