Geeks With Blogs
Robert's Sysadmin Blog Unraveling the datacenter one fibre at a time


Update 18 march:
Short awnser: Time Zone settings
Scroll down for more info!

----------------------------------------------------

FFS, the sentence "The clocks on the client and server machines are skewed"
produces a mere 2 pages in google. For something that seems to be relatively easy to have happen, there is a sad mount of data available on the problem. I hope this post helps.

So I was setting up 2 Windows Server 2003 images. I had copied an already working configuration of mine, renamed it, and wanted to use these copies for a small server farm Sharepoint installation.

I start up the two images: A W2K3 domain controller, and a W2K3 member server, and check the event logs to see if all went well. Well it didnt.

Userenv Event ID 1097
Windows cannot find the machine account, The clocks on the client and server machines are skewed

Userenv Event ID 1030
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.


The member server was producing Userenv Event ID 1079 and Userenv Event ID 1030 (see below), and the DC was producing W32time Event ID 12 (see below)

The eventlog on the DC furthermore showed that the member server was running into errors on a Kerberos level. This makes sense of course; Kerberos requires accurate time data to function, and if that isnt working propery, Kerberos will run into problems.

What annoyes me is that on the client, you get such strange results.. or I mean a lack thereof. The login procedes normally, and it isnt until you look in the eventlog that you see Kerberos is failing.. on some level, apparently with the only consequence that you can see, being that it cant poll for GPO objects. I cant believe that that would be the only thing to fail, surely Windows is gonna run into more serious problems somewhere if it cant propery authenticate Kerberos with its DC! Surely!

Now W32time Event ID 12 is perfectly normal and can be ignored, accoring to KB article 816042:
How to configure an authoritative time server in Windows Server 2003. Windows would rather refer to an external time source.. but in this virtual pc world, there is no external world, so the DC will have to make do with the CMOS. Checked the registry setting that reflected this.

So if this error is normal and can be ignored, then why is my member server being so damned difficult??

You know how you are always instructed to use Netdiag to solve Kerberos problems? Guess what..  it doesnt tell you anything about this problem. It doesnt even fail Kerberos.

So I finally delved into the Windows Time Service, and ended up doing w32tm /resync /rediscover on the member server.

Reboot.

Hey guess what. Same error.

Back to Google, and the following Experts-Exchange discussion threw some more ideas' my way.
http://www.experts-exchange.com/Operating_Systems/Windows_Server_2003/Q_20973984.html

Ran DC Diag on the DC, something interesting:

Starting test: MachineAccount
   * The current DC is not in the domain controller's OU
   ......................... SERVER1 failed test MachineAccount

Interesting...    and its true.. I had moved the DC's computer account to a different OU. I didnt think it would matter, after all, all I thought the OU would matter is if it happened to have some kind of (delegation) rights on there that where non-standard.. and of course linked GPO's.

DCDiag passed all other tests. So lets go verbose and in depth:
DCDiag /test:MachineAccount /v

 Starting test: MachineAccount
    * The current DC is not in the domain controller's OU
    * SPN found :LDAP/server1.contoso.com/contoso.com
    * SPN found :LDAP/server1.contoso.com
    * SPN found :LDAP/SERVER1
    * SPN found :LDAP/server1.contoso.com/CONTOSO
    * SPN found :LDAP/3997ffc6-e7bd-4a6f-a63b-f60a38b805f0._msdcs.contoso.com
    * SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/3997ffc6-e7bd-4a6f-a63b-f60a38b805f0/contoso.com
    * SPN found :HOST/server1.contoso.com/contoso.com
    * SPN found :HOST/server1.contoso.com
    * SPN found :HOST/SERVER1
    * SPN found :HOST/server1.contoso.com/CONTOSO
    * SPN found :GC/server1.contoso.com/contoso.com
    ......................... SERVER1 failed test MachineAccount


Not much news there.

