(7) 動作確認 最後に
特にエラーが出ず作業が終わったのであれば、少しサーバを落ち着かせてから再起動しましょう。
これだけのミドルウェアが複雑に絡んでいるシステムなので、Windowsサービスも多数関係しています。特に性能の低い仮想サーバで動かしていると、自動起動がタイムアウトしてトラブルの原因にもなるので、再起動してメインのサービスがちゃんと全部上がってくるか目視でまず確認しておきます。
大丈夫そうなら、サーバ上で Configuration manager の管理コンソールを起動します。
イケてない例↓
筆者の場合は、サーバスペックの問題と、ウイルス対策ソフトの干渉の問題でSQL Serverサービスの起動が制限時間内に終わらず、自動（遅延開始）に設定したら、SMS Execute（CMの中心のサービス）が起動する際にSQLサーバがいないという悲しいことになっているのが原因のようです。悩ましいですねぇ。
ちなみに私の記事をメニューから見たレアな方でなければ、SMS？なんでケータイのショートメールと思うかもしれませんが、これは前身の製品名SMS2003(Systems Management Service)によります。
管理コンソールが起動できたら、サイトのステータスとコンポーネントのステータスを確認しましょう。
サイトのステータスは基本的にすべてOkである必要があります。そのうえで、コンポーネントのステータスは出ている警告の内容を確認し、納得のいく理由があるものについてはそのままでかまいません。例えば、上記のスクリーンショットの例ではWSUSの同期の警告が出ていますが、WSUSはさっきインストールしたばかりで上流サイトと同期がとれていなくても不思議はありません。…といった具合です。通常運用時に出ている警告も同様に無視してよいでしょう。
そして、DDNSの公示も確認。IP変更になった場合は特に大事ですが、その場合はちゃんとAレコードも確認が必要ですね。
あとは、クライアントとの関係性ですね。すべてのシステムのオブジェクトの状態を見ましょう。
緑が１つもないのはさすがにまずいです。管理者であるあなたが普段常用しているクライアントの状態を確認し、場合に寄ったらクライアントを再起動して様子を見ましょう。サイトコードもサイトサーバのホスト名を変えていなければ、全部グレーになることはまず考えにくいのですが。
管理者の常用クライアントの接続性に問題なさそうなら、その常用クライアントパソコンで管理コンソールが起動できるか確認します。
コンテンツが表示できるなら、そのクライアントPCとサーバの接続性は問題ないということになります。
あとはクライアントポリシーがちゃんと生き渡っているかどうかですが、コンソールへの反映には時間がかかりますし、そもそもハードインベントリやポリシーを取りに行く間隔もサイトごとにバラバラかと思います。
このサーバはもともとが検証用なのでポリシーの更新もハードウェアインベントリの更新も間隔を短めにしていますが、本番機だと負荷や輻輳防止で間隔が長いケースもあると思うので、可能なら切り替え前に短くして、切り替え後の安定動作を確認したら戻すようなことも有用かもしれません。
ミドルウェア関連で、IISマネージャやMS SQL Management Studio、WSUSコンソールもさっと確認しておきましょう。
あとはまあ、新規のクライアントインストールをしてみるくらいですかね。システムとサイトコンポーネントの監視は少なくとも数日は行っておいた方がよいと思います。
最後に感想を。今回の狙いは、クライアントから見てサーバのすげ替えに気づかれないようにサーバのOSやハードを入れ替えることが目標でした。SQLサーバのバージョンを上げてもよいという条件のおかげで、WS2012R2からWS2022へは事前準備さえきっちりやれば移行はできなくなさそうです。
これくらいの手順なら、一度事前演習をしていればサーバを止めるのは１日（日中帯６〜７時間程度）でできそうです。それくらいで終わらないと切り戻しとなった時の手間や判断が辛くなりますよね。
もう１つ、サイトの復元はできることなら本番サーバではやりたくない手順の一つですが、そうはいえども運用の仕事をしているといつ何時トラブルに見舞われるか予知することなどできません。復元手順を理解することで、ピンチに陥った時に冷静に最善手を選ぶことができるとするならそれは大きなメリットになります。
あくまで「非公式」手順ではあるのですが、リスクを上回るメリットを感じる方は試してみるのもよろしいのではないでしょうか。
← １つ前へ ＊＊ 目次に戻る ＊＊ １つ先へ →