While enjoying the wonderful world of SOX I encountered something strange.
On the PDCE I can, from a client, go to manage computer - connect to another
computer - enter the PDCE name (SILC055) - connect and view the event logs.
However, from the same client, for the other DC (SILC056), I can enter the DC
name and connect, but when I attempt to view the event logs, I get "Access is
denied".
I can log into '56 with the same account I used from the client and am able
to see the event logs locally.
It sounds like maybe some sort of local policy setting but I don't have a
clue where to start looking.
Does anyone have any ideas?
thx,
ka
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-ad/200912/1
Regards,
Pledge Technologies.
--
PledgeTechnologies
------------------------------------------------------------------------
PledgeTechnologies's Profile: http://forums.techarena.in/members/161606.htm
View this thread: http://forums.techarena.in/active-directory/1285121.htm
Browsing works fine. I can type \\silc056\sysvol from the same client and it
pops right up - for some reason it takes a long time to do the same thing
with "\scheduled tasks" though - over a miniute.
any other thoughts?
thx,
keith
PledgeTechnologies wrote:
>First Check if AD Replication is working fine.
>If yes, check if group policies are applying successfully.
>Also check if you are able to access the problem server through networ
>browsing.. i.e. \\servername
>
>Regards,
>Pledge Technologies
>
>--
>PledgeTechnologie
>
>http://forums.techarena.i
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a0fdbd5a61d70@uwe...
No, both the client and the backup dc are within 1 minute of the PDCE. It's
good to know about the kerberos though. I knew the times needed to be close
but I couldnt remember why.
I did discover that the machine I was attempting the eventlog view from is
on a different domain. I still think it should work as the domains trust
eachother and I am in 'domain admins' on both domains. But at least it seems
less likely that there is some sort of security policy issue on the backup DC.
Should I execute a net time /setsntp:<domain> on the backup DC to get it to
sync with the PDC?
Or perhaps I should do net time /setsntp:SILC055 to get it to sync directly
with the PDC without the confusion of resolving the domain to the dc?
Thanks for your help
Keith
Paul Bergson [MVP-DS] wrote:
>Time issue? Is the skew between the two dc's greater than 5 minutes? What
>about between the client and the dc. Anything over 5 minutesd breaks the
>ability for Kerberos to work.
>
>> Hi and Thanks for the response.
>> I don't see any indication of replicaton problems - Application logs are
>[quoted text clipped - 24 lines]
>>>
>>>http://forums.techarena.i
--
Message posted via http://www.winserverkb.com
If you are within a minute on both machines there isn't an issue. I
wouldn't change the other machines time source, both seem to be ok. If you
attempt to log onto the machine from the other domain as a user from that
domain can you access the event log? If so then it sounds like something
isn't setup correctly with your trust and the domain admins groups.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a1097c6171ed8@uwe...
A couple of things.
First, It did work from a different PC on the domain when it didn't work for
mine.
Second, It now magically works from mine too...
Third, I did a check and SILC056(DC) is pointed to SILC055 (PDCE) to get it's
time but for some reason cant sync to it: I get an event ID w32time 24. Can 1
DC not sync from another? That sounds improbable...
thx,
K
Paul Bergson [MVP-DS] wrote:
>Sorry, been on vacation the past couple of weeks.
>
>If you are within a minute on both machines there isn't an issue. I
>wouldn't change the other machines time source, both seem to be ok. If you
>attempt to log onto the machine from the other domain as a user from that
>domain can you access the event log? If so then it sounds like something
>isn't setup correctly with your trust and the domain admins groups.
>
>> Hi Paul,
>>
>[quoted text clipped - 32 lines]
>>>>>
>>>>>http://forums.techarena.i
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-ad/201001/1
Follow this by:
net stop w32time && net start w32time
Client should now be part of the time domain heirarchy
If the dc is already pointing at the PDCe the PDCe should be getting its
time externally (Although this won't cause your problem). You should run
debug logging to track down the error. Also the dc should be getting time
from its domain's PDCe.
Fsmo list
netdom query fsmo
Setup PDCe (Follow this exactly as described)
http://support.microsoft.com/kb/816042
Troubleshooting time on a PDCe
http://technet.microsoft.com/en-us/library/bb727060.aspx
Set debug logging
http://support.microsoft.com/kb/816043/en-us
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a19ff60875f42@uwe...
Thanks for the info.
Netdom verified that silc055 is running all roles.
I went through the kb for configuring time server and checked each reg entry
and all were pretty much in order. The only discrepancies were the values set
for poll interva, max pos, and max neg phase correction.
Of those, poll interval was set to 3601 - which seemed ok, and both min and
max phase correction was set to all f's hex - which seemed a little much.
I didn't change them, or activate logging because the last time I made these
modifications, we had a large number of users who started getting profile
messages at login and many had to have their profiles rebuilt (some can just
reboot and the message clears). We had never had an issue (in the 2 short
months the domain had been up) prior to my mucking about in there.
The other notable point is that, as far as I know, no other clients are
having a problem synchronizing with PDCE (Silc055), just DC Silc056. I know
my PC syncs with '55 as I have changed the time a couple of minutes and it
resets overnight.
Let me know what you think.
Thanks,
Keith
Paul Bergson [MVP-DS] wrote:
>All dc's should be syncing there time from the PDCe. If that isn't the case
>then reset time on the dc in question
>From a command prompt:
> "net time /setsntp: " (Note the blank space prior to the end ")
> Tells the client to delete the current registry settings for time
>
>Follow this by:
> net stop w32time && net start w32time
> Client should now be part of the time domain heirarchy
>
>If the dc is already pointing at the PDCe the PDCe should be getting its
>time externally (Although this won't cause your problem). You should run
>debug logging to track down the error. Also the dc should be getting time
>from its domain's PDCe.
>
>Fsmo list
>netdom query fsmo
>
>Setup PDCe (Follow this exactly as described)
>http://support.microsoft.com/kb/816042
>
>Troubleshooting time on a PDCe
>http://technet.microsoft.com/en-us/library/bb727060.aspx
>
>Set debug logging
>http://support.microsoft.com/kb/816043/en-us
>
>> Hi Paul,
>> I hope you had a Merry Christmas and Happy New Year.
>[quoted text clipped - 28 lines]
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a1ad20121cd41@uwe...
The domains have a 2-way trust, and one of the NT4 groups that I am in, is in
the local administrators group on both of these machines, so I would think
that I should be able to view the logs.
However, unless a symptom of a larger problem, I am not too worried about it.
I would like to pursue the SILC056 time issue tho. Any ideas why I can't get
that rascal to sync with SILC055?
As I mentioned before, clients can sync ok, it's just SILC056 that cant. In
comparing the Silc056 w32time registry entries with a normal client I see the
following differences:
SILC056
client
\parameters\type Nt5DS
AllSync this seems ok
\parameters\NtpServer key doesnt exist
time-a.nist.gov,0x1 is it possible the clients are syncing from an external
source instead of domain? how can I verify the sync source?
\TimeProviders\NtpClient\EventLogFlangs 1
0
\TimeProviders\NtpClient\specialPollTi... blank
time-a.nist.gov,7b128a8
any ideas?
thx,
ka
Paul Bergson [MVP-DS] wrote:
>I'm not sure what else to tell you other than to attempt a connection and if
>denied look in the Event logs for any clues. I would look on both the
>client and the dc that is blocking the connection.
>
>> Hi Paul,
>>
>[quoted text clipped - 62 lines]
Hi KA,
I remember you were having a previous issue with time sync awhile back. I
guess it wasn't resolved?
Paul mentioned a few things to help figure out the time issue. However, you
did state that it all worked prior to you "mucking" around with it. What
exactly did you do?
Also, expect a few minutes time skew. The time service is not set to sync
within seconds. If you see a one or two minute off issue, that is by design.
If you need anything tighter than that for say, banking transactional
logging, or say for something like what the stock market uses (which is
critical), you will need to go with a third party time service that keeps
everything within a second or less of each other.
Take a look at my time blog and how to setup time on each DC. I wouldn't do
it in the registry, or it will complicate matters when trying to support/fix
it. I hope it helps.
Configuring the Windows Time Service for Windows Server
http://msmvps.com/blogs/acefekay/archive/2009/09/18/configuring-the-windows-time-service-for-windows-server.aspx
As for remotely accessing logs or accessing any machine, can you open an MMC
using the RunAs using credentials from the other domain across the trust? If
not, then there is possibly a trust issue.
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.
Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
If you feel this is an urgent issue and require immediate assistance, please
contact Microsoft PSS directly. Please check http://support.microsoft.com
for regional support phone numbers.
The original time issues were 1: the PDCE couldn't sync with an external time
source. and 2: no clients could sync with the domain (PDCE).
Both of those issues were pretty much resolved. The PDCE is syncing with the
external time source, and most clients are syncing with the PDCE. (at least
apparently. I can change the time on a client and it will resync in the
course of a couple of hours - and when I do a net time /querysntp it shows
that a time source isnt set - which would seem to indicate that it is syncing
from the domain)
The only exception I am aware of is the dc, silc056. This of course, suggests
that it has to be something on the DC itself (or perhaps something in the
domain controller policy? - but that was defaulted using dcgpofix).
I executed:
w32tm /config /syncfromflags:domhier /update
w32tm /resync /rediscover /nowait
on SILC056 and got a different eventlog message: EventID 27 from source
W32time, which claimed the signature was unsigned. Hopefully this is a clue
that will point us in the right direction. Any ideas?
I reread you blog but the only thing I saw in reference to DCs was the same
as I executed above.
Thanks for your help
thx,
Keith
Ace Fekay [MVP-DS, MCT] wrote:
>> OK, I realized that the PC I am having trouble from is on a different
>> domain -
>[quoted text clipped - 51 lines]
>>>>>>>>>>>
>>>>>>>>>>>http://forums.techarena.i
Hi Keith,
Maybe the only suggestion I have left, and this is between this thread and
the previous time issue thread, is to possibly demote SILC056, await
replication to verify it's existence has been removed, delete its Site
object, remove its reference in WINS, then wait a few hours, then re-promote
it using the same name. Sometimes you would be surprised this 4 hour
provedure (or less) works wonders. The only reason I am suggesting this, is
because of all the changes with the time registry, the GPO, and any other
things that may have been changed and not possibly set back to default
(possibly overlooked or forgot).
Ace
See this article (Below) pay particular attention to the settings that
prevent it from getting its time from the domain.
http://technet.microsoft.com/en-us/library/bb727060.aspx
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a1c641f1b9152@uwe...
Not sure if he has run the debug logging like I pointed to earlier. That
can really help track an issues like this down.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"Ace Fekay [MVP-DS, MCT]" <ace...@mvps.RemoveThisPart.org> wrote in message
news:OIWecfCk...@TK2MSFTNGP06.phx.gbl...
Oh, I thought he ran the debugging? I must have misread his responses. Maybe
if he posts what he finds, that would be helpful.
ace
Here isa trace from the debug log.
Do you see any clues?
9395 01:40:16.9578616s - ---------- Log File Opened -----------------
149395 01:40:16.9578616s - Entered W32TmServiceMain W2K3SP1
149395 01:40:16.9578616s - CurSpc:15625000ns BaseSpc:15625000ns SyncToCmos:
Yes
149395 01:40:16.9578616s - PerfFreq:2992780000c/s
149395 01:40:16.9578616s - Time zone OK.
149395 01:40:16.9578616s - ReadConfig: Found provider 'NtpClient':
149395 01:40:16.9578616s - ReadConfig: 'Enabled'=0x00000001
149395 01:40:16.9578616s - ReadConfig: 'DllName'='C:\WINDOWS\system32\
w32time.dll'
149395 01:40:16.9578616s - ReadConfig: 'InputProvider'=0x00000001
149395 01:40:16.9578616s - ReadConfig: Found provider 'NtpServer':
149395 01:40:16.9578616s - ReadConfig: 'Enabled'=0x00000001
149395 01:40:16.9578616s - ReadConfig: 'DllName'='C:\WINDOWS\system32\
w32time.dll'
149395 01:40:16.9578616s - ReadConfig: 'InputProvider'=0x00000000
149395 01:40:16.9578616s - ReadConfig (policy): Found provider 'NtpClient':
149395 01:40:16.9578616s - ReadConfig (policy): 'Enabled'=0x00000001
149395 01:40:16.9578616s - ReadConfig: 'PhaseCorrectRate'=0x00000007
149395 01:40:16.9578616s - ReadConfig: 'UpdateInterval'=0x00000064
149395 01:40:16.9578616s - ReadConfig: 'FrequencyCorrectRate'=0x00000004
149395 01:40:16.9578616s - ReadConfig: 'PollAdjustFactor'=0x00000005
149395 01:40:16.9578616s - ReadConfig: 'LargePhaseOffset'=0x02FAF080
149395 01:40:16.9578616s - ReadConfig: 'SpikeWatchPeriod'=0x00000384
149395 01:40:16.9578616s - ReadConfig: 'HoldPeriod'=0x00000005
149395 01:40:16.9578616s - ReadConfig: 'MinPollInterval'=0x00000006
149395 01:40:16.9578616s - ReadConfig: 'MaxPollInterval'=0x0000000A
149395 01:40:16.9578616s - ReadConfig: 'AnnounceFlags'=0x0000000A
149395 01:40:16.9578616s - ReadConfig: 'LocalClockDispersion'=0x0000000A
149395 01:40:16.9578616s - ReadConfig: 'MaxNegPhaseCorrection'=0xFFFFFFFF
149395 01:40:16.9578616s - ReadConfig: 'MaxPosPhaseCorrection'=0xFFFFFFFF
149395 01:40:16.9578616s - ReadConfig: 'EventLogFlags'=0x00000002
149395 01:40:16.9578616s - ReadConfig: 'MaxAllowedPhaseOffset'=0x0000012C
149395 01:40:16.9578616s - ReadConfig: failed. Use default one
'TimeJumpAuditOffset'=0x00007080
149395 01:40:16.9578616s - DomainHierarchy: LSA role change notification.
Redetecting.
149395 01:40:16.9578616s - ClockDisciplineThread: Starting:149395 01:40:16.
9578616s - LI:3 S:0 RDl:0 RDs:0 TSF:0x0
149395 01:40:16.9578616s - Starting Providers.
149395 01:40:16.9578616s - Starting 'NtpClient', dll:'C:\WINDOWS\system32\
w32time.dll'
149395 01:40:16.9578616s - NtpTimeProvOpen("NtpClient") called.
149395 01:40:16.9578616s - sysPrecision=-6, systmeClockResolution=156250
149395 01:40:16.9578616s - NtpProvider: Created 2 sockets (1 listen-only): 10.
10.10.30:123, (127.0.0.1:123)
149395 01:40:16.9578616s - PeerPollingThread: waiting forever
149395 01:40:16.9578616s - ReadConfig:
'AllowNonstandardModeCombinations'=0x00000001
149395 01:40:16.9578616s - ReadConfig: 'CompatibilityFlags'=0x80000000
149395 01:40:16.9578616s - ReadConfig: 'SpecialPollInterval'=0x00000E10
149395 01:40:16.9578616s - ReadConfig: 'ResolvePeerBackoffMinutes'=0x0000000F
149395 01:40:16.9578616s - ReadConfig:
'ResolvePeerBackoffMaxTimes'=0x00000007
149395 01:40:16.9578616s - ReadConfig: 'EventLogFlags'=0x00000000
149395 01:40:16.9578616s - ReadConfig: 'LargeSampleSkew'=0x00000003
149395 01:40:16.9578616s - ReadConfig: 'ManualPeerList'='SILC055.vvv.com'
149395 01:40:16.9578616s - ReadConfig: 'CrossSiteSyncFlags'=0x00000002
149395 01:40:16.9578616s - PeerPollingThread: waiting 0.000s
149395 01:40:16.9578616s - NtpClient started.
149395 01:40:16.9578616s - PeerPollingThread: PeerListUpdated
149395 01:40:16.9578616s - Starting 'NtpServer', dll:'C:\WINDOWS\system32\
w32time.dll'
149395 01:40:16.9578616s - Resolving domain hierarchy
149395 01:40:16.9578616s - NtpTimeProvOpen("NtpServer") called.
149395 01:40:16.9578616s - ReadConfig:
'AllowNonstandardModeCombinations'=0x00000001
149395 01:40:16.9578616s - PeerPollingThread: WaitTimeout
149395 01:40:16.9578616s - Resolving SILC055.VVV.com
149395 01:40:16.9578616s - Created reachability group: (
149395 01:40:16.9578616s - 10.10.10.48:123,
149395 01:40:16.9578616s - )
149395 01:40:16.9578616s - PeerPollingThread: waiting 0.000s
149395 01:40:16.9578616s - PeerPollingThread: WaitTimeout
149395 01:40:16.9578616s - Reachability: Attempting to contact peer SILC055.
VVV.com (ntp.m|0x0|10.10.10.30:123->10.10.10.48:123).
149395 01:40:16.9578616s - Polling peer SILC055.VVV.com (ntp.m|0x0|10.10.10.
30:123->10.10.10.48:123)
149395 01:40:16.9578616s - Sending packet to SILC055.VVV.com (ntp.m|0x0|10.10.
10.30:123->10.10.10.48:123) in Win2K detect mode, stage 1.
149395 01:40:16.9578616s - Peer poll: Max:64.0000000s Cur:00.0000000s
149395 01:40:16.9578616s - PeerPollingThread: waiting 64.000s
149395 01:40:16.9578616s - ListeningThread -- DataAvailEvent set for socket 0
(10.10.10.30:123)
149395 01:40:16.9578616s - ListeningThread -- response heard from 10.10.10.48:
123
149395 01:40:16.9578616s - RPC Caller is NT AUTHORITY\LOCAL SERVICE (S-1-5-19)
149395 01:40:16.9578616s - /-- NTP Packet:
149395 01:40:16.9578616s - | LeapIndicator: 0 - no warning; VersionNumber:
3; Mode: 4 - Server; LiVnMode: 0x1C
149395 01:40:16.9578616s - | Stratum: 2 - secondary reference (syncd by (S)
NTP)
149395 01:40:16.9578616s - | Poll Interval: 15 - out of valid range;
Precision: -6 - 15.625ms per tick
149395 01:40:16.9578616s - | RootDelay: 0x0000.0FFEs - 0.0624695s;
RootDispersion: 0x0000.1697s - 0.0882416s
149395 01:40:16.9578616s - | ReferenceClockIdentifier: 0x81060F1D - source IP:
129.6.15.29
149395 01:40:16.9578616s - | ReferenceTimestamp: 0xCEF644B86D2DB89F149395
01:40:16.9578616s - - 12907730744426478900ns - 149395 00:45:44.4264789s
149395 01:40:16.9578616s - | OriginateTimestamp: 0xCEF65180F5366AF6149395
01:40:16.9578616s - - 12907734016957861600ns - 149395 01:40:16.9578616s
149395 01:40:16.9578616s - | ReceiveTimestamp: 0xCEF65180F935E9C6149395
01:40:16.9578616s - - 12907734016973478900ns - 149395 01:40:16.9734789s
149395 01:40:16.9734866s - | TransmitTimestamp: 0xCEF65180F935E9C6149395
01:40:16.9734866s - - 12907734016973478900ns - 149395 01:40:16.9734789s
149395 01:40:16.9734866s - >-- Non-packet info:
149395 01:40:16.9734866s - | DestinationTimestamp: 149395 01:40:16.9734866s -
0xCEF65180F5366AF6149395 01:40:16.9734866s - - 12907734016957861600ns149395
01:40:16.9734866s - - 149395 01:40:16.9578616s
149395 01:40:16.9734866s - | RoundtripDelay: 000ns (0s)
149395 01:40:16.9734866s - | LocalClockOffset: 15617300ns - 0:00.015617300s
149395 01:40:16.9734866s - \--
149395 01:40:16.9734866s - Peer SILC055.VVV.com (ntp.m|0x0|10.10.10.30:123-
>10.10.10.48:123) is not Win2K. Setting compat flags.
149395 01:40:16.9734866s - Peer poll: Max:64.0000000s Cur:63.9843750s
149395 01:40:16.9734866s - Response from peer SILC055.VVV.com (ntp.m|0x0|10.
10.10.30:123->10.10.10.48:123), ofs: +00.0156173s
149395 01:40:16.9734866s - 5 Age:5 Ofs:+00.0000000s Dly:+00.0000000s RDly:+00.
0000000s Dsp:16.0000000s RDsp:00.0000000s Dst:16.0000000s FDsp:08.0000000s
149395 01:40:16.9734866s - 4 Age:4 Ofs:+00.0000000s Dly:+00.0000000s RDly:+00.
0000000s Dsp:16.0000000s RDsp:00.0000000s Dst:16.0000000s FDsp:12.0000000s
149395 01:40:16.9734866s - 3 Age:3 Ofs:+00.0000000s Dly:+00.0000000s RDly:+00.
0000000s Dsp:16.0000000s RDsp:00.0000000s Dst:16.0000000s FDsp:14.0000000s
149395 01:40:16.9734866s - 2 Age:2 Ofs:+00.0000000s Dly:+00.0000000s RDly:+00.
0000000s Dsp:16.0000000s RDsp:00.0000000s Dst:16.0000000s FDsp:15.0000000s
149395 01:40:16.9734866s - 1 Age:1 Ofs:+00.0000000s Dly:+00.0000000s RDly:+00.
0000000s Dsp:16.0000000s RDsp:00.0000000s Dst:16.0000000s FDsp:15.5000000s
149395 01:40:16.9734866s - 0 Age:0 Ofs:+00.0156173s Dly:+00.0312500s RDly:+00.
0624695s Dsp:00.0312500s RDsp:00.0882416s Dst:00.0468750s FDsp:07.7500000s
149395 01:40:16.9734866s - Reachability: peer SILC055.VVV.com (ntp.m|0x0|10.
10.10.30:123->10.10.10.48:123) is reachable.
149395 01:40:16.9734866s - Query 1 (BACKGROUND): <SITE: Default-First-Site-
Name, DOM: VVV.com, FLAGS: 00026B00>
149395 01:40:16.9734866s - Query 1: \\SILC055.VVV.com found. Score: 12
149395 01:40:16.9734866s - Created reachability group: (
149395 01:40:16.9734866s - 10.10.10.48:123,
149395 01:40:16.9734866s - )
149395 01:40:16.9734866s - PeerPollingThread: waiting 0.000s
149395 01:40:16.9734866s - PeerPollingThread: waiting 0.000s
149395 01:40:16.9734866s - NtpServer started.
149395 01:40:16.9734866s - PeerPollingThread: PeerListUpdated
149395 01:40:16.9734866s - Successfully started 2 providers.
149395 01:40:16.9734866s - Reachability: Attempting to contact peer SILC055.
VVV.com (ntp.d|10.10.10.30:123->10.10.10.48:123).
149395 01:40:16.9734866s - Polling peer SILC055.VVV.com (ntp.d|10.10.10.30:
123->10.10.10.48:123)
149395 01:40:16.9734866s - W32TmServiceMain: waiting i16.000s (64.000s)
149395 01:40:16.9734866s - Sending packet to SILC055.VVV.com (ntp.d|10.10.10.
30:123->10.10.10.48:123) in Win2K detect mode, stage 1.
149395 01:40:16.9734866s - Peer poll: Max:64.0000000s Cur:00.0000000s
149395 01:40:16.9734866s - PeerPollingThread: waiting 63.985s
149395 01:40:16.9734866s - W32TmServiceMain: resync req, irreg already
pending.
149395 01:40:16.9734866s - W32TmServiceMain: waiting i16.000s (64.000s)
149395 01:40:16.9734866s - W32TmServiceMain: waiting i16.000s (64.000s)
149395 01:40:16.9734866s - ListeningThread -- DataAvailEvent set for socket 0
(10.10.10.30:123)
149395 01:40:16.9734866s - ListeningThread -- response heard from 10.10.10.48:
123
149395 01:40:16.9734866s - /-- NTP Packet:
149395 01:40:16.9734866s - | LeapIndicator: 0 - no warning; VersionNumber:
3; Mode: 4 - Server; LiVnMode: 0x1C
149395 01:40:16.9734866s - | Stratum: 2 - secondary reference (syncd by (S)
NTP)
149395 01:40:16.9734866s - | Poll Interval: 15 - out of valid range;
Precision: -6 - 15.625ms per tick
149395 01:40:16.9734866s - | RootDelay: 0x0000.0FFEs - 0.0624695s;
RootDispersion: 0x0000.1697s - 0.0882416s
149395 01:40:16.9734866s - | ReferenceClockIdentifier: 0x81060F1D - source IP:
129.6.15.29
149395 01:40:16.9734866s - | ReferenceTimestamp: 0xCEF644B86D2DB89F149395
01:40:16.9734866s - - 12907730744426478900ns - 149395 00:45:44.4264789s
149395 01:40:16.9734866s - | OriginateTimestamp: 0xCEF65180F9366AF6149395
01:40:16.9734866s - - 12907734016973486600ns - 149395 01:40:16.9734866s
149395 01:40:16.9734866s - | ReceiveTimestamp: 0xCEF65180F935E9C6149395
01:40:16.9734866s - - 12907734016973478900ns - 149395 01:40:16.9734789s
149395 01:40:16.9734866s - | TransmitTimestamp: 0xCEF65180F935E9C6149395
01:40:16.9734866s - - 12907734016973478900ns - 149395 01:40:16.9734789s
149395 01:40:16.9734866s - >-- Non-packet info:
149395 01:40:16.9734866s - | DestinationTimestamp: 149395 01:40:16.9734866s -
0xCEF65180F9366AF6149395 01:40:16.9734866s - - 12907734016973486600ns149395
01:40:16.9734866s - - 149395 01:40:16.9734866s
149395 01:40:16.9734866s - | RoundtripDelay: 000ns (0s)
149395 01:40:16.9734866s - | LocalClockOffset: -7700ns - 0:00.000007700s
149395 01:40:16.9734866s - \--
149395 01:40:16.9734866s - non-auth peer set authenticated packet!
149395 01:40:18.9578616s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE
149395 01:40:32.9734866s - W32TmServiceMain: timeout
149395 01:40:32.9734866s - TimeProvCommand([NtpClient], TPC_GetSamples)
called.
149395 01:40:32.9734866s - NtpClient returned 1 samples.
149395 01:40:32.9734866s - Sample 0 offset:+00.0156173s delay:+00.0937195s
dispersion:07.8696767s
149395 01:40:32.9734866s - Intersection successful with 0 dropped samples.
149395 01:40:32.9734866s - 0: Sample:0 SyncDist:399165364 SelectDisp:0
149395 01:40:32.9734866s - Sample 0 chosen. Select Dispersion:00.0000000s
149395 01:40:32.9734866s - ClockDispln:ClockDispln Update: *STALE*
149395 01:40:32.9734866s - W32TmServiceMain: waiting 64.000s
Paul Bergson [MVP-DS] wrote:
>Ace,
>I don't know if this would help. I suspect that time would still be
>attempting from an external source.
>
>Not sure if he has run the debug logging like I pointed to earlier. That
>can really help track an issues like this down.
>
>>> Hi Ace,
>>>
>[quoted text clipped - 49 lines]
>>
>> Ace
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"Paul Bergson [MVP-DS]" <pbbergs@no_spammsn.com> wrote in message
news:ee1Q5XGk...@TK2MSFTNGP06.phx.gbl...
Compare this machines registry to a working domain hiarchy machine.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"kabbott via WinServerKB.com" <u56473@uwe> wrote in message
news:a1faf061f530b@uwe...
Was this from a workstation? As Paul said, it's pulling time externally and
not from the PDC Emulator.
If so, have you tried this?
w32tm /config /syncfromflags:domhier /update
After that run:
net stop w32time
net start w32time
Ace