NIC Teaming設定がドライバー更新後に消えたときは、いきなり作り直すより、まず「本当に設定が消えたのか」「NICが別デバイスとして再認識されたのか」「ベンダー独自UIだけが消えたのか」を切り分けるのが最短です。特に Windows Server では、更新後に NIC の見え方が変わって既存チームが元のメンバーを見失ったり、Hyper-V では LBFO 前提の構成そのものを見直す必要があったりします。(Microsoft Learn)
この記事では、NIC Teaming設定がドライバー更新後に消えたと感じたときに、最初に見るべき項目、よくある原因、復旧手順、やってはいけない操作までを、Windows Server を前提に実務向けに整理します。
まず押さえる前提
Microsoft の NetLbfo(LBFO)機能は、Windows Server 2012 以降のサーバー OS 向け機能です。クライアント OS に cmdlet はありますが、基本的にはリモート管理用で、Server 側の NIC Teaming と同じ前提で見ないほうが安全です。さらに、現行の Microsoft Learn では Hyper-V の仮想スイッチを LBFO チームにバインドする構成は見直し対象で、Hyper-V では SET を使う方向に整理されています。(Microsoft Learn)
つまり、同じ「NIC Teamingが消えた」に見えても、通常の Windows Server の LBFO と Hyper-V ホストの SET 移行案件 と ベンダー独自チーミングの UI 消失 は、対処がまったく違います。ここを混ぜると、復旧が長引きます。(Microsoft Learn)
最初の10分でやる確認
まずは GUI ではなく PowerShell で現状を採取します。Get-NetAdapter は既定で可視アダプターだけを返すため、更新後の取りこぼしを避けるには -IncludeHidden を付けるのが重要です。ドライバーの見え方、チーム本体、チームメンバー、詳細プロパティをまとめて確認すると、かなりの確率で原因の方向性が見えます。(Microsoft Learn)
Get-NetAdapter -Name * -IncludeHidden | Format-Table Name, InterfaceDescription, InterfaceName, Status -Auto
Get-NetAdapter -Name * -IncludeHidden | Format-Table -View Driver
Get-NetLbfoTeam
Get-NetLbfoTeamMember
Get-NetAdapterAdvancedProperty -Name "*" -AllProperties -IncludeHidden
見るポイントは次の4つです。
Get-NetAdapter -IncludeHiddenで、同じ NIC が別名や非表示デバイスとして増えていないか確認する。(Microsoft Learn)Format-Table -View Driverで、更新後にドライバーの提供元や版数が変わっていないか確認する。(Microsoft Learn)Get-NetLbfoTeamとGet-NetLbfoTeamMemberで、チーム本体が残っているか、メンバー NIC がぶら下がっているか確認する。(Microsoft Learn)Get-NetAdapterAdvancedProperty -AllProperties -IncludeHiddenで、RSS や VLAN、オフロード系などの詳細設定が更新前と変わっていないか確認する。詳細プロパティはレジストリ上の NIC クラス配下に保持されます。(Microsoft Learn)
原因別の対処
NIC が別デバイスとして再認識された
Windows のネットワーク インターフェイス識別子は永続固定ではなく、Microsoft Learn でも InterfaceIndex は NIC の無効化・有効化で変わり得ると明記されています。Azure VM の公式トラブルシュートでも、ハードウェア MAC が変わると旧 NIC が ghost NIC として hidden devices に残り、接続や列挙に悪影響を出すケースが説明されています。ドライバー更新後に起きる「設定が消えた」は、これに近い見え方になっていることが多いです。(Microsoft Learn)
この場合は、今アクティブな NIC と、古い hidden NIC を見分ける ことが先です。名前だけで消すのではなく、Get-NetAdapter -IncludeHidden の Status、InterfaceName、ドライバービューを見て、現在使われている NIC を確定させてください。ghost NIC のクリーンアップ方法としては、Microsoft も Device Manager の View → Show hidden devices から hidden NIC を削除する手順を案内しています。(Microsoft Learn)
実務では、hidden NIC を消しただけで終わらず、チームに紐づく IP、DNS、監視、バックアップエージェントのバインド先が新しいインターフェイス名に追随しているか まで確認すると、再発しにくくなります。
チーム本体は残っているが、メンバー NIC が外れている
Get-NetLbfoTeam でチームが見え、Get-NetLbfoTeamMember で片側だけ消えているなら、まずはメンバーの付け直しを試すのが安全です。Add-NetLbfoTeamMember で既存チームに NIC を戻せます。チームが壊れている場合は Remove-NetLbfoTeam で削除し、New-NetLbfoTeam で元の設計どおりに作り直します。これらの cmdlet は管理者権限が必要です。(Microsoft Learn)
# 既存チーム確認
Get-NetLbfoTeam -Name "Team1"
Get-NetLbfoTeamMember -Team "Team1"
# メンバーだけ戻す
Add-NetLbfoTeamMember -Name "Ethernet2" -Team "Team1"
# チームを作り直す場合の例
Remove-NetLbfoTeam -Name "Team1"
New-NetLbfoTeam -Name "Team1" -TeamMembers "Ethernet1","Ethernet2" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic
ここで大事なのは、元のチーミング方式を崩さない ことです。New-NetLbfoTeam では LACP、Static、SwitchIndependent を選べます。LACP はスイッチ側設定が前提、Static もホストとスイッチの両方で設定が必要、SwitchIndependent はスイッチ設定不要です。更新前に LACP だった環境を、確認せずに SwitchIndependent で作り直すと、別の障害を増やします。(Microsoft Learn)
また、Microsoft は New-NetLbfoTeam の説明で、異なる速度の NIC をチーム化するのはサポート外 としています。ドライバー更新後に片方だけ 1Gbps 扱いになった、片方だけ別ドライバー版で認識された、といった状態なら、先に速度・ドライバーの不一致を直してください。(Microsoft Learn)
Intel などベンダー独自チーミングの UI だけが消えた
「チーム設定が消えた」の正体が、実は Windows の LBFO ではなく、ベンダー独自 UI の消失 ということもあります。Intel の現行ドキュメントでは、Intel ANS は Windows Server 2016 以降でサポートされず、Windows 11 以降でもサポートされません。さらに、Intel の Windows Server 2022 向けドライバーパッケージでは PROSet は廃止済み と案内されています。(Intel)
そのため、更新前に見えていた「Teaming/VLAN」タブや PROSet ベースの設定画面が、更新後に戻らないのは珍しくありません。Intel も、汎用ドライバーを入れる前に サーバーメーカーの提供するドライバーを優先するよう推奨 しており、メーカー版に置き換えると機能やカスタマイズが変わる可能性があると明記しています。サーバーが Dell / HPE / Lenovo などの OEM 機なら、まず OEM 提供パッケージに戻して確認するのが現実的です。(インテル)
もうひとつの落とし穴がロールバックです。Intel のユーザーガイドでは、アダプターチームや Intel PROSet が残った状態だと Windows Server の Roll Back Driver は正しく動かない と案内されています。ロールバック前にチームを外す前提で考えたほうが安全です。(Intel)
Hyper-V ホストなら、LBFO 前提のまま直そうとしない
Hyper-V ホストで起きているなら、いまの焦点は「LBFO を戻す」ではなく、SET へ寄せるべきか の判断です。現行の Microsoft Learn では、Hyper-V Virtual Switch は LBFO チームにバインドできず、代わりに SET を使う構成が案内されています。一方で、LBFO 自体は Hyper-V 以外の用途では引き続きサポートされています。つまり、問題なのは LBFO 全体ではなく、Hyper-V と組み合わせた前提 です。(Microsoft Learn)
SET を作るときは、Microsoft の例でも New-VMSwitch -EnableEmbeddedTeaming $True を使います。SET を使うなら少なくとも 2 本の NIC を使い、受信分散を最大化したいなら 2 NIC 構成が基本です。(Microsoft Learn)
New-VMSwitch "SETSwitch" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true
作成後の SET チームは Set-VMSwitchTeam で調整できます。現行のドキュメントでは、SET のチーミングモードは SwitchIndependent のみ、負荷分散アルゴリズムは Dynamic と HyperVPort が使えます。クラスターでは、同じ種類のトラフィックに使う NIC は ノード間で同一 NIC・同一ドライバー・同一ファームウェア にそろえ、SET では全ノードで identical が要件です。ドライバー更新後に片ノードだけ動きがおかしくなるなら、ここを最優先で疑ってください。(Microsoft Learn)
役割やサービス側が「消えたように見える」
チームそのものを戻しても、役割側の設定が旧チームを見ていると「また消えた」に見えます。Microsoft には、Windows Server 2016 / 2019 の DNS サーバーで、NIC Teaming アダプターの IP を ListenAddresses に設定していても、再起動後にその設定が削除され、全 IP で待ち受けるように戻る事例が公開されています。原因は、サービス開始時点で team adapter が利用可能になっていないことです。解決策として、DNS Server サービスを Automatic (Delayed Start) に変更する案内があります。(Microsoft Learn)
ドライバー更新後の再起動で「設定が消えた」と感じたら、NIC Teaming 自体だけでなく、DNS・監視・バックアップ・固定バインドされたサービス が旧 interface alias や旧 team IP を見ていないかを一緒に点検してください。DNS の事例は公式に文書化されていますし、ほかの役割でも同じ発想で切り分けると早いです。(Microsoft Learn)
やってはいけないこと
hidden NIC を見つけてすぐ全部消す
Get-NetAdapter は既定で visible だけを返します。まず -IncludeHidden で全体像を出してから、いま使っている NIC と ghost NIC を区別してください。Microsoft も ghost NIC クリーンアップでは hidden devices の確認を案内していますが、削除前の見極めを飛ばすと現用 NIC まで巻き込みます。(Microsoft Learn)
LACP チームを確認せずに SwitchIndependent で作り直す
LACP と Static はスイッチ側設定が必要で、SwitchIndependent は不要です。更新前の方式を把握しないまま作り直すと、リンクアップしても通信が不安定になります。(Microsoft Learn)
チームを残したままドライバーをロールバックする
Intel の資料では、アダプターチームや PROSet が存在する状態では Windows Server の Roll Back Driver が正しく動かないと案内されています。ロールバックが必要なら、チーム解除まで含めて計画してください。(Intel)
権限不足のまま復旧を続ける
New-NetLbfoTeam、Remove-NetLbfoTeam、Set-NetLbfoTeamMember はいずれも管理者権限が必要です。更新後に「見えるのに変更できない」「追加だけ失敗する」ときは、構成不良の前に権限を疑ったほうが早いです。(Microsoft Learn)
再発を防ぐ更新手順
本番環境では、Microsoft は 最新の署名済み OEM/IHV ドライバー を使うよう案内しています。ベンダー機では汎用ドライバーで機能やカスタマイズが変わることがあるため、OEM パッケージを優先してください。クラスターでは、同じ用途の NIC はノード間で NIC・ドライバー・ファームウェアをそろえるのが基本です。(Microsoft Learn)
更新前には、最低でも次の情報を残しておくと復旧がかなり楽になります。更新後に差分を見比べれば、単なる表示消失か、メンバー外れか、詳細設定リセットかを判断しやすくなります。(Microsoft Learn)
Get-NetAdapter -Name * -IncludeHidden | Format-Table -View Driver
Get-NetLbfoTeam | Format-List *
Get-NetLbfoTeamMember | Format-Table *
Get-NetAdapterAdvancedProperty -Name "*" -AllProperties -IncludeHidden
新規構築や更改のタイミングなら、Hyper-V ホストは最初から SET 前提で設計し、ベンダー独自 UI に依存した運用は減らしたほうが安定します。逆に、Hyper-V を使わない純粋なサーバー用途なら、LBFO はいまも非 Hyper-V シナリオではサポート対象です。用途に応じて分けて考えるのが正解です。(Microsoft Learn)
迷ったらこの順番で進める
Get-NetAdapter -IncludeHiddenと driver view で、NIC が増えていないか、hidden adapter が残っていないか確認する。(Microsoft Learn)Get-NetLbfoTeamとGet-NetLbfoTeamMemberで、チーム本体とメンバーのどちらが消えたのか切り分ける。(Microsoft Learn)- メンバー外れなら
Add-NetLbfoTeamMember、チーム破損ならRemove-NetLbfoTeam→New-NetLbfoTeamを検討する。ただし元の TeamingMode を崩さない。(Microsoft Learn) - Hyper-V ホストなら、LBFO を戻すより SET へ寄せる判断を優先する。(Microsoft Learn)
- 復旧後は DNS など役割側のバインド設定を確認し、必要なら delayed start など起動順も見直す。(Microsoft Learn)
NIC Teaming設定がドライバー更新後に消えたときは、見た目だけで「設定が飛んだ」と決めつけないことが重要です。まず現状を採取し、再認識・メンバー外れ・ベンダーUI消失・Hyper-V 前提不整合 のどれかを見抜けば、余計な再構築を避けられます。次にやるべきことは、PowerShell で現状を確認し、用途が Hyper-V なのか非 Hyper-V なのかを確定させることです。そこが決まれば、復旧ルートはかなり絞れます。(Microsoft Learn)

コメント