# LBFO のチーミング アダプターが起動失敗するナゾ、まさかの原因が判明したよ！

こんにちは、しぃちゃんだよ！今日は Windows Server の LBFO チーミングにまつわる、ちょっとレアだけど地味に困る不具合のお話だよ。原因が分かるとスッキリするから、みんなも一緒に見ていこうね。

## なにが発表されたの？

これは JP Windows Support(日本マイクロソフト Windows プラットフォーム サポート)のブログで説明された事象だよ。OS 起動時に、LBFO(Load Balancing Failover)のメンバー NIC はちゃんとリンクアップしているのに、チーミング アダプター自体の初期化が失敗して起動できないことが稀にあるんだって。

こうなると「ネットワーク接続」画面ではチーミング アダプターが「無効」と表示されて、そこから有効化しても「無効」状態から復旧しないの。`Get-NetAdapter` で確認すると、メンバー NIC は Up 状態でリンク速度も出ているのに、チーミング アダプターだけ Status が Not Present、LinkSpeed が 0 bps になっちゃうんだよ。

## なぜ重要なの？

LBFO は Windows Server で複数の NIC をまとめて冗長化・負荷分散するための仕組みだから、サーバーのネットワーク接続性を支える大事な機能なの。それが起動のタイミング次第で失敗して、しかも自動では復旧しないとなると、気づかないうちにサーバーがネットワークから孤立しちゃうリスクがあるんだよね。

しかも今回の事象は「稀に」しか起きないタイミング依存の不具合だから、再現性が低くて原因を特定しづらいのが厄介なところ。イベントログの違いを知っておくだけでも、切り分けがぐっと楽になるよ。

## これで何が変わるの？

この記事のおかげで、管理者はこの事象が「ドライバーのロード競合」という明確な原因を持つことを知って、正しい手順で切り分け・復旧できるようになるよ。原因不明のネットワーク障害として長時間悩む必要がなくなるのがうれしいポイントだね。

## 深く潜ってみよう

原因は、OS 起動時に NdisImPlatform ドライバーのロードと、NIC チーミング アダプターのデバイス追加処理が並行して走ることにあるの。ドライバーのロードが完了する前にデバイス追加処理が始まってしまうと、チーミング アダプターの初期化が失敗しちゃうんだって。

この競合はドライバーのロードにかかる時間に依存するタイミング依存の事象で、ブートログを有効にしている環境では発生確率が少し上がるとのことだよ。

イベントログでの見分け方も紹介されているよ。

- 正常時: Microsoft-Windows-MsLbfoEventProvider に「DriverEntry exiting, Status = 0」の後、「Initializing TeamNic」「Member created」「Aggregator created」まで記録される
- 事象発生時: 「DriverEntry exiting, Status = 0」だけが記録されて、それ以降のログが残らない

対処法は 2 段構えだよ。

- 予防策: `msconfig` を起動して「ブート」タブでブートログのチェックを外す(ブートログ有効時は事象が起きやすくなるため)
- 復旧方法: (A) デバイス マネージャーでチーミング アダプターを一度無効化してから再度有効化する、または (B) OS を再起動する

## まとめ

- LBFO のチーミング アダプターが、まれに起動時の競合で「Not Present・0 bps」のまま復旧しなくなる
- 原因は NdisImPlatform ドライバーのロードとデバイス追加処理のタイミング競合
- ブートログを無効化すると発生を抑止でき、発生時は該当アダプターの無効化・有効化か OS の再起動で復旧できる
- イベントログの「Initializing TeamNic」以降が記録されているかどうかで切り分けできる

LBFO チーミングを使っている Windows Server 環境の管理者さんで、原因不明の起動時ネットワーク障害に悩んだことがある人にはきっと役立つ話だよ！