Intune 有線LAN(802.1X)プロファイルが上書きされない原因と対処法｜netsh・WiredNetwork CSP・Proactive Remediations

Intune の「Wired Network (IEEE 802.1X)」で有線LANの 802.1X を配布しているのに、過去の誤設定が端末に残り、新しい構成プロファイルが反映されない――。この“上書きされない”問題を、端末側の LAN プロファイル(XML)から切り分け、再発しにくい運用と自動修復まで含めて整理します。

起きている症状（よくある問い合わせパターン）

現場でよく見かけるのは、次のような状況です。

Intune の Wired Network (IEEE 802.1X) 構成プロファイルで、有線LANの 802.1X（EAP-TLS / PEAP / TEAP など）を配布している
過去に配布した誤った設定が端末に残っていて、新しいプロファイルを割り当てても端末側が変わらない
Intune 側では「成功」「適用済み」に見えるのに、端末の実体（XML）が古いまま
新規端末、または 手動設定や旧配布が一度も無い端末 では同じプロファイルが正常に動く

観点	見え方	よくある誤解
Intune ポータル	成功 / 適用済み	「端末の設定も更新されたはず」
端末（LAN プロファイル）	古い XML のまま	「同期が走っていないだけ」
ネットワーク接続	失敗、または意図しない認証方式で接続	「証明書が悪い／RADIUS が悪い」

結論：原因は「端末側に残る LAN(802.1X) プロファイルが“張り付く”こと」

この問題の本質は、Intune の設定配布そのものよりも、Windows が保持している 802.1X の LAN プロファイル（XML）にあります。

Intune の有線 802.1X は、内部的に WiredNetwork CSP（LanXML）を使う

Intune の「Wired Network (IEEE 802.1X)」は、Windows 側では WiredNetwork CSP を通じて LanXML を適用します。ここで配布される実体は、Windows の有線LANプロファイルで、LAN_profile スキーマと OneX（802.1X）スキーマを含む XML です。

代表的な形は次のような構造です（概念イメージ）。

&lt;LANProfile xmlns="https://www.microsoft.com/networking/LAN/profile/v1"&gt;
  &lt;MSM&gt;
    &lt;security&gt;
      &lt;OneXEnabled&gt;true&lt;/OneXEnabled&gt;
      &lt;OneX xmlns="https://www.microsoft.com/networking/OneX/v1"&gt;
        &lt;EAPConfig&gt;...&lt;/EAPConfig&gt;
      &lt;/OneX&gt;
    &lt;/security&gt;
  &lt;/MSM&gt;
&lt;/LANProfile&gt;

“上書きされない”は、実質「古いプロファイルが優先されている／置き換わらない」

端末に古い LAN プロファイルが残っていると、Intune が新しい LanXML を配布しても、端末側で期待どおりに置き換わらず、結果として 古い 802.1X 設定がそのまま使われ続けることがあります。

この状態が厄介なのは、Intune の管理画面上は「適用済み」に見えやすく、“配布は成功しているのに、実体が変わらない”というギャップが発生する点です。

なぜ特定の端末だけで起きるのか（発生しやすい条件）

次のような端末は、特にこの問題にハマりやすいです。

発生しやすい端末	理由	現場のあるある
過去に GPO で有線 802.1X を配布していた	GPO 由来の設定が残る／再適用されることがある	「Intune 移行後も GPO が生きていた」
スクリプトや手動で 802.1X を設定したことがある	端末ローカルの LAN プロファイルが既に存在	「検証用に手で入れた設定が残っていた」
最初に誤った Intune プロファイルを配布してしまった	誤設定が“初期値”として残り続ける	「後から正しいプロファイルに直したのに治らない」
ハイブリッド参加でポリシー経路が複数ある	GPO/MDM/ローカルの優先や競合が複雑化	「端末ごとに履歴が違う」

まずやるべき切り分け：端末側の LAN プロファイルを“見える化”する

最短で原因に到達するには、端末に入っている LAN(802.1X) プロファイルを確認するのが近道です。Windows では netsh lan が強力です。

確認に使うコマンド一覧

目的	コマンド	ポイント
有線インターフェース名を確認	`netsh lan show interfaces`	以降の export/delete で `interface="Ethernet"` のように使う
LAN プロファイルの存在確認	`netsh lan show profiles`	端末にプロファイルが残っているかの当たりを付ける
LAN プロファイル XML を出力（全体）	`mkdir C:\Temp netsh lan export profile folder="C:\Temp"`	`MachineProfile.xml` 等が出る。差分比較に便利
特定インターフェースのプロファイルを出力	`netsh lan export profile folder="C:\Temp" interface="Ethernet"`	インターフェース紐づきの XML が出る（例：`Ethernet.xml`）

XML で見るべき“差分ポイント”

XML を開いたら、少なくとも次の観点を見ます。

認証方式：EAP-TLS / PEAP / TEAP など（EapMethod Type の差、EAPConfig の中身）
端末認証かユーザー認証か：マシン証明書利用、ユーザー資格情報、SSO（preLogon/postLogon）
サーバー検証：信頼するルート CA、サーバー名、ユーザープロンプト抑制
古い誤設定の痕跡：誤った CA、誤ったサーバー名、不要な EAP 設定が残っている

ここで、端末側 XML が古い内容のままなら、以降はかなり高い確度で“古い LAN プロファイルが新しい Intune 設定を実質ブロックしている”と判断できます。

最小構成での再現テスト：削除 → 再適用を確認する

いきなり全台に対処しないのがコツです。まずは 1〜2 台のテスト端末で、原因を確定させます。

テスト端末での安全な進め方

可能なら、対象端末がWi-Fi 等の代替経路でインターネットに出られる状態で実施（有線が落ちても復旧できる）
リモート接続だけに依存している端末は注意（削除した瞬間に 802.1X が外れて通信断する可能性）
作業前に export で XML をバックアップしておく

削除の実行（インターフェース指定）

有線インターフェースに紐づくプロファイルを削除します（インターフェース名は環境に合わせてください）。

netsh lan delete profile interface="Ethernet"

必要に応じて、機器全体（MachineProfile）側も含めて整理したい場合は、インターフェース指定なしで削除を試すケースもあります（運用ポリシーや影響範囲に応じて）。

netsh lan delete profile

再適用（同期）の考え方

ここで重要なのは、IME（Intune Management Extension）の同期＝構成プロファイルの即時再適用ではない点です。構成プロファイル（MDM）側の反映は、Windows の MDM クライアントのチェックイン（ユーザー操作の「同期」や、管理者のデバイス同期指示、定期チェックインなど）に依存します。

端末側：設定アプリの「職場または学校にアクセス」から同期、Company Portal の同期
管理者側：Intune 管理センターのデバイス操作で「同期」

削除後に再度 export して XML を確認し、新しい意図した内容に置き換わったことが確認できれば、原因はほぼ確定です。

原因が確定したら：現実的な解決策は「自動修復（検知→削除→再適用）」

数十台ならまだしも、数百〜数千台を手で直すのは現実的ではありません。ここからは Intune 運用として破綻しないように、Proactive Remediations（Endpoint analytics）やスクリプト配布で自動化します。

自動化の設計パターン（おすすめ順）

パターン	内容	メリット	注意点
検知してから削除	XML を export → 期待値と一致しない端末だけ削除	影響を最小化できる	検知条件（文字列/ハッシュ）の設計が必要
無条件で削除	対象グループ全台で delete を実行	実装は簡単	通信断のリスクが最大。パイロット必須
移行用に経路を分ける	GPO 残存の除去、段階移行、対象スコープの整理	長期的に事故が減る	設計と合意形成が必要

Proactive Remediations で使えるサンプル（検知＋修復）

ここでは「古い XML が残っている端末だけ直す」ために、export した XML の中にある“期待するキーワード”で判定する例を示します。例えば、EAP のサーバー名や、想定している CA/設定の一部など、環境で一意になりやすい文字列を使うのがコツです。

前提：このスクリプトは SYSTEM（デバイスコンテキスト）で動かす想定です。

検知スクリプト例（期待する設定が入っていない端末を検出）

$ErrorActionPreference = "Stop"

$interfaceName = "Ethernet"     # 環境に合わせて変更
$temp = "C:\Temp\LanProfileCheck"
$expectedKeyword = "EapHostConfig"  # 例：もっと具体的な固有文字列に置き換える（サーバー名/CA名など）

New-Item -ItemType Directory -Path $temp -Force | Out-Null

# 現在のプロファイルをエクスポート

& netsh lan export profile folder="$temp" interface="$interfaceName" | Out-Null

$xmlPath = Join-Path $temp ($interfaceName + ".xml")
if (-not (Test-Path $xmlPath)) {
# XML が無い＝そもそも未設定/取得できない。運用方針に応じて検出扱いにするか決める
exit 1
}

$xml = Get-Content -Path $xmlPath -Raw

# 期待するキーワードが無ければ「不正（修復が必要）」

if ($xml -notmatch [regex]::Escape($expectedKeyword)) {
exit 1
}

# 正常

exit 0

修復スクリプト例（削除して再適用を促す）

修復側は基本的に「削除」を担当します。削除後の再適用は、端末チェックインのタイミングに依存しますが、運用上は管理者側からの同期やユーザー向け手順とセットにするのが安定です。

$ErrorActionPreference = "Continue"

$interfaceName = "Ethernet"  # 環境に合わせて変更

# 削除（インターフェースに紐づく LAN プロファイル）
& netsh lan delete profile interface="$interfaceName" | Out-Null

Start-Sleep -Seconds 3

# ここで「無理やり同期を叩く」系の処理は環境差が大きいため、
# 運用としては Intune 側のデバイス同期やユーザー操作の同期を推奨。
# 代替として、ログだけ残して終了するのが安全。
exit 0

キーワード設計の実務ポイント

「EapHostConfig」などの一般的な語ではなく、環境固有になりやすい語を使う（例：RADIUS のサーバー名、想定 CA 名、特定のポリシー値）
複数のキーワードで AND 判定にすると誤検知が減る
Export される XML は改行や空白で揺れることがあるため、完全一致よりも部分一致が安定

“削除したら通信が落ちる”問題への現実的な備え

有線 802.1X は、企業ネットワークの入り口そのものです。削除は強力ですが、やり方を誤ると端末がネットワークから落ちます。実務では次のガードを入れるのがおすすめです。

ガード	狙い	具体例
パイロットグループ	影響の見える化	IT 部門端末、検証室端末から段階展開
代替回線の確保	切断時も復旧可能に	Wi-Fi 接続中のみ修復を走らせる運用
実行タイミング	業務影響を下げる	夜間・出社時・オンサイト対応時に実行
ローカル復旧手順	最悪時の戻し	USB/ローカル管理者で一時的に設定投入できる手順を用意

GPO 併用環境での落とし穴：削除しても“戻ってくる”場合

ハイブリッド環境や移行期に多いのが、GPO がまだ生きていて、有線 802.1X 設定が再配布されるケースです。この場合は、Intune 側で正しい設定を配っても、端末がポリシー更新のたびに古い構成へ戻ることがあります。

見分け方としては、netsh lan show profiles の結果や、端末のポリシー適用状況（gpresult）で「どの経路で入っているか」を確認します。GPO が原因なら、やるべきことは明確で、GPO の停止/除外 → 残存プロファイルの整理 → Intune へ一本化の順で進めるのが安全です。

トラブルシュートを標準化する（社内手順書に入れたいチェックリスト）

この手の事象は、担当が変わると同じところで詰まりがちです。最短で切り分けられるよう、次の流れをそのままテンプレ化するのがおすすめです。

端末で netsh lan show interfaces（インターフェース名確認）
netsh lan show profiles（プロファイルが存在するか）
netsh lan export profile（XML を取得して中身で判断）
古い誤設定なら、テスト端末で netsh lan delete profile → 再適用を確認
確定後、Proactive Remediations で 検知→修復 を展開

今後の再発防止：プロファイル設計と移行設計の考え方

最後に、再発を減らすための考え方を整理します。単に「削除スクリプトを配って終わり」にすると、次の変更時にまた同じ苦労をしがちです。

変更管理のポイント

802.1X の大変更（EAP 方式変更、サーバー検証条件の変更、認証モード変更）をする際は、検証→段階展開→全体展開を前提にする
移行期は「GPO を止めたつもり」になりやすいので、GPO の残存チェックを手順に組み込む
“成功”表示だけで判断せず、端末の XML を根拠に判断する（これが最重要）

運用で効く小技（現場目線）

「正しい XML の特徴（キーワード）」を決めておき、検知スクリプトの精度を上げる
ネットワークチーム（NAC/RADIUS）と、失敗ログの見方（サーバー側の拒否理由）を共有する
端末側イベントログ（Wired AutoConfig/DeviceManagement など）も、一次切り分けの観点として整理する

まとめ（このページで持ち帰れること）

Intune の有線LAN(802.1X) は、Windows 側では WiredNetwork CSP（LanXML）として LANProfile/OneX の XMLを適用する
端末に古い LAN プロファイルが残っていると、新しい Intune プロファイルが反映されない（実体が置き換わらない）状態になりうる
切り分けは netsh lan で「存在確認 → export → XML 中身確認」が最短
対処は「テスト端末で削除→再適用確認」→ 確定後に Proactive Remediations で検知＆自動修復が現実的
削除は強力なので、通信断リスクを前提にパイロットとガード設計を入れる

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Intune 有線LAN(802.1X)プロファイルが上書きされない原因と対処法｜netsh・WiredNetwork CSP・Proactive Remediations

起きている症状（よくある問い合わせパターン）

結論：原因は「端末側に残る LAN(802.1X) プロファイルが“張り付く”こと」

Intune の有線 802.1X は、内部的に WiredNetwork CSP（LanXML）を使う

“上書きされない”は、実質「古いプロファイルが優先されている／置き換わらない」

なぜ特定の端末だけで起きるのか（発生しやすい条件）

まずやるべき切り分け：端末側の LAN プロファイルを“見える化”する

確認に使うコマンド一覧

XML で見るべき“差分ポイント”

最小構成での再現テスト：削除 → 再適用を確認する

テスト端末での安全な進め方

削除の実行（インターフェース指定）

再適用（同期）の考え方

原因が確定したら：現実的な解決策は「自動修復（検知→削除→再適用）」

自動化の設計パターン（おすすめ順）

Proactive Remediations で使えるサンプル（検知＋修復）

検知スクリプト例（期待する設定が入っていない端末を検出）

修復スクリプト例（削除して再適用を促す）

キーワード設計の実務ポイント

“削除したら通信が落ちる”問題への現実的な備え

GPO 併用環境での落とし穴：削除しても“戻ってくる”場合

トラブルシュートを標準化する（社内手順書に入れたいチェックリスト）

今後の再発防止：プロファイル設計と移行設計の考え方

変更管理のポイント

運用で効く小技（現場目線）

まとめ（このページで持ち帰れること）

この記事を書いた人

コメント

コメントするコメントをキャンセル

Intune 有線LAN(802.1X)プロファイルが上書きされない原因と対処法｜netsh・WiredNetwork CSP・Proactive Remediations

起きている症状（よくある問い合わせパターン）

結論：原因は「端末側に残る LAN(802.1X) プロファイルが“張り付く”こと」

Intune の有線 802.1X は、内部的に WiredNetwork CSP（LanXML）を使う

“上書きされない”は、実質「古いプロファイルが優先されている／置き換わらない」

なぜ特定の端末だけで起きるのか（発生しやすい条件）

まずやるべき切り分け：端末側の LAN プロファイルを“見える化”する

確認に使うコマンド一覧

XML で見るべき“差分ポイント”

最小構成での再現テスト：削除 → 再適用を確認する

テスト端末での安全な進め方

削除の実行（インターフェース指定）

再適用（同期）の考え方

原因が確定したら：現実的な解決策は「自動修復（検知→削除→再適用）」

自動化の設計パターン（おすすめ順）

Proactive Remediations で使えるサンプル（検知＋修復）

検知スクリプト例（期待する設定が入っていない端末を検出）

修復スクリプト例（削除して再適用を促す）

キーワード設計の実務ポイント

“削除したら通信が落ちる”問題への現実的な備え

GPO 併用環境での落とし穴：削除しても“戻ってくる”場合

トラブルシュートを標準化する（社内手順書に入れたいチェックリスト）

今後の再発防止：プロファイル設計と移行設計の考え方

変更管理のポイント

運用で効く小技（現場目線）

まとめ（このページで持ち帰れること）

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル