Windows Server 2016のNPS（RADIUS）設定を、Windows Server 2012 R2へ移そうとしてXMLをImportすると失敗する…という相談はよくあります。原因は「手順ミス」ではなく、NPS構成DBのバージョン差による“下位移行”の壁です。この記事では、失敗の理由と最短で安全に移行する方法、さらにRADIUSクライアントだけを移す現実解をまとめます。
起きている問題：2016でExportしたXMLが2012 R2でImportできない
NPS（Network Policy Server）は、RADIUSクライアント情報（NASや無線LANコントローラ、スイッチなど）や、接続要求ポリシー／ネットワークポリシー、会計ログ（Accounting）設定などをまとめて保持しています。移行時は、Microsoftが案内している手順どおりに、netshまたはPowerShellで設定をXMLへエクスポートし、宛先でインポートするのが一般的です。
ところが、Windows Server 2016で作成したXMLをWindows Server 2012 R2へ取り込もうとすると、コマンド自体は実行できてもImportが失敗し、期待どおり設定が移りません。エラー文言は環境で変わりますが、概ね「構成が互換ではない」「データベースのバージョンが一致しない」といった方向性になります。
この時点で「XMLが壊れている」「手順が間違っている」と疑いがちですが、結論から言うと2016 → 2012 R2の“下位バージョン移行”そのものが壁になっているケースが中心です。
原因の本質：NPS構成DBのバージョン差（上位→下位）は想定されていない
MicrosoftのNPS移行手順には、重要な注意としてソース側NPSデータベースのバージョンが宛先より高い場合、このexport/import手順は使わない旨が明記されています。つまり、2016で構成を作り、2012 R2へ「戻す」ような移行は、失敗し得る（＝互換性が保証されない）という位置付けです。
ここでいう「NPSデータベース」は、RADIUSの各種設定を保持している内部構成DBのことで、OSバージョン差によってスキーマ（保存形式）が変わる可能性があります。上位バージョンの機能や属性を含む構成を、下位バージョンが理解できないのは自然です。
| 移行方向 | 成否の傾向 | 考え方 |
|---|---|---|
| 2012 R2 → 2016/2019/2022 | 成功しやすい | 宛先が同等以上なら、上位互換で取り込みやすい |
| 2016 → 2016/2019/2022 | 成功しやすい | 同等以上であれば標準手順（export/import）が機能しやすい |
| 2016 → 2012 R2 | 失敗しやすい | 下位移行は想定外。フルImportに頼らず別案を検討 |
まず確認：両サーバーのNPS DBバージョンを比較する
「本当にバージョン差が原因か？」を確認するために、両サーバーで次のコマンドを実行し、出力内のNPS database version（表記は環境により近い文言）を比較します。
netsh nps show configポイントは単純で、ソース側（2016）のDBバージョン > 宛先側（2012 R2）のDBバージョンであれば、標準のXML importが失敗する条件に合致しやすい、ということです。逆に、宛先を2016/2019/2022にできるなら、移行作業は一気に簡単になります。
移行方針の決め方：最短で安定するのは「宛先を同等以上にする」
現場で詰まりやすいのは「2012 R2へ移したい理由」が、古いサーバーを再利用したい／既存環境の縛りなどに起因しているケースです。ただ、NPSは認証基盤であり、止まると無線LANやVPN、802.1X認証がまとめて影響を受けます。運用リスクを下げる観点では、次の優先順位で方針を検討するのがおすすめです。
| 優先度 | 方針 | メリット | デメリット |
|---|---|---|---|
| 高 | 宛先を2016/2019/2022以上にして丸ごと移行 | 作業が短く、再現性が高い。設定の抜け漏れを減らせる | 新サーバー準備が必要 |
| 中 | 2012 R2に手動で再構築（XMLを設計書として活用） | どうしても2012 R2が必要な制約に対応できる | 工数が大きい。設定差分が出やすい |
| 中 | RADIUSクライアントだけ移して、ポリシーは作り直す | 影響範囲を小さく段階移行しやすい | 結局、ポリシーの再作成が必要になることが多い |
パターンA：宛先を同等以上で用意してNPS構成を丸ごと移行する（推奨）
2016 → 2016/2019/2022（またはそれ以上）であれば、Microsoftの標準手順で移行できる可能性が高くなります。特に、複雑な802.1X（EAP/PEAP/EAP-TLS）や複数ポリシーを運用している環境ほど、丸ごと移行が安全です。
事前準備（失敗を減らすチェックリスト）
| チェック項目 | 内容 | 理由 |
|---|---|---|
| NPS役割の追加 | 宛先に「Network Policy and Access Services」→「Network Policy Server」を追加 | 機能が入っていないとImportできない |
| 管理者権限で実行 | netsh / PowerShellを必ず管理者として起動 | 権限不足でImportが失敗しやすい |
| 既存設定のバックアップ | 宛先にすでにNPS設定がある場合、必ず事前にExportで退避 | Importは基本的に既存設定を上書きする（マージ不可） |
| NPSのAD登録 | NPSコンソールで「NPS（ローカル）」を右クリック→「Active Directory にサーバーを登録」 | ドメインユーザー認証やダイヤルインプロパティ参照で必要 |
| 証明書（EAP） | PEAP/EAP-TLSを使う場合、宛先にサーバー証明書（秘密鍵込み）とルート/中間CA証明書を用意 | NPS構成のImportだけでは証明書が揃わず認証が失敗する |
| ファイアウォール/ポート | RADIUS（UDP 1812/1813 等）の受信を許可 | 切り替え後の疎通確認でつまずきやすい |
移行コマンド（netsh / PowerShell）
実務では、互換性・再現性の観点からnetshでの移行が分かりやすいです。共有シークレット（PSK）をXMLに含めるかどうかでコマンドが変わります。
| 目的 | ソース（エクスポート） | 宛先（インポート） |
|---|---|---|
| PSKを含めずに退避（安全寄り） | netsh nps export filename="C:\temp\nps.xml" | netsh nps import filename="C:\temp\nps.xml" |
| PSKを含めて退避（作業短縮） | netsh nps export filename="C:\temp\nps.xml" exportPSK=YES | netsh nps import filename="C:\temp\nps.xml" |
PowerShellでも移行可能です。環境によって引数が異なる場合があるため、宛先/ソース双方で次を先に確認してから使うと安全です。
Get-Command -Module NPS
Get-Help Export-NpsConfiguration -Full
Get-Help Import-NpsConfiguration -Full重要：exportPSK=YESのXMLは「認証情報そのもの」
exportPSK=YESで出力したXMLには、RADIUSクライアントの共有シークレットが暗号化されない形で含まれるとされています。つまり、そのファイルはパスワード一覧と同等です。作業を早く終わらせるために便利ですが、運用上は以下を徹底してください。
- ファイルはBitLockerや暗号化領域に保管し、作業後は安全に削除する
- メール添付や平文のファイル共有を避け、アクセス権を絞った共有先を使う
- 可能ならPSKを含めずにExportし、移行後に機器側/サーバー側で再入力する
切り替えを安全に進める（停止時間を最小化する）
移行後は、NPSサーバーを差し替えるだけでは終わりません。RADIUSクライアント（無線LAN AP/コントローラ、VPN装置など）が参照するRADIUSサーバー先を新サーバーへ向ける必要があります。現実的には次の手順が安全です。
- 新NPSで同じポリシーが存在することを確認（GUIで条件/制約/プロファイルをチェック）
- 新NPSで会計ログが出ること、イベントログに致命的エラーがないことを確認
- RADIUSクライアント側に新NPSをセカンダリとして追加し、疎通テスト
- 問題なければ新NPSをプライマリへ昇格（段階的に切り替え）
「一気に切り替える」と、証明書やポリシーの差分があった場合に影響範囲が広がります。段階切り替えにすると、問題切り分けが圧倒的に楽になります。
パターンB：どうしても2012 R2へ移行したい場合の現実解
結論として、2016 → 2012 R2でフルImportに期待するのは危険です。うまくいったとしても「たまたま」で、将来の運用変更や再移行で再び詰まる可能性があります。2012 R2へ寄せる必要がある場合は、次の考え方で進めるのが現実的です。
やることは「移行」ではなく「再構築」
2016側でExportしたXMLは、2012 R2に取り込めなくても設計書（設定の写し）として非常に価値があります。XMLやNPSコンソールを見ながら、2012 R2側で同等の設定を作り直します。工数は増えますが、結果として安定します。
| 再構築でハマりやすい項目 | 確認ポイント | 対策 |
|---|---|---|
| ネットワークポリシー | 条件（グループ/接続種別）、制約（認証方式）、設定（RADIUS属性） | まず最小構成の1本を作り、動作確認後に増やす |
| 接続要求ポリシー | プロキシ有無、宛先RADIUSサーバーグループ | 認証をどこで完結させるか（ローカル/転送）を明確化 |
| 証明書/EAP | PEAPのサーバー証明書選択、EAP-TLSのCA連鎖 | 宛先サーバーに証明書（秘密鍵込み）を移し、NPSで選び直す |
| 会計ログ | 保存先パス、SQL/テキスト、ローテーション | パスが存在するか、サービスアカウントの権限があるか確認 |
「同じに作ったつもり」を防ぐコツ
- ポリシー順序：NPSは上から評価されるため、順序が違うだけで動作が変わります
- 条件の粒度：ユーザーグループ、NASポートタイプ、呼び出し元属性など、条件が多いほど差分が出やすい
- RADIUS属性：VLAN割り当て（Tunnel-Private-Group-ID等）やベンダー固有属性は特に要注意
- ログの見方：イベントビューアーの「Network Policy and Access Services」ログで拒否理由（条件不一致、証明書不備など）を追う
RADIUSクライアントだけ移したい：選択Importはできない前提で考える
「せめてRADIUSクライアント（NAS）の一覧だけでも取り込みたい」という要望は多いのですが、標準の移行手順は設定の一部だけを選んでImportする（マージする）機能が基本的にありません。Importは上書き型で、必要なものだけ追加する用途に向きません。
そのため、RADIUSクライアントだけを移す場合は、次のいずれかが現実的です。
- 台数が少ない：NPSコンソールで手動作成（確実で速い）
- 台数が多い：PowerShellで一覧を採取し、宛先で一括作成（作業ミスを減らす）
- 共有シークレットも必要：exportPSK=YESのXMLを「参照用」にして、秘密情報の扱いを徹底したうえで転記
手動でRADIUSクライアントを再作成する手順（確実）
GUIで作る場合は、NPSコンソールで以下をたどります。
- 「RADIUS クライアントとサーバー」→「RADIUS クライアント」→「新規」
- フレンドリ名（識別しやすい名前）、アドレス（IPまたはFQDN）、共有シークレット、ベンダー名、必要なら追加オプションを入力
台数が10台程度なら、この方法が最も事故が少ないです。入力後に「認証が通るか」を1台ずつテストし、問題があればすぐ戻せます。
PowerShellでRADIUSクライアント一覧をエクスポートする（公開情報だけ）
クライアントが多い場合は、まず2016側で一覧を抜き出してCSVにします。共有シークレットは取得できない／扱うべきでないことも多いため、CSVにはアドレスと名前など“公開情報だけ”を出す運用が安全です。プロパティ名は環境差が出ることがあるため、最初にGet-Memberで確認してからSelect-Objectを調整してください。
# 2016（ソース）側
$clients = Get-NpsRadiusClient
$clients | Get-Member
# 例：NameとAddressだけをCSV化（必要なら列を追加）
$clients |
Select-Object Name, Address |
Export-Csv -Path "C:\temp\radius-clients.csv" -NoTypeInformation -Encoding UTF8PowerShellでRADIUSクライアントを一括作成する（宛先）
宛先（2012 R2側）でCSVを読み込み、RADIUSクライアントを作成します。共有シークレットは機器ごとに異なる場合が多いため、運用に合わせて入力方法を決めてください（例：同一PSKなら一括、個別PSKなら別列に持たせる、など）。以下は同一PSKをまとめて設定する例です。作成コマンドの引数は環境差が出ることがあるため、事前にGet-Help New-NpsRadiusClient -Fullで確認すると確実です。
# 2012 R2（宛先）側
Get-Help New-NpsRadiusClient -Full
$csv = Import-Csv "C:\temp\radius-clients.csv"
# 同一の共有シークレットを使う例（入力は画面に表示されない）
$secret = Read-Host "Shared Secret" -AsSecureString
$plain = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
[Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret)
)
foreach ($c in $csv) {
# 既存がある場合はスキップ（重複作成を防ぐ）
$exists = Get-NpsRadiusClient | Where-Object { $_.Name -eq $c.Name }
if ($null -ne $exists) { continue }
New-NpsRadiusClient -Name $c.Name -Address $c.Address -SharedSecret $plain
}ここで重要なのは、共有シークレットをCSVに平文で持たせないことです。どうしても自動化したい場合は、別途、社内の安全な資格情報管理（例：パスワードマネージャー、限定権限の保管庫）を使い、スクリプトから安全に取り出す設計にしてください。
Importが失敗するときの切り分けポイント（対応OSでも役立つ）
宛先を同等以上にしてもImportがうまくいかない場合、バージョン差以外の要因が混ざっている可能性があります。ありがちなポイントを先に潰すと、復旧が早いです。
| 症状 | よくある原因 | 確認/対処 |
|---|---|---|
| Import直後に設定が反映されない | 管理者権限不足、NPS未インストール | 管理者で実行し、役割が入っているか確認 |
| 一部だけ欠ける（特にEAP関連） | 証明書が宛先にない | サーバー証明書（秘密鍵付き）を移し、NPSで再選択 |
| 認証が通らない | AD登録不足、時刻ずれ、ファイアウォール | NPSをADに登録、NTP確認、UDP 1812/1813を開放 |
| 機器からの要求が届かない | RADIUSクライアント未登録、送信元IP違い | 機器の送信元IPとNPS側登録が一致しているか確認 |
よくある質問
XML Importができないなら、2016のXMLを編集して2012 R2に取り込めますか？
現実的にはおすすめしません。Importに成功したとしても、内部的に想定外の値が混ざると運用中に別の不具合として表面化する可能性があります。2012 R2へ寄せる必要があるなら、XMLは「参照用」にして、手動／スクリプトで再構築するほうが安全です。
NPS構成をImportしたのに、PEAPの認証が失敗します
多い原因は「証明書が宛先にない」または「NPSで証明書を選び直していない」です。特にPEAPはサーバー証明書の選択が重要で、秘密鍵を含む証明書が宛先に正しく入っていないと失敗します。Importは万能ではなく、OSの証明書ストアまで自動移行されない点に注意してください。
Importは“追記”ではなく“上書き”と聞きました。既存のNPSに追加したい場合は？
安全策は、まず宛先側の設定をExportして退避したうえで、どちらの構成を採用するかを決め、必要なら手動で合成することです。Importでうまくマージしようとすると、設定の欠落や意図しない上書きが起きやすくなります。
まとめ：2016→2012 R2は「下位移行」なので、目的に合わせて最適解を選ぶ
Windows Server 2016から2012 R2へNPS（RADIUS）構成を持っていこうとしてXML Importが失敗する場合、互換性の問題にぶつかっている可能性が高いです。最短で安定させるなら、宛先を同等以上のWindows Serverにして標準手順で移行するのが基本です。
どうしても2012 R2が必要なら、XMLを設計書として再構築に切り替えましょう。RADIUSクライアントだけ移す場合も、選択Importはできない前提で、手動またはPowerShellによる一括作成が現実的です。認証基盤の移行は「止めない」「漏れを出さない」が最優先です。段階切り替えとログ確認をセットにして進めてください。
コメント