Windows Server の KMS 認証で slmgr.vbs -ato が 0xC004F074 になり、KMS の TCP 1688 も通らない場合は「名前解決→1688疎通→KMS側状態→しきい値」の順で潰すのが最短です。必要ポート、双方向の考え方、到達期間（180日）を具体手順で解説します。
0xC004F074（KMS に接続できない）は何が起きている？
エラー 0xC004F074 は、KMS クライアントが「KMS ホストを見つけられない、または到達できない」状態で発生しやすい代表例です。KMS は基本的に TCP 1688 で通信しますが、実際の現場では次のような要因が重なり、原因が見えにくくなります。
- DNS の自動検出（SRV レコード
_vlmcs._tcp）が引けず、KMS 名が解決できていない - 名前は解決できるが、経路 FW/ACL やホスト側 FW で 1688 が遮断されている
- KMS ホスト側がそもそも 1688 を待ち受けていない（構成不備、サービス停止など）
- KMS のしきい値（最低台数）に届かず、通信できても認証が成立しない
| よくある症状 | まず疑うポイント |
|---|---|
slmgr.vbs -ato が 0xC004F074 | DNS（_vlmcs._tcp）でKMSが見つからない／手動指定が誤り／1688到達不可 |
| telnet 1688 が接続できない | 経路FW/ACL、KMSホスト側FW、KMSサービス未待受、名前解決ミス（IPv6含む） |
| 同じKMSを使うのに一部サーバーだけ失敗 | 片方向ACL、戻り経路（非対称ルーティング）、DNSサフィックス/参照DNSの違い、古いKMS固定設定 |
結論：KMS 認証で「追加で開けるべきポート」は基本的に多くない
質問の核心（1688以外のポート／双方向／到達期間）を先に整理すると、運用判断がしやすくなります。
| 項目 | 結論 | 補足 |
|---|---|---|
| 1688 以外に開けるべきポートはある？ | 基本は不要 | KMS 通信自体は TCP 1688。自動検出を使うなら DNS（TCP/UDP 53）が実質必要 |
| 1688 は双方向（in/out）で開ける必要がある？ | セッションとして成立すればOK | 一般的なステートフル FW なら「クライアント→KMS の送信許可」と「KMS 側 1688 の待受（インバウンド許可）」が主。片方向ACLは戻り通信も要確認 |
| 認証のためにどれくらい KMS に到達できる必要がある？ | 180 日以内に再到達できることが現実ライン | 認証後は約 7 日ごとに更新を試み、失敗時は短い間隔で再試行。閉域運用なら「定期開放」設計が重要 |
最優先：KMS サーバー名の解決（DNS / FQDN）を確認する
KMS クライアントは通常、ドメイン DNS に登録された SRV レコード _vlmcs._tcp を参照して KMS ホストを自動検出します。つまり、1688 の前に DNS でつまずくケースが非常に多いです。
DNS（SRV レコード）を確認するコマンド例
クライアント側（認証したい Windows Server）で、以下を実行して結果を確認します。
nslookup -type=SRV _vlmcs._tcp.<あなたのドメイン>
# PowerShell（利用できる環境なら）
Resolve-DnsName -Type SRV _vlmcs._tcp.<あなたのドメイン>- SRV レコードが引けない：DNS 側にレコードがない、参照DNSが違う、ネットワーク的に DNS に到達できない可能性
- SRV レコードは引けるがホスト名が不正：古いKMS名が残っている、移行後の更新漏れの可能性
- SRV のターゲット名は正しいが A/AAAA で IP に解決できない：KMS ホストの名前解決が別で失敗している可能性
「古い KMS が固定されている」パターンもある
過去に手動で slmgr /skms を設定した端末は、その設定が残っている限り DNS 自動検出に戻りません。KMS の移行後に「このサーバーだけ見つからない」「昔のKMSへ行っている」場合は、いったん固定設定をクリアしてから再試行すると切り分けが早いです。
# KMS ホストの手動指定を解除（DNS 自動検出に戻す）
slmgr /ckms
# 必要なら改めて手動指定
slmgr /skms <kmsFQDN>:1688DNS が使えない／引けない環境の切り分け
検証環境や閉域環境では、DNS 自動検出を捨てて「手動指定」で切り分けると原因が明確になります。
- hosts で FQDN→IP を解決できるようにする（DNSがない場合の暫定策）
- KMS ホストを手動指定して認証を試す
slmgr /skms <kmsFQDN>:1688
slmgr /ato手動指定で成功するなら「DNS 自動検出（_vlmcs._tcp）まわり」が主因、手動指定でも失敗するなら「1688疎通 or KMS 側状態」が主因、と切り分けできます。
通信の本体：KMS は TCP 1688 が基本（ただし“到達”の前提がある）
KMS のライセンス認証トラフィック自体は、原則として TCP 1688 です。よってファイアウォール設計はシンプルで、クライアント（認証対象）→KMS ホスト（認証サーバー）宛ての TCP 1688 を許可できていれば足りることがほとんどです。
「双方向で開ける？」の正しい捉え方（ステートフルとステートレス）
ネットワークの会話としては、要求（SYN/データ）はクライアントから出て、応答は同じセッションで戻ってきます。つまり “双方向に穴を開ける” というより、セッションとして成立させるのがポイントです。
- ステートフル FW（一般的な社内FW/Windows FW）：クライアントからのアウトバウンド 1688 が許可され、KMS 側で 1688 を待ち受け（インバウンド許可）していれば、多くの場合は戻り応答も自動で通ります。
- ステートレス ACL（厳密な片方向ACL、特殊なNW機器）：戻りのトラフィック（KMS:1688 → クライアントのエフェメラルポート）が遮断されない設計か要確認です。
「サーバー側だけ 1688 を開けたのに繋がらない」「セグメントを跨ぐと繋がらない」場合は、ステートレス ACL や戻り経路（非対称ルーティング）を疑うと早いです。
KMS のポートが 1688 以外に変更されていないか
既定ポートは 1688 ですが、ポリシーや移行の都合で KMS ホスト側の待受ポートを変更している環境もあります。DNS の SRV レコードが指すホストは正しいのに 1688 だけ繋がらない場合は、KMS ホスト側の設定（待受ポート）を確認してください。クライアント側は slmgr /skms <kmsFQDN>:<ポート> のようにポートを明示できます。
必要になりがちな“追加通信”は DNS（53）
KMS の自動検出を使うなら、KMS 自体の 1688 とは別に DNS（TCP/UDP 53） の到達が必要です。逆に言うと、「KMS のために 1688 以外も開ける」話は通常は出ません。ただし、次のような“周辺条件”が原因で、結果的に認証が失敗することがあります。
| 通信/条件 | 目的 | 開ける/整える場面 |
|---|---|---|
| TCP 1688 | KMS 認証通信 | 必須（クライアント→KMS） |
| TCP/UDP 53（DNS） | _vlmcs._tcp の自動検出、KMS 名称解決 | 自動検出を使うなら実質必須 |
| UDP 123（NTP） | 時刻同期 | 必須ポートではないが、時刻ずれが大きい環境では事前に整えておくと安全 |
telnet だけで判断しない：疎通テストとログで“どこで止まるか”を見る
telnet は「TCP で接続できるか」を見るには便利ですが、失敗時に情報が少なく、また環境によっては telnet クライアント自体が入っていないこともあります。現場では、疎通テスト＋ライセンス情報＋サーバー側ログをセットで確認するのが確実です。
クライアント側：疎通とライセンス状態を同時に確認
# 1688 疎通（Windows標準）
Test-NetConnection <kmsFQDN> -Port 1688
# IP を指定して DNS を迂回（DNS切り分け）
Test-NetConnection -Port 1688
# ライセンス状態（代表例）
slmgr /dlv
slmgr /dliTest-NetConnectionの結果でTcpTestSucceeded : Trueにならないなら、まずはネットワーク（FW/ACL/経路）を疑います。- FQDN では失敗するが IP 直打ちだと成功する場合、原因はほぼ DNS（名前解決・IPv6・参照DNS）側に寄ります。
slmgr /dlvでは、チャネル（KMS クライアントか）、設定されている KMS ホスト、前回のエラーなどが追えます。
IPv6（AAAA）でハマるケース
名前解決が IPv6（AAAA）を返し、ネットワーク的に IPv6 到達ができない環境だと「名前は解決できるのに繋がらない」状態になります。Test-NetConnection の詳細表示や ping -4/ping -6 で、どのアドレスへ向かっているかを確認すると原因が掴みやすいです。
KMS サーバー側：待ち受け・サービス・イベントログ
KMS ホスト（認証サーバー）側では、次を確認します。
- TCP 1688 を待ち受けているか（KMSホストが正しく構成されているか）
- ホスト側ファイアウォールで 1688 が許可されているか
- イベントログに要求が届いているか
# 待ち受け確認（例）
netstat -an | find "1688"
# サービス確認（例：Software Protection）
sc query sppsvcイベントログは、KMS の要求を処理した痕跡が残っているかを見ます。ホスト側に一切ログが出ないなら「そもそも届いていない」可能性が高く、届いているのに失敗しているなら「しきい値」「ホストキー」「構成」などの可能性が上がります。
落とし穴：KMS のしきい値（最低台数）を超えないと認証が成立しない
KMS は “いつでも誰でも” 認証できる仕組みではなく、一定数のクライアントがカウントされて初めて認証要求に応答する性質があります。ここでつまずくと、1688 が通っていても slmgr.vbs -ato が成功しません。
| 対象 | しきい値（目安） | ポイント |
|---|---|---|
| Windows クライアント OS | 25 | 社内PCが少ない検証環境だと届かないことが多い |
| Windows Server OS | 5 | サーバー台数が少ない環境では MAK/ADベース認証の方が現実的なことも |
KMS ホスト側の slmgr /dlv で Current count（現在のカウント） を確認し、しきい値に達しているかを見てください。しきい値未満の場合、ネットワーク疎通が完璧でも「認証できない」のが仕様です。
“30日”が絡む理由（小規模環境で起きがち）
KMS のカウントは永続ではなく、一定期間（目安として30日）で“最近見かけたクライアント数”が目減りします。台数がギリギリの環境だと、たまたま開けた日にしきい値を満たせず、認証が通らないことがあります。閉域運用で「必要なときだけ開ける」運用をする場合、この挙動を踏まえた設計が重要です。
「今日だけ 1688 を開けて閉じる」は可能。ただし 180 日ルールを理解する
KMS クライアントは、いったん認証が通っても永久に固定されるわけではなく、定期的に KMS へ到達して更新し続けることで認証状態を維持します。
- ライセンスの有効期限（KMS の更新猶予）は一般に 180 日
- 認証後もクライアントは おおむね 7 日ごとに更新（再認証）を試みる
- 更新に失敗すると、短い間隔で再試行するため、閉じている期間は失敗ログが溜まりやすい
したがって、セキュリティ都合で 1688 を常時開放したくない場合でも、少なくとも 180 日以内に一度は KMS に到達できる経路を用意するのが現実的です。運用としては次のような設計がトラブルを減らします。
| 設計パターン | メリット | 注意点 |
|---|---|---|
| 常時許可（1688 を閉域内で許可） | 最も安定。更新失敗ログも出にくい | セグメント分離が必要なら送信元を絞る（サーバー/端末のIPレンジ限定） |
| 定期開放（例：月1回数時間だけ許可） | セキュリティ方針に合わせやすい | しきい値や「更新タイミングのばらつき」で取りこぼしが出ないよう余裕を持つ |
| VPN 等で到達経路を用意 | 持ち出し端末や拠点間でも更新しやすい | VPN 経路の DNS 解決（サフィックス）もセットで設計する |
| 代替方式（MAK / AD ベース認証）を検討 | 台数が少ない環境や、1688 を開けられない要件に強い | 組織のライセンス体系と運用要件に合わせて選定が必要 |
手順で潰す：名前解決→1688→KMS側→しきい値（チェックリスト）
原因が複合していると迷子になりがちなので、現場で使える順番に落とし込みます。チェック結果を表に埋めていくと、チームでの切り分けもスムーズです。
| 手順 | 確認内容 | コマンド例 | NG のときに次に見る場所 |
|---|---|---|---|
| 1 | DNS SRV _vlmcs._tcp が引ける | nslookup -type=SRV _vlmcs._tcp.<domain> | DNS サーバー設定、参照先、レコード登録、名前解決経路 |
| 2 | KMS ホスト名が IP に解決できる（A/AAAA） | nslookup <kmsFQDN> | DNS の A/AAAA、hosts、DNS サフィックス、IPv6 到達性 |
| 3 | TCP 1688 が到達できる | Test-NetConnection <kmsFQDN> -Port 1688 | 経路FW/ACL、KMSホストFW、戻り経路、NAT |
| 4 | KMS ホストが 1688 を待ち受けている | netstat -an | find "1688" | KMSホストの構成（ホストキー/サービス）、Windows FW ルール |
| 5 | しきい値に達している | slmgr /dlv（KMSホスト側） | 台数不足、カウントの目減り、代替方式（MAK/ADベース） |
“通っているのに失敗する”ときに見る追加ポイント
KMS クライアントキー（GVLK）が入っているか
Windows Server を KMS で認証するには、KMS クライアントチャネルになっている必要があります。slmgr /dli でチャネル表記を確認し、意図せず MAK 等になっていないかをチェックします。イメージ展開後の設定ミスで、KMS を見に行かない状態になっていることもあります。
クローン展開による識別子の重複（CMID/GUID）
テンプレートVMやイメージから大量展開した環境では、正しい手順を踏んでいないと、クライアント識別子の重複が起きて KMS のカウントや挙動が不安定になることがあります。Sysprep（generalize） を前提にした展開になっているか、手順を見直してください。
IP 重複、ルーティング、名前解決サフィックスのズレ
「特定のサーバーだけ認証できない」場合、KMS そのものより環境要因が原因のことが多いです。
- IP アドレス重複や ARP の競合
- 戻り経路が別経路になる（非対称ルーティング）
- FQDN を短縮名で指定していて DNS サフィックスが合っていない
- DNS が複数系統あり、参照先によって SRV レコードが存在しない
セキュリティを落とさずに 1688 を通すコツ（最小権限のFWルール）
「1688 を開ける」と言っても、無制限に開放する必要はありません。KMS は社内向けの仕組みなので、次のように送信元・宛先・ポートを絞ったルールにすると監査にも耐えやすくなります。
| 設定対象 | 方向 | 許可内容（例） | ポイント |
|---|---|---|---|
| ネットワークFW | クライアント → KMS | 送信元：認証対象サブネット / 宛先：KMSホスト / TCP 1688 | セグメント分離環境でも基本はこれで足りる |
| KMSホストの Windows FW | インバウンド | TCP 1688 を許可（必要なら送信元IPを制限） | OS側FWが閉じているとネットワークFWがOKでも失敗する |
| DNS | クライアント → DNS | TCP/UDP 53（必要範囲で） | _vlmcs._tcp を使うなら最優先で通す |
まとめ：最短で解決するための考え方
0xC004F074 の多くは「KMS の 1688 が閉じている」だけでなく、DNS の自動検出（_vlmcs._tcp）や戻り通信を含む経路、そしてしきい値が絡んで発生します。特に閉域・分離ネットワークでは、手動指定で切り分けしてから、必要最小限のポート（主に 1688 と 53）を、運用要件に合わせて常時許可／定期開放で設計すると再発が減ります。
迷ったら、①名前解決（DNS/FQDN）→②TCP 1688 疎通→③KMS 側で要求を受けているか→④しきい値を満たしているかの順に、ログとテスト結果で事実を積み上げてください。これが最も速く、説明もしやすい解決ルートです。
コメント