Windows ServerでUniFi Networkのサービス再インストールが失敗する原因と解決策：JavaエラーでもGUIは動くのにサービスだけ止まるときの対処

UniFi Network Application を Windows Server 上で運用していると、ある日突然「Web GUI に入れない」「Windowsサービスが停止している」という状態に遭遇することがあります。手動で java -jar ... で起動すると動くのに、サービスの再インストール（uninstall/install）が Java エラーっぽいログを吐いて失敗する――このパターンは、アプリ本体の故障というより “サービスとして動かすための土台” が崩れているケースが多いです。

• Windows ServerでUniFi Networkのサービス再インストールが失敗する原因と解決策：JavaエラーでもGUIは動くのにサービスだけ止まるときの対処
  • まず状況を切り分ける：アプリは正常、サービス機構が壊れている可能性が高い
  • よくある原因1：サービスが参照するJavaが“手動起動時”と違う
    • 対処：サービスに「絶対パスのJava」を使わせる
  • よくある原因2：サービス実行ユーザーの権限不足で停止する
    • 対処：サービスのログオンユーザーを見直す
  • よくある原因3：サービス登録の残骸（削除しきれていない）で再インストールが失敗する
    • 対処：いったんサービスを“完全に消す”
  • よくある原因4：複数Javaの混在（JDK/JRE、旧版、別ディレクトリ）が引き金
    • 対処：Javaの参照先を一本化するチェックリスト
  • 実務的に効く“復旧の型”：安全な順番で直す

まず状況を切り分ける：アプリは正常、サービス機構が壊れている可能性が高い

手動起動で UniFi Network Server（UniFi Network Application）が動作するなら、DBやアプリ本体が致命的に壊れている確率は下がります。問題の中心は次のどれかに寄りやすいです。

• サービス登録情報（実行パス、引数、作業ディレクトリ）の不整合

• Java の参照先（PATH / JAVA_HOME / 実行ファイルの場所）のズレ

• サービス実行ユーザーの権限不足（ファイル・ログ・データディレクトリへのアクセス不可）

• 旧バージョンのサービス設定が残骸として残っている

• 32/64bit不整合や、複数JREが混在している

ログに出てくる logback の初期化メッセージは 必ずしも異常ではなく、起動時に出る通常ログ であることも多いので、「Javaエラーが見える＝Javaが壊れている」と決め打ちしないのがコツです。

よくある原因1：サービスが参照するJavaが“手動起動時”と違う

手動で java -jar lib\ace.jar ... を実行するときは、そのコンソール環境の PATH や JAVA_HOME が使われます。一方、Windowsサービスは別の環境で起動するため、

• サービス側は古い Java を掴んでいる

• PATH が通っておらず java が見つからない/別物になる

• 期待する場所に JRE がない

といったズレが起きます。

対処：サービスに「絶対パスのJava」を使わせる

サービス登録時に java ではなく、たとえば以下のように 実体の java.exe のフルパス を指定するのが安定策です。

• 例：C:\Program Files\Eclipse Adoptium\jre-21...\bin\java.exe

さらに、作業ディレクトリ（Working Directory）が UniFi のインストールフォルダになっているかも重要です。作業ディレクトリがずれると lib\ace.jar や設定ファイル参照が崩れます。

よくある原因2：サービス実行ユーザーの権限不足で停止する

「手動では動くのにサービスだと止まる」原因の定番がこれです。サービスは LocalSystem や特定ユーザーで動くため、次の権限がないと起動直後に落ちます。

• UniFi のデータディレクトリ（例：data 配下）への読み書き

• ログ出力先への書き込み

• Java 実行ファイルや UniFi 配下への読み取り

• 必要ポート（8080/8443 等）を掴む権限・競合

対処：サービスのログオンユーザーを見直す

1. services.msc を開く

2. UniFi のサービスを開く

3. 「ログオン」タブで実行アカウントを確認

4. UniFi インストールフォルダとデータフォルダに必要なアクセス権を付与

運用上は「専用のサービスアカウント」を作り、UniFi関連フォルダへの権限を明示しておくとトラブルが減ります。

よくある原因3：サービス登録の残骸（削除しきれていない）で再インストールが失敗する

uninstallsvc を叩いても、サービス定義が残っていたり、別名で残っていたりすると再インストールがこけます。特にバージョン更新や移行を何度かやっている環境で起きがちです。

対処：いったんサービスを“完全に消す”

• サービス名を確認して停止

• サービスが残っているなら削除（管理者権限のコマンドで）

• UniFi 側の「サービス関連ファイル」が中途半端に残っていないか確認

その上で、管理者権限のプロンプトでインストール系のコマンドを実行します。**再インストールスクリプトは必ず「管理者として実行」**が前提です。

よくある原因4：複数Javaの混在（JDK/JRE、旧版、別ディレクトリ）が引き金

Windows Server では「以前入れたJava」「別アプリ用のJava」「アップデート後のJava」が混在しやすく、結果としてサービスが想定外の Java を拾います。

対処：Javaの参照先を一本化するチェックリスト

• where java でどの java が優先されているか

• java -version が期待どおりか（手動起動・管理者起動の両方で）

• 環境変数 JAVA_HOME と PATH の整合

• サービス設定に絶対パスを入れて固定できているか

「Adoptium の公式JREを入れ直したのに直らない」場合でも、サービスが別の java.exe を掴んでいると症状が残ります。

実務的に効く“復旧の型”：安全な順番で直す

最後に、現場で復旧率が高い手順を「安全な順番」でまとめます。

1. アプリが動くことを確認（手動起動でWeb GUIが上がるならOK）

2. UniFi サービスを停止（残っているなら）

3. サービス登録を完全に削除（残骸がない状態にする）

4. Java を一本化（where java / java -version / 可能ならサービスは絶対パス）

5. 管理者権限でサービス再インストール（スクリプトや uninstallsvc/installsvc を管理者で）

6. サービス実行ユーザーと権限を調整（フォルダ権限・ログオン設定）

7. 起動後にログ確認（起動直後に落ちるなら権限・パス・作業ディレクトリが濃厚）

この手の障害は「Javaそのもの」より、“サービスが見る世界”と“手動起動が見る世界”の差が原因であることがほとんどです。手動で動くのは強い手がかりなので、サービス側の Java の参照先・作業ディレクトリ・権限を順番に潰すと、再発もしにくい安定構成に持っていけます。