Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question

migrated from superuser.com Dec 27 '10 at 17:11

This question came from our site for computer enthusiasts and power users.

    
Call DHL to bring the box to you. –  Andrejs Cainikovs Dec 27 '10 at 21:44
    
@Adrejs: Brilliant! –  Detritus Maximus Dec 27 '10 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. –  John Gardeniers Dec 29 '10 at 4:48
    
@John: Does that mean you think Kyle's local credentials solution will not work? –  Detritus Maximus Dec 29 '10 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. –  John Gardeniers Dec 29 '10 at 20:42
add comment

5 Answers

up vote 4 down vote accepted
+50

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.

share|improve this answer
    
@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 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. –  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
show 2 more comments

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

share|improve this answer
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
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
show 2 more comments

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.

share|improve this answer
    
Er, he asked whether it's possible to do it without actually physically being at the machine... –  Matthieu Cartier Dec 21 '10 at 16:02
    
Where did it state "without actually physically being at the machine"? –  ngen Dec 21 '10 at 16:06
    
Title: "Cannot access client pc REMOTELY..." –  Detritus Maximus Dec 21 '10 at 16:21
    
Your last line is misleading, it sounds like you're open to "going to the machine" if necessary. –  ngen Dec 21 '10 at 16:23
    
Added clarification. –  Detritus Maximus Dec 21 '10 at 16:27
add comment

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.

share|improve this answer
    
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? –  Weltenwanderer 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
add comment

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.