Windows Server 2019でDHIS2のWARが展開されない原因と対処法 XAMPP共存環境のチェックリスト

Windows Server 2019へDHIS2（例：2.40）をリモート導入したところ、WARのデプロイ自体は「成功したように見える」のに、webapps\ROOT配下にフォルダがほとんど生成されず、Catalinaログにも決定的なエラーが出ない──この症状は、Tomcatが「展開に失敗している」のではなく「展開できない条件のまま途中で止まっている」ケースが多いです。XAMPP（Apache運用中）と同居している本番サーバー特有の落とし穴を中心に、深掘りポイントを整理します。

Windows Server 2019でDHIS2のWARが展開されない原因と対処法 XAMPP共存環境のチェックリスト

起きている現象を整理する（切り分けの前提）

WARをwebappsへ置く／Managerからデプロイする
Catalinaログ上は大きなエラーがなく、デプロイ完了っぽい
しかしwebapps\ROOT（またはコンテキスト配下）に生成されるフォルダが極端に少ない
検証用のVirtualBox環境では同じ設定で成功
本番はWindows Server 2019 + XAMPP（Apacheが既存サイトを提供）

この条件だと、アプリ側の設定よりも、サーバー側（権限・プロセス・パス・I/O・セキュリティ）に起因する可能性が高いです。

まず最優先：Tomcatが「どのユーザー権限」で動いているか

WAR展開は、TomcatがZIP（WAR）を解凍してファイルを大量生成する処理です。ここで詰まる典型が以下です。

1) サービスアカウントの権限不足

TomcatがWindowsサービスとして動いている場合、サービスの実行ユーザーがLocalSystemや制限されたユーザーだと、フォルダ生成や一時領域書き込みで失敗しやすいです。失敗がログに出にくいこともあります。

確認ポイント

Tomcatをサービスで起動しているなら「ログオン」ユーザーは誰か
tomcat\temp、tomcat\webapps、tomcat\work、tomcat\logs に書き込み権限があるか
リモートでファイルを配置したユーザーと、Tomcat実行ユーザーが別でないか

対処

Tomcatサービスのログオンユーザーを、十分な権限を持つ専用アカウントに変更
上記フォルダに「フルコントロール（少なくとも変更・書き込み）」を付与
変更後は必ずサービス再起動

次に多い：ウイルス対策・EDRがWAR展開を妨げる

Windows Serverのセキュリティ製品（Defender含む）が、WAR展開時の大量ファイル生成・クラスファイル展開を「怪しい動き」と見てブロック／隔離することがあります。ログがTomcat側に残りにくく、「フォルダが増えない」症状になりがちです。

確認ポイント

セキュリティ製品の隔離ログ／イベントログに該当がないか
webapps配下やtemp/workへのリアルタイムスキャンが有効になっていないか

対処

Tomcatのディレクトリ（webapps, work, temp, logs）を除外設定
一時的に保護を緩めて再デプロイし、挙動が変わるか確認（検証後に戻す）

Tomcatの設定で「展開しない」状態になっていないか

2) `unpackWARs` / `autoDeploy` が無効

conf/server.xmlのHost設定で、WARの自動展開が止まっていると、置いても展開されません。ただし「一部だけできる」症状とはズレることもあるので、念のため確認します。

確認ポイント

<Host ... unpackWARs="true" autoDeploy="true"> になっているか
conf/Catalina/localhost/ にコンテキスト定義を置いていないか（別設定で上書きされる場合あり）

3) 既存ROOTアプリとの競合

XAMPP環境では、既に別のROOTアプリ（またはROOTフォルダ）が存在し、Tomcatが衝突して中途半端な状態になることがあります。

対処の考え方

いきなりROOTにせず、まず dhis.war のように別コンテキストでデプロイして挙動を見る
既存webapps\ROOTを退避し、ROOT.warは慎重に適用する

ログが静かすぎるときに見るべき場所

