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:
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!
Best Answer
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.