You know... remember Userenv Event ID 1079 (Windows cannot find the machine account, The clocks on the client and server machines are skewed) on the client?

Still think its reffering to not being able to find its own computer account, cause that is what I had been assuming uptil now....

So on the member server: netdiag /test:member /v

Domain membership test . . . . . . : Passed
    Machine is a . . . . . . . . . : Member Server
    Netbios Domain name. . . . . . : CONTOSO
    Dns domain name. . . . . . . . : contoso.com
    Dns forest name. . . . . . . . : contoso.com
    Domain Guid. . . . . . . . . . : {524322ED-7D02-4301-9929-FE40BBFAF75E}
    Domain Sid . . . . . . . . . . : S-1-5-21-3731928977-4000084638-1050712798
    Logon User . . . . . . . . . . : Administrator
    Logon Domain . . . . . . . . . : SRVSQL01

Nothing wrong there eh? And besides, if there was a problem with the computer account of this member server, I probably wouldn't even have been able to log on, plus you would get some errors in the eventlog of the DC.

So... lets just try moving the DC's computer account back to its default OU.

Shutdown member server, Reboot DC.

DC still producing
W32time Event ID 12

Start member server.

Same error.... UserEnv Event ID 1030 and 1097

Un. Fucking. Believable.


C:\Documents and Settings\Administrator>net time /setsntp:
The command completed successfully.

C:\Documents and Settings\Administrator>net time /set /yes
Current time at
\\SERVER1 is 3/17/2005 1:55 AM

Local time (GMT-08:00) at \\SERVER1 is 3/16/2005 5:55 PM

The command completed successfully.


And in the event log:
W32time Event ID 37
The time provider NtpClient is currently receiving valid time data from server1.contoso.com (ntp.d|192.168.0.3:123->192.168.0.1:123).

Looking good.

gpupdate on the member server

Same error.... UserEnv Event ID 1030 and 1097 ..  complete and utter contradictory between the results.

netdiag /v  on member server reveals nothing, exept for no default gateway being defined.

on the DC: nltest /dsgetdc:maisto /timeserv
DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Interesting!

From the help:
NLTest can test and reset the secure channel established by the NetLogon service. This secure channel is established between clients and the domain controller that logs them on. NLTest does not work for clients using Kerberos for authentication since this secure channel is not used with Kerberos.

Oke..  so does that mean then that if Kerberos can authenticate properly, its not gonna use the NetLogon secure channel, so this test is useless?

Oke.. referencing the Experts-Exchange article again...  lets try decoupling the Default DC policy, and see what happens after a full reboot.

Still no dice. Decoupled the policy object from the Domain Controllers OU, no change.

More handy information at http://www.wilsonmar.com/1clocks.htm
 Once a domain controller is known to keep accurate time, use RegEdit to mark the computer as reliable by navigating to HKEY LOCAL MACHINE \SYSTEM \CurrentControlSet \Services \W32Time \Parameters subkey and changing the "ReliableTimeSource" REG_DWORD to value "1".
This information is echo'd here aswell:
http://support.microsoft.com/kb/q223184/

Rebooted both servers. No luck.

Red phoned me with an observation...  he noticed something wierd about the following:
C:\Documents and Settings\Administrator>net time /set /yes
Current time at
\\SERVER1 is 3/17/2005 1:55 AM

Local time (GMT-08:00) at \\SERVER1 is 3/16/2005 5:55 PM

The command completed successfully.

I hadn't noticed it. I had paid attention to the event log, and had not taken enough time to check what the net time command showed me very simply. System time itself seemed to be syncronous. Well duh! If its 12am here, and its 12am in Australia, clocks are gonna show the same time!

I reset the server to GMT+1 (Amsterdam time)
I reset the member server to GMT+1
Reboot both

Problem is solved, no more wierd errors, GPO is applied succesfully.

