SQL Server 2014 実践シリーズ （HTML 版）
「No.2 SQL Server 2014 への移行とアップグレードの実践」

4.10　ケース2「新規サーバーへのアップグレード」のまとめ

ケース 2 での操作手順をまとめると、次のようになります。

1．現在のマスター環境を丸ごと新規サーバーへ複製する

　- 現在のマスターでオフライン バックアップ（全データベース）を取得する
　 （ユーザー データベースに関しては、オンライン バックアップでも可）
　- 現在のマスターを停止して、ネットワークから切り離す（旧マスターとなる）
　- 新規サーバーに OS をインストールし、マシン名を旧マスターと同じ名前へ変更する
　 （インストールする OS は、旧マスターと異なるものでも可）
　- 新規サーバーを Active Directoryドメインへ参加させる
　- 新規サーバーへ旧マスターと同じバージョンの SQL Server をインストールする
　- 旧マスターの SQL Server にインストール済みの修正プログラムを、新規サーバーにもインストールする
　- 新規サーバーの SQL Server を停止する
　- 旧マスターで取得したオフライン バックアップを上書きコピーする（復元する）
　 ユーザー データベースをオンライン バックアップで取得している場合は、SQL Server の起動後に、該当データベースを復元する
　- 新規サーバーの SQL Server を起動する
　- レジストリに格納されている情報を再設定する（TCP ポート番号や起動時パラメーターでのトレースフラグ設定などのうち、旧マスターで設定を変更しているものがある場合はそれらを再設定する）
　- OS の設定で、旧マスターで変更しているものがある場合は、それらを再設定する
　 （フォルダー構成や、NTFS アクセス許可、ユーザーの権利、共有フォルダーなど）

以上で旧マスターとまったく同じ環境を丸ごと新規サーバー上で動作させることができます。

2．アップグレード アドバイザーによる事前チェックを行う

3．SQL Server 2014 へのアップグレード要件を確認する（アップグレード可能な Service Pack や .NET Framework 3.5 SP1、PowerShell 2.0 など）

4．新規サーバーを SQL Server 2014 へアップグレードする

5．SQL Server 2014 の最新の修正プログラム（CU や Service Pack など）をインストールする

6．統計（Statistics）を更新する

7．データベースの互換性レベルを 120 へ上げる（オプション）

8．BIDS（Business Intelligence Development Studio）を利用している場合は、SSDT-BI（SQL Server Data Tools - Business Intelligence for Visual Studio）をインストールする（オプション）

作業のポイントは、ハードウェア リプレース時の新規サーバーへの完全複製です。旧マスターと同じ名前のサーバーを作成すること、同じ Active Directory ドメインに参加していること、旧マスターの SQL Server と同じパスにインストールすること、同じ名前のインスタンス名にすること、同じサービス アカウントを利用すること（サービス アカウントはドメイン ユーザーであること）、同じ種類の修正プログラムを適用すること、同じフォルダー構成／NTFS アクセス許可にすることなどを守っていれば、問題が起こることはありません（弊社のお客様では、問題なく動作しています）。

唯一の問題は、Windows のローカル ユーザーを利用している場合ですが、この場合はいくつかのものが動作しなくなりますが、データベースとジョブについては、所有者を設定することで正常に動作するようになります。ログイン アカウントについては、スクリプト生成ウィザードでスクリプト化を行っておくことで再設定を容易に行えます。

Windows のローカル ユーザーの問題は、（旧マスターで）Management Studio を Windows のローカル ユーザーで操作していることに起因するので、今後のことを考慮すると、Management Studio を利用するときは、Active Directory のドメイン ユーザーで操作することを強くお勧めします。

Note： サービス アカウントが同じドメイン ユーザーではない場合
このケースでは、SQL Server サービスのサービス アカウントが、旧マスターと新規サーバーで同一のドメイン ユーザーであることが条件でしたが、これは各種の暗号化に関わるサービス マスター キーが関係しています。サービス マスター キーは、SQL Server のセットアップ時にサービス アカウントに紐付いて作成されるので、旧マスターと新規サーバーで同じサービス アカウントを利用することで、共通のサービス マスター キーを利用できるようになります。
サービス マスター キーは、リンク サーバーのセキュリティ設定（リモート ログインのパスワードなど）や、データベース メールでのメール サーバーへのログイン パスワード、TDE（透過的なデータ暗号化）で利用するデータベース マスター キーなどで利用され、（内部的なデータを含めた）各種のデータを暗号化するための最も重要なキーになります。
このため、サービス アカウントが同じドメイン ユーザーではない場合は（Windows のローカル ユーザーなどをサービス アカウントにしている場合は）、リンク サーバーや、データベース メール、TDE などが、新規サーバー側で動作しないということになります。サービス マスター キーが原因で、うまく動作しない場合には、次のように「暗号化解除中にエラーが発生しました」エラーが発生します。

これを回避するには、サービス マスター キーを作成し直します（REGENERATE します）。作成し直しは、次のように ALTER SERVICE MASTER KEY ステートメントを実行します。

USE master
ALTER SERVICE MASTER KEY REGENERATE

このステートメントを実行しても、「暗号化解除中にエラーが発生しました」エラーが発生する場合には、次のように FORCE（強制）オプションを付けて、作成し直します。

USE master
ALTER SERVICE MASTER KEY FORCE REGENERATE

ただし、このように、FORCE を利用した場合は、暗号設定が失われる可能性があるので、暗号化が関連する機能（リンク サーバーのセキュリティ設定やデータベース メールでのメールサーバーへのログイン情報など）の再設定が必要になる場合があります。TDE を利用している場合には、データベース マスター キーや証明書のバックアップが必要になる、あるいは再設定が必要になる場合があります。
したがって、サービス アカウントは、同一のドメイン ユーザーを利用するようにすることが重要になります。サービス アカウントが同一のドメイン ユーザーであれば、こういった問題は発生しません。もし、サービス アカウントに Windows のローカル ユーザーを利用している場合は、第5章で説明するリンク サーバーやデータベース メールのスクリプト化の手順を利用して、旧マスター側で設定をスクリプト化しておくことをお勧めします（これで再設定が容易になります）。