「catalinaにエラーが出ない」のに展開されないとき、ログの見方が不足しているケースが多いです。

見るべきログ（代表）

logs/catalina.YYYY-MM-DD.log
logs/localhost.YYYY-MM-DD.log（アプリの起動失敗が出やすい）
logs/manager.YYYY-MM-DD.log（Manager経由デプロイの場合）
Windowsの「イベントビューアー」→ アプリケーション（Java/Tomcat起因の例外が出ることがある）

追加で有効な観点

展開途中で止まる場合、workやtempに痕跡が残ることがある
webapps配下に「展開途中のフォルダ」ができては消える、という動きがあれば権限・セキュリティ・I/Oが濃厚

本番サーバー特有：パス長・文字・ネットワーク配置の罠

4) Windowsのパス長制限（Long Path）

WAR展開は深い階層を作るため、インストール先が深いと失敗しやすいです。VirtualBoxでは短いパス、本番では深いパス、という差があると再現が割れます。

対処

Tomcatを C:\Tomcat\ のような短いパスに置く
WARも短いパスへ置いてからデプロイする
グループポリシーでLong Path対応が無効になっていないかも確認

5) リモート配置（ネットワーク経由）によるブロック

リモートでコピーしたファイルに「ブロック」属性が付いたり、共有経由のI/Oが不安定だと、展開に失敗することがあります。

対処

WARを一度ローカルディスクへ置き直す
ファイルのプロパティに「ブロック解除」が出ていれば解除
可能ならManagerの「Upload WAR file to deploy」で直接投入して比較

Javaの整合性：動いているようで実は合っていない

DHIS2はJavaや依存ライブラリ要件の影響を受けます。WARが展開できても、初期化で落ちると「フォルダが増えない／起動しない」に見えることがあります。

確認ポイント

Tomcatが参照しているJavaが想定どおりか（JAVA_HOME、サービスの環境変数）
本番と検証でJDK/JREのメジャーバージョンが一致しているか
32bit Javaが紛れ込んでいないか（メモリ不足・互換性問題の温床）

対処

bin/setenv.bat を用意し、Javaやメモリ設定を明示
-Xms -Xmx を現実的な値に（小さすぎると展開・初期化で失敗しやすい）

「ROOT配下に少しだけできる」症状に効く実践手順

最後に、再現条件を潰しやすい手順をまとめます。順にやると原因が浮きやすいです。

Tomcat停止
webappsから対象WARと展開済みフォルダを削除（ROOTなら特に慎重に退避）
work と temp の中身を削除
セキュリティ製品でTomcatフォルダを除外（可能なら一時検証）
Tomcatを短いパスへ移動（可能なら C:\Tomcat\）
Tomcatを「権限のある専用ユーザー」でサービス起動
まずROOTではなく別名（例：dhis.war）でデプロイ
localhostログとイベントログも含めて確認
問題が解消したらROOT化やApache連携（リバースプロキシ）に進む

Apache（XAMPP）共存時の考え方：役割分担を明確に

XAMPPのApacheが既存サイトを担っているなら、DHIS2はTomcat側で動かし、Apacheはリバースプロキシでつなぐ構成が安定しやすいです。ポート競合やROOT競合を避けられ、切り分けも容易になります。

Apache：80/443で受ける（既存サイトも継続）
Tomcat：8080などでDHIS2を稼働
Apacheから /dhis などへプロキシ（または専用サブドメイン）

まとめ

Windows Server 2019で「WARはデプロイされたように見えるのに展開が進まない」場合、原因はアプリ設定よりも、Tomcat実行ユーザー権限、セキュリティ製品のブロック、パス長・配置場所、ログの見落としに集中しがちです。特に本番サーバーはXAMPPで既存運用がある分、ROOT競合や権限の複雑化が起きやすいので、まずは別コンテキストでのデプロイと、work/temp削除＋権限・除外設定の確認から進めると、最短で原因へ到達できます。