Ask the Network & AD Support Team

Windows Time サービスの ID 36 の警告。これって無視しても大丈夫ですか？

jpnetds — Fri, 17 May 2013 11:23:00 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の藤田です。

今回は、Windows Time サービスの警告イベント ID:36 についてご案内します。

=======================================================

[1] ID 36 の警告についての説明

=======================================================

システム
ログに以下のようなイベントが記録されたことはありませんか？

-----

イベントの種類: 警告

イベント
ソース: W32Time

イベント ID: 36

説明:

使用可能なタイムスタンプがタイムサービスプロバイダーによって提供されなかったため、タイムサービスは 86400 秒間、システム時刻を同期していません。タイムサービスは、タイムソースと同期できるようになるまで、ローカルのシステム時刻を更新しません。ローカルシステムがクライアントの時刻サーバーとして機能するように構成されている場合は、タイムソースとしてクライアントにアドバタイズすることを止めます。タイムサービスは継続してタイムソースとの同期を試みます。詳細については、他の W32time イベントのシステムイベントログを確認してください。'w32tm /resync' を実行すると、時刻の同期を即座に強制実施できます。

-----

何か問題が発生しているのか、気になりますよね？

この警告イベントは、主にイベントの記録対象となったクライアントが、同期先の NTP サーバーと最後に同期を行ってから 24 時間、同期が行われなかった際に記録されます。

実は、これだけでは問題が発生しているかどうかの判断ができず、無視してもいい場合とそうではない場合があります。

この記事では、無視しても良いか否か判断する方法をお伝えします。

=======================================================

[2] 時刻同期の間隔について

=======================================================

このイベントを無視しても良いか否かは、時刻同期間隔によって決まります。

時刻同期間隔が 24 時間以上に設定されている場合は、 ID:36 を無視しても問題ありません。

時刻同期間隔が 1 時間などの短い間隔で設定されているにもかかわらず、ID:36 が記録されるのであれば、問題が起きている可能性が高いと判断できます。

時刻同期間隔は以下のレジストリキーの値によって、SpecialPollInterval レジストリ値を時刻同期間隔とするのか、MaxPollInterval と MinPollInterval レジストリ値を時刻同期間隔とするのか、決定します。

時刻同期の方法を指定するレジストリキー

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

レジストリキー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

値の名前：Type

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

時刻同期先を指定するレジストリキー

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

レジストリキー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

値の名前：NtpServer

値のデータ：時刻同期先の IP アドレス,フラグ

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

時刻同期の方法を指定するレジストリキーに「NTP」「AllSync」が指定されている場合は、時刻同期先を指定するレジストリキーの値のデータを参照します。

時刻同期先を指定するレジストリキーの値のデータに設定していただくフラグについて、ご説明させていただきます。

フラグの設定は任意です。設定しなかった場合は、いずれのフラグも設定されていないものとして扱われます。

フラグを設定する場合、下記のパラメータを指定します。

0x1 - SpecialPollInterval レジストリ値を同期間隔として使用して時刻同期を行います。設定されていない場合は、MaxPollInterval と MinPollInterval レジストリ値を同期間隔として使用して時刻同期を行います。

0x2 - UseAsFallbackOnly モードを使用します。優先的に同期を行うよう設定されている NTP サーバーが使用不可の場合に同期を取るサーバーとして設定されます。

0x4 - SymmetricActive モードとして要求を送信します。お互いが同期を取る時刻同期方法となります。

0x8 - Client モードとして要求を送信します。サーバー、クライアント、という区分を行い、クライアントからサーバーに対してのみの、一方通行の時刻同期を行います。

例えば、SpecialPollInterval で指定された時間の同期間隔かつ、Client モードとして動作させたい場合は、0x9 (0x1 + 0x8) を設定していただくなど、組み合わせて設定していただくことも可能です。

なお、ドメイン環境において、時刻同期の方法を指定するレジストリキーに「NT5DS」が設定されている場合は、時刻同期先を指定する NtpServer のレジストリキーの値は無視されます。

そして、MaxPollInterval と MinPollInterval レジストリ値を同期間隔として使用して時刻同期を行います。

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

SpecialPollInterval

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

レジストリキー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

値の名前: SpecialPollInterval

ワークグループ環境の既定値 : 604800

ドメインメンバーの既定値 : 3600

ドメインコントローラーの既定値 : 3600

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

MaxPollInterval

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

レジストリキー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W32Time\Config

値の名前: MaxPollInterval

ワークグループ環境の既定値 : 15

ドメインメンバーの既定値 : 15

ドメインコントローラーの既定値 : 10

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

MinPollInterval

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

レジストリキー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W32Time\Config

値の名前: MinPollInterval

ワークグループ環境の既定値 : 10

ドメインメンバーの既定値 : 10

ドメインコントローラーの既定値 : 6

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

※ MaxPollInterval と MinPollInterval を使用する場合は、実際には 2 のべき乗で時刻同期間隔が計算されます。

**********************************************

ワークグループ環境

**********************************************

既定の状態で、SpecialPollInterval の値を使用して時刻同期を実施した場合、 1 週間に 1 度時刻同期します。

よって、ID:36 が記録された場合、無視しても問題ありません。

既定の状態で、MaxPollInterval と MinPollInterval の値を使用して時刻同期を実施した場合、約 17 分から約 9 時間の範囲内で時刻同期が行われるようになります。

よって通常は ID:36 は記録されません。記録された場合は、何か問題が生じている可能性が高いので、正常に時刻同期が行えているかの確認を行うべき、ということになります。

**********************************************

ドメインメンバー

**********************************************

既定の状態で、SpecialPollInterval の値を使用して時刻同期を実施した場合、1 時間に 1 度時刻同期します。

MaxPollInterval と MinPollInterval の値を使用して時刻同期を実施した場合、約 17 分から約 9 時間の範囲内で時刻同期が行われるようになります。

**********************************************

ドメインコントローラー

**********************************************

既定の状態で、SpecialPollInterval の値を使用して時刻同期を実施した場合、1 時間に 1 度時刻同期します。

MaxPollInterval と MinPollInterval の値を使用して時刻同期を実施した場合、約 1 分から約17 分の範囲内で時刻同期が行われるようになります。

=======================================================

[3] 他に注意すべき点

=======================================================

警告 ID:36 については、上記に記述した内容に加えて、3 つの注意点があります。

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

1.ワークグループ環境のトリガー起動サービス

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

ワークグループ環境にて、SpecialPollInterval の値を時刻同期間隔とする場合、ID:36 が記録されないようにする方法として、SpecialPollInterval の間隔を86400 秒 (1 日) より小さい値に設定する方法があります。

ここで、注意しなければならないのが、トリガー起動サービスです。

ワークグループ環境では既定で時刻同期を行う Windows Time サービスが停止しています。

時刻同期するためにはこのサービスを起動しておく必要があります。

しかし、ワークグループ環境のWindows Server 2008 R2 の既定の設定では、Windows Time サービスを自動的に停止させる設定が有効になっております。

このため、時刻同期の間隔を色々と調整しても、実際には一週間に一度しか時刻同期が行われず、ID 36 の警告が記録されてしまいます。

これに対処するためには、以下のコマンドを実行して Windows Time サービスのトリガー起動サービスを削除し、Windows Time サービスを自動起動に設定する方法があります。

sc triggerinfo w32time delete