So windows keeps track of two times: Its own current system time, and the Local time, based on the time zone.
What I find curious however, is that if I change the time zone on the member server to say, Darwin (GMT+9.30), net time will give you this:

C:\Documents and Settings\Administrator>net time
Current time at
\\SERVER1 is 3/19/2005 1:44 AM

Local time (GMT+01:00) at \\SERVER1 is 3/18/2005 5:14 PM

The command completed successfully.

And then run a GPUpdate, and you will get errors again.

Our member server, SERVER2, sees SERVER1's current time as local time +GMT +9.30, even though it knows that SERVER1's local time is different.
What suprises me is that our little experiment shows that Active Directory uses current time, as apposed to local time, to compare stuff, in this case within its policy engine.
Kerberos on the other hand, seems to have no problem with the disparency. As long as local time, equating to system time, is synced, there are no problems for Kerberos.

Question number 1 : Why does the Group Policy Engine, Userenv, seemingly rely on 'current time' as it interprets it from another server (that might be halfway across the globe), as apposed to 'local time', which is what Kerberos seems to rely on, and which is what all this time sync stuff is based on!

Now what I find rather puzzling about this, is, what if you had a single domain, spread out over 2 continents? How are you suppose to organize your time.
In this case I have a DC in Amsterdam, and a member server in Darwin.

But wait! Clients get their time data from DC's, I knew that. And by our little experiment we have shown that if the time-zones dont match up, you get problems. So my member server would have to have a time zone of GMT+1, just cause of this problem?

But what if we place a  DC in darwin? How does this work when 2 DC's talk to eachtother? You setup your two DC's, and the Darwin DC has the Darwin time zone.
Question number 2: Does Policy processing still fail across the DC's in that case? Does the use of AD 'Sites' mitigate this problem perhaps?

Awnsers to these questions to follow!

 

------------------------------------------------------------

Key-frases and texts:

W32time Event ID 12
Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source.  It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source.  Otherwise, this machine will  function as the authoritative time source in the domain hierarchy.  If an external  time source is not configured or used for this computer, you may choose to disable  the NtpClient.


Userenv Event ID 1097
Windows cannot find the machine account, The clocks on the client and server machines are skewed

Userenv Event ID 1030
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.




 

Posted on Wednesday, March 16, 2005 11:18 PM Tech , In The Trenches | Back to top


Comments on this post: ITT: The clocks on the client and server machines are skewed (solved)

# re: ITT: The clocks on the client and server machines are skewed (unsolved)
Requesting Gravatar...
a very useful resource for checking eventid problems is.... http://eventid.net

quick check on 1030 brings a lot of useful comments, including one that says these errors can be ignored....

I'd also recommend searching google groups as well as web - there are a couple of posts regarding these errors... I'm sure you've already verified this (and the fact you can log on suggests it is not an issue) but is the *date* the same on both servers as net time /set only synchs the time?

It'll be interesting to see if the problems disappear in April after Daylight Saving Time ends....
Left by petal on Mar 18, 2005 12:01 AM

# re: ITT: The clocks on the client and server machines are skewed (unsolved)
Requesting Gravatar...
1. Start Registry Editor
2. Navigate to the following Registry key:
HKLM\System\CCS\Control\LSA\Kerberos
3. In the Kerberos key, on the right you will see a value of Auth0 = ScSubAuth. Click this value, and then on the Edit menu, click Delete.
4. Repeat the previous step for the following registry key:
HKLM\System\CCS\Control\LSA\MSV1_0
5. After you remove these values, restart the computer and log on as usual.


and also check your Time zone settings on the server there seems to be a difference
Left by Red on Mar 18, 2005 4:44 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
winderz is teh hair puller of yore.
had simmiliar problems and realized it was the time zone as you stated. you would think that client settings would update and reflect what is set on the DC located at the site. just dont get why not.
glad your werked it out.
AJ
Left by clockwerkboy on May 30, 2006 3:09 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I got an even better one for you guys. I have a lone physical DC running Server 2003. On a separate PC running Windows XP, I threw VMware on there and loaded Server 2003 in it, simply for testing purposes. In order to prevent any clock fighting, I disabled the "Automatically adjust clock for daylight savings time" option in the virtual 2003, so that it didn't mess up XP's own auto set. I then dcpromo my virtual 2003 to my existing domain.

Everything seems to be working right. The virtual machine shows up in the domain computers list, no errors generate, a box prompting me to reboot pops up, and one last look in Active Directory shows the machine in the Domain Controllers OU.

But all is not well. Upon login, the system cannot find my network profile. A temporary generic one is loaded instead. When I try to manually access it by entering the \\server\path location, I get a network path not found error. When I try to load AD, I get the error message "The clocks on the client and server machines are skewed." I have them auto update, no good. I manually hand jam the time into them. They are all within 1 second of each other. Still no good. Then I decide just for the hell of it to click the daylight savings time adjustment box on the virtual machine. The clock instantly jumps forward one hour. Geh. I set *that* one to match the current time. AD is now replicating and all is working correctly. ^_^
Left by Zumdahl on Oct 16, 2006 12:38 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I had the same problem and turned out to be my VMware ESX server was not sychronizing time properly with an internet NTP server. Once I fixed the ESX server, my Windows services in the guest VM's worked fine. My problem specifically was that I had a typo in the NTP server address in ESX and my specified DNS servers were incorrect.
Left by VM User on Mar 01, 2008 8:09 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
Gr8 Blog...it really helped me..!! I had the same situation like 'VM User', the NTP setting was not done on one of the VM Server hosting the guest machine which had these messages... as soon as we started the NTP on the ESX Server..the problem vashined...
Left by Mangesh on May 29, 2008 3:34 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
Hi Friends,

Am still getting the same error on client PC. 1030 1097.
I m having one DC and time is set to current date and time i.e. my local time.
I created new CLient in VMWare which is having XP OS. and the time set on this client b4 joining to DC was the current time.
I joined it and error started coming, actually I am trying to solve the "GPO not getting applied" Problem.
Any suggestions?

Thanks
Left by Wasim on Jul 13, 2008 10:47 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
maybe you should have just listed the fix instead of trying to show off your l33t skillz on how you fixed something
Left by fgdsgd on Sep 05, 2008 2:01 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
Good work, except I would put the solution more to the top of the document, so the user doesn't have to weed through the explanation first, having to find out at the end if it doesn't work for them.
Left by Anthony on Nov 18, 2008 5:31 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I had this problem with a 2k3 server and an XP client the problem as slightly different in that it was located in the date format
win 2K3 date = 07/20/2008
Win XP date = 20/07/2008
both set to the same region in all options, editing the dates to match on the XP box corrected the problem
Left by Cheeba on Jul 21, 2009 5:02 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I had this problem on win2k3 and xp desktops. Turned out that like you I overlooked the obvious, which was that the date setup on the server was AM instead of PM. Cheers!
Left by Makios on Aug 19, 2009 5:18 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
Awesome work! Been a while since I enjoyed troubleshooting, but it was a good read following the diagnostic trail. The time setting was the cluprit for our VM 2003 server too.

Thanks
Left by rob on Nov 25, 2009 2:08 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
dude - hat off. Had a similar issue a few months ago.
Well done!

D
Left by dominic Carmody on Jun 29, 2010 4:48 AM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I fixed the problem installing a new NTP server for the vmware servers
Left by chris on Feb 07, 2011 8:06 PM

# re: ITT: The clocks on the client and server machines are skewed (solved)
Requesting Gravatar...
I wish I had found this earlier!
Left by matthew Ogden on May 26, 2011 6:10 PM

Your comment:
 (will show your gravatar)


Copyright © Robert Kloosterhuis | Powered by: GeeksWithBlogs.net