Windows 11でVeeam Backup for Microsoft 365導入が失敗する原因とVeeam.Archiver.Service停止を整理

本記事が扱う事象は、Windows 11の新規環境にVeeam Backup for Microsoft 365（旧称：Veeam Backup for Microsoft Office 365）を導入しようとした際、インストール途中でロールバックが発生し、Veeam.Archiver.Serviceの起動段階で停止するケースです。具体的には、C++ランタイム（Microsoft Visual C++ Runtime）のバージョン判定で一度つまずいた後、MSIのカスタムアクションがNET STARTでサービス起動を試みるものの、「Der Dienst reagiert auf die Kontrollfunktion nicht（サービスが制御機能に応答しない）」が返り、最終的にエラー1603で中断する流れが示されています。 (Veeam Community Forums)

• 事象の発生経緯と環境条件の整理
• MSIログが示す失敗点と「NET HELPMSG 2186」の意味
• Windows 11のサポート範囲と「バージョン差」という論点
• C++ランタイムのバージョン判定が先に崩れる構造
• 切り分けで見るべきログと条件差（表で整理）

事象の発生経緯と環境条件の整理

Windows 11 Proの新規インストール環境に対し、Veeam Backup for Microsoft 365のISO（8.2.0.2202、8.3.0.2201）で導入を試みたところ、まず「より新しいC++ランタイムが入っているためインストールが失敗する」という前段が発生しています。そこで新しいランタイムを削除し、ISO同梱の古いランタイムを導入することで処理が進むものの、しばらく動作した後にインストール全体が中断した、という記述です。 (Veeam Community Forums)

この時点で、OS側の依存コンポーネント判定と、製品側の前提条件が一致していない可能性が中心論点になります。 そのため、単発のエラーというより、(1)依存関係のバージョン整合、(2)サービス起動の成否、(3)OSサポート範囲、の3点を分けて整理する必要があります。なお、対象環境はProxmox上のWindows 11 VMで、導入済みはvirtio系のゲストドライバとエージェント程度とされています。 (Veeam Community Forums)

MSIログが示す失敗点と「NET HELPMSG 2186」の意味

ログ上の分岐点は、MSIがStartArchiverServiceの段階でNET.EXE START "Veeam.Archiver.Service"を実行し、そこでWindowsが「Der Dienst reagiert auf die Kontrollfunktion nicht」を返している点です。併記される「NET HELPMSG 2186」は、Windowsのメッセージ体系では「The service is not responding to the control function（サービスが制御機能に応答しない）」に相当します。 (Veeam Community Forums)

つまり、インストールが失敗した直接要因は“ファイル展開の失敗”ではなく“サービス起動確認が通らなかったこと”です。 その後、WixQuietExec64がエラーを返し、カスタムアクションが1603（致命的エラー）として扱われ、ロールバックに進んだ形になります。 (Veeam Community Forums)

ここで重要なのは、NET STARTが失敗する理由が複数系統に分かれる点です。サービス実行ファイルの起動直後クラッシュ、依存DLL不足、権限やサービスアカウント設定の不整合、起動待ちタイムアウトなどが同じ表面症状になり得ます。そのため、MSIだけで完結せず、イベントログやサービスの実起動ログまで含めた因果関係の確認が実務上の確認点となります。

Windows 11のサポート範囲と「バージョン差」という論点

Veeamのシステム要件では、Veeam Backup for Microsoft 365がサポートするWindows 11は22H2と23H2として明記されています。 (Veeam Software) 一方で、フォーラム側の返信でも「8.3はWindows 11を23H2までサポートするため、Windows 11のバージョン確認が必要」という趣旨が示されています。 (Veeam Community Forums)

OSのメジャー更新（例：24H2以降）が混在すると、前提としているランタイムやサービス制御の挙動が変わり、同一のインストーラでも結果が分岐し得ます。 特に本製品は.NET 8系コンポーネントを前提にしており、必要ランタイム範囲（例：ASP.NET Core Runtime 8.0.10–8.0.xx など）も要件として提示されています。 (Veeam Software)

以上を踏まえると、「Windows 11である」だけでは条件が足りず、「どのWindows 11ビルドか」が成否を左右する整理になります。また、製品ビルド自体も8.2.0.2202（2025-11-06系）と8.3.0.2201（2025-12-18系）で更新差があるため、同じ症状でも再現条件が一致しない可能性が残ります。 (Veeam Software)

C++ランタイムのバージョン判定が先に崩れる構造

本記事の対象となる事象では、インストール開始時点で「新しいC++ Runtime librariesが入っているため失敗する」という挙動が先に出ています。 (Veeam Community Forums) ここは一般に、(1)同梱再頒布パッケージの検出ロジックが“特定ビルド一致”を前提にしている、(2)OS側に入っている再頒布パッケージが想定外の系列で、上書きや修復が通らない、といった構造に整理されます。

依存関係の判定が厳格な場合、実行環境としては“新しい”構成でも、インストーラの条件式では“不適合”として扱われます。 そのため、ランタイムを入れ替えて進行したとしても、次段のサービス起動で別の不整合が露出する、という連鎖が成立します。なお、8.3のリリース情報では.NETコンポーネントの更新（8.0.21）が記載されており、Windwos側の.NET状況と整合しない場合に差が出る余地も残ります。 (Veeam Software)

一方で、ランタイム入れ替え自体が環境の状態を変えるため、インストール失敗が「どの時点の状態」で起きたかが追跡しにくくなります。つまり、C++ランタイム問題とサービス起動問題は別系統として切り分け、再現条件を固定した上でログを並べる必要がある、という整理になります。

切り分けで見るべきログと条件差（表で整理）

サービス起動失敗は、ディスク性能や起動遅延など“タイムアウト系”でも起こり得るため、イベントログ側の7000/7009系（サービス起動失敗）や関連サービス未起動が確認点になります。Veeam側の別フォーラムでも、サービスが止まったまま残る状況が「遅いブートディスクや劣化したRAID」などで起こり得る、という整理が提示されています。 (Veeam Community Forums) さらに、MSI 1603は「致命的エラー」の総称であり、個別原因はログから別途抽出する扱いです。 (Microsoft Learn)

要点を整理すると、MSIは“最後に失敗した場所”を示すにとどまり、根因はWindowsサービス起動の失敗側に残ります。 そのため、実務上は「どの層で失敗しているか」を表で固定し、同じ観測点を取る運用が多いです。たとえば次のように整理されます。

ただし、サービス起動失敗の原因が「依存DLL不足」なのか「即時クラッシュ」なのかで、必要ログが変わります。そこで、ログ採取箇所も事前に固定されることが多いです。

この結果、(1)Windows 11の版数が要件範囲内か、(2)依存ランタイムの整合が取れているか、(3)仮想基盤側の起動遅延が混入していないか、という順に論点を戻して整理する構造になります。なお、今回のログではサービスアカウントがLocalSystemとして構成される挙動も見えるため、権限というより「起動後に応答できない」側の確認が中心になります。 (Veeam Community Forums)