Robert's Sysadmin Blog

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?

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

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.

• Share This Post:
• 
• 
•