皆様、こんにちは。カスペルスキー製品担当SEの小池です。
以前、KSC11からKSC13.1へのバージョンアップに関する記事 (こちら) を記載致しました。
今回はこの関連で、現行のKSC11を別のサーバーに新築したKSC13.2へリプレースする方法について記載致します。
現行のKSCにおいて、サーバーOSのサポート期限が間近な時などはリプレースが必要になると思いますので、この記事が参考になれば幸いにございます。
今回の内容は以下の通りです。
- 製品バージョン情報
- KSCリプレースの概要
- 検証環境概要
- リプレース手順
製品バージョン情報
今回の記事は以下のバージョンにて検証し、画面ショットを取得しております。
【現行環境 (リプレース元) 】
●管理サーバー
OS：Windows Server 2012R2
DB：Microsof SQL Server 2012 Express (KSCと同居)
Kaspersky Security Center：11.0.0.1131
Kaspersky Security Center Web Console：11.1.144
Kaspersky Endpoint Security for Windows プラグイン：11.7.0.669
●保護対象デバイス
Windows Server 2019
●保護製品
Windows Endpoint Securiy for Windows ：11.7.0.669
●利用ライセンス
任意
【新環境 (リプレース先) 】
●管理サーバー
OS：Windows Server 2019
DB：Microsof SQL Server 2019 Express (KSCと同居)
Kaspersky Security Center：13.2.0.1511
Kaspersky Security Center Web Console：13.2.582
Kaspersky Endpoint Securiy for Windows プラグイン ：11.7.0.669
●保護対象デバイス
Windows Server 2019
●保護製品
Kaspersky Endpoint Securiy for Windows ：11.7.0.669
●利用ライセンス
任意
KSCリプレースの概要
まず最初に申し上げるのは、KSCのリプレースはメーカーとして正式にサポートしています。
具体的にはこちらをご参照ください。
KSCリプレースは主に以下の流れで実行します。
① リプレース先の新環境を構築する。
② リプレース元KSCサーバーにて、バックアップユーティリティを用いてバックアップを取得する。
③ ②で取得したバックアップをリプレース先の新環境でリストアする。
④ リプレース元の環境で管理していた各種デバイスが参照するKSCを、リプレース先の新環境のKSCに変更する。
⑤ (任意) リプレース先の新環境のKSCで、ネットワークエージェントのパッケージが内部的に保持する参照先KSC情報を新環境のKSCに変更する。
⑥ (任意) 古いネットワークエージェントをバージョンアップさせる。
上記①で作成する新環境において、KSCはリプレース元のKSCと同じバージョンである必要はありません。(これは後述しますが、②③で旧バージョンKSCで取得したバックアップを新バージョンKSCにリストア可能であるためです。)
KSCのプラグインはリプレース元KSCとリプレース先KSCで合わせる必要があります。①の時点でリプレース元KSCで使用しているプラグインが判明している場合は、リプレース先KSCにも同じものインストールしてください。
なお、リプレース先KSCへプラグインをインストールするタイミングは、最遅で③が終わった後でも可です。
次に、上記の②③において、リプレース元とリプレース先のKSCはバージョンが異なっていても、リプレース元KSCで取得したバックアップをリプレース先KSCにリストアすることが可能です。
根拠となるのオンラインヘルプはこちらです
上記④は、KSCのタスク "管理サーバーの変更" を用いるか、各端末でコマンド (klmover) を実行するかのどちらかで実現します。
KSCのタスク "管理サーバーの変更" で実施する場合、確実にリプレース元KSCで管理していた全デバイスがリプレース先KSCに移動するまで、リプレース元のKSCを稼働させたままにしてください。
(こちらの "移行作業における注意事項 " 参照。)
なお、KSCのタスク "管理サーバーの変更" と各端末でコマンドを実行する方法は併用も可能です。
デバイス数が多い場合などは、まず大多数のデバイスをKSCのタスクでリプレース先KSCへ移動させ、残っているデバイスはコマンドを実行して手動でリプレース先KSCへ移動させるという方法も可能です。
上記⑤⑥は任意手順としております。
⑤は、②③の作業によってリプレース先KSCにリストアされたリプレース元KSCのネットワークエージェントパッケージの接続先KSCを、リプレース元KSCからリプレース先KSCに変更しております。
ただし、KSCでデバイスを統合管理する場合、基本的にKSCに接続する際に使用するネットワークエージェントはKSCのバージョンに合わせるという暗黙ルールがあります。
ですので、リプレース先KSCにて新しいデバイスを追加する場合は、基本的にはリプレース先KSCのバージョンのネットワークエージェントのパッケージを用いるようにしてください。
⑥は、リプレース先KSC管理下に移動してきた各デバイスのネットワークエージェントをバージョンアップする手順です。
KSCの接続先を変更しただけではネットワークエージェントのバージョンは上がりません。
しかし先述した通り、KSCでデバイスを統合管理する場合、基本的にKSCに接続する際に使用するネットワークエージェントはKSCのバージョンに合わせるという暗黙ルールがありますので、それを守るために⑥を実施してネットワークエージェントのバージョンを上げることをお勧めします。
検証環境概要
まず本記事においてリプレース前の状況は以下の通りとします。
上の図のリプレース前の状況に対し、概要で紹介した作業①～⑦を実施したリプレース後の状態は以下の通りです。
上の図のFQDNを見ていただくとお分かりいただける通り、リプレース元のKSC11とリプレース先のKSC13.2は同じドメインに参加している想定です。
各種ソフトウェアのバージョンについては、本ブログ冒頭の "製品バージョン情報" に記載の通りです。
リプレース手順
ここからは具体的に先述の製品バージョンにおけるリプレース手順を紹介いたします。
ここで紹介いたします手順は全てメーカー記事 (こちら) をベースにしておりますので、併せて参照いただけると幸いです。
この記事におけるリプレース手順は、先述したKSCリプレースの概要の章の作業①～⑦に対応するため、章の名前の冒頭に①～⑦を付与しています。
① リプレース先サーバー (KSC13.2) の準備
まず、リプレース先となるOSに SQL Server Express 2019 Express と KSC13.2 をインストールします。
KSCのインストール手順はオンラインヘルプをご参照いただければと存じます。
Kaspersky Security Center のインストール
KSC用のDBにSQL Server 2019 を利用する場合は、KSC13.2をインストール後に追加作業が必要なので、これを実施します。
https://blogs.networld.co.jp/entry/2021/09/13/093420blogs.networld.co.jp
最後にリプレース元KSC11で使用しているプラグインを、リプレース先KSC13.2にもインストールします。
この①の作業が完了した時点で環境は以下の通りとなっています。
② 現行環境 (KSC11) のバックアップ取得
この章では、リプレース元KSC11でバックアップユーティリティを利用してバックアップを取得します。
リプレース元のKSCサーバーにて、バックアップユーティリティを管理者権限で実行します。
[次へ]をクリックします。
[管理サーバーデータのバックアップを実行] を選択し、[次へ] をクリックします。
デフォルトのまま [次へ] をクリックします。
[はい] をクリックします。
バックアップが取得されるまで待機します。(データが多いとかなり時間がかかることがあります。エラー等のメッセージが出ない限りは気長にお待ちください…。)
[動作が正常に終了しました。] と表示されたら、[次へ] をクリックします。
[完了] をクリックします。
C:\ProgramData\KasperskySC\SC_Backup に以下のようにバックアップが取得できていることを確認します。
このフォルダーごと、丸々リプレース先のKSCサーバーの任意の場所にコピーします。
②の作業はこれで完了です。
この②の作業が完了した時点で環境は以下の通りとなっています。
③ 新環境 (KSC13.2) へ現行環境 (KSC11) のデータリストア
この章では、②の手順でリプレース先の任意の場所にコピーしたリプレース元KSCのバックアップを、リプレース先KSCにリストアします
リプレース先KSCサーバーで、Kasperskyのバックアップユーティリティを管理者権限で実行します。
[次へ] をクリックします。
[管理サーバーデータを復元] を選択し、[次へ] をクリックします。
[参照] をクリックし、先ほどコピーしておいたリプレース元で取得したバックアップフォルダーを指定し、[次へ] をクリックします。
リストアが完了するまで待機します。
[動作が完了しました。] と表示されたら、[次へ] をクリックします。
[完了] をクリックします。
リストアによりサービスが再起動しているので、少なくとも15分ほど放置します。日常を忘れてボーっとしてください。
しばらく放置したら、リプレース先のKSCサーバーのOSを再起動します。
OSの再起動が完了したら、KSCのMMCベース管理コンソールを起動します。
その際、以下の画面が表示された場合は [はい] をクリックします。
リプレース先のKSC13.2で、リストアしたデータの内容をざっと確認します。
なお、先述した通りバックアップデータにはプラグインは含まれていません。
リプレース元のKSCとリプレース先のKSCでインストールしているプラグインに差がある場合、以下のようにポリシーやタスクのアプリケーション名が "不明" となります。
この場合は、リプレース元のKSCでインストールしていたプラグインと同じものを、リプレース先のKSCにもインストールしましょう。
インストールすると↑の画面のようにアプリケーション名が "不明" となっていたものが、↓の画面のように正常に表示されるようになります。
リプレース先KSCでデータがキチンとリストアされたことを確認出来たら、③の作業は完了です。
この③の作業が完了した時点で環境は以下の通りとなっています。
④ 管理対象のデバイスの参照先KSCの変更
この章では、リプレース元KSCで管理していた各種デバイスが参照するKSCをリプレース先KSCに変更します。
変更方法は2つあります。片方もしくは両方を併せて使うことも可能ですので、環境やデバイス台数に合わせて検討してください。
KSCのタスクを利用する場合
ここで紹介するのは、リプレース元KSCで "管理サーバーの変更" タスクを使う方法です。
リプレース元KSCのMMCベースコンソールで、[タスク] を開き、[新規タスク] をクリックします。
KSCのタスクツリーで [詳細] を展開し、[管理サーバーの変更] を選択して[次へ] をクリックします。
暗号化データがある場合、KSCを切り替えると参照できなくなるデータがある旨がメッセージで表示されます。
問題が無ければ [OK] で進めてください。
ちょっとでも不安がある場合はいったんリプレース作業を中止して、メーカーサポートに駆け込んでください。
管理サーバーアドレス欄にリプレース先KSCのFQDN もしくは IPを入力します。
デバイスーリプレース先KSC間にプロキシがある場合は、この画面でそれらの情報も併せて入力します。
[次へ] をクリックします。
タスクを割り当てるデバイスの選択方法は任意に選択してください。
この手順では例として一番上の [ネットワークの管理サーバーによって検出されたデバイスを検出する] で進めます。
タスクを割り当てたいデバイスやグループにチェックを入れ、[次へ] をクリックします。
デフォルトの設定のまま、[次へ] をクリックします。
ここもデフォルトの設定のまま [次へ] をクリックします。
タスク名を任意に設定し、[次へ] をクリックします。
[ウィザード完了後にタスクを実行する] を任意に設定します。今回はチェックありで進めます。
[完了] をクリックします。
タスク一覧画面に自動遷移します。
先ほど作成した管理サーバーの変更タスクが完了するまで待機します。
リプレース先KSCサーバーでMMCベースのコンソールを起動し、デバイスの移動状況を確認します。
以上で、④の実現方法1つ目である、リプレース元KSCで "管理サーバーの変更" タスクを使う方法は完了です。
この作業が完了した時点で環境は以下の通りとなっています。
各端末でklmoverコマンドを実行して参照先KSCを変更する場合
ここで紹介するのは、リプレース元KSC管理下にある各デバイスでklmoverコマンドを実行して、参照先KSCをリプレース先KSCに変更する方法です。
なお、この手順はメーカーのこちらのサイトにも詳しい情報が載っておりますので、併せてご参照ください。
https://support.kaspersky.co.jp/9290
まず、参照先KSCを変更したいデバイスにログインし、管理者権限でコマンドプロンプトを起動します。
そして以下のコマンドでディレクトリを移動します。
>cd C:\Program Files (x86)\Kaspersky Lab\NetworkAgent
次にklmoverコマンドを使ってKSC参照先を変更します。
klmoverコマンドの指定方法は以下の通りです。
>klmover -address <リプレース先KSCのFQDNかIPアドレス>
例えば、今回の検証環境においてリプレース先KSCのFQDNは KSC-After.testdom.local なので、以下の通りとなります。
>klmover -address KSC-After.testdom.local
出力に "動作が正常に完了しました。" と表示されることを確認したら、コマンドプロンプトを閉じます。
リプレース先KSCサーバーでMMCベースのコンソールを起動し、デバイスの移動状況を確認します。
以上で、④の実現方法2つ目である、klmoverコマンドを用いた参照先KSCの変更は完了です。
この作業が完了した時点で環境は以下の通りとなっています。
⑤(任意) ネットワークエージェントのインストールパッケージにおける参照先KSCの変更
この章の手順は任意です。
リプレース元KSCのデータをリプレース先KSCにリストアした際、インストールパッケージもリストアされます。
このリストアされたインストールパッケージの中には、ネットワークエージェント (今回の例だと11) のパッケージも含まれております。
ネットワークエージェント11のパッケージの参照先KSC情報は、リプレース元KSCのままとなっているので、それをリプレース先KSCに変更する作業がこの⑤です。
(ぶっちゃけ、リプレース後はリプレース先のKSCにある新しいネットワークエージェントのパッケージをメインで使ってほしいでの、この手順はあまり要らないかな…と思いつつ一応書きます。)
リプレース先KSCのMMCベースコンソールを起動し、[詳細]>[リモートインストール]>[インストールパッケージ]を開きます。
リプレース元KSCとリプレース先KSCのバージョンが異なる場合、この画面上にはネットワークエージェントが2つあります。
このうち、リプレース元KSCと同じバージョンのネットワークエージェントを選択し、右クリック>[プロパティ]を開きます。
[接続] セクションを開き、[管理サーバー] 欄にリプレース先KSCのFQDNかIPを入力します。
他の項目は変更せずに、[OK] をクリックします。
以上で、 ⑤(任意) ネットワークエージェントのインストールパッケージにおける参照先KSCの変更作業は完了です。
⑥(任意) リプレース先KSCに接続しているネットワークエージェントのバージョンアップ
この章の手順は任意…と書いていますが、実行を強く推奨します。
④の手順完了時、各デバイスにインストールされているネットワークエージェントのバージョンは古いまま (リプレース元KSCと同じバージョン) です。
KSCには、接続に利用するネットワークエージェントはKSCと同じバージョンを使うという暗黙の前提ルールみたいなのがあるのですが、それに反した状況になっています。
ですのでこの手順⑥で、各デバイスにインストールされているネットワークエージェントをリプレース先KSCと同じバージョンにバージョンアップさせます。
この手順ではKSCからネットワークエージェントを上書きリモートインストールする方法を紹介いたします。
リプレース先KSCのMMCベースコンソールを起動し、[詳細]>[リモートインストール]>[インストールパッケージ]を開きます。
パッケージ一覧にあるネットワークエージェントのパッケージ (リプレース先KSCと同じバージョン) を選択し、右クリック>[アプリケーションのインストール] をクリックします。
新しいバージョンのネットワークエージェントを上書きインストールしたいデバイスの選択方法を任意に指定します。
この手順では例として、[インストールするデバイスの選択] で進めます。
新しいネットワークエージェントを上書きインストールするグループやデバイスにチェックを入れ、[次へ] をクリックします。
[アプリケーションが既にインストールされている場合再インストールしない] のチェックを外し、[次へ] をクリックします。
[デバイスを再起動しない] を選択し、[次へ] をクリックします。
ネットワークエージェントインストール後、デバイスを移動するか否かは任意に設定してください。
[次へ] をクリックします。
[アカウントが不要 (ネットワークエージェントインストール済み)] を選択し、[次へ] をクリックします。
[リモートインストールウィザードの終了後にタスクを実行しない] については任意に指定してください。
この例ではチェックを入れずに進めます。
[次へ] をクリックします。
[完了] をクリックします。
タスク一覧画面に自動遷移します。
新しいネットワークエージェントのリモートインストールタスクの完了状況を確認します。
以上で、⑥ (任意) リプレース先KSCに接続しているネットワークエージェントのバージョンアップする作業は完了です。
この作業が完了した時点で環境は以下の通りとなっています。
イレギュラー対応手順 (筆者の独断と偏見にまみれたナレッジ)
この章では、筆者がリプレース作業中に遭遇した想定外事象における対応を記載します。
リプレース先KSCのWebコンソールで自己署名証明書に関するエラーが出てログインできない
リプレース先KSCのWebコンソールに以下のメッセージが出てログインできない事態が発生しましたが、解消できたのでその手順を記載します。
管理サーバーが信頼されていない自己署名証明書を使用しています。
本製品の設定を編集し、管理サーバー用に有効な証明書を指定してください。
Kasperskyの製品ダウンロードページ (2021年11月4日時点では以下のURL) から、Web Consoleの個別インストーラーを入手します。
製品のダウンロード | Endpoint Security for Business | カスペルスキー
入手したWeb Consoleのインストーラーを管理者権限で実行します。
言語を任意に選択して、[OK] をクリックします。
[証明書を再発行する] を選択し、[次へ] をクリックします。
即、証明書の再発行が実行されます。
ウィザード完了後に再度Webコンソールに接続し、ログインできるか確認してみてください。
これで今回のリプレースに関する手順の紹介は終わりです。
今回はKSCをリプレース 且つ バージョンアップする手順を紹介いたしました。
カスペルスキー製品のライフサイクルだけでなく、OSのサポート、ハード保障、DBのサポート等 様々な要因があり、リプレースはいつかは検討しなければいけない作業になります。
KSCのリプレースはそれなりに事前確認・検証が必要な作業ではありますが、全体像を把握したうえで対応すればそれほど難しい作業ではありません。
KSCのリプレースを検討なさっている方にこの記事が参考になれば、大変幸甚にございます。
この度は最後まで記事をご覧いただき誠にありがとうございました。
記載事項へのご指摘、ご不明点、ご質問等ございましたら、以下からご連絡いただければと存じます。
https://www.networld.co.jp/product/kaspersky/
それでは次回の記事でお会いしましょう！