トリガー起動サービスについては以下の公開ドキュメントがございます。

あわせてご確認ください。

Windows 7 および Windows Server 2008 R2 のスタンドアロン環境で Windows Time サービスが自動的に起動しない

http://support.microsoft.com/kb/2385818/ja

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

2. KB2493006 の問題

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

Windows Time サービスが起動していて、時刻同期間隔は 24 時間以内であるにも関わらず、ID:36が記録される場合、Windows Time サービスが　UDP123 番ポートを正しくバインドできていないという既知の不具合が発生している可能性が考えられます。

KB2493006 の問題の詳細については、以前の記事「Windows Time サービスを使用した時刻同期に必要なネットワーク通信について」をご確認いただければと存じます。

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

3. NTP サーバーとして動作させる場合

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

NTP サーバーとして動作しているマシンにおいて、ID:36 が記録される場合、上位のNTP サーバーからの時刻を正常に受信できていないと判断して、下位 NTP サーバーに正しい時刻同期情報が配信されない可能性があります。

また、NTP サーバーとして動作させるのであれば、既定の��定ではなく、もう少し短い間隔で上位のNTP サーバーと時刻同期を行うようにした方が、安定した時刻の配信を行う上では望ましいです。

今回は、以上です！！

ファイル共有の仕組み - Server サービスと Workstation サービス -

jpnetds — Wed, 08 May 2013 14:16:00 GMT

こんにちは。Windows プラットフォームサポート担当の進藤です。

「ファイルサーバー上のファイルを開くのに時間がかかるようになった。」

ファイルサーバーを管理されているご担当者様などから、このような問題を解消したいといったお問い合わせをいただくことがあります。

今回はファイルサーバーを利用するにあたり、ファイル共有の仕組みを理解する上で基本となる 2 つのサービスについてお話します。

1. Workstation サービスと Server サービス

Windows におけるファイル共有は「共有リソースへのアクセスを要求するクライアント (ワークステーション)」と「その要求を受け付けて処理を行うサーバー」で構成されており、それぞれ「Workstation
サービス」と「Server サービス」という名前のサービスがその役割を担っています。

次のようにサービスの一覧から各サービスが起動していることを確認することができます。

Workstation サービス

Server サービス

2. ファイル共有に必要なコンポーネント

Workstation サービスと Server サービスは、ネットワークのプロパティに表示されている「Microsoft ネットワーク用クライアント」と「Microsoft ネットワーク用ファイル共有とプリンタ共有」のコンポーネントに含まれており、ファイル共有を利用するには、この 2 つのコンポーネントが必要になります。

3. ファイル共有へアクセスする流れ

では実際に、クライアントからサーバー上の共有フォルダーのリソースにアクセスする場合の処理の流れについてご説明します。

クライアント上では、アプリケーションがファイル共有を利用してリモートのファイルを要求すると、まず、Workstation サービスがその要求を受け付けます。これらの要求は、リダイレクターサブシステム (rdbss.sys) および SMB ミニリダイレクター (mrxsmb.sys) によって処理され、TCP/IP 経由の SMB プロトコルセッションおよび要求に変換されます。Windows Vista からは、SMB 2.0 プロトコルがサポートされており、mrxsmb10.sys ドライバーは従来の SMB トラフィックを処理し、mrxsmb20.sys ドライバーは SMB 2.x以降のトラフィックを処理します。

サーバー上では、SMB 接続が受け付けられて、SMB 要求が NTFS およびローカル記憶域スタックを通じてローカルファイルシステム操作として処理されます。srv.sys ドライバーは従来の SMB トラフィックを処理し、srv2.sys ドライバーは SMB 2.x以降のトラフィックを処理します。srvnet.sys コンポーネントは、両方の SMB プロトコルについてネットワークとファイルサーバー間のインターフェイスを実装しています。

4. LanmanWorkstation と LanmanServer

Workstation サービスと Server サービスという名前は表示名であり、実際にはそれぞれ別の名前が存在します。LanmanWorkstation と LanmanServer です。これらの名前は各サービスのプロパティから確認することができます。レジストリから SMB の設定を変更されたことがある方は、これらの名前に見覚えがある方もいらっしゃるかもしれません。

Workstation サービス は LanmanWorkstation

Server サービス は LanmanServer

5. Server サービスの処理がボトルネックとなっている例

一般的に、ファイル共有へのアクセスに時間がかかる場合、ネットワーク (SNP や SMB)、サーバーのパフォーマンス、サードパーティ製のソフトウエアなど様々な原因が考えられます。その中でも、Server サービスに関するパフォーマンスモニターの値が高い場合、Server サービスの処理がボトルネックとなっていることが疑われます。

具体的には、 Server サービスの負荷状態を確認するためには、パフォーマンスモニターの Server オブジェクトや Server Work Queues オブジェクトを確認します。(もちろん、CPU 負荷やメモリの使用状況など一般的に負荷状況を確認する際のカウンタも確認します)

それぞれのオブジェクトのカウンターの詳細につきましては、パフォーマンスモニターの説明をご参照いただければと思いますが、今回はServer Work Queues オブジェクトの Queue Length 値に着目します。今回はそれぞれの意味についての説明は省略しますが、Queue Length のカウンタには、複数のインスタンスがあり、そのインスタンスで値が4 を超える状態が続くものがある場合、クライアントから要求された処理が滞留しているために、ファイル共有のアクセスに時間が掛っていることを疑います。

Server サービスは、クライアントからファイル共有の要求を受けると、その要求をキューに格納します。このキューに格納された要求を Server サービスの各ワーカースレッドが処理を実施していきますが、それぞれの処理が遅延、あるいは大量の要求を受け付け、処理が追いつかない場合にキューに要求が滞留し、結果としてファイル共有へのアクセスが遅い事象が発生します。処理が遅延する原因としては、ディスクや CPU 処理に時間を要している場合、各処理に介在するフィルタドライバの処理で時間を要している (ウィルス対策ソフトウェアはフィルタドライバを使用するアプリケーションの典型的な例です)
ことが疑われますが、以下のレジストリ値によりServer サービス自体のワーカースレッド数 (MaxThreadsPerQueue) の最大値を増やすことで対策ができる場合もあります。

キー : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
名称 : MaxThreadsPerQueue
種類 : REG_DWORD
値 : Queue 1 個あたりのワーカースレッドの最大値
範囲 : 1 ～ 65535
デフォルト : 以下の値は、レジストリによる設定が行われていない場合の既定値となります。ワークキューは、従来のSMB用とSMB2.x以降用とで独立しており、それぞれに既定値が設定されています。

     Windows Vista / Windows Server 2008
        SMB: 10
        SMB2: 10

    Windows 7 / Windows Server 2008 R2
        SMB:10
        SMB2: 20

    Windows 8 / Windows Server 2012
        SMB:10
        SMB2/3: 20

* レジストリエディタを使用し、MaxThreadsPerQueue のレジストリ値を追加 (値が既に存在する場合は変更) します。
* レジストリの設定後は OS の再起動が必要です。
* ひとまず MaxThreadsPerQueue のレジストリ値に 50 を設定していただき、事象が改善が見られるかどうか確認をお願いいたします。
* 設定を行った場合、SMB/SMB2/SMB3いずれも「同じ値」に設定されます。例えば、Windows Server 2008 R2において、このパラメーターに50を設定した場合には、SMB/SMB2ともに、50のスレッドが使えるようになります。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Spike 状態から抜けられない!?!?

jpnetds — Mon, 15 Apr 2013 00:47:29 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の藤田です。

今回は、Spike 状態についてご案内します。

システムログに ID : 50 が記録された経験はありませんか？

下記のようなイベントですが、内容を確認すると、時刻同期が正常に行えているのか、それとも何か異常が発生しているのか、少し不安になってしまうと思います。

今回は、このイベント ID 50 がどのような場合に記録されるかについて、詳細を説明したいと思います。

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

ログの名前:
System

ソース:
Microsoft-Windows-Time-Service

日付:
2013/04/01 15:33:55

イベント ID:
50

タスクのカテゴリ:
なし

レベル:
警告

キーワード:
クラシック

ユーザー:
N/A

コンピュータ:
NTP2008R2domain.test12.com

説明:

タイムサービスにより 900 秒間で 5000 ミリ秒を超える時間差が検出されました。時間差が発生した原因として、正確度の低いタイムソースと同期した、またはネットワークの状態が最適でなかったことが考えられます。タイムサービスは現在同期されておらず、他のクライアントへの時間の提供、またはシステムクロックの更新を行うことができません。タイムサービスプロバイダから有効なタイムスタンプが受信されると、タイムサービスは自動的に訂正されます。

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

このログは、Windows Time サービスの内部状態が "Spike" の状態から "Unset" の状態に遷移したことを示しています。

では、Spike 状態ってどんな状態？

まずは、w32time の状態遷移についてご説明します。(下記はすべて、既定値における動作です。)

NTP クライアントの内部状態は、"Unset" の初期状態から、正常に時刻サンプルを取得する度に、"Unset"=> "Hold" => "Sync" へと推移します。

・ Unset の状態で 1 回時刻のサンプルを取得すると Hold の状態に移行します。

・ Hold の状態で 5 回、時刻のサンプルを正常に取得できると、Sync の状態に移行します。

時刻サンプルを取得した後、実際にその時刻に同期するかどうかの精査が行われますが、Unset、Hold の状態においては、NTP クライアントと NTP サーバーの時刻差に関わらず時刻同期が行われます。

しかし、W32time サービスの内部状態が "Sync" の時に、5 秒以上ずれた時刻サンプルを NTPサーバーから受信すると、その信頼性の確認のために、SpikeWatchPeriod で設定された一定期間 (15分間) 時刻の更新を行わない"Spike" の状態となります。

w32time は時刻補正を行う毎に下記のように内部状態を遷移させています。

<図>

+→Unset: クライアントと NTP サーバーにどのような時刻差があっても、時刻補正を行う状態です。

| ｜

| ｜（Hold
状態へ遷移します）

| ↓

| Hold: Spike と判定されるか否かにかかわらず、取得した時刻サンプルにあわせて時刻補正を行う状態です。

| ｜

| ｜（既定では 5 回目以上で Sync へ遷移します、Hold の回数は "HoldPeriod" によって設定されています）

| ↓

| Sync: Sync 状態になると、Spike と判断されない場合のみ時刻補正を行います。

| ｜

| ｜（
Spike と判断されると Spike 状態へ遷移します）

| ↓

+←Spike: SpikeWatchPeriod にて設定された時間はローカルと 5 秒以上時刻がずれた時刻サンプルを許容しない状態となります。SpikeWatchPeriodにて設定された時間が経過した後の同期時に、Event 50 を発生させて Unset 状態へ遷移します。

===========================

推移の条件と経過時間について

===========================

1. Unset→Hold

Unset 状態の場合、次の同期時に Hold 状態へ移行します。

この時刻同期処理においては、必ず時刻同期に成功して、Hold に移行します。

2. Hold→Sync

Hold 状態は
"HoldPeriod" の回数、同期が行われてから Sync 状態へ移行します。

この Hold 状態においては、5 秒の時刻のずれを検知した場合でも、時刻同期を行います。

3. Sync→Spike

定義されている時刻差に問題がない場合、この Sync 状態が継続されます。

時刻差が発生し Spike と判断される条件に一致した場合 (5 秒の時刻のずれを検知) に次の同期時に Spike 状態へ移行します。

4.
Spike→Unset

Spike
状態となった場合 "SpikeWatchPeriod" で設定された時間はローカルと 5 秒以上時刻がずれた時刻サンプルを許容しない状態となります。"SpikeWatchPeriod"にて定義された時間が経過した後に次の同期時に Unset 状態へ移行します。

このUnset 状態へ移行した際にイベント ID : 50 を通知し、同期が再開されます。

===========================

Spike と判断される条件

===========================

以下に該当する場合、Windows Time サービスは Spike と判定されます。

・NTP サーバーから受信した時刻とローカルタイムの差分 5000 ms を超える時間差を検出した場合

- 詳細

Windows
Time サービス
NTP サーバーと同期した後、NTP サーバーから受信した時刻とローカルタイムの差分が LargePhaseOffset の値 (既定で 5 秒) 以上の場合には Spike 状態となり、"SpikeWatchPeriod" で設定された時間は、ローカルと 5 秒以上時刻がずれた時刻サンプルを許容しない状態となります。

この場合 Spike 状態のままレジストリ値 SpikeWatchPeriod の時間が経過すると常時時刻同期を行うモードであるUnset 状態に遷移し、再度同期処理を開始します。

"SpikeWatchPeriod" で定義された時間内に Spike 状態からの復帰ができないと、イベントビューア上にイベント ID:50 が記録され、Spike状態から Unset 状態へ遷移したことが通知されます。

===========================

ID 50 のイベントが発生する一般的な要因

===========================

上記のような理由で ID 50 のイベントが記録されますが、このイベントが記録される一般的な要因としては、下記のようなものが挙げられます。

・ハードウエアクロックの異常

・上位
NTP サーバーの異常

・意図的に時刻を変更した直後

・ 3rd パーティ製のアプリケーションによる時刻の変更

・仮想環境におけるホスト OS との時刻同期機能の影響

また、仮想環境においては、ソフトウェア的にクロックのエミュレートを行う必要があるため、物理環境と比べてローカル時刻のずれが発生しやすいとの報告があります。

===========================

KB2638243 の問題

===========================

Spike の発生要因については上述した通りですが、ここで注意すべきことがあります。

Windows Server 2008 以降の OS バージョンで SpecialPollInterval の値を用いて時刻同期の間隔を指定している場合、Spike 状態に移行した後に Unset状態に移行することができず、その後の時刻同期が正常に行えなくなってしまう既知の問題があります。

え！？じゃあ、どうしたらいいの？

実はこの問題、弊社の製品の問題として認識しており、公開ドキュメント (KB2638243) があります。

When SpecialPollInterval is used as
a polling interval, the Windows Time service does not correct the time if the
service gets into Spike state

http://support.microsoft.com/kb/2638243/en-us

*********************************

対処法

*********************************

対処法は 2 つ

[1] SpecialPollInterval の値を時刻同期間隔としないで、MaxPollInterval と MinPollInterval の値を時刻同期間隔とする。

[2] SpecialPollInterval の値を時刻同期間隔としている場合、SpecialPollInterval の値を小さくする。

[1] を選択していただくと、そもそも Spike 状態にならないので、KB2638243 の問題について懸念する必要はなくなります。

[2] を選択していただいた場合、時刻同期間隔を短くしていただくことで、Spike 状態に移行することを防ぐことができます。

マシンそのものの時計がずれやすいケースもありますが、その場合、Windows Time サービスの機能では制御することはできません。

Windows Time サービスから可能な対処策は、SpecialPollInterval の値を変更していただく方法があります。

時刻同期間隔を短くすると、時計のずれによって時刻の乖離が大きくなることを防ぐことができます。

よって、Spike 状態になる確率を下げることが可能となります。

SpecialPollInterval

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProvider\NtpClient

値 : SpecialPollInterval

値のデータ : 43200

＃例として 12 時間に変更してみました。

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

レジストリ変更後、設定を反映させる必要があります。

下記のコマンドを実行するか、Windows Time サービスを再起動することで、設定変更した内容を反映させてください。

w32tm /config /update

KB2638243 の問題について

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

KB2638243 の問題は、下記のすべての条件に合致した場合に発生します。

・ NTP クライアントは、手動で設定した NTP サーバーとの間で時刻同期を行う。

・ NTP クライアントは、SpecialPollInterval で指定された間隔に従い、時刻同期を行う。

・ NTP クライアントと NTP サーバーの間の時刻差が 5 秒
(LargePahseOffset) よりも大きい。

上記の全ての条件に合致した場合、この問題が発生したと推測できます。

これにより、一度 Spike 状態に遷移してしまうと、Unset 状態への復帰が期待通りに行われず、継続的に NTP サーバーとの時刻同期に失敗し続ける問題が発生します。

通常、Spike 状態を検知した場合は、一度 NTP クライアントの内部状態が "Unset" の状態に初期化されます。これにより、次回の時刻同期のタイミングで、NTP サーバーから取得した時刻サンプルを基に必ず時刻合わせが行われることが期待されます。

しかしながら、Windows Server 2008 以降の OS バージョンにおいては、Spike 状態に移行した後の NTP クライアントの内部状態の遷移は、SpecialPollInterval を使用して時刻同期を行う設定であったとしても、MinPollInterval で指定された間隔に従って内部状態の遷移が行われるように動作が変更されております。

この動作変更に伴い、MinPollIntervalで定義された間隔が SpecialPollInterval で定義された間隔よりも非常に小さい場合、次回の時刻同期のタイミングでは既に "Unset" 状態から "Sync" 状態への移行が行われます。この際に、NTP サーバーとの時刻差が 5 秒以上ある場合は、再度 Spike を検知して時刻同期に失敗する結果となります。

公開情報に記載の通り、SpecialPollIntervalを使用しない設定に変更していただくか、MinPollInterval の値を大きい値に変更して、次回の時刻同期が行われるまでの間に "Sync" 状態への移行が行われないようにする必要がございます。

では、実際に対処しましょう！！

SpecialPollInterval を使用して時刻同期を行う場合は、MinPollInterval の設定を変更してください。MinPollIntervalの値は 2 のべき乗です。

MinPollInterval

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

値 : MinPollInterval

現在の値 : a

変更後の値 : f

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

今回は時刻同期間隔(SpecialPollInterval の値) を 12 時間にしているので、MinPollInterval の値は f にしてみました。

2 の 15 乗は 32768 秒で約 9 時間ですので、Unset に移行後、Sync まで状態が遷移する前に次の時刻サンプルを受信することができます。ここでのポイントは SpecialPollInterval で指定した時間内に内部状態が Sync まで遷移しないように、MinPollInterval の間隔を考慮することです。

レジストリ変更後、設定を反映させる必要があります。

下記のコマンドを実行してください。お忘れなく・・・

w32tm /config /update

いかがでしたでしょうか？

実際のお問い合わせでも、イベント ID : 50 が記録された、原因不明だがいきなり時刻同期できなくなったという案件はたくさんあります。

思い当たることあれば、一度、上述の事柄を見直してみましょう。

仮想マシンの通信速度遅延 - VMQ 無効化手順 -

jpnetds — Fri, 12 Apr 2013 10:33:00 GMT

Windows プラットフォームサポート担当の米屋 (よねや) です。

すっかり春の陽気になって参りましたが、皆さんいかがお過ごしでしょうか。

近年では、企業ネットワーク内で仮想化プラットフォームが使用されることも一般的になってきましたが、弊社の提供している Hyper-V もおかげさまで好評で、多数のお客様に採用いただいております。

それに伴って私たち技術サポート部門宛にも、仮想環境上で発生した様々なトラブルに関するお問い合わせが寄せられる頻度が増えてきました。

その中でも最近特に多いのが、仮想マシンと外部のマシンの通信速度が大幅に遅延したり、期待するスループットが出ないというお問い合わせです。

原因は様々ですが、ホストマシンの NIC に設定されている仮想マシンキュー (VMQ: Virtual Machine Queue) の機能を無効化することで大幅に通信速度が上がったり問題の改善が見られたという報告が、多数寄せられております。

VMQ 自体は、Hyper-V の仮想スイッチの機能の一部を NIC にオフロードして、通信のパフォーマンスを向上することを目的とした機能ですが、一部のハードウェアの組み合わせにおいてはこの機能が期待通りに動作せず、逆にパフォーマンスが劣化してしまうことがあるようです。今回はこのVMQ の機能の無効化方法をご案内いたしますので、予期しない通信の遅延にお悩みの方は、是非一度、無効化することで現象に変化が見られるかをお試しいただければと思います。

=================================

VMQ の無効化手順

=================================

1) ホストマシンに管理者権限でログオンし、コマンドプロンプトで ncpa.cpl と入力し、実行します。

2) “ネットワーク接続 “ ウィンドウが表示されますので、対象のアダプターを右クリックし、[プロパティ] を選択します。

3) [構成] をクリックします。

4) [詳細設定] のタブを選択します。

5) [プロパティ] の項目にて [Virtual Machine Queues] の項目を "無効" disabled にします。

※ NIC によっては、[仮想マシンキュー] 、[VMQ] などの項目名になっている場合がございます。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Windows Time サービスを使用した時刻同期に必要なネットワーク通信について

jpnetds — Thu, 28 Mar 2013 11:46:21 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の藤田です。

今回は Windows Time サービスを使用した時刻同期に必要なネットワーク通信についてご説明します。

Windows Time サービスを使用して時刻同期するためには、必ず UDP 123 番ポートを使用します。

通常、Windows Time サービスによる NTP プロトコルの時刻同期には、送信元ポート番号、宛先ポート番号の双方とも、UDP 123 番ポートを使用します。

よって、必ず Windows Time サービスが UDP 123 番ポートをバインドしなければなりません。

バインドできてるか否か確認する方法は以下の通りです。

Windows
Time サービスが起動しているにもかかわらず、あれ？と思ったら、以下のコマンドを実行して、確認してみてください。

netstat -aonb

// 実行結果の例 (こちらは、弊社の検証環境で確認した結果です。あくまでも参考としてご利用いただければと存じます。

//139 はPID を示しています。PID はプロセス起動毎に変更されますのでご留意いただければと存じます。

<IPv4>

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

UDP
0.0.0.0:123 *:* 139

W32Time
[svchost.exe]

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

<IPv6>

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

UDP
[::]:123 *:* 139

W32Time
[svchost.exe]

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

バインドに失敗していた場合、上記のようなログは表示されません。

つまり、上記のログが確認できれば OK です。

では、バインドできなかったときはどうしたらよいのでしょうか？

対処法は主に以下の 3 つです。

1. Windows Time サービスの再起動

2. w32tm /resync /rediscover

3. KB2493006 の適用 (Windows Vista/7/2008/2008R2)

=========================================

1. Windows Time サービスの再起動

=========================================

Windows Time サービスを再起動していただくことで、UDP 123 番ポートをバインドしなおします。

よって、現象が解消する可能性があります。

コマンドを使用して、Windows Time サービスを再起動することもできます。

-サービス再起動コマンド

net stop w32time

net start w32time

=========================================

2. W32tm /resync /rediscover

=========================================

/rediscoverオプションはネットワーク構成を再検出し、ネットワークソース (今回は UDP 123 番ポート) を再発見してから、バインドし、時刻同期させるコマンドです。

つまり、時刻同期先の設定を探してから時刻同期を実行しますので、現象が解消する可能性があります。

=========================================

3. KB2493006 の適用 (Windows Vista/7/2008/2008R2)

=========================================

KB2493006 の問題は、例えば Windows Time サービス起動時にネットワーク通信ができない状態にあるなど、特定の条件下で必ず発生する問題ではありません。

OS の内部動作の非常に小さなタイミングのずれによって発生する不具合であり、どのような状態であっても、Windows Time サービスの起動時に稀に発生し得る現象となります。

KB2493006では、Windows Time サービスによって正しく UDP のポート 123 番がバインドできず、その後時刻同期が行われない現象についてご案内しております。

KB2493006 の問題に合致する際、UDP のポート 123 番が正しくバインドできない原因は、Windows Time サービスの起動時の処理に関連しています。

Windows Server 2008 以降の OS では、Windows Time サービス起動時の動作は以下のようになります。

[1] UDP のポート 123 番ポートがバインドされます (動作①とします)

[2] その後レジストリ設定やネットワーク設定などを読み取ります。

[3] 一度 UDP のポート 123 番を Close します。 (動作②とします)

[4] 改めて UDP のポート 123 番をバインドし直します。 (動作③とします)

通常この動作が問題となることはございませんが、動作②の後、動作③を実施する際に、まだ UDP のポート 123 番の Close 処理が完了していない場合には、動作③が失敗します。

その後 UDP のポート 123 番の Close が完了し、Windows Time サービスは UDP のポート 123 番をバインドしていない状態で稼働することとなり、NTP パケットが送受信できず、時刻同期ができない状態となります。

この修正モジュールを適用していただくと、UDP 123 番ポートのバインドに失敗することは回避できますので、ぜひ、ご検討ください。

- 参考情報

Windows Server 2008 または Windows Server 2008 R2 で W32Time サービスが正常に開始されますが、時間の同期は実行されません。

http://support.microsoft.com/kb/2493006/ja

この問題も、先日の記事にあります、KB2638243 の問題と同じくらいお問い合わせが多い問題です。

Windows Time サービスが起動しているのに、時刻同期できていないときにはこのあたり、確認してみてください。

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

補足

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

ちなみに、以下のようなログが表示された時も、Windows Time サービスは UDP 123 番ポートは正しくバインドできていません。

この場合、Windows Time サービス以外が UDP 123 番をバインドしています。

// 実行結果の例 (こちらは、弊社の検証環境で確認した結果です。あくまでも参考としてご利用いただければと存じ��す。

// 515 はPID を示しています。PID はプロセス起動毎に変更されますのでご留意いただければと存じます。

<IPv4>

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

UDP
0.0.0.0:123 *:* 515

ABC.exe

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

<IPv6>

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

UDP
[::]:123 *:* 515

ABC.exe

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

この場合は、ABC.exe を停止し、Windows Time サービスが UDP 123 番ポートをバインドするようにしていただくほかありません。

SNP (Scalable Networking Pack) 機能に関する最新情報

jpnetds — Tue, 05 Mar 2013 12:25:00 GMT

こんにちは。

今日は、以前公開した下記の Blog 記事についての、最新の OS バージョンの情報をお伝えします。

予期せぬ挙動が!?　新機能 Scalable Networking Pack をご存知ですか?

http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx

Windows 8 / Windows Server 2012 でも SNP の無効化の切り分けが有効な状況についての基本的な考え方については変わりはありません。

ただし、これらの OS バージョンでは、NetDMA の機能がサポートされなくなった他、既定値なども変更されています。

このため、SNP 機能に関する設定値の確認方法、既定値、無効化方法、有効化方法などを改めてご紹介します。

========================================

Receive Side Scaling (RSS)

========================================

RSS 機能の既定値、および設定方法は、Windows Server 2008 R2 と同様です。

設定を行う際は、以下の netsh コマンドにて変更が可能となります。

// 既定値(有効) にします。

netsh int tcp set global rss=default

// 有効にします。

netsh int tcp set global rss=enabled

// 無効にします。

netsh int tcp set global rss=disabled

========================================

TCP Chimney Offload

========================================

TCP Chimney Offload の設定方法は、Windows Server 2008 R2 と同様ですが、既定値は無効 (disabled) に変更されています。

// 既定値(有効) にします。

netsh int tcp set global Chimney=default

// 有効にします。

netsh int tcp set global Chimney=enabled

// 無効にします。

netsh int tcp set global Chimney=disabled

なお、ヘルプコマンド (netsh int tcp set global help) を確認しますと、以下のように既定値は automatic であるとの記載がございますが、実のところ、上記のとおり、既定値は "無効" であり、ヘルプの記載内容の記載が誤りであることが分かりました。

この点については、混乱を招いてしまい皆様にはご迷惑をお掛けして申し訳ございませんが、上記の方法にてご対応いただきたくお願いします。

ヘルプより：

========================================

Network Direct Memory Access (NetDMA)

========================================

Windows Server 2012 より、NetDMA の機能は削除されています。

netsh int tcp show global コマンドを実行いただくと、NetDMA は disabled (無効) と表示されます。

また、netsh int tcp set global NetDMA=enabled を実行した場合、コマンド自体は成功いたしますが、設定値は反映されません。

C:\>netsh int tcp set global netdma=enabled OK

C:\>netsh int tcp show global

アクティブ状態を照会しています...

絶対 step モードで時刻同期させたくない場合の設定方法について

jpnetds — Thu, 28 Feb 2013 12:18:00 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の藤田です。

今回は、絶対 step モードで時刻同期させたくない場合の設定方法についてご案内します。

まずは、前回のおさらいもかねて Slew モードについてちょこっと説明します。

Slew モードで時刻同期するためには以下の 2 つの条件を満たす必要がありましたよね。

条件 1. NTP Client と NTP Server の時刻の差がMaxAllowedPhaseOffset で設定されている時間より小さいこと。

条件 2. AbsoluteValueOfCurrentTimeOffset/PhaseCorrectRate/UpdateInterval < System Clock Rate/2 の不等式が満たされること。

これが満たされないと、Step モードになってしまいます。

データベースのように時刻が重要な意味を持つアプリケーションにおいては、Step モードで時刻同期が行われ、時刻が過去にさかのぼるような状況になると、システムの動作に異常が発生することが懸念されます。

そこで、時刻が遡る時刻同期が発生しないように設定するための設定例を下記にご案内いたします。

上記のように、特に時刻の情報が遡ることによる問題が懸念されるサーバー機等につきましては、下記の設定をご参考に、パラメーターの調整を頂ければと存じます。

必ず Slew モードで時刻を同期させる方法・・・は、残念ながら、ありません。

このため、「これ以上時刻が進んでいた場合は時刻同期の処理を行わないようにする閾値」を指定する、MaxNegPhaseCorrection のレジストリ値を調整することで、時刻が遡る時刻同期を発生させないようにすることが可能です。

【ドメインコントローラーの場合】

ドメインコントローラー上でデータベースが運用されているシナリオは稀ですが、ここではご紹介します。

設定対象のコンピューターがシングルプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300) ※ 既定の値となります

MaxPosPhaseCorrection : 0x0002a300 (172800) ※ 既定の値となります

MaxNegPhaseCorrection : 0x2 (2)

PhaseCorrectRate : 0x7 (7) ※ 既定の値となります

UpdateInterval : 0x64 (100)※ 既定の値となります

****************************************

設定対象のコンピューターがマルチプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300) ※ 既定値となります

MaxPosPhaseCorrection : 0x0002a300 (172800) ※ 既定値となります

MaxNegPhaseCorrection : 0x2 (2)

PhaseCorrectRate : 0x7 (7) ※ 既定値となります

UpdateInterval : 0x64 (100)※ 既定値となります

****************************************

SystemClockRate (シングルプロセッサでは約 10ms 、マルチプロセッサでは約 15ms) は環境によって変動することがあり、必ずしも、NTP クライアントと NTP サーバーの時刻差が 3.5 秒 / 5 秒よりも小さければ Slew モードになるとは限りません。そこである程度の余裕を持たせる意味を含め、MaxNegPhaseCorrection を 2 秒に設定することにより、時刻が指定した時間以上進んでいる場合には、時刻修正を実施しないように設定する例をご案内しております。もちろん、パラメータを微調整することで、この範囲を変更することは可能です。

【メンバーサーバーの場合】

設定対象のコンピューターがシングルプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300) ※ 既定値となります

MaxPosPhaseCorrection : 0xffffffff (4294967295) ※ 既定値となります

MaxNegPhaseCorrection : 0x78 (120)

PhaseCorrectRate : 0x1 (1) ※ 既定値となります

UpdateInterval : 0x7530 (30000)※ 既定値となります

****************************************

設定対象のコンピューターがマルチプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300) ※ 既定値となります

MaxPosPhaseCorrection : 0xffffffff (4294967295) ※ 既定値となります

MaxNegPhaseCorrection : 0xb4 (180)

PhaseCorrectRate : 0x1 (1) ※ 既定値となります

UpdateInterval : 0x7530 (30000)※ 既定値となります

****************************************

SystemClockRate は環境によって変動することがあり、必ずしも、NTP クライアントと NTP サーバーの時刻差が 150 秒 / 225 秒よりも小さければ Slew モードになるとは限りません。そこである程度の余裕を持たせる意味を含め、MaxNegPhaseCorrection を 120 秒 / 180 秒に設定することにより、時刻が��定した時間以上進んでいる場合には、時刻修正を実施しないように設定する例をご案内しております。

【WORKGROUP の場合】

WORKGROUP 環境については、いつも Step モードで時刻同期されると思ったほうが良い状態でしたよね。(前回の記事)

WORKGROUP 環境については、前回の記事の通り、MaxAllowedPhaseOffset の値のデータを変更していただく必要がございます。

例えば、ドメインコントローラーやメンバーサーバーのように 300 に設定変更していただくなど。

そのうえで、MaxNegPhaseCorrection の値を変更していただければと存じます。

既定の状態において関連するレジストリとその値は次の通り。

MaxAllowedPhaseOffset : 1

PhaseCorrectRate : 1

UpdateInterval : 360000

例えば、メンバーサーバーの既定値に変更すると。。。150 秒 / 225 秒以内の時刻のずれであれば、Slew モードで時刻同期するようになります。

MaxAllowedPhaseOffset : 300

PhaseCorrectRate : 1

UpdateInterval : 30000

その後、MaxNegPhaseCorrection の値を変更し、120 秒 / 180 秒以上時刻がずれている場合は、時刻同期を行わないようにします。

設定対象のコンピューターがシングルプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300)

MaxPosPhaseCorrection : 0xffffffff (4294967295)

MaxNegPhaseCorrection : 0x78 (120)

PhaseCorrectRate : 0x1 (1)

UpdateInterval : 0x7530 (30000)

****************************************

設定対象のコンピューターがマルチプロセッサの場合

****************************************

レジストリキー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxAllowedPhaseOffset : 0x12c (300)

MaxPosPhaseCorrection : 0xffffffff (4294967295)

MaxNegPhaseCorrection : 0xb4 (180)

PhaseCorrectRate : 0x1 (1)

UpdateInterval : 0x7530 (30000)

****************************************

しかし、このままでは。。。特に大きな時刻のズレが発生した場合、時刻同期しなくなってしまいます。

そこで、※SpecialPollInterval を設定することで、時刻同期の間隔を調整して、大きな時刻のずれが生じる前に時刻同期の処理を実施するように設定できます。

たとえば、1 時間に一度時刻同期を行わせたい場合は、この値を 3600 にご設定いただくことになります。

どの程度のペースでどのくらいの時刻のずれが生じるかにつきましては、お使いのハードウェアに依存しますので、環境に合わせて SpecialPollInterval の値を決定していただく必要がございます。

【設定方法】

****************************************

SpecialPollInterval の値を有効にするために、時刻同期先を指定するレジストリキーの値のデータを「NTP」を設定してください。

時刻同期先を指定するレジストリキー

-----------

レジストリキー： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

値の名前 : Type

値のデータ : NTP

-----------

SpecialPollInterval の値を使用して時刻同期させる為に、時刻同期先の IP アドレスと、フラグ (0x9) を設定してください。

NTPサーバーを指定するレジストリキー

-----------

レジストリキー： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

値の名前 : NTPServer

値のデータ : NTP サーバーの IP アドレス,0x9

-----------

SpecialPollInterval の値を設定してください。

SpecialPollInterval

-----------

レジストリキー： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

値の名前 : SpecialPollInterval

値のデータ: 時刻のずれが大きくならない範囲で、間隔を指定します。

-----------

※ 特に大きな時刻のズレが発生しない環境におきましては、この SpecialPollInterval による時刻同期間隔の調整は不要です。

※ また、SpecialPollInterval を設定するNTPクライアントが Windows Vista 以降の場合以下文章番号 2638243の問題が発生する可能性もございます。

参照先のNTPサーバーの時刻が時刻が変動しやすい (SpecialPollInterval の間隔内に、5 秒以上のずれが発生する場合) などの場合は、他のパラメーターも調整して、上記の問題を回避する必要があります。

- 該当文書番号: 2638243

When
SpecialPollInterval is used as a polling interval, the Windows Time service does not correct the time if the service gets into Spike state

http://support.microsoft.com/kb/2638243/en-us

この KB に記載の現象や、時刻同期のスパイクの仕組みについては、また次回、ご紹介します！

Windows Time サービス - Slew モードと Step モード -

jpnetds — Fri, 28 Dec 2012 06:19:00 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の藤田です。
今回は、時刻の合わせ方 - Step モードと Slew モード - について、ご紹介したいと思います。

1. おさらい～ step モードと slew モードについて～

既にご存知の方も多いと思いますが、まずは Step モードと Slew モードについて、おさらいしたいと思います。

===============
Slew モードの時刻の合わせ方
===============
データベースのトランザクション管理などに影響を与えないために、NTP サーバーと NTP クライアントの時刻差を徐々に縮めることによって、時刻が戻ることを防ぎながら時刻を修正します。
具体的には、NTP クライアントの方が時刻が遅れている場合には、例として、実際には 0.9 秒しか経っていないにもかかわらず、1 秒時刻を進めることにより、NTP サーバーと NTP クライアントの時刻差を徐々に縮めます。
逆に、NTP クライアントの方が時刻が進んでいる場合には、例として、実際には 1.1 秒経っているにもかかわらず、1 秒だけ時刻を進めることにより、NTP サーバーと NTP クライアントの時刻差を徐々に縮めます。

===============
Step モードの時刻の合わせ方
===============
Slew モードのように徐々に時間差を縮めるのではなく、目標の時刻に瞬時に変更します。
NTP サーバーよりも NTP クライアントの方が時刻が進んでいる場合、NTP クライアントの時刻は過去に戻ります。

2. どちらのモードが使用されるか？

では、本題にはいります。
Slew モードと Step モード、どのようにして、どちらの合わせ方が適用されるのか、ご存じでしょうか ?

Slew モードで時刻同期をする一般的な条件は下記の通りです。

次の 2 つの条件をすべて満たす場合、Slew モードで時刻同期を実施することができます。
逆に、2 つの条件のいずれかを満たしていない場合は、Step モードで時刻同期を実施します。

条件 1.
AbsoluteValueOfCurrentTimeOffset < MaxAllowedPhaseOffset の不等式が満たされること。

条件 2.
AbsoluteValueOfCurrentTimeOffset/PhaseCorrectRate/UpdateInterval < System Clock Rate/2 の不等式が満たされること。

上記の条件式のそれぞれの値の意味を、下記にご説明します。

■ AbsoluteValueOfCurrentTimeOffset
この値は、NTP Client が NTP Server に対して Polling した際の NTP Client と NTP Server の時刻の差です。

■ MaxAllowedPhaseOffset
NTP Server から受信した時刻と NTP Client の時刻差が何秒までであれば、Slew モードで時刻同期を行うことが許容されるかの設定値です。
上記の条件 1 の判定に置いて使用されます。この値は、下記のレジストリで設定されています。

レジストリキー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
値の名前: MaxAllowedPhaseOffset

■ PhaseCorrectRate、UpdateInterval
NTP Server から受け取った時刻サンプルをもとに、どのくらいの間隔で、どのくらいの速度で時刻をあわせていくかの傾きを示す設定値です。
これらの値は、下記のレジストリで設定されています。

レジストリキー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
値の名前: PhaseCorrectRate
値の名前: UpdateInterval

■ System Clock Rate
システムのクロックレートを表す値です。通常であれば、シングルプロセッサーでは約 10ms、マルチプロセッサーでは約 15 ms となります。

3. サーバーの役割による違い

上述の通り、Slew モードと Step モードのいずれが使用されるかは、NTP Client と NTP Server の時刻差によって、動的に決定されます。
また、ドメインコントローラーか、ドメインのメンバーサーバーか、ワークグループ環境かによって、上記の条件式で使用される各パラメーターの既定値が異なるため、Slew モードで時刻同期できる「NTP Server との時刻のずれ」の値も異なります。

今回は、Windows Server 2008 R2 を題材にして、実際に既定の構成では、どれくらいの時刻差であれば Slew モードになるのかを確認してみます。

【ドメインコントローラーの場合】
既定の状態において関連するレジストリとその値は次の通りとなっております。
MaxAllowedPhaseOffset : 300
PhaseCorrectRate : 7
UpdateInterval : 100

実際に条件式にあてはめて、計算してみましょう。

条件 1.
AbsoluteValueOfCurrentTimeOffset < 300 秒

条件 2.
- マルチプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 7 ÷ 100 < 0.015 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 5.25 秒

- シングルプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 7 ÷ 100 < 0.010 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 3.5 秒

つまり、NTP Server との時刻差が 5.25 秒未満、もしくは 3.5 秒未満の場合は、Slew モードで時刻同期が行われる結果となります。

【ドメインメンバーサーバーの場合】
既定の状態において関連するレジストリとその値は次の通りとなっております。
MaxAllowedPhaseOffset : 300
PhaseCorrectRate : 1
UpdateInterval : 30000

実際に条件に合うかどうか、計算してみましょう。

条件 1.
AbsoluteValueOfCurrentTimeOffset < 300 秒

条件 2.
- マルチプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 1 ÷ 30000 < 0.015 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 225 秒

- シングルプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 1 ÷ 30000 < 0.010 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 150 秒

つまり、NTP Server との時刻差が 225 秒未満、もしくは 150 秒未満の場合は、Slew モードで時刻同期が行われる結果となります。

【ワークグループの場合】
既定の状態において関連するレジストリとその値は次の通りとなっております。
MaxAllowedPhaseOffset : 1
PhaseCorrectRate : 1
UpdateInterval : 360000

条件 1.
AbsoluteValueOfCurrentTimeOffset < 1 秒

条件 2.
- マルチプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 1 ÷ 360000 < 0.015 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 2700 秒

- シングルプロセッサーの場合
AbsoluteValueOfCurrentTimeOffset ÷ 1 ÷ 360000 < 0.010 ÷ 2
AbsoluteValueOfCurrentTimeOffset < 1800 秒

つまり、NTP Server との時刻差が 1 秒未満の場合は、Slew モードで時刻同期が行われる結果となります。
えっ！？！？ 1 秒？？？
そうです、既定の状態ではワークグループ環境の場合は、NTP Client と NTP Server の時刻の差が 1秒以内でなければ、Slew モードで時刻同期することができません。。。

既定の状態だとStep モードになると考えたほうが良いですね。
では、どうしたら Slew モードで時刻同期することができるようになるのでしょうか ?

ワークグループ環境では条件 1 の方が強く働いて、Step モードが採用される結果となっています。このため、MaxAllowedPhaseOffset の値のデータを変更していただく必要がございます。
例えば、ドメインコントローラーやメンバーサーバーのように 300 に設定変更していただくと、300 秒までの時刻差の場合は、Slew モードで時刻同期を行うように動作が変更されます。
パラメーターの調整を行いたい場合は、上述の各レジストリの値を変えて、Slew モードで時刻同期をする条件に当てはめ、任意の値をご設定いただくことができます。

しかし・・・NTP Server との時刻差がいつも同じくらいの間に収まっているとは限りません。NTP Server との時刻差がどのような値になったとしても、確実に Step モードで時刻同期させないための設定はどうしたらよいのでしょうか？？

その方法は次回、ご紹介いたします！！

<今回の参考情報>
Windows Time サービスにおける時刻同期の仕組み
http://support.microsoft.com/kb/2722681/ja

ルート証明書更新プログラムのパッケージ (KB 931125) がWSUSで公開されました

jpnetds — Thu, 12 Apr 2012 04:23:23 GMT

みなさん、こんにちは Windows Active Directory & Network 担当村木ゆりかです。

つい先月、ルート証明書の更新プログラムが Windows Vista および Windows 7 を対象に配布開始となりました。
Microsoft Update カタログを KB 番号 "931125" で検索すると、詳細を確認することができます。

http://catalog.update.microsoft.com/v7/site/Search.aspx?q=931125

従来、ルート証明書の更新プログラムは Windows XP のみを対象として配布されていました。
Windows Vista 以降では定期的にルート証明書を Windows Update サイトより更新する仕組みが実装されたため、更新プログラムとしては配布対象ではありませんでした。

このため、オフライン環境の Windows Vista / Windows 7 クライアントは Windows Update サイトに接続できず、ルート証明書を更新することが出来ませんでした。

今回、Windows Vista / Winodws 7も配布対象となったことにより、オフライン環境に対してもルート証明書の更新プログラムを配布することができるようになりました。
WSUS より配布を行いたい場合には "更新" のクラスを同期対象に含めるか、または Microsoft Update カタログサイトを WSUS サーバー上で開き、個別にインポートしてください。

なお、現時点では、32 ビットOS 対象、クライアントOS対象のものだけ公開されておりますが、64 ビットOS対象、サーバOS対象も、今後リリースされる予定です。

ルート証明書の更新プログラムについては、下記のブログ記事もご参照ください。

Windows PKI - その2 - ルート証明書更新プログラムとは？
http://blogs.technet.com/b/jpntsblog/archive/2009/12/24/windows-pki-2.aspx

エラーイベント MRxSmb、ID:8003 が頻繁に発生する

jpnetds — Thu, 25 Aug 2011 09:40:00 GMT

みなさま、こんにちは。Network & Active Directory チームの丸山です。

今日は、最近お客様からのお問い合わせが増えてきております、コンピューターブラウジングのエラーイベント MRxSmb、ID:8003 について、ご案内をしたいと思います。

1. コンピューターブラウジングについて

===========================================================

まず、コンピューターブラウジングに関しまして、簡単にご紹介します。

Computer Browser サービスでは、ファイルやプリンターを公開する Server サービスを開始している同じネットワーク上に存在するコンピューターを一覧表示します。

上記が示すコンピューターの一覧は「ブラウズリスト（browse list）」と呼ばれ、[マイネットワーク] 、または NET VIEW コマンドの実行で確認することができます。

ブラウズリストは、ネットワーク上の「ブラウザー」と呼ばれるコンピューターが管理しています。

ブラウザーでは、例えばどれか 1 台のブラウザーがダウンしても他のブラウザーが代わって機能し、同じネットワーク全体で最低でも 1 台以上のコンピューターがブラウザーとして機能するようになっています。

ブラウザーの中で、アクティブなものを「マスターブラウザー」と呼び、これがブラウズリストを代表して管理しています。マスターブラウザーは同じネットワーク内の存在するコンピューターの中から自動的に選定され、同じネットワーク上のコンピューターの情報をホストしています。

また、その他のブラウザーは「バックアップブラウザー」といい、マスターブラウザーがダウンした場合に代わってマスターブラウザーとなります。

2. MRxSmb、ID:8003 について

===========================================================

本イベントは、何らかの原因からマスターブラウザーとして動作していたブラウザーがダウンし、バックアップブラウザーが代わってマスターブラウザーとして機能し、元々マスターブラウザーとして動作していたブラウザーが再度マスターブラウザーに昇格しようとした際に発生いたします。

イベント記録例

本イベントの内容は、上述のように、マスターブラウザーの競合によって発生するイベントであり、マスターブラウザーとして動作しているサーバーが、他のコンピューターから自分がマスターブラウザーとして動作しているということを示すアナウンスを受け取った時に記録されます。

3. エラーイベント MRxSmb、ID:8003 が記録される事での影響

===========================================================

本イベントは、コンピューターブラウジングに関して、マスターブラウザーの選定に関する環境が不安定な状況にあることを示します。結果として、マイネットワークの参照に影響を与える可能性はありますが、それ以外について、サーバーに影響を与えるものではございません。また、マイネットワークの参照をおこなうような環境でも、その参照に問題が発生していない場合には、無視していただいても差し支えございません。

4. エラーイベント MRxSmb、ID:8003 が記録される原因および対策

===========================================================

エラーの原因につきましては、一般的には以下の 4 つの原因が考えられます。それぞれで対応策が異なりますので、ご確認、ご実施をいただきまして、現象が回避するか否かお確かめください。

A) マスターブラウザーのネットワーク環境が不安定な場合

マスターブラウザーのネットワークケーブルが何らかの要因にて一時的に切断し、新しいマスターブラウザーの選定が行われ、再度ネットワークへ戻された場合などに、本イベントが発生する場合がございます。

また、マスターブラウザーのネットワークが一時的なダウンを繰り返していると、この間に別のコンピューターがマスターブラウザーとなるため、元のマスターブラウザーのネットワーク回復時に本イベントが発生する場合がございます。

--対応策

このような場合には一時的にイベントは発生しますが、マスターブラウザーの選定の結果、優先度の高いコンピューターがマスターブラウザーになりますので、特に対処する必要はありません。

B) サブネットマスクが不正である場合

クライアントコンピューターのサブネットマスクが正しく設定されていない、あるいは他サーバーのサブネットと異なっている場合に、本イベントが発生する場合がございます。

--対応策

イベントログに記載されているコンピューター (サーバーアナウンスを送信しているコンピューター) の TCP/IP プロトコルの設定をご確認いただき、正しいサブネットマスクに設定し直す必要がございます。

=参考資料=

不正なサブネットマスクでイベント ID : 8003 8009 8019 が表示

http://support.microsoft.com/kb/143153/ja

C) ルーターが UDP ポート 137 および 138 をフォワードしている場合

ネットワーク上のルーターが UDP ポートの 137 および 138 をフォワードするような設定になっていると、他のマスターブラウザーからサーバーアナウンスを受信してしまい、本イベントが記録される可能性がございます。

--対応策

UDP ポート 137、138 のフォワードを止めることで回避します。

=参考資料=

UDP 転送によって 8003 参照エラーが発生する

http://support.microsoft.com/kb/135464/ja

D) マルチホーム環境の場合

ネットワークアダプターカードを複数利用するマルチホーム環境の場合、"Computer Browser" サービスが使用しているアダプターの切り替わりのタイミングなどに、本イベントが記録される場合がございます。

--対応策

イベントの記録元となっているコンピューターにて、"Computer Browser" サービスを [停止/無効] とする方法が有効でございます。

上記の内容が、本イベントのトラブルシューティングとして、お読みいただきました皆様のお役にたてれば幸いでございます。

万が一、上記の設定でも問題が解決できない場合は、弊社のサポート窓口へのお問い合わせをご検討くださいますよう、お願い申し上げます。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Ask the Network & AD Support Team

Windows Time サービスの ID 36 の警告。これって無視しても大丈夫ですか？

ファイル共有の仕組み - Server サービスと Workstation サービス -

Spike 状態から抜けられない!?!?

仮想マシンの通信速度遅延 - VMQ 無効化手順 -

Windows Time サービスを使用した 時刻同期に必要なネットワーク通信について

SNP (Scalable Networking Pack) 機能に関する最新情報

絶対 step モードで時刻同期させたくない場合の設定方法について

Windows Time サービス - Slew モードと Step モード -

ルート証明書更新プログラムのパッケージ (KB 931125) がWSUSで公開されました

エラーイベント MRxSmb、ID:8003 が頻繁に発生する

Windows Time サービスを使用した時刻同期に必要なネットワーク通信について