ApexOneリプレースで結構困った備忘録

はじめに

ApexOneのリプレース作業に少し入らせてもらい、ちょっと困った点がいくつかあったので残しておく。
本当にいらないところで結構時間を取られてしまった。

サーバーの認証証明書のパスワードがわからない

新規構築なら全然気にする必要はないが、リプレースになると話は別。
移行先のサーバーを証明するものが何もないため、移行後にエージェントがサーバーを認証できない。

保存場所はトレンドマイクロが手順にしてくれているため割愛するが、
パスワードが分からない場合は、旧サーバーで再発行できるとのこと。
今回はパスワードあったからよかったけど、なかったら面倒だった。
あとは新規で作ってADグループポリシーでルート証明書の配布でもいいっぽい。

旧サーバーにSSMSが入ってない

データベースの移行が必要だが、旧サーバーにSSMSが入っていなかった。
じゃあ入れてバックアップ取るか、と思ったら、.NET4.7.2が入っていないためにインストール不可。
4.6以上ならOKと出てきたくせに、結局4.7.2を入れるまで動いてくれなかった。

Webコンソールの挙動がおかしい

ログインして画面動かしたと思ったら、「ApexOne Masterが停止しました」と表示される。
ちょっとタブ動かしたら、「タイムアウトしました」と出る。
今回はバージョン11564で新規インストールだったが、どうやらバージョンのバグらしく、パッチの14081を適用したら改善した。
以下はイベントログで出たエラーをGeminiに相談した回答。

Libcmdhndlrconsolev2.dllが原因で発生するイベント ID 1000（アプリケーションクラッシュ）は、Apex One環境で発生することが知られている問題です。このモジュールは、主にサーバー側のプロセスがWebコンソールやエージェントからのコマンド/リクエストを処理する際に使用されます。この障害は、DB移行後の設定や権限の問題、あるいはモジュール自体の破損やバグによって引き起こされている可能性が高く、特定の**Critical Patch（CP）**を適用することで解決するケースが報告されています。このモジュール障害は、メインのサーバープロセスである ofcservice.exe のクラッシュとして現れることが多く、イベントログに障害モジュールとして $\text{Libcmdhndlrconsolev2.dll}$ が記録されます。

1. サービスの再起動と基本的な健全性チェックまず、基本的な手順としてサービスの再起動と、モジュールの破損がないかを確認します。サービスの再起動:Windowsのサービス管理画面から、Trend Micro Apex One Master Service、Trend Micro Apex One Control Manager、および関連するすべてのApex Oneサービスを停止し、再起動してください。ファイルサイズの確認:$\text{Libcmdhndlrconsolev2.dll}$ が存在するパス（通常は C:\Program Files (x86)\Trend Micro\Apex One\PCCSRV\web\service\ など）に移動し、ファイルのサイズやタイムスタンプが他のモジュールと比べて異常でないか確認します。イベントログの詳細確認:クラッシュを示すイベント ID 1000 のエラーログに、例外コード $\text{0xc0000005}$（アクセス違反）など、具体的な例外コードやオフセットが記載されていないか、再度確認してください。この情報は、原因特定に役立ちます。
2. DB移行後の設定と権限の再確認（最重要）移行後の設定不備や権限不足が、DB処理を行う $\text{Libcmdhndlrconsolev2.dll}$ のクラッシュを引き起こす可能性が高いです。DB接続設定の再確認:新しいDBサーバーへの接続文字列、ユーザー名、パスワードが、Apex Oneの設定ファイル（例: ofcscan.ini）内で正確に移行先のものに更新されているか、ダブルチェックしてください。権限の確認:Apex Oneのサービス（ofcservice.exe など）を実行しているアカウント（通常はLocal Systemまたはサービスアカウント）が、**新しいDBサーバーのApex Oneデータベースに対して十分なアクセス権限（SELECT, INSERT, UPDATE, DELETEなど）**を持っているか確認してください。権限不足の場合、DBアクセス時にモジュールがクラッシュすることがあります。
3. Critical Patch (CP) の適用この種のモジュールクラッシュは、特定の環境や操作で発生する製品側のバグであることが多く、トレンドマイクロから提供されている**Critical Patch（CP）**を適用することで解消するケースがほとんどです。最新のCPの確認:現在使用しているApex Oneのバージョンとビルド番号（例: Apex One 2019 SP1 Build 12534など）を確認し、そのバージョンに対してリリースされている最新のCritical PatchのReadmeファイルを参照してください。最新のCPの修正内容に、「$\text{ofcservice.exe}$ がクラッシュする問題」や「$\text{Libcmdhndlrconsolev2.dll}$ に関する問題」が含まれていないか確認し、含まれている場合はそのCPを適用してください。
   💡 過去の報告例: 以前、特定のビルド（例: Apex One Service Pack 1 Build 12534）において、$\text{Libcmdhndlrconsolev2.dll}$ が原因で ofcservice.exe がクラッシュする問題が報告され、後のCritical Patchで修正されています。最新のCPを適用することで、モジュール自体が修正され、クラッシュが解消される可能性が最も高いです。

ちなみに、旧サーバーは11564で問題なく動いていた。その違いは一体。

インストール時の設定でどれを入れていいかわからない

旧サーバーのインストール時とは手順が一部違ったらしく、
どれを入れて、どれを入れないのかが分かりにくかった。
サービスの状態とか、Webコンソール内の設定を見ながらやったが、
実際完了した後に確認すると一部異なる部分があったらしい。

Smart Protectionとかは後からでも入れられるため、データベースとかの設定だけちゃんとしていれば何とかなりそう。

エージェントの接続先サーバー切り替え時の挙動が不安

旧サーバーから「エージェントの移動」を使って、新サーバーへの移行を行ったが、
「危険な状態」→「参照先変更」→消える→エージェント画面出てくる
みたいなのを3周ぐらいしていて、ちょっと怖かった。

ちなみに、今回は1台ずつ様子見ながら移行していたが、
他の1台を移行するたびに先ほどの状態にすべての端末がなっているように見えた。

エージェント移行すると、旧サーバーからは削除され、新サーバーのみでオンラインになる。

データベース移行したとて完了ではない

データベースの移行が完了すると、端末の一覧は表示されるが、
あくまでガワだけができている状態。
参照先も変わっていないし、一覧が出ているだけなので注意が必要。
そのあとにエージェント移行が必要。

まとめ

運用はしていたが構築はまた別の難しさがあった。
設定移行したのに移行できていなかったり、結局そのあたりは目で確認しないといけない…。
基本的にはトレンドマイクロの出している手順で行けます！！！（データベースは先に移行するのをおすすめ）