Windows Server 2022 ドメインコントローラーでIntel Serial IO（ACPI\INTC1085）ドライバー不一致を解決する手順

Windows Server 2022へアップグレードした同一ハードのドメインコントローラーで、片方だけ「ACPI\INTC1085（Intel Serial IO）」が不明なデバイスとして残る——そんな“ズレ”は意外と起こります。本記事ではDriverStoreが同期されない理由と、PDC側へ安全にドライバーを導入する手順、権限やポリシーで詰まったときの対処をまとめます。

今回の事象（症状）

約40台の端末が参加するActive Directoryドメインに、まったく同一構成のWindows Server 2022 Standard ドメインコントローラー（DC）が2台ある環境で、Intel Serial IO 関連デバイスのドライバーがDC間で不一致になったケースです。

項目	非PDC側DC	PDC側DC
OS	Windows Server 2022 Standard	Windows Server 2022 Standard
ハードウェア	同一マザーボード／同一構成	同一マザーボード／同一構成
デバイスマネージャー	不明なデバイス: ACPI\INTC1085 が残る	同様に残る／ただし導入手段が見つからない
ドライバーストア	INTC系（Serial IO/GPIO）ドライバーが存在	INTC系ドライバーが見当たらない
手動更新の結果	一覧から Intel Serial IO GPIO Host Controller – INTC1084 を選択して即導入できた	同じ一覧に出ない／そもそも候補が無い

見た目は「同じ機械なのに、片方だけドライバーが無い」という不思議な現象ですが、結論から言うとドライバーストア（DriverStore）はDC間で複製されないため、差が出ても不思議ではありません。そして、差が出る典型パターンを押さえると、再現性のある手順で揃えられます。

なぜ同一構成でもDriverStoreの中身が違うのか

ADの複製対象は「OSの部品」ではない

ドメインコントローラー同士で複製されるのはActive Directoryのデータベース（NTDS）やSYSVOL等であり、C:\Windows\System32\DriverStore 配下のドライバーは各サーバーのローカル資産として独立しています。
そのため、2台のDCが同じドメインに所属していても「インストール済みドライバーが一致する保証」はありません。

ドライバーは“入手経路”と“導入タイミング”で差が出る

DriverStoreの差は、たいてい「どこから、いつ入ったか」が原因です。Intel Serial IO のようなチップセット系ドライバーは特に、Windows Update（オプションのドライバー更新）やベンダーインストーラーの挙動で結果が変わります。

ズレが起きる要因	具体例	現場での確認ポイント
Windows Updateの差	片方だけ「オプションの更新プログラム」でSerial IOドライバーが配布された	更新履歴／WSUS配信方針／ドライバー配布の有無
ベンダーインストーラーの差	「OS判定」で片方はインストールされ、片方はスキップされた（Server OSを弾く等）	実行したインストーラーのログ／導入順序
アップグレードの差	Server 2022へのアップグレード時に片方は成功、片方は一部失敗してドライバー登録が欠けた	セットアップログ／デバイスインストール関連ログ
グループポリシーの差	「Windows Updateでドライバーを含めない」「デバイスのインストール制限」などが効いている	Default Domain Controllers Policy／ローカルGPO
クリーンアップの差	メンテナンス処理で古いドライバーやキャッシュが整理された	タスクスケジューラ／メンテナンス設定／実行履歴

PDCだからドライバーが変わるのか？

「PDC（PDCエミュレーター役割）だからDriverStoreが違う」という直接の仕様はありません。ただし、運用上PDC側が“より守られている”ことはよくあります。

• 更新を慎重にする（オプション更新を入れない、検証後に適用する）
• GPOでデバイス導入を厳しめにしている
• 保守作業が少なく、結果的にドライバーが入る機会が少ない

つまり「PDCだから」ではなく、“PDCとして扱っているがゆえの運用差”が原因になりやすい、という捉え方が現実的です。

導入前にやるべき確認（原因切り分けの最短ルート）

不明なデバイスのハードウェアIDを確定する

まずは対象が本当にIntel Serial IO（GPIO/Host Controller）なのか、ハードウェアIDで確定させます。

• デバイスマネージャー → 不明なデバイス → プロパティ → 詳細 → ハードウェアID
• ACPI\INTC1085（または INTC1084）が見えることを確認

DriverStoreに該当パッケージがあるか（PnPUtilで確認）

GUIで見つからない場合でも、pnputil でドライバーストア登録の有無を確認すると判断が早いです。管理者権限のコマンドプロンプトで実行します。

pnputil /enum-drivers

一覧が多い場合は、いったんテキストに落としてから“狙って”検索します。

pnputil /enum-drivers > C:\Temp\drivers.txt
findstr /i /c:"INTC1084" /c:"INTC1085" /c:"Serial IO" /c:"GPIO" C:\Temp\drivers.txt

ここで重要なのは、Published Name（例：oem42.inf）を控えることです。後で削除・再導入をする場合も、この名前が軸になります。

セットアップログで「なぜ入らないか」を見る（意外と効く）

