w32tm /monitor を実行すると、ドメイン（または指定したコンピューター）の時刻同期状態が一覧表示されます。しかし「この一覧は、どこに保存された情報（DB・レジストリ・AD属性など）を参照しているのか？」が見えづらく、調査が止まりがちです。ここでは /monitor の内部動作を“台帳探し”ではなく“問い合わせ系ツール”として整理し、現場で迷わない切り分け手順までまとめます。
w32tm /monitorとは：何をして、何をしていないのか
w32tm は Windows Time Service（W32Time）の設定・監視・トラブルシュートに使うコマンドで、/monitor はその名の通り「W32Time を監視する」ための機能です。/monitor のポイントは、“保存済みの一覧”を表示するというより、実行時点で対象を見つけて問い合わせ、その結果を整形して出しているところにあります。
そのため、次のような現象が起きても不思議ではありません。
- 同じコマンドでも、実行のたびに出力に出たり出なかったりする（対象が一時的に応答できない、ネットワーク経路が不安定など）
- 「どこかに一覧が保存されているはず」と探しても、決定的な“台帳”が見つからない
- 表示される情報の一部は “相手側の状態” であり、実行した側の設定だけでは説明できない
結論：/monitor は「固定の台帳」より「その場の問い合わせ結果」を表示する性格が強い
「w32tm /monitor はどこから情報を取っているのか？」という問いに対して、実務上のいちばん役に立つ答えは次です。
/monitor は、AD の特定属性やレジストリにある“一覧表”を読むというより、ドメイン（または指定先）を対象に、実行時点で動的に問い合わせた結果を表示する。たとえば DC が停止中・再起動中・一時的に応答不能のタイミングだと、その回の /monitor には出てこない可能性があります。
この前提を置くと、「参照元（DB/AD/レジストリ）を特定したい」という悩みは、次の2つに分解できます。
| 分解すると何を見ればよいか | あなたが気にしている疑問 | /monitor の実体 |
|---|---|---|
| 監視対象の列挙 | 一覧に載るサーバーはどこから来る？ | ドメイン内の候補を“発見”している（固定リストではない） |
| 監視情報の取得 | オフセットや Source はどこから来る？ | 対象サーバーへ問い合わせて得た応答を表示している |
| 参照先（同期元）の決定 | そもそも誰が誰から同期する？どこに設定がある？ | これは /monitor の“元ネタ”ではなく、W32Time の仕組み（設定＋ロジック） |
監視対象の「一覧」はどこから来る？：/domain 指定時の列挙の正体
/monitor の指定オプションから見える“性格”
/monitor は、監視対象を /domain と /computers のどちらでも与えられます。/computers は明示的な固定リストで、/domain は「ドメインを監視する」という“発見型”です。加えて /threads で並列数を指定できます。
さらに地味に重要なのが、/computers の名前に アスタリスク（*） を付けると、そのコンピューターを PDC として扱う、という仕様です（出力や扱い方に影響します）。この挙動は「PDC を意識した監視をしたい」という用途を想定したものです。
w32tm /monitor /domain:example.local
w32tm /monitor /computers:DC01,DC02,*DC03 /threads:10“AD の RootDSE/Schema を見て一覧化”ではなく、DC を見つける仕組みに乗っている
/domain で「ドメインを監視」する場合、実装としては「そのドメインの DC をどう見つけるか」が核心になります。Windows で“ドメインの DC を見つける”といえば、一般に DC Locator（Netlogon サービス／DsGetDcName など）の仕組みを使います。DC Locator は DNS に登録された SRV レコードを使った発見（DNS-based discovery）を基本に、必要に応じて UDP ベースの LDAP ping で可用性を確認し、結果をキャッシュします。
つまり、/monitor の「対象候補」は、次のような要素の影響を強く受けます。
- DNS の SRV レコード（_msdcs 配下など）に DC が正しく登録されているか
- サイト/サブネット設計により「近い DC」として選ばれやすいか（AD サイト情報も関与）
- Netlogon のキャッシュ状況（直近に見つけた DC の情報を保持する動き）
- 実行時点での疎通（応答がない DC は“候補にいても”落ちることがある）
この観点で見ると、「/monitor の一覧が毎回同じでない」ことは、むしろ自然な挙動です。“台帳”というより“探索＋疎通確認”に近いからです。
AD に“参照元メタデータ”はある？：あるが、/monitor のための専用台帳ではない
質問で挙がりやすい「Configuration / RootDSE / Schema に参照元があるのか？」について、整理して言うと次の通りです。
- 時刻同期の“状態”（オフセット、遅延など）は、AD に保管された値ではなく、問い合わせの結果として得られるもの。
- DC を見つけるための材料（DNS SRV、サイト/サブネットなど）は AD/DNS に存在し、Windows の DC 発見ロジックに影響する。
- 時刻同期の“設定”（NTP サーバー指定や NT5DS など）は、基本は各マシンの W32Time 設定（レジストリ／ポリシー）であり、AD の単一属性にまとまって置かれているわけではない。
「AD に何があるか」を DC 発見という観点で具体化すると、DNS マネージャー上では SRV レコードが _msdcs 配下などに作成されます。また Microsoft 以外の DNS を使う場合は、DC 側に %systemroot%\System32\Config\Netlogon.dns というファイルがあり、そこに登録内容が書き出されます。
表示される情報はどこから来る？：対象サーバーへの問い合わせ（ネットワーク観点）
W32Time の同期は UDP 123 が前提
W32Time は NTP 仕様に基づき、時刻同期の通信に UDP 123 を使います。ドメイン内で「同期できる／できない」「/monitor が取れる／取れない」は、最終的に UDP 123 の到達性に左右されます。
/monitor の出力は、あなたの PC（実行ホスト）から見た「各対象との時刻差・遅延」なので、次の点に注意が必要です。
- 実行ホストの時刻が狂っていると、全体の見え方もずれます。（相対比較の物差しが狂う）
- “Source” は相手が参照している同期元を示すことが多く、実行ホストの設定ではなく相手側の状態です。
- ネットワーク遅延が大きい環境では、オフセットが揺れやすくなります。
“一覧の情報”が保存されているように見える理由
/monitor は一見すると「ドメイン内の時刻サーバー一覧を表示している」ように見えますが、実際には次の2つを同時にやっています。
- 対象候補を見つける（DC を発見する、または指定リストを使う）
- その対象へ問い合わせて、時刻同期の状態を取ってくる
この2段構えのため、「どこかに一覧があるはず」という感覚になりやすいのですが、固定台帳に依存していない以上、毎回同じ出力になる保証はありません。
「参照先（同期元）」はどこに設定され、どう決まる？：W32Time の根本ロジック
ドメイン参加の基本：NT5DS（ドメイン階層同期）がデフォルト
ドメイン参加コンピューターの多くは、時刻同期タイプが NT5DS（ドメイン階層）になり、ドメイン階層に従って DC から時刻をもらいます。例外として、フォレスト ルート ドメインの PDC エミュレーターが外部時刻ソースと同期するように構成される、というのが王道の設計です。
ここが重要で、/monitor は「この階層ロジックそのもの」を決めているわけではありません。/monitor は“監視結果”を出すだけで、参照先の決定は W32Time の仕組み（役割・設定・ポリシー）です。
手動 NTP（MANUAL）や GPO は「各マシンの設定」
「どの NTP サーバーを参照するか」は、基本的に各マシンの W32Time 設定（ポリシー／レジストリ）で決まります。実務で見るべき代表例は次の系統です。
- 同期タイプ（例：NT5DS / NTP / ALL など）
- 手動 NTP を使う場合の NTP サーバー一覧（manual peer list）
- NTP クライアント/サーバー機能の有効・無効
- ポーリング間隔などの運用パラメータ
設定の確認は、まずはコマンドで十分です。特に w32tm /query /configuration は「実行時設定」と「それがどこから来ているか（ポリシーかローカルか）」まで追えるので、参照先を追跡するときの起点になります。
現場で迷わない：/monitor の“分からなさ”を潰す調査フロー
まずは監視対象を固定して、ブレ要因を消す
「/monitor の一覧がどこから来るか」を追う前に、いったん/computers で対象を固定して、出力の変動要因（探索・列挙）を切り離すのが近道です。
rem 対象を固定して監視（並列数も増やす）
w32tm /monitor /computers:DC01,DC02,DC03 /threads:10これで出力が安定しない場合は、原因は「列挙」ではなく「問い合わせ（疎通・応答・サービス状態）」側に寄ります。
/monitor の出力と突き合わせる“正攻法コマンド”
| 目的 | コマンド | 見るポイント | なぜ有効か |
|---|---|---|---|
| 相手が誰から同期しているか | w32tm /query /status | Source / 最終同期時刻 / Stratum など | /monitor の “Source” を裏取りできる |
| 設定値とその由来（GPOかローカルか） | w32tm /query /configuration | (Policy) 表示、NtpServer、Type など | 参照先の“決定要因”を追える |
| 相手との時刻差を連続観測 | w32tm /stripchart /computer:DC01 /dataonly /samples:10 | 揺れ幅、傾向 | 瞬間値ではなく傾向で判断できる |
| レジストリ値を素早く確認 | w32tm /dumpreg /subkey:Parameters | Type / NtpServer など | コマンドだけで“設定”に迫れる |
| 再同期のトリガー | w32tm /resync /rediscover | エラー有無、イベントログ | “今どうなるか”を観測しやすい |
“列挙側”を疑うときに見るポイント：DNS SRV と DC Locator
/monitor の対象が「ドメインのはずなのに DC が出てこない」「台数が合わない」という場合、列挙側（発見側）を疑います。ここで効くのが DNS SRV の確認です。
rem DC を見つける代表的な SRV（例）
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.localSRV レコードは、DNS マネージャーの _msdcs 配下（例：.../_msdcs/dc/_tcp）に作成され、_ldap や _kerberos などが登録されるのが基本です。DC 発見は DNS SRV を使うのが推奨され、クライアントは SRV を引いた後に UDP ベースの LDAP ping で可用性確認を行い、結果をキャッシュする流れになります。
よくある実務パターンとして、次のどれかが混ざると “/monitor の一覧が謎” になります。
- DNS の SRV 登録が壊れている／遅延している（新設 DC が見つからない）
- サイト/サブネット設計により、遠隔サイトの DC が候補に出にくい／逆に出やすい
- 実行ホストから特定 DC への経路だけ不安定（その DC だけ欠ける）
“問い合わせ側”を疑うときに見るポイント：UDP 123 とサービス状態
列挙はできているのに結果が取れない場合は、問い合わせ側（時刻問い合わせの到達性）です。W32Time の同期通信は UDP 123 が前提なので、ファイアウォールやセキュリティ製品、NW 機器で UDP 123 が落ちていないかを確認します。
| 症状 | ありがちな原因 | 確認ポイント | 次の一手 |
|---|---|---|---|
| /monitor で一部の DC だけ出ない | その DC が停止・再起動中、疎通不良 | 同一タイミングで ping/名前解決/ポート疎通 | /computers で固定して再現性を確認 |
| 出力はあるがオフセットが極端に大きい | 参照先が不適切、時刻の段差、VM 時刻同期の干渉 | 各 DC の /query /status の Source | PDC の外部 NTP 設定と他 DC の NT5DS を点検 |
| “Source” が期待と違う | 相手側が手動 NTP に固定、GPO 未適用 | /query /configuration の (Policy) 表示 | GPO/レジストリ/サービス再起動で整合 |
| 全体に揺れが大きい | ネットワーク遅延、WAN 越え監視 | /stripchart で傾向を見る | 監視地点（実行ホスト）をサイト内に置く |
ログで“問い合わせと応答”を追う：イベントログとプライベートログ
「内部動作が知りたい」「どこで失敗しているか確実に掴みたい」という場合、ログは強力です。W32Time は System のイベントログ（Time-Service 系）に加えて、w32tm でプライベートログ（デバッグログ）を有効化できます。
rem プライベートログを有効化（例）
w32tm /debug /enable /file:C:\Temp\w32time.log /size:10000000 /entries:0-300 /truncate
rem 無効化
w32tm /debug /disableログを併用すると、次のような切り分けがしやすくなります。
- /monitor に出ないのは「列挙できていない」のか「問い合わせが通っていない」のか
- 同期元の切替（DC 階層／手動 NTP）が、意図通りに発生しているか
- GPO 適用後に設定が実際に反映されたか（再起動・サービス再起動が必要か）
“台帳”を探すより早い：目的別の最短アプローチ
最後に、よくある目的ごとに「最短で答えに辿り着く見方」をまとめます。
| あなたの目的 | まずやること | 次にやること | 結論が出るポイント |
|---|---|---|---|
| “/monitor の一覧”の参照元を知りたい | /computers で固定してブレを止める | DNS SRV（_msdcs）と DC Locator 観点で確認 | 一覧は固定台帳ではなく探索＋問い合わせの結果 |
| “誰が誰から同期しているか”を知りたい | 各サーバーで /query /status | /query /configuration で設定由来確認 | 参照先は W32Time の設定とロジックで決まる |
| “PDC が正しく外部 NTP を参照しているか”を確かめたい | PDC で /query /configuration | /query /status で Source/Stratum を確認 | フォレスト ルートの PDC が外部同期の要 |
| “なぜズレるのか”原因を突き止めたい | /monitor＋/stripchart で揺れを把握 | イベントログ＋プライベートログで追跡 | 列挙・問い合わせ・設定のどこが原因か分離できる |
まとめ：/monitor を「ADの台帳」ではなく「実行時プローブ」として扱う
w32tm /monitor の“分かりにくさ”は、「一覧＝保存された何か」と見なしてしまうところから始まります。実際には、/monitor はドメイン（または指定先）を対象に、見つけて、問い合わせて、結果を表示するツールです。だからこそ、出力が変動し得ます。
そして「参照先（同期元）がどこか」を突き止めるには、/monitor 単体よりも w32tm /query /status と w32tm /query /configuration を軸に、PDC エミュレーターとドメイン階層（NT5DS）の考え方で追うのが最短です。発見（DNS SRV/DC Locator）と問い合わせ（UDP 123/W32Time）を分けて見れば、もう “どこから取っているのか分からない” で詰まることはなくなります。
コメント