(2) 必要な資材
WS2022で動かす新しいサーバは実質新規構築する（コンテンツだけ復元する）ことになりますので、サーバ構築に関する資材は全部必要です。
MS Volume Lisence Service Center は Microsoft 365管理センターの一角に移設になりましたが、やることは一緒です。
SQL Server があるのはいいのですが（今回はせっかくなので最新版2022を使います。CMもSQLもプロダクトキーが必要なので忘れず取得しましょう）、CBが執筆時点で最新の2403しかありません。これは、2309が基準バージョンではないからだと思われます。それは仕方ないのですが、１つまえの基準バージョン2303もダウンロードできないんですね。旧バージョンはOSが2012R2なので、2403にするのは不可能です。
実はこういうことがあるのを予期してか、サイトの復元を行う場合にはConfiguration Managerのインストール資材はCBの更新を行った際にサイトサーバの中に置かれるようになっているんだそうです。
「CD.Latest Configuration Managerのフォルダー」
むしろ、サイト復元するときは必ずこれを使え、と書いてあります。したがって、WS2012R2サーバをシャットダウンする前にこの情報を抜き出して、WS2022サーバの適当な場所にコピーする必要があります。
旧サーバから忘れずに取ってこないといけないものがもう１つ、サイトバックアップの内容です。賢明な管理者のみなさまなら、普段サイトバックアップがどのタイミングでどこに保存されているかなんて、設計書を見なくても分かって当然ですよね（ええ、私はわかっていませんでしたよ、もちろん。なので旧サーバを立ち上げてコンピュータアカウントを復活させて管理コンソールを確認する羽目になりました。そして挙句の果てに保存先がファイルサーバだったと気づいて orz になりました←ダメなやつ）
ちゃんと確認しましょう。（ファイルのタイムスタンプを見てスケジュール通りに実行されていたかも確認）。
うちでは1週間に1度のスケジュールですが、SQL Serverの障害に備えるためには、DBの変更履歴保存期間も考慮した方がよいという話もあります。そうはいってもクライアント台数の多いサイトサーバだとバックアップ時のCPU負荷とストレージ容量が結構大きいので、どこまでどうするかは管理者の匙加減になります。
サイトの復元を行う場合の重要な制限事項として、SQL Server のバージョンが新しくなる分には問題ないが、エディションが異なってはいけません。旧サーバがStandardなら新サーバもStandardです。事前に確認しておきましょう。
SQL Server に関しては、VLSCからダウンロードできる本体に加えて、以下のコンポーネントが必要ですので、用意しておきましょう。
・SQL Server Management Studio
こいつはちょっとトラップがしかけてあって、下図のリンクをクリックすると黙って英語版が落ちてきます。
「使用できる言語」から日本語を選択しましょう。
・SQL Server Reporting Service
こっちはちゃんと言語が選択できるページに飛びます。なんだかなぁ。
・ODBC Driver 18 for SQL Server (CB2309でも必要になったモジュール)
・SQLServer Native client 2012
あとでやりますが、少なくともCB2309ではNative clientがないと環境チェックでひっかかります。ただ、Native client は実質終了アナウンスがされているんですよね。いろいろ思案した結果、2012のNative clientをインストールしたら環境チェックはパスしたので、これでよしとしています。今のところこれが原因とみられるコンポーネントエラーなどは出ていません。いずれは ODBCドライバで代替されるものとは思います。
SQL Server関連以外だと、これまでのCBと同様ですが、Windows ADK と、ADKから別パッケージになってしまった（SQLのManagement Studioもそうだったんですが）Windows PE もダウンロードしておく必要があります。
それと、資材ではないのですが、事前にどうするか確認しておいた方がよいことが2点あります。
1つめは、CB2309の時にお話しした、TLS/拡張HTTP設定の件です。すでに内部認証局があってTLS運用している場合はある意味何も選択の猶予はなく、きめられた方法で対処するだけですが、拡張HTTPは状況を見て作業の１週間程度くらい前には無効にしておくことも検討した方がよいかもしれません。一番怖いのはCMクライアントが新サーバからCMのポリシーを受け取れないことなので、安全第一だと筆者は考えております。
もう1つ、EntraID(AAD)連携もサーバがすり替わるとうまく動かない可能性をはらんでいます。すでに連携済みの場合はONにしたままとOFFにすることでどちらがリスクが高いのか（これはクライアント台数や運用している内容によるので状況により答えは変わります）よく検討された方がよいです。
← １つ前へ ＊＊ 目次に戻る ＊＊ １つ先へ →
