Time.windows.comを使用するように構成されたドメインコントローラーがあります(0x09フラグが設定されています)。私はシステムのクロックが頻繁に速いことに気づきました-10分から45分でさえ変わります。私はいつもシステムの日付/時刻を本来あるべき状態にリセットし続けなければなりません。
"w32tm/query/source"を実行すると、time.windows.comを使用していることがわかり、明らかにMicrosoftが正しくない時間を処理しないと信頼していますが、サーバーのクロックが速いのはなぜですか?
編集:
システムログにいくつかのタイムサービスイベントがあります。
イベントID:142
メッセージ:ローカルクロックが同期されていないため、タイムサービスはタイムソースとしてのアドバタイズを停止しました。
イベントID:139
メッセージ:タイムサービスがタイムソースとしてアドバタイズを開始しました。
これら2つのメッセージは、1時間ごとにペアで表示されます。イベント142は、139が表示されてから14〜16分後に表示されます。
数か月前に戻って、これらのイベントが表示されます。
イベントID:35
メッセージ:タイムサービスは現在、システム時刻をタイムソースのtime.windows.com、0x9(ntp.m | 0x9 | 0.0.0.0:123-> 65.55.21.21:123)と同期しています。
イベントID:37
メッセージ:時間プロバイダーNtpClientは現在、time.windows.com、0x9(ntp.m | 0x9 | 0.0.0.0:123-> 65.55.21.21:123)から有効な時間データを受信しています。
イベントID:47
メッセージ:タイムプロバイダーNtpClient:手動で構成されたピアtime.windows.com、0x9からの8回の接続試行後、有効な応答がありません。このピアはタイムソースとして破棄され、NtpClientはこのDNS名で新しいピアを発見しようとします。エラーは次のとおりです。次の理由で時間サンプルが拒否されました:ピアが同期されていないか、ピアの最後の同期から長すぎます。
これら3つのイベントは、10月に一度だけログに表示されます。
編集:
W32tm/query/status/verboseの出力は次のとおりです。
enter code here
C:\Users\Administrator>w32tm /query /status /verbose
Leap Indicator: 3(last minute has 61 seconds)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1794868s
Root Dispersion: 4.6419912s
ReferenceId: 0x41371515 (source IP: 65.55.21.21)
Last Successful Sync Time: 2011-12-05 23:25:18
Source: time.windows.com,0x9
Poll Interval: 6 (64s)
Phase Offset: 0.0000695s
ClockRate: 0.0156243s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 2 (The computer did not resync because only stale time data was available.)
Time since Last Good Sync Time: 1281.9919104s
私は同じ問題を抱えていて、今朝最後にそれを解決しました。これが私がしたことです:
時間の問題があるサーバーと、ntpを正しく同期している別のメンバーサーバーの両方のレジストリ(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Timeのすべてのハイブとキー)を確認します。
いくつかの不一致を見つけ、必要なキーハイブを作業サーバーから壊れたサーバーにエクスポートしました。次のキーはめちゃくちゃになっています。ここに、作業用ボックスから壊れたキーにエクスポートした適切なキーがあります。これらの値は実際の値とは異なる場合があるため、以下のキーは使用しないでください。
セキュリティハイブが見つからなかったので、これで再作成しました。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Security]
"Security"=hex:01,00,04,80,84,00,00,00,90,00,00,00,00,00,00,00,14,00,00,00,02,\
00,70,00,05,00,00,00,00,00,14,00,fd,01,02,00,01,01,00,00,00,00,00,05,12,00,\
00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,\
00,00,00,14,00,8d,01,02,00,01,01,00,00,00,00,00,05,04,00,00,00,00,00,14,00,\
8d,01,02,00,01,01,00,00,00,00,00,05,06,00,00,00,00,00,14,00,9d,01,02,00,01,\
01,00,00,00,00,00,05,13,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,\
00,00,00,00,00,05,12,00,00,00
NtpServer Hiveにキーが欠落していることに気付きました。これはインポートすることで修正されました:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer]
"DllName"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,00,6f,00,\
74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,77,\
00,33,00,32,00,74,00,69,00,6d,00,65,00,2e,00,64,00,6c,00,6c,00,00,00
"Enabled"=dword:00000000
"InputProvider"=dword:00000000
"AllowNonstandardModeCombinations"=dword:00000001
"EventLogFlags"=dword:00000000
"ChainEntryTimeout"=dword:00000010
"ChainMaxEntries"=dword:00000080
"ChainMaxHostEntries"=dword:00000004
"ChainDisable"=dword:00000000
"ChainLoggingRate"=dword:0000001e
次に、フェーズを減らすために次の既存のキーを修正しました。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"MaxAllowedPhaseOffset"=dword:00000001
"SpecialPollInterval"=dword:00000005
"SpecialInterval"=dword:00000001
レジストリが正しいことを確認したら、管理者としてコマンドラインから次のコマンドを発行します。
w32tm /config /manualpeerlist:"YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM,0x01" /syncfromflags:MANUAL /update
net stop w32time && net start w32time
w32tm /resync /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM /rediscover
数分待ってから同期を確認しました
w32tm /monitor /computers:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
次のようになります。
YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM[IPOFYOUR.NTP.OR.DC:123]:
ICMP: 0ms delay
NTP: +0.0496804s offset from local clock
RefID: YOURNTPSERVER-OR-PDCHERE [IPOFYOUR.NTP.OR.PDC]
Stratum: 3
次にフェーズを確認します。
w32tm /stripchart /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
次のようになります。
10:08:42 d:+00.0000000s o:+00.0139224s [ * ]
10:08:44 d:+00.0000000s o:-00.0015659s [ * ]
10:08:46 d:+00.0000000s o:-00.0014534s [ * ]
10:08:48 d:+00.0000000s o:-00.0013418s [ * ]
10:08:50 d:+00.0000000s o:-00.0012421s [ * ]
お役に立てれば!
これはDCがPDCエミュレーターの役割を果たしていますか? PDCエミュレーターの役割を持つものを外部タイムソースで構成するだけで済みます。他のDCは自動的にPDCと同期します。
タイムサービスの現在のステータスは、w32tm /query /status /verbose
を介して取得できます。ローカルクロックのステータス、最後の同期時の偏差、および精度に関する詳細が表示されます。ログに記録されたイベントによると、ローカルクロックはタイムソースに対して信頼性が低すぎるようです。デフォルトのw32time同期間隔は、いくつかの同期が成功した後1024秒になります。これは約17分で、これはおおよそイベント139と142の時間差です。
これが仮想化システムである場合は、代替のタイマーハードウェアエミュレーションを確認する必要があります。 VMWareは このトピックに関する包括的な論文 を発行しています。これは、さまざまな仮想化製品を使用する場合でも読む価値があります。
これが物理システムの場合は、回避策としてw32timeサービスのMaxPollIntervalを減らすか、PDCエミュレーターの役割をより信頼性の高いクロックを持つ別のマシンに移動することを検討してください。
編集:「古くなった時間データ」の問題は、実際に照会しようとしているタイムサーバーの問題である可能性があります。 NTP構成のデフォルトの「time.windows.com」をパブリックNTPプール( <region>.pool.ntp.org
)のサーバーに置き換えてみてください(net time /setsntp:<servername>
を使用するだけです)