ドライバーの導入失敗は、デバイスマネージャーだけ見ていると原因が分かりません。次のログに INTC1085 を含む行が残ることが多いので、エラーコード（アクセス拒否、署名、互換性など）を確認すると切り分けが早くなります。

• C:\Windows\inf\setupapi.dev.log（デバイスインストールの詳細ログ）
• イベントビューアー：Microsoft → Windows → DeviceSetupManager

解決策（推奨順）：PDC側へIntel Serial IOドライバーを導入する

最も安全で再現性が高い：PnPUtilで「エクスポート→追加→インストール」

DriverStoreを直接いじるより、Windows標準の仕組みでドライバーパッケージを移す方が安全です。まず、正常に認識できている非PDC側DCで、該当ドライバーをエクスポートします。

非PDC側DC（エクスポート）

mkdir C:\Temp\DriverExport
pnputil /export-driver * C:\Temp\DriverExport

エクスポート先に多数のフォルダーができます。Intel Serial IO関連を探すコツは次の通りです。

• フォルダー内の .inf をメモ帳で開き、INTC1084 / INTC1085 を検索する
• デバイスマネージャー → 対象デバイス → ドライバー詳細 で、使用中のINF名（oemXX.inf 等）を控えて突き合わせる

PDC側DC（追加＆インストール）

エクスポートしたフォルダー一式をUSBや共有でPDCへ持ち込み、管理者権限で次を実行します。

pnputil /add-driver C:\Temp\DriverExport\*.inf /subdirs /install

最後にデバイスマネージャーで対象デバイスが「Intel Serial IO GPIO Host Controller」等に変わること、イベントログ（DeviceSetupManager）にエラーが残らないことを確認します。再起動が必要な場合もあるため、DCではメンテナンス時間帯に実施してください。

実例：動作しているDCから“同じフォルダー”を持ってきて導入する（コピー方式）

質問者の環境では、非PDC側のDriverStoreにあるIntel Serial IOドライバーのフォルダー（例：serialio_inf_xxxxx）を特定してPDC側へ持ち込み、そこから導入することで解決できました。

ポイント：コピー先はDriverStore直下である必要はありません

WindowsはINFからのインストール時に必要ファイルをDriverStoreへ取り込みます。つまり、フォルダーをそのまま C:\Temp 等へ置き、そこを指定して導入できることが多く、TrustedInstaller保護領域への直接コピーを避けられます。

1. 非PDC側DCで、デバイスマネージャー → 対象デバイス → ドライバーの詳細 から、参照されている .inf の場所を確認します。
   例：C:\Windows\System32\DriverStore\FileRepository\serialio_inf_xxxxx\xxxx.inf
2. 上記の serialio_inf_xxxxx フォルダーを、PDC側の C:\Temp\serialio_pkg などへコピーします。
3. PDC側で不明なデバイス（ACPI\INTC1085）を右クリック → ドライバーの更新 → 「コンピューターを参照してドライバーを検索」で C:\Temp\serialio_pkg を指定します。

もし「どうしてもDriverStore配下に置かないと候補に出ない」「コピーが途中で失敗する」といった場合は、権限・ポリシーが絡んでいる可能性が高いので、次章の対処を先に確認してください。

ベンダーサイト／Windows Updateから入手して導入する

同一機種のDCが複数あるなら、長期運用を考えると「正規の配布元から再取得できる状態」を作っておくのが理想です。

ベンダーサイト（マザーボード／サーバー機器メーカー）

• 機器型番（サーバー型番、マザーボード型番）を確認する
• ベンダーのサポートページで Intel Serial IO / GPIO Host Controller を含むチップセット系ドライバーを入手する
• ZIP/EXEを展開し、INFが見える状態にしてから「参照して検索」または pnputil で追加する

Windows Update（オプションのドライバー更新）

• Windows Updateを手動実行し、オプションの更新プログラム → ドライバー更新 を確認する
• 組織で「品質更新にドライバーを含めない」設定やWSUS配信を使っている場合は、ここに出てこないことがある

導入方法の比較（どれを選ぶべきか）

方法	メリット	デメリット／注意点	おすすめ度
PnPUtil（export→add/install）	標準機能で安全、再現性が高い、DriverStoreの整合性を壊しにくい	エクスポート量が多く、対象INFの特定にひと工夫必要	★★★★★
DISM /Add-Driver	オンラインイメージへ直接追加でき、スクリプト化しやすい	INFの指定ミスで別ドライバーを入れやすい／強制オプションの使い方に注意	★★★★☆
フォルダーコピー＋デバイスマネージャー指定	同一環境から“完全に同じパッケージ”を持っていきやすい	フォルダー特定を誤ると別物を入れてしまう。ログ確認が大事	★★★☆☆
DriverStore配下へ直接コピー	状況によっては最短で解決する	TrustedInstaller保護・ACL変更が絡みやすい。基本は最後の手段	★★☆☆☆

権限で詰まる理由と、必要な権限の整理

DCでの「管理者」はローカル管理者ではなくドメイン側の権限

ドメインコントローラーはローカルSAMを持たないため、いわゆる「ローカル管理者」運用がやりにくいのが特徴です。一般に次のいずれかの権限が前提になります。

• Domain Admins：DC上で管理者権限を持つ典型
• Enterprise Admins：フォレスト全体の管理（複数ドメインの場合）

DriverStoreの所有者はTrustedInstaller

C:\Windows\System32\DriverStore は保護領域で、所有者はTrustedInstallerです。Domain Adminであっても、エクスプローラーでのコピーや上書きが失敗することがあります。ここで重要なのは、次の考え方です。

• 基本方針：DriverStoreを直接書き換えない（PnPUtil/DISM等の正規手段を使う）
• どうしても直接コピーが必要なときだけ、一時的に権限を確保する

必要な権限の目安（作業別）

作業	必要な権限の目安	補足
デバイスマネージャーで「ドライバーの更新」	管理者権限（Builtin\Administrators相当）	GPOでインストール制限があると失敗する
pnputil /add-driver / dism /Add-Driver	管理者権限	実行は「管理者として実行」した端末で行う
GPO（デバイス導入制限）を変更	Domain Admins（またはGPO編集権限）	変更は影響範囲が大きいので“最小・一時”を徹底

SYSTEM権限で実行して回避する（どうしても通らないとき）

署名やGPO以外の理由で「管理者でも導入が通らない」場合、SYSTEM権限でデバイスマネージャーやPnPUtilを実行すると通ることがあります。代表例として、Microsoft SysinternalsのPsExecを使う方法が知られています。

psexec -s -i cmd.exe
# 開いたSYSTEMのコマンドプロンプトから
devmgmt.msc

※SYSTEM実行は強力です。用途をドライバー導入に限定し、作業後は必ず閉じてください。

グループポリシー（デバイスのインストール制限）を疑うポイント

「候補があるのに入らない」「署名が有効でも弾かれる」場合は、GPOのデバイス導入制限が効いていることがあります。特にDCでは、Default Domain Controllers Policyで制限されているケースが多いです。

ポリシーの場所	設定名（例）	影響
コンピューターの構成 → 管理用テンプレート → システム → デバイスのインストール → デバイスのインストールの制限	管理者がデバイスのインストール ポリシーを上書きできるようにする	管理者による導入を許可しやすくする
同上	他のポリシー設定で記述されていないデバイスのインストールを禁止する	ホワイトリスト運用だと新規デバイスが入らない
同上	これらのデバイス セットアップ クラスのインストールを禁止する	クラス単位で導入をブロック

GPOを一時的に緩める場合は、影響範囲がDC全体に及ぶ点に注意し、作業後に元へ戻す運用を前提にしてください。反映確認は以下が便利です。

gpupdate /force
gpresult /r

システム整合性のチェック（インストールが失敗する／ストア不整合の疑い）

アップグレード直後やコンポーネント不整合が疑われる場合、次の手順でWindowsイメージの健全性を確認してから再トライすると成功率が上がります。

DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

導入後の確認チェックリスト（“直ったつもり”を防ぐ）

• デバイスマネージャーで ACPI\INTC1085 が消え、Intel Serial IO系として認識されている
• pnputil /enum-drivers でSerial IO/GPIO関連パッケージが登録されている
• C:\Windows\inf\setupapi.dev.log にエラーが残らない
• 再起動後も状態が維持される（ドライバーがロールバックしていない）

再発防止：DC間でドライバー差分を作らない運用のコツ

今回のような「片方だけ入っている／片方だけ無い」を減らすには、仕組みを押さえて“揃える運用”に寄せるのが効果的です。

DCは「OS更新」と「ドライバー更新」を同じルールで回す

• Windows Update直当て／WSUS／ベンダーツールのどれで配布するかを決め、DC間で統一する
• オプションドライバー更新を許可するか、禁止するかを明文化する（中途半端が一番ズレる）

ドライバーの棚卸しを定期的に取る

月次でも四半期でもよいので、DCごとにドライバー一覧を保存しておくと、差分の発見が一気に楽になります。

pnputil /enum-drivers > C:\Temp\drivers_<server>.txt

差分が出たら「いつ入ったのか」を追えるため、Windows Updateやベンダー導入のどちらが原因かも特定しやすくなります。

“直接コピー”は最後の手段にして、標準コマンドを主役にする

DriverStore配下の手動コピーは、うまくいくこともありますが、ACL変更の副作用や将来の更新での不整合を招きやすい方法です。今回のようなIntel Serial IO（INTC1084/INTC1085）の導入でも、まずは pnputil か dism を優先し、どうしても無理な場合にのみコピーを検討する、という順番が安全です。

まとめ

• ドメインコントローラー間で複製されるのはADデータであり、DriverStoreは同期されないため、同一構成でもドライバー差は起こり得ます。
• PDC側にIntel Serial IO GPIO Host Controller（INTC1084/INTC1085）を入れるなら、まずはPnPUtilでエクスポート→追加→インストールが安全で確実です。
• 権限やGPOが邪魔をすることがあるため、管理者権限・TrustedInstaller保護・デバイス導入ポリシーの3点をセットで確認すると最短で解決できます。