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.


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!

  • Call DHL to bring the box to you. Commented Dec 27, 2010 at 21:44
  • @Adrejs: Brilliant! Commented Dec 27, 2010 at 23:05
  • Hmm.... You want to remotely solve a problem that is preventing you from having remote access to the target machine. I believe your solution can be found at Ollivander's Wand Shop. Commented Dec 29, 2010 at 4:48
  • @John: Does that mean you think Kyle's local credentials solution will not work? Commented Dec 29, 2010 at 13:42
  • if remote access is being denied it makes no difference what credentials are being used. However, you have nothing to lose by trying it, other than about 30 seconds of your time. Commented Dec 29, 2010 at 20:42

5 Answers 5


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: 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. Commented Dec 28, 2010 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. Commented Dec 28, 2010 at 17:26
  • I've updated my answer to more directly answer your question. Commented Dec 29, 2010 at 4: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. Commented Dec 29, 2010 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. Commented Dec 29, 2010 at 17:16

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

  • 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. Commented Dec 21, 2010 at 18:00
  • It's not elegant, no, but it does at least overcome the problem with no additional requirements. :) Commented Dec 21, 2010 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
    Commented Dec 27, 2010 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
    Commented Dec 27, 2010 at 22:15
  • 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. Commented Dec 28, 2010 at 14:36

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:


See if that helps.

  • Er, he asked whether it's possible to do it without actually physically being at the machine... Commented Dec 21, 2010 at 16:02
  • Where did it state "without actually physically being at the machine"?
    – ngen
    Commented Dec 21, 2010 at 16:06
  • Title: "Cannot access client pc REMOTELY..." Commented Dec 21, 2010 at 16:21
  • Your last line is misleading, it sounds like you're open to "going to the machine" if necessary.
    – ngen
    Commented Dec 21, 2010 at 16:23
  • Added clarification. Commented Dec 21, 2010 at 16:27

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.

  • 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. Commented Dec 21, 2010 at 17:04
  • Have you tried to rdp to the client machine? Commented Dec 21, 2010 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. Commented Dec 21, 2010 at 19:57

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.

  • 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. Commented Dec 21, 2010 at 17:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .