Domino サーバーのバージョンアップは、「新しい機能は使いたい。でも、止まったら困る」という気持ちが同居する作業です。この記事では、弊社が Domino 9.0.1 / 10 / 11 のサーバーを Domino 12.0.2 や 14.5 系（14.5.0、14.5.1 など、執筆時点の最新）へ上げるときに、作業の前に確認している項目をまとめました。
※ 本記事の対象は、社内で Domino サーバーを運用している情報システム部門の方です。読了目安: 約 8 分
HCL 製品の対応 OS やサポート期間はバージョンごとに変わるため、本文では断定せず、HCL の公式情報へのリンクを示します。最終的な判断は、お使いのバージョンの公式ドキュメントで確かめてください。
- HCL Domino の製品ドキュメント: help.hcl-software.com/domino
- 製品のサポート情報・修正情報: HCL Software サポート
まず決めること: どのバージョンへ、いつ、誰が
確認項目に入る前に、3つのことを決めておくと、あとの作業が迷いません。
- どのバージョンへ上げるか。 決め手になるのは、サポートの残り期間、必要な機能、安定性（リリースからの経過と修正の状況）の3つです。どれを重く見るかは会社によって違います。HCL Technologies 社（以下 HCL）の製品ライフサイクルは上のサポートサイトでバージョンごとに公開されているので、まずそこを確かめ、判断に迷う場合は HCL アンバサダーのような専門家がいる会社に相談するのも一つの方法です
- いつ止められるか。 実際にバージョンアップの作業を行う当日は、作業中そのサーバーのメールやアプリが使えません。業務を止められる時間帯（夜間・休日）と、その長さを先に確保します。問題が起きたときに元に戻す作業の時間も含めて見積もります
- 誰がやるか、誰に連絡するか。 作業する人、問題が起きたときに判断する人、利用部門への連絡役を決めておきます。1人で全部をやろうとすると、問題が起きたときに手が足りなくなります
事前に確認する項目（チェック表）
ここからが本題です。弊社がバージョンアップのご相談を受けたときに使っているヒアリングシートから、どの会社にも共通する 7 項目を選び、表にまとめました。印刷して、1項目ずつ確認した日付を書き込む使い方をおすすめします。
| # | 確認する項目 | 確認の方法 | 見落とすとどうなるか |
|---|---|---|---|
| 1 | 行き先のバージョンの要件と、今のバージョンからの道筋 | HCL の公式ドキュメントで、新しいバージョンのシステム要件（対応 OS など）、ライフサイクル（サポートの期限）、今のバージョンから直接アップグレードできるか（サポートされるアップグレード元）を見る | インストール自体が通らない。または、動いても HCL のサポートを受けられない |
| 2 | サーバーの構成と使っている機能 | 台数、メールとアプリの分離、クラスタ構成（専用 NIC の有無）、ID Vault・DAOS・Sametime の利用、サーバー接続文書の数、events4.nsf に手で作った文書 |
上げる順番を間違える。使っている機能の設定が新しいバージョンで引き継がれない |
| 3 | ネットワークと名前 | サーバー名の名前解決は社内 DNS か。新しいサーバーで IP アドレスやコンピュータ名を変えるか | 名前や IP を変えると、接続文書・外部システム・クライアントの設定に影響が出る |
| 4 | アドレス帳と設定のカスタマイズ | 公開アドレス帳（names.nsf）の改変、二次アドレス帳、ジャーナル機能、ポリシー設定の内容 |
テンプレートの更新でカスタマイズが消える。ポリシーが想定どおりに効かない |
| 5 | メールの経路と周辺の製品 | 送受信の経路で経由するウイルスチェック・スパム対策、バックアップソフト、その他のサードパーティ製品の対応版 | Domino は動くのに、メールが届かない・バックアップが取れない |
| 6 | クライアントと利用者 | Notes クライアントのバージョン（ベーシック / スタンダード）、Traveler・Verse・iNotes・Nomad の利用、ブラウザから使っているアプリ（XPages など）の有無、特別な対応が要る利用者の人数、先行利用者（パイロット）を出せる部署 | サーバーは上がったのに、クライアント側の対応が後手に回る。役員の端末で問題が出る |
| 7 | 進め方と戻し方 | 作業は週末か、完了の期日、体制、打ち合わせの頻度。「何がどうなったら戻すか」の判断基準と、戻す手順 | 期日から逆算した計画が立たない。深夜に判断に迷い、中途半端な状態で朝を迎える |
既存の Notes アプリの互換性は、以前ほど心配しなくてよくなりました。最近のバージョンでは、アプリが動かなくなる例はほとんどありません。ひとつだけ落とし穴として覚えておきたいのは、バージョンの間で Domino に同梱される Java のバージョンが大きく上がることがある点です。Java に依存した作り方をしているアプリは多くありませんが、該当する場合は、新しいバージョンの Java で動くかを検証環境で確かめてください。
ヒアリングシートの項目は、ここに載せたものがすべてではありません。弊社ではお客様の環境に合わせて、さらに細かく確認しています。
進め方は1つではない: HCL が示す4つの選択肢
確認項目が埋まったら、どの方法で上げるかを決めます。バージョンアップの方法は1つではありません。HCL が公開している「HCL Notes/Domino V12 アップグレードガイド」では、サーバーのアップグレード方法が次の4つの選択肢に整理されています。V12 向けの資料ですが、方法の考え方は今のバージョンでも変わりません。
| 選択肢 | 内容 | 向いている場合 |
|---|---|---|
| 1. その場でアップグレード（簡易インストール） | 今のサーバーを止めてインストーラーを実行し、再起動する。最も簡単で一般的 | 今のバージョンが 10.0 以上で、OS とハードウェアが新しいバージョンの要件を満たし、サーバー名・ID・フォルダ構成を変えないとき |
| 2. その場でアップグレード（10 より前のバージョンから） | いったん今の Domino をアンインストールしてから、新しいバージョンを入れる。その前に notes.ini・names.nsf・ID・改変したテンプレートなどを必ずバックアップする |
今のバージョンが 10 より前のとき。古いファイルが残らず、競合を避けられる |
| 3. ハードウェアや OS の更新を伴う並行アップグレード | 新しいハードウェアに、プログラム・データ・トランザクションログを同じ場所に移してから新しいバージョンを入れ、ホスト名とネットワークの ID を引き継ぐ | 今のハードウェアや OS が新しいバージョンの要件を満たさないとき。サーバーの名前と ID は変えない |
| 4. 新しい ID で新しいサーバーを建てる | 新しい名前・新しい ID のサーバーを独立して構築し、テストしてから切り替える。利用者とクライアントの設定、アプリの移し替えが要る | 構成を見直したいとき。切り替えの前に、できあがった状態をテストできる |
出典: HCL Notes/Domino V12 アップグレードガイド（HCL Technologies、2021年9月）「Domino サーバーの最適なアップグレードプロセスの決定」
どの選択肢でも、ガイドが共通して求めているのは次の点です。
- 先にテスト環境で、同じ手順を一度通す
- ハードウェアと Domino を同時に変えない。 別々に上げると、問題が起きたときにどちらの原因かを切り分けられる
- クラスタは1台ずつ上げ、最終的に全台を同じバージョン・同じテンプレートにそろえる
- Traveler を同じサーバーで動かしているなら、Domino を先に上げてから Traveler のインストーラーを再実行する
- アップグレード後は、
fixupの再実行と、古い設定が残ったnotes.iniの整理を検討する
弊社でよく使う進め方: 新しいサーバーを別に建てて、切り替える
弊社がご相談を受ける案件では、選択肢 3・4 の考え方に近い「新しいサーバーを別に建てて、検証してから切り替える」方法をとることがあります。移行の前に本番と同じ構成で検証でき、切替日の停止時間を短くできるからです。
ただし、この方法が常に正解ではありません。サーバーが1台か少数の構成では有効ですが、クラスタ構成では新旧の環境をそろえる作業項目が一気に増え、抜け漏れも起きやすくなります。選択肢 1 で済む環境では、その場でのアップグレードのほうが早く確実なことも多くあります。環境と要件に合わせて選びます。
- 新しい環境を別の名前で構築する。 新しいバージョンの Domino を入れたサーバーを、検証用の名前で用意します。既存の環境とバージョンが混在する期間があるので、その間の不具合を避ける設定も入れます。メール DB とアプリ DB のレプリカは、検証が終わった時点で新サーバー上に作っておきます。こうしておくと、切替日の作業は「レプリカの同期」だけで済みます
- 検証する。 基本機能、アプリ、Traveler などのモバイル連携、アーカイブ、バックアップの順に、動作を確認します。確認する項目と合格の基準は、テスト仕様書として先に書いておきます
- 切替日。 当日の作業は、おおよそ次の順です。レプリカを最後に同期する → 接続文書・プログラム文書を一時的に無効にする → 現行サーバーを停止する → 名前解決（DNS や hosts）を新サーバーに向ける → 新サーバーを起動し、テンプレートの置き換えなどのバックグラウンド処理が終わるのを見届ける → クライアントからの接続、クラスタのフェイルオーバー、アーカイブ、モバイル、SSL を順に確認する。作業の一つひとつに、見積時間と担当者を書いたタイムチャートを用意します
- 移行後。 Notes クライアントのバージョンアップと、メールテンプレートの更新を行います。サーバーを上げた直後にクライアントまで一気に変えないのは、問題が起きたときに切り分けやすくするためです
移行判定と、戻す計画を先に決める
どの選択肢をとる場合でも、作業の最後に 移行判定 を置きます。「ここまでの確認がすべて通ったら移行を確定し、通らなければ戻す」という判断の場です。判定の基準と、戻すときの手順（コンティンジェンシープラン）は、計画の段階で文章にしておきます。
- 発動の条件: たとえば「切替日の何時までに動作検証が終わらなければ」「主要なアプリのうち何が動かなければ」
- 対応策: その場でのアップグレードなら、取っておいたバックアップからファイルを戻してサーバーを再起動する。別のサーバーに建てた場合なら、名前解決を元のサーバーに戻し、停止していた現行サーバーを起動する
深夜に迷わないために、この2つを先に決めておくことが、作業そのものより大事です。
検証用のサーバーを社内に用意しにくい場合は、一時的にクラウド上に作る方法もあります。
まとめ
Domino サーバーのバージョンアップで大事なのは、作業そのものより、作業の前にどれだけ確認し、どの方法で進めるかを決めているかです。
- 行き先のバージョン・止められる時間・体制を先に決める
- 7 項目のチェック表を埋める。とくにサーバー構成とクライアント側の確認は早めに
- 方法は HCL の4つの選択肢から環境に合わせて選ぶ。どの方法でも、先にテスト環境で手順を通し、ハードウェアと Domino を同時に変えない
- 移行判定の基準と戻す計画を先に決めておく
チェック表は、この記事の画像を印刷してそのまま使っていただけます。
バージョンアップの計画書・タイムチャートの作成、検証環境の準備、切替日の作業は、弊社の運用サポートでもお手伝いしています。「自社だけでは手が足りない」「検証環境を用意する場所がない」という場合は、お気軽にご相談ください。
Notes/Domino のバージョンアップや新機能の導入をお手伝いします。→ Notes/Domino 運用サポート
