Configuration Manager のバックアップと回復

 

適用対象: System Center 2012 Configuration Manager,System Center 2012 Configuration Manager SP1,System Center 2012 Configuration Manager SP2,System Center 2012 R2 Configuration Manager,System Center 2012 R2 Configuration Manager SP1

System Center 2012 Configuration Manager のようなエンタープライズ ソリューションでは、重要なデータの損失を防ぐために、バックアップと復元の両方の準備を整えておく必要があります。 このような準備は、Configuration Manager サイトと階層のデータの損失を最小限に抑え、できる限り短時間で回復するために欠かせない作業です。 ここでは、Configuration Manager サイトをバックアップする方法と、サイトで障害が発生したときやデータが損失したときにサイトを回復する方法について説明します。

• SMS ライター サービス

• Configuration Manager サイトのバックアップ

  • バックアップ メンテナンス タスク

  • Data Protection Manager を使用したサイト データベースのバックアップ

  • バックアップ スナップショットのアーカイブ

  • AfterBackup.bat ファイルの使用

  • その他のバックアップ タスク

• Configuration Manager サイトの回復

  • 回復オプションの検討

    • サイト サーバーの回復オプション

    • サイト データベースの回復オプション

  • サイトの無人回復スクリプト ファイルのキー

  • 回復後の作業

  • セカンダリ サイトの回復

SMS ライター サービス

SMS ライターは、バックアップ中にボリューム シャドー コピー サービス (VSS) と相互に動作するサービスです。Configuration Manager サイトのバックアップを正常に完了するには、SMS ライター サービスが実行されていなければなりません。

目的

SMS ライターは、VSS に登録して、そのインターフェイスとイベントをバインドします。 VSS がイベントをブロードキャストするか、SMS ライターに特定の通知を送信すると、SMS ライターは、その通知に応答して適切な措置を取ります。 SMS ライターは、<ConfigMgr のインストール先フォルダー>\inboxes\smsbkup.box にあるバックアップ コントロール ファイル (smsbkup.ctl) を読み取って、バックアップするファイルとデータを確認します。 次に、この情報、および、SMS レジストリ キーとサブキーの特定のデータに基づいて、さまざまなコンポーネントからなるメタデータを構築します。 SMS ライターは、このデータが要求されたときに VSS に送信します。 VSS は、要求元のアプリケーション、つまり Configuration Manager バックアップ マネージャーに、このメタデータを送信します。 バックアップ マネージャーは、バックアップするデータを選択し、そのデータを VSS 経由で SMS ライターに送信します。 SMS ライターは、バックアップを開始するのに必要な処理を行います。 その後、VSS がスナップショットを撮る準備ができたら、イベントを送信します。SMS ライターは、スナップショットが作成されている間は、Configuration Manager のすべてのサービスを停止して、Configuration Manager の動作を止めます。 スナップショットの作成が終わったら、SMS ライターが、停止していたサービスを再開します。

SMS ライター サービスは自動的にインストールされます。 VSS アプリケーションがバックアップまたは復元を要求したときに、このサービスが実行されていなければなりません。

ライター ID

SMS ライターのライター ID:03ba67dd-dc6d-4729-a038-251f7018463b。

アクセス許可

SMS ライターは、ローカル システム アカウントで実行する必要があります。

ボリューム シャドウ コピー サービス

VSS は、システムのアプリケーションがボリュームに書き込んでいる間にボリュームをバックアップできるようにするフレームワークを実装する COM API のセットです。 VSS は、ディスクのデータを更新するユーザー アプリケーション (SMS ライター サービス) と、アプリケーションのバックアップを取るユーザー アプリケーション (Backup Manager サービス) を連携させるインターフェイスとして機能します。 VSS の詳細については、Windows Server TechCenter の「Volume Shadow Copy Service (ボリューム シャドウ コピー サービス)」を参照してください。

Configuration Manager サイトのバックアップ

System Center 2012 Configuration Manager には、スケジュールに従って、サイト データベース、特定のレジストリ キー、および特定のフォルダーとファイルをバックアップするメンテナンス タスクが組み込まれています。 このメンテナンス タスクが完了したら自動的に後処理が行われるようにするには、AfterBackup.bat を作成します。 通常、AfterBackup.bat ファイルは、バックアップのスナップショットを安全な場所にアーカイブするのに使います。 ただし、バックアップ フォルダーにファイルをコピーしたり、他の補助タスクを開始ときにも使うことができます。 次に、Configuration Manager のバックアップ戦略をたてるときに役立つ情報を示します。

[!メモ]

Configuration Manager では、サイト データベースを回復するときに、Configuration Manager のバックアップ メンテナンス タスクで行われたバックアップと、別のプロセスで行われたサイト データベース バックアップのどちらでも使用できます。 たとえば、Microsoft SQL Server のメンテナンスの一環として行われたバックアップから、サイト データベースを復元することができます。Configuration Manager SP1 以降では、System Center 2012 Data Protection Manager (DPM) で行われたバックアップからサイト データベースを復元できます。 詳細については、「Data Protection Manager を使用したサイト データベースのバックアップ」をご覧ください。

バックアップ メンテナンス タスク

Configuration Manager サイトのバックアップは、"サイト サーバーのバックアップ" という組み込みメンテナンス タスクのスケジュールを設定することで自動化することができます。 中央管理サイトとプライマリ サイトをバックアップすることはできますが、セカンダリ サイトやサイト システム サーバーのバックアップはサポートされていません。Configuration Manager のバックアップ サービスは、バックアップ コントロール ファイル (<Configuration Manager のインストール フォルダー>\Inboxes\Smsbkup .box\Smsbkup .ctl) で定義されている指示に従って実行されます。 このバックアップ コントロール ファイルを変更して、バックアップ サービス動作を変更することができます。 サイトのバックアップ状態に関する情報は、Smsbkup.log ファイルに書き込まれます。 このファイルは、サイト サーバーのバックアップ メンテナンス タスクのプロパティで指定した、バックアップ先フォルダーに保存されます。

次に、サイト サーバーのバックアップ メンテナンス タスクを有効にする手順を示します。

サイトのバックアップ メンテナンス タスクを有効にするには

1. Configuration Manager コンソールで、[管理] をクリックします。

2. [管理] ワークスペースで [サイトの構成] を展開して、[サイト] をクリックします。

3. バックアップ メンテナンス タスクを有効にしたいサイトを選択します。

4. [ホーム] タブの [設定] グループで、[サイト保守タスク] をクリックします。

5. [サイト サーバーのバックアップ] をクリックしてから、[編集] をクリックします。

6. [このタスクを有効にする] を選択してから、[パスの設定] をクリックしてバックアップ先を指定します。 次のオプションがあります。

   セキュリティ メモ
   バックアップ ファイルの改ざんを防ぐため、ファイルを安全な場所に保存してください。 最も安全なバックアップ パスは、フォルダーに NTFS ファイル システムのアクセス許可を設定できるローカル ドライブです。 選択するオプションに関係なく、Configuration Manager では、バックアップ パスに保存されたバックアップ データは暗号化されません。

   - **サイト データおよびデータベース用のサイト サーバーのローカル ドライブ**:サイト サーバーのローカル ディスク ドライブの指定したパスに、サイトとサイト データベースのバックアップ ファイルが保存されるようにします。 バックアップ タスクを実行する前に、ローカル フォルダーを作成する必要があります。
   
     <div class="alert">
   
     <table>
     <colgroup>
     <col style="width: 100%" />
     </colgroup>
     <thead>
     <tr class="header">
     <th><img src="images/Gg712320.s-e6f6a65cf14f462597b64ac058dbe1d0-system-media-system-caps-security(TechNet.10).jpeg" title="System_CAPS_security" alt="System_CAPS_security" /> セキュリティ メモ</th>
     </tr>
     </thead>
     <tbody>
     <tr class="odd">
     <td><p>サイト サーバーのローカル システム アカウントが、サイト サーバーのバックアップ先フォルダーへの NTFS <strong>書き込み</strong>権限を持っている必要があります。</p>
     <p>SQL Server を実行しているコンピューターのローカル システム アカウントが、サイト データベースのバックアップ先フォルダーへの NTFS <strong>書き込み</strong>権限を持っている必要があります。</p></td>
     </tr>
     </tbody>
     </table>
   
     </div>
   
   - **サイト データおよびデータベース用のネットワーク パス (UNC 名)**:指定した UNC パスに、サイトとサイト データベースのバックアップ ファイルが保存されるようにします。 バックアップ タスクを実行する前に、共有を作成する必要があります。
   
     <div class="alert">
   
     <table>
     <colgroup>
     <col style="width: 100%" />
     </colgroup>
     <thead>
     <tr class="header">
     <th><img src="images/Gg712320.s-e6f6a65cf14f462597b64ac058dbe1d0-system-media-system-caps-security(TechNet.10).jpeg" title="System_CAPS_security" alt="System_CAPS_security" /> セキュリティ メモ</th>
     </tr>
     </thead>
     <tbody>
     <tr class="odd">
     <td><p>SQL Server が別のコンピューターにインストールされている場合は、サイト サーバーのコンピューター アカウントと SQL Server のコンピューター アカウントが、共有ネットワーク フォルダーの NTFS<strong>書き込み</strong>権限と共有権限を持っている必要があります。</p></td>
     </tr>
     </tbody>
     </table>
   
     </div>
   
   - **サイト サーバーおよび SQL Server のローカル ドライブ**:サイト サーバーのバックアップ ファイルが、サイト サーバーのローカル ドライブの指定したパスに保存され、サイト データベースのバックアップ ファイルが、サイト データベース サーバーのローカル ドライブの指定したパスに保存されるようにします。 バックアップ タスクを実行する前に、ローカル フォルダーを作成する必要があります。
   
     <div class="alert">
   
     <table>
     <colgroup>
     <col style="width: 100%" />
     </colgroup>
     <thead>
     <tr class="header">
     <th><img src="images/Gg712320.s-e6f6a65cf14f462597b64ac058dbe1d0-system-media-system-caps-security(TechNet.10).jpeg" title="System_CAPS_security" alt="System_CAPS_security" /> セキュリティ メモ</th>
     </tr>
     </thead>
     <tbody>
     <tr class="odd">
     <td><p>サイト サーバーのコンピューター アカウントが、サイト サーバーに作成するフォルダーの NTFS <strong>書き込み</strong>権限を持っている必要があります。 SQL Server のコンピューター アカウントが、サイト データベース サーバーに作成するフォルダーの NTFS <strong>書き込み</strong>権限を持っている必要があります。 このオプションは、サイト データベースがサイト サーバーにインストールされていない場合のみ選択できます。</p></td>
     </tr>
     </tbody>
     </table>
   
     </div>
   

   [!メモ]

   バックアップ先を参照できるのは、UNC パスを指定した場合だけです。 

   重要
   バックアップ先フォルダー名や共有名に Unicode 文字を含めることはできません。

7. サイトのバックアップ タスクを実行する適切なスケジュールを設定します。 ベスト プラクティスとして、営業時間外に実行することをお勧めします。 階層構造がある場合は、サイトの障害発生に備え、データの保管期間が長くなるように、少なくとも 1 週間に 2 回実行するスケジュールを設定してください。

   [!メモ]

   バックアップを構成しているサイト サーバーと同じコンピューターで Configuration Manager コンソールを実行している場合は、サイト サーバーのバックアップ タスクのスケジュールでローカル時間が使われます。 バックアップを構成しているサイト サーバーとは異なるリモート コンピューターで Configuration Manager コンソールを実行している場合は UTC が使われます。

8. サイト バックアップ タスクが失敗した場合にアラートを生成するかどうかを選択して、[OK] をクリックしてから、[OK] をクリックします。 選択したら、Configuration Manager がバックアップ エラーに関する重大なアラートを生成したときに、[監視] ワークスペースの [アラート] ノードで確認できます。

 

サイト サーバーのバックアップ メンテナンス タスクのスケジュールを設定したら、サイトで障害が発生した場合にサイト回復の準備ができており、データの回復計画を進められるように、このタスクが正常に実行されることを確認します。 サイトのバックアップ メンテナンス タスクが正常に実行されたことを確認するには、次の手順に従います。

サイト サーバーのバックアップ メンテナンス タスクが正常に実行されたことを確認するには

• 次のいずれかの操作を行います。

  • サイト サーバーのバックアップ メンテナンス タスクで作成したバックアップ先フォルダーにあるファイルのタイムスタンプを確認します。 このタイム スタンプが、メンテナンス タスクのスケジュールで設定した前回の実行日時と同じ場合は、タスクが正常に完了しています。

  • [監視] ワークスペースの [コンポーネントのステータス] ノードで、SMS_SITE_BACKUP のステータス メッセージを確認します。 サイトのバックアップが問題なく完了している場合は、ID 5035 のメッセージが表示されているはずです。

  • バックアップが失敗したら警告を生成するようにサイト サーバーのバックアップ メンテナンス タスクが構成されている場合は、[監視] ワークスペースの [アラート] ノードでバックアップ エラーを確認できます。

  • <ConfigMgrInstallationFolder>\Logs にある Smsbkup.log で警告やエラーを確認します。 サイトのバックアップが問題なく完了している場合は、メッセージ ID "Backup completed" の "STATMSG: ID=5035" というメッセージとタイムスタンプが表示されているはずです。

  ヒント
  サイト サーバーのバックアップ メンテナンス タスクが正常に実行されなかった場合は、SMS_SITE_BACKUP サービスを停止してから、再開してみてください。

Data Protection Manager を使用したサイト データベースのバックアップ

System Center 2012 Configuration Manager SP1 以降:

Configuration Manager SP1 以降では、System Center 2012 Data Protection Manager (DPM) を使用してサイト データベースをバックアップできます。 DPM でサイト データベース コンピューターの新しい保護グループを作成する必要があります。 新しい保護グループの作成ウィザードの [グループ メンバーの選択] ページで、データ ソース一覧から SMS ライター サービスを選択してから、該当するメンバーとしてサイト データベースを選択します。 DPM を使用したサイト データベースのバックアップの詳細については、TechNet の「Data Protection Manager」ドキュメント ライブラリを参照してください。

重要
Configuration Manager では、名前付きインスタンスを使用する SQL Server クラスターの DPM バックアップはサポートしていませんが、SQL Server の既定インスタンスを使用する SQL Serevr クラスターの DPM バックアップはサポートしています。

サイト データベースを復元したら、セットアップの手順に従ってサイトを回復します。 Data Protection Manager を使って回復したサイト データベースを使用するには、[手動で回復したサイト データベースを使用する] 回復オプションを使用します。

バックアップ スナップショットのアーカイブ

サイト サーバーのバックアップ メンテナンス タスクを初めて実行するときに、障害が発生したサイト サーバーの復元に使用できるバックアップ スナップショットが作成されます。 その後、スケジュールに従って、バックアップ タスクが実行されると、新しいバックアップ スナップショットが作成され、前のスナップショットが上書きされます。 つまり、サイトのバックアップ スナップショットは 1 つだけになります。それより前のスナップショットに戻すことはできません。

しかし、次のような状況を考慮して、バックアップ スナップショットを複数アーカイブしておくことをお勧めします。

• バックアップ メディアに障害が発生したり、紛失したりすることがあります。また、バックアップ メディアに部分的にしかバックアップが格納されない場合もあります。 障害が発生したスタンドアロンのプライマリ サイトは、バックアップがまったくない状態で復元するよりも、古いバックアップから復元する方が手間がかかりません。 階層にあるサイトの場合は、SQL Server の変更の追跡の保有期間内のバックアップでなければなりません。それ以外は必要ありません。

• サイト内の破損が検出されないまま、バックアップ サイクルが何回か繰り返される可能性があります。 そのため、バックアップ サイクルを何回かさかのぼり、サイトが破損する前のバックアップ スナップショットが必要になることがあります。 これは、スタンドアロンのプライマリ サイトと、SQL Server の変更の追跡の保有期間内にバックアップしている階層内のサイトに当てはまります。

• サイトのバックアップ スナップショットがまったくない状態になる可能性があります。 たとえば、サイト サーバーのバックアップ タスクは現在のデータのバックアップを開始する前に以前のバックアップ スナップショットを削除するので、タスクが正常に実行されなかった場合は、有効なバックアップ スナップショットがなくなります。

AfterBackup.bat ファイルの使用

サイト サーバーのバックアップ タスクでサイトが正常にバックアップされると、AfterBackup.bat というファイルが自動的に実行されます。 この AfterBackup.bat ファイルは、手動で作成して <Configuration Manager のインストール フォルダー>\Inboxes\Smsbkup に保存しておく必要があります。 AfterBackup.bat ファイルが正しいフォルダーに保存されていると、バックアップ タスクの完了後に、このファイルが自動的に実行されます。 AfterBackup.bat を使って、バックアップが完了するたびにバックアップ スナップショットがアーカイブされるようにしたり、サイト サーバーのバックアップ メンテナンス タスクに含まれていない後処理が自動的に行われるようにすることができます。 前者の場合は、AfterBackup.bat でアーカイブ処理とバックアップ処理を統合することにより、常に新しいバックアップ スナップショットがアーカイブされるようにします。 AfterBackup.bat ファイルが存在しない場合は、バックアップ タスクでその実行がスキップされます。バックアップ処理自体には、何も影響ありません。 サイト バックアップ タスクによって AfterBackup.bat ファイルが正常に実行されたことを確認するには、[監視] ワークスペースの [コンポーネントのステータス] ノードを参照して、SMS_SITE_BACKUP のステータス メッセージを確認します。 AfterBackup.bat コマンド ファイルの実行が正常に開始された場合は、ID 5040 の付いたメッセージが表示されているはずです。

ヒント
サイト サーバーのバックアップ ファイルをアーカイブする AfterBackup.bat ファイルを作成するには、バッチ ファイルで、Robocopy などのコピー コマンド ツールを使用する必要があります。 たとえば、AfterBackup.bat ファイルを作成して、1 行目に Robocopy E:\ConfigMgr_Backup \\ServerName\ShareName\ConfigMgr_Backup /MIR と記述します。 Robocopy の詳細については、「Robocopy」のコマンド ライン リファレンスを参照してください。

AfterBackup.bat を使用する本来の目的は、バックアップ スナップショットをアーカイブすることですが、バックアップするたびに何らかの後処理を行うための AfterBackup.bat を作成することもできます。

その他のバックアップ タスク

サイト サーバーのバックアップ メンテナンス タスクによって、サイト サーバー ファイルとサイト データベースのバックアップ スナップショットが作成されますが、この他にも、バックアップすることを検討した方がよい項目があります。 次のセクションの情報を、Configuration Manager のバックアップ戦略をたてるときの参考にしてください。

Reporting Services のカスタム レポートのバックアップ

Reporting Services の定義済みのレポートを変更した場合や、カスタム レポートを作成した場合は、レポート サーバー データベース ファイルのバックアップを取ることが重要です。 レポート サーバーのバックアップには、レポートとモデルのソース ファイル、暗号化キー、カスタム アセンブリや拡張機能、構成ファイル、カスタム レポートで使用する SQL Server カスタム ビュー、カスタム ストアード プロシージャなどが含まれていなければなりません。

重要
System Center 2012 Configuration Manager を新バージョンにアップグレードすると、定義済みのレポートが新しいレポートで上書きされます。 定義済みレポートを変更した場合は、レポートをバックアップしてから新しいバージョンをインストールし、その後 Reporting Services でレポートを復元してください。

Reporting Services のカスタム レポートのバックアップの詳細については、SQL Server 2008 Books Online の「Reporting Services インストールのバックアップおよび復元操作」を参照してください。

コンテンツ ファイルのバックアップ

Configuration Manager のコンテンツ ライブラリは、ソフトウェア更新プログラム、アプリケーション、オペレーティング システムなどの展開で使用するコンテンツ ファイルがすべて保管されている場所です。 コンテンツ ライブラリは、サイト サーバーと各配布ポイントにあります。 サイト サーバーのバックアップ メンテナンス タスクでは、コンテンツ ライブラリのファイルやパッケージ ソース ファイルはバックアップされません。 サイト サーバーで障害が発生したときに、コンテンツ ライブラリのファイルに関する情報は、サイト データベースに復元されますが、コンテンツ ライブラリのファイルとパッケージ ソース ファイルはサイト サーバーに手動で復元する必要があります。

• コンテンツ ライブラリ:コンテンツ ライブラリを復元してからでないと、配布ポイントにコンテンツを再配布することはできません。 コンテンツの再配布を開始すると、Configuration Manager によって、サイト サーバーにあるコンテンツ ライブラリから配布ポイントにコンテンツがコピーされます。 サイト サーバーのコンテンツ ライブラリは、SCCMContentLib フォルダーにあります。このフォルダーは、通常、サイトがインストールされたときに、空きディスク領域が最も大きかったドライブにあります。 コンテンツ ライブラリの詳細については、「Configuration Manager のコンテンツ管理の概要」を参照してください。

• パッケージのソース ファイル:パッケージのソース ファイルを復元してからでないと、配布ポイントのコンテンツを更新することはできません。 コンテンツの更新を開始すると、Configuration Manager によって、パッケージ ソースから新しいファイルや変更されたファイルがコンテンツ ライブラリにコピーされ、次に、コンテンツ ライブラリから、関連する配布ポイントにコピーされます。 すべてのパッケージとアプリケーションのパッケージ ソースの場所を見つけるには、SQL Server で SELECT * FROM v_Package というクエリを実行します。 パッケージ ID の先頭の 3 文字を見ると、パッケージ ソースのサイトがわかります。 たとえば、CEN00001 というパッケージ ID では、CEN がソース サイトのサイト コードです。 パッケージのソース ファイルを復元するときは、障害発生前と同じ場所に復元する必要があります。 コンテンツの更新の詳細については、「配布ポイントのコンテンツの更新」の「Configuration Manager のコンテンツ管理の操作とメンテナンス」セクションを参照してください。

サイト サーバーのファイル システムのバックアップに、コンテンツ ライブラリとパッケージ ソースの両方の場所を含めていることを確認してください。

カスタム ソフトウェア更新プログラムのバックアップ

System Center Updates Publisher 2011 は、カスタム ソフトウェア更新プログラムの Windows Server Update Services (WSUS) への発行、ソフトウェア更新プログラムの Configuration Manager との同期、ソフトウェア更新プログラムのコンプライアンスの評価、およびカスタム ソフトウェア更新プログラムのクライアントへの展開を行えるスタンドアロン ツールです。Updates Publisher 2011 では、ソフトウェア更新プログラムのリポジトリとしてローカル データベースを使用します。Updates Publisher 2011 を使ってカスタム ソフトウェア更新プログラムを管理している場合は、Updates Publisher 2011 データベースをバックアップに含める必要があるかどうかを検討してください。 Updates Publisher の詳細については、System Center TechCenter ライブラリの「System Center Updates Publisher 2011」を参照してください。

次の手順に従って、Updates Publisher 2011 データベースをバックアップします。

Updates Publisher 2011 データベースをバックアップするには

1. Updates Publisher を実行しているコンピューターで、%USERPROFILE%\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.0000\ の Updates Publisher 2011 データベース ファイル (Scupdb.sdf) を見つけます。Updates Publisher 2011 を実行するユーザーごとに異なるデータベース ファイルがあります。

2. データベース ファイルをバックアップ先にコピーします。 たとえば、バックアップ先が E:\ConfigMgr_Backup の場合は、Updates Publisher 2011 データベース ファイルを E:\ConfigMgr_Backup\SCUP2011 にコピーします。

   ヒント
   コンピューターにデータベース ファイルが複数ある場合は、各データベース ファイルのユーザーを示すサブ フォルダーに保存することを検討してください。 たとえば、E:\ConfigMgr_Backup\SCUP2011\User1 というサブフォルダーと E:\ConfigMgr_Backup\SCUP2011\User2 というサブフォルダーに、それぞれ該当するデータベース ファイルを保存します。

ユーザー状態の移行データ

オペレーティング システムを展開するときに、現在のオペレーティング システムのユーザー状態を維持したい場合は、Configuration Manager のタスク シーケンスを使って、ユーザー状態データをキャプチャして復元します。 ユーザー状態データを格納しているフォルダーは、状態移行ポイントのプロパティに一覧されます。 このユーザー状態の移行データは、サイト サーバーのバックアップ メンテナンス タスクでバックアップされません。 そのため、ユーザー状態の移行データを格納するように指定したフォルダーを手動でバックアップする必要があります。 次の手順に従って、ユーザー状態の移行データを格納しているフォルダーを確認します。

ユーザー状態の移行データを格納しているフォルダーを確認するには

1. Configuration Manager コンソールで、[管理] をクリックします。

2. [管理] ワークスペースで [サイトの構成] を展開して、[サーバーとサイト システムの役割] をクリックします。

3. 状態移行規則をホストするサイト システムを選択してから、[サイト システムの役割] で [状態移行ポイント] を選択します。

4. [サイトの役割] タブの [プロパティ] グループで、[プロパティ] をクリックします。

5. ユーザー状態移行データが保存されているフォルダーが [全般] タブの [フォルダーの詳細] セクションに一覧表示されます。

Configuration Manager サイトの回復

Configuration Manager サイトで障害が発生した場合や、サイト データベースのデータがなくなった場合は、Configuration Manager サイトを回復する必要があります。 サイトの回復の中心となる作業は、データの修復と同期です。これは、業務の中断を防ぐためにも必要な作業です。 サイトの回復を開始するには、インストール メディアから Configuration Manager のセットアップ ウィザードを実行するか、無人インストール用スクリプトを記述し、Setup コマンドで /script オプションを指定します。 使用できる回復方法は、Configuration Manager サイト データベースのバックアップがあるかどうかによって異なります。

重要
サイトのデータベースを回復する場合は、SQL Server の同じバージョンとエディションを使用する必要があります。 たとえば、SQL Server 2008 上で稼働していたデータベースを SQL Server 2012 に復元することはできません。 同様に、SQL Server 2012 の Standard エディションで稼働していたサイト データベースを SQL Server 2012 の Enterprise エディションに復元することはできません。

サイトの回復を開始するには、インストール メディアから Configuration Manager のセットアップ ウィザードを実行するか、無人インストール用スクリプトを記述し、Setup コマンドで /script オプションを指定します。 使用できる回復方法は、Configuration Manager サイト データベースのバックアップがあるかどうかによって異なります。

重要
サイト サーバーの [スタート] メニューから Configuration Manager セットアップを実行する場合は、[サイトを回復する] オプションは使用できません。 インストール メディアからセットアップを実行する必要があります。

[!メモ]

データベースのレプリカ用に構成されたサイト データベースを復元した後で、データベースのレプリカを使用するためには、データベースの各レプリカを再構成して、パブリケーションとサブスクリプションの両方を再作成する必要があります。

回復オプションの検討

Configuration Manager のプライマリ サイト サーバーと中央管理サイトの回復を検討するときには、サイト サーバーとサイト データベースという 2 つの要素を考慮する必要があります。 どのオプションを選択するかを決めるときに、次のセクションを参考にしてください。

重要
Configuration Manager SP1 以降、セカンダリ サイトを復元する新しいオプションを使用できます。 セカンダリ サイトの回復については、「セカンダリ サイトの回復」セクションを参照してください。

[!メモ]

前に回復できなかったサイトや、完全にインストールされていないサイトを回復する場合は、まず、セットアップで [Configuration Manager をアンインストールする] オプションを選択しないと、サイトを回復するオプションを選択することはできません。 アンインストールしようとしているサイトに子サイトがある場合は、[Configuration Manager をアンインストールする] オプションを選択する前に、アンインストールするサイトのサイト データベースを手動で削除する必要があります。削除しないと、アンインストールが正常に完了しません。

サイト サーバーの回復オプション

[サイトを回復する] オプションを使用可能にするには、System Center 2012 Configuration Manager インストール メディア、またはソース ファイルを含むネットワーク共有フォルダーからセットアップを開始する必要があります。 セットアップを実行したときに、選択できる回復オプションは次のとおりです。

• 既存のバックアップを使用してこのサイト サーバーを回復する:このオプションは、サイト エラーの発生前に、[サイト サーバーのバックアップ] メンテナンス タスクの一部としてサイト サーバー上で作成された Configuration Manager サイト サーバーのバックアップが存在する場合に使用します。 サイトが再インストールされ、バックアップされているサイトに基づいて、サイト設定が構成されます。

• このサイト サーバーを再インストールする:サイト サーバーのバックアップを作成していない場合に、このオプションを使用してください。 サイト サーバーが再インストールされますが、初めてインストールしたときと同じようにして、サイト設定を指定する必要があります。 必ず、サイトを初めてインストールしたときと同じサイト コードとサイト データベース名を使ってください。

[!メモ]

セットアップ プログラムによって、サーバーに Configuration Manager サイトが存在することが検出された場合は、サイトの回復を開始できますが、選択できる回復オプションが限られています。 たとえば、既存のサイト サーバーでセットアップを実行した場合は、サイト データベース サーバーは回復できますが、サイト サーバーの回復オプションは無効になっています。

サイト データベースの回復オプション

セットアップを実行するときに、次のサイト データベースの回復オプションを選択できます。

• バックアップ セットを使用してサイト データベースを復元する:このオプションは、サイト データベース エラーの発生前に、サイト上で実行された [サイト サーバーのバックアップ] メンテナンス タスクの一部として作成された Configuration Manager サイト データベースのバックアップが存在する場合に使用します。 階層構造がある場合は、サイト データベースの最後のバックアップ以後に加えられた変更が、中央管理サイト (プライマリ サイトを回復するとき)、または基準プライマリ サイト (中央管理サイトを回復するとき) から取得されます。 スタンドアロンのプライマリ サイトのサイト データベースを回復する場合は、最後のバックアップ以後にサイトに加えられた変更を回復することはできません。

  階層内のサイトのサイト データベースを回復するときは、そのサイトが中央管理サイトとプライマリ サイトのどちらであるかと、最後のバックアップが SQL Server の変更の追跡の保有期間内に作成されたかどうかによって、回復方法が異なります。 詳細については、このトピックの「サイト データベースの回復方法」セクションを参照してください。

  [!メモ]

  サイト データベースが存在するのに、バックアップ セットを使用してサイト データベースを回復するオプションを選択した場合は、正常に回復できません。

• このサイトの新しいデータベースを作成する:Configuration Manager サイト データベースのバックアップを作成していない場合に、このオプションを使用してください。 階層構造がある場合は、新しいデータベースが作成され、プライマリ サイトの回復用には、中央管理サイトからレプリケートされたデータが使われ、中央管理サイトの回復用には、基準プライマリ サイトからレプリケートされたデータが使われます。 スタンドアロンのプライマリ サイトを回復する場合や、プライマリ サイトのない中央管理サイトを回復する場合は、このオプションを選択することはできません。

• 手動で回復したサイト データベースを使用する:このオプションは、Configuration Manager サイト データベースの回復は完了したものの、回復プロセスを完了させる必要がある場合に使用します。Configuration Manager では、サイト データベースを回復するときに、Configuration Manager のバックアップ メンテナンス タスクで行われたバックアップと、DPM または別のプロセスで行われたサイト データベース バックアップのどちらでも使用できます。Configuration Manager 以外で作成されたバックアップを使った場合は、サイト データベースの回復プロセスを完了するために、セットアップを実行して、このオプションを選択する必要があります。 階層構造がある場合は、サイト データベースの最後のバックアップ以後に加えられた変更が、中央管理サイト (プライマリ サイトを回復するとき)、または基準プライマリ サイト (中央管理サイトを回復するとき) から取得されます。 スタンドアロンのプライマリ サイトのサイト データベースを回復する場合は、最後のバックアップ以後にサイトに加えられた変更を回復することはできません。

  [!メモ]

  DPM を使用してサイト データベースをバックアップするときに、Configuration Manager で復元プロセスを続行する前に、DPM の手順を使用して指定の場所にサイト データベースを復元します。 DPM の詳細については、TechNet の「Data Protection Manager」ドキュメント ライブラリを参照してください。

• データベースの回復をスキップする:Configuration Manager サイト データベース サーバーでデータ損失が発生していない場合に、このオプションを使用してください。 このオプションは、回復しようとしているサイト サーバーとは別のコンピューターにサイト データベースがある場合だけ選択できます。

SQL Server の変更の追跡の保有期間

SQL Server のサイト データベースでは、変更の追跡機能が有効になっています。 そのため、過去のある時点以後にデータベース テーブルに加えられた変更に関する情報を、Configuration Manager が照会することができます。 保有期間とは、この変更の追跡データを残しておく期間のことです。 既定では、サイト データベースの追跡データの保有期間は 5 日に構成されています。 サイト データベースを回復するときは、バックアップがこの保有期間内に作成されたかどうかによって、回復プロセスが異なります。 たとえば、サイト データベースで障害が発生した時点で、最も新しいバックアップが作成後 7 日経過している場合は、保有期間外に作成されていることになります。

サイトのデータまたはグローバル データの再初期化プロセス

サイトのデータまたはグローバル データの再初期化とは、サイト データベースにある既存のデータを別のサイト データベースに置き換えるプロセスのことです。 たとえば、"ABC" というサイトのデータを "XYZ" というサイトのデータで再初期化するときは、次の処理が行われます。

• サイト "XYZ" からサイト "ABC" にデータがコピーされます。

• サイト "ABC" のサイト データベースから、サイト "XYZ" の既存のデータが削除されます。

• サイト "XYZ" からコピーされたデータが、サイト "ABC" のサイト データベースに挿入されます。

例 1

プライマリ サイトを、中央管理サイトのグローバル データで再初期化する:回復プロセスで、プライマリ サイト データベースにあるプライマリ サイト用グローバル データが削除され、中央管理サイトからコピーされたグローバル データに置き換えられます。

例 2

中央管理サイトを、プライマリ サイトのサイト データで再初期化する:回復プロセスで、中央管理サイト データベースにある、該当するプライマリ サイト用サイト データが削除され、そのプライマリ サイトからコピーされたサイト データに置き換えられます。 他のサイト用のサイト データは影響を受けません。

サイト データベースの回復方法

サイト データベースがバックアップから復元されると、Configuration Manager では前回のデータベースのバックアップ以後にサイト データとグローバル データに加えられた変更の回復が開始されます。 次の表に、サイト データベースがバックアップから復元された後で、Configuration Manager によって行われる処理を示します。

	データベースが、変更の追跡の保有期間以内にバックアップされている場合		データベースが、変更の追跡の保有期間より前にバックアップされている場合
回復するサイト	グローバル データ	サイト データ	グローバル データ	サイト データ
プライマリ サイト	バックアップ以後にグローバル データに加えられた変更を、中央管理サイトからレプリケートします。	中央管理サイトを、プライマリ サイトのサイト データで再初期化します。 バックアップ以後に加えられた変更は失われますが、データの大部分は、プライマリ サイトに情報を送信するクライアントによって、再び生成されます。	プライマリ サイトを、中央管理サイトのグローバル データで再初期化します。	中央管理サイトを、プライマリ サイトのサイト データで再初期化します。 バックアップ以後に加えられた変更は失われますが、データの大部分は、プライマリ サイトに情報を送信するクライアントによって、再び生成されます。
中央管理サイト	バックアップ以後にグローバル データに加えられた変更を、プライマリ サイトからレプリケートします。	バックアップ以後にサイト データに加えられた変更を、すべてのプライマリ サイトからレプリケートします。	中央管理サイトを、プライマリ サイトのサイト データで再初期化します。 他のすべてのプライマリ サイトを、中央管理サイトのグローバル データで再初期化します。 基準サイトを指定していない場合は、すべてのプライマリ サイトを、中央管理サイトのグローバル データ (バックアップから復元されたデータ) で再初期化します。	中央管理サイトを、各プライマリ サイトのサイト データで再初期化します。

サイトの回復手順

次のいずれかの手順に従って、サイト サーバーとサイト データベースを回復します。

セットアップ ウィザードを使ってサイトの回復を開始するには

1. Configuration Manager のセットアップ ウィザードを、インストール メディアかネットワークの共有フォルダーから実行します。 たとえば、Configuration Manager DVD を挿入するときに、[インストール] オプションを使用して、セットアップ ウィザードを開始できます。 または、ネットワークの共有フォルダーにある Setup.exe を開きます。

2. [はじめに] ページで、[サイトを回復する] を選択してから、[次へ] をクリックします。

3. 表示される指示に従って、順次適切なオプションを選択し、ウィザードを完了します。

   重要
   サイトの回復中に、セットアップ プログラムによって、SQL Server で使用している SQL Server Service Broker (SSB) のポートが検出されます。 サイトの回復中に、このポートの設定を変更しないでください。変更すると、回復が完了した後で、データが正しくレプリケートされません。

   [!メモ]

   System Center 2012 R2 Configuration Manager から、セットアップ ウィザードで Configuration Manager の任意のインストール先パスを指定できるようになりました。 これより前のバージョンでは、サイトが元々インストールされていた場所のパスしか指定できませんでした。

サイトの無人回復を開始するには

1. サイトを回復するのに必要な無人インストール スクリプトを準備します。

2. コマンド /script オプションを使用して Configuration Manager セットアップを実行します。 たとえば、セットアップの初期化ファイルに ConfigMgrUnattend.ini という名前を付けて、Setup コマンドを実行するコンピューターの C:\Temp ディレクトリに保存した場合、コマンドは次のようになります:Setup /script C:\temp\ConfigMgrUnattend.ini

サイトの無人回復スクリプト ファイルのキー

Configuration Manager の中央管理サイト、またはプライマリ サイトの無人回復を実施するには、無人インストール スクリプトを作成して、Setup コマンドに /script オプションを付けて実行します。 このスクリプトで、セットアップ ウィザードで入力するのと同じ種類の情報を指定します。ただし、既定の設定はありません。 使用する回復方法に該当するセットアップ キーの値をすべて指定する必要があります。

Configuration Manager の無人セットアップを実行するには、初期化ファイルと、/script Setup コマンドライン オプションを使用します。 無人セットアップは、Configuration Manager の中央管理サイトとプライマリ サイトの回復でサポートされています。 /script Setup コマンド ライン オプションを使用するには、初期化ファイルを作成して、/script Setup コマンド ライン オプションの後ろに、その初期化ファイル名を入力する必要があります。 .ini という拡張子が付いている限り、ファイル名そのものは重要ではありません。 コマンド ラインでセットアップ初期化ファイルを指定するときは、そのファイルの完全パスを入力する必要があります。 たとえば、C:\setup フォルダーにある setup.ini というセットアップ初期化ファイルを使う場合は、コマンド ラインに次のように入力します。

setup /script c:\setup\setup.ini

セキュリティ メモ
Setup コマンドを実行するには、管理者権限が必要です。 必ず、[管理者として実行] を選択してから、コマンド プロンプトを開いてください。

スクリプトは、セクション名、キー名、値で構成します。 セクションの必須キーは、スクリプトを記述している回復の種類によって異なります。 セクション内でのキーの順序、およびファイル内でのセクションの順序は重要ではありません。 キー名の大文字と小文字は区別されません。 キーの値を指定するときは、キー名の後ろに等号 (=) 入力してから、キーの値を続けます。

次のセクションにある表を、サイトの無人回復用スクリプトを記述するときの参考にしてください。 この表には、スクリプトで指定できるキーとその値、必須かどうかの別、該当するインストールの方法、およびキーの説明が示されています。

中央管理サイトの無人回復

次の情報を、無人セットアップ用スクリプト ファイルを使って中央管理サイトを回復するときの参考にしてください。

セクション	キー名	必須	値	説明
Identification	操作	○	RecoverCCAR	中央管理サイトを回復します。
RecoveryOptions	ServerRecoveryOptions	○	1、2、4 1 = サイト サーバーと SQL Server を回復します。 2 = サイト サーバーだけを回復します。 4 = SQL Server だけを回復します。	セットアップでサイト サーバーと SQL Server のいずれか、または両方を回復するかを指定します。 ServerRecoveryOptions の設定値によって、関連するキーの設定が異なります。 値 = 1:サイトのバックアップを使ってサイトを回復したい場合は、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。 DatabaseRecoveryOptions キーを 10 に設定して、バックアップからサイト データベースが復元されるようにした場合は、BackupLocation キーを指定する必要があります。 値 = 2:サイトのバックアップを使ってサイトを回復したい場合は、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。 値を 4 に設定した場合:DatabaseRecoveryOptions キーを 10 に設定して、バックアップからサイト データベースが復元されるようにした場合は、BackupLocation キーを指定する必要があります。
	DatabaseRecoveryOptions	状況によって異なる	10、20、40、80 10 = バックアップからサイト データベースを復元します。 20 = 別の方法を使って手動で回復されたサイト データベースを使用します。 40 = サイトの新しいデータベースを作成します。 サイト データベースのバックアップがない場合に、このオプションを使用してください。 グローバル データとサイト データは、別のサイトをレプリケートすることによって回復します。 80 = データベースの回復をスキップします。	セットアップで SQL Server のサイト データベースをどのように回復するかを指定します。 このキーは、ServerRecoveryOptions キーを 1 または 4 に設定したときに必要です。
	ReferenceSite	状況によって異なる	<ReferenceSiteFQDN>	データベースのバックアップが変更の追跡の保有期間より前に作成されているか、バックアップなしでサイトを回復する場合に、中央管理サイトでグローバル データを回復するために使用する基準プライマリ サイトを指定します。 バックアップが変更の追跡の保有期間より前に作成されており、基準サイトを指定しなかった場合は、すべてのプライマリ サイトが、中央管理サイトから復元されたデータで再初期化されます。 バックアップが変更の追跡の保有期間内に作成されており、基準サイトを指定しなかった場合は、バックアップ作成以後に加えられた変更だけが、プライマリ サイトからレプリケートされます。 プライマリ サイト同士の変更内容が競合している場合は、中央管理サイトで、最初に受け取った変更内容が採用されます。 このキーは、DatabaseRecoveryOptions キーを 40 に設定したときに必要です。
	SiteServerBackupLocation	×	<PathToSiteServerBackupSet>	サイト サーバーのバックアップ セットがある場所を指定します。 このキーは、ServerRecoveryOptions キーを 1 か 2 に設定したときにオプションで指定するキーです。 サイトのバックアップを使ってサイトを回復したい場合に、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。
	BackupLocation	状況によって異なる	<PathToSiteDatabaseBackupSet>	サイト データベースのバックアップ セットがある場所を指定します。BackupLocation キーは、ServerRecoveryOptions キーを 1 か 4 に設定したときに必要です。このキーを指定したときは、DatabaseRecoveryOptions キーを 10 に設定してください。
Options	ProductID	○	xxxxx-xxxxx-xxxxx-xxxxx-xxxxx Eval	インストールする Configuration Manager のプロダクト キー。必ず、ダッシュも入力してください。Configuration Manager の試用版をインストールする場合は、Evalと入力します。
	SiteCode	○	<SiteCode>	階層内のサイトを識別する固有の英数字 3 文字。 障害が発生する前にサイトに付いていたサイト コードを指定する必要があります。 サイト コードの制限の詳細については、「Configuration Manager サイトの名前付け」トピックの「Configuration Manager のサイトのインストールと階層の作成」セクションを参照してください。
	SiteName	○	<SiteName>	このサイトの説明。
	SMSInstallDir	○	<ConfigMgrInstallationPath>	Configuration Manager のプログラム ファイルのインストール フォルダーを指定します。 > [!メモ] > <P>System Center 2012 R2 Configuration Manager から、Configuration Manager の任意のインストール パスを指定できるようになりました。 これより前のバージョンでは、サイトで障害が発生する前に使っていたパスしか指定できませんでした。</P> </div> </td>
	SDKServer	○	<SMS プロバイダーの FQDN>	SMS プロバイダーをホストするサーバーの FQDN を指定します。 障害が発生する前に SMS プロバイダーをホストしていたサーバーを指定する必要があります。 初期インストールが終わった後で、他の SMS プロバイダーを追加して構成することができます。 SMS プロバイダーの詳細については、「Configuration Manager のサイト システムの役割」トピックの「Configuration Manager のサイト システムの計画」セクションを参照してください。
	PrerequisiteComp	○	0 または 1 0 = ダウンロードします。 1 = 既にダウンロードされています。	セットアップの前提条件ファイルが既にダウンロード済みかどうかを指定します。 この値を 0 に設定すると、セットアップ時にファイルがダウンロードされます。
	PrerequisitePath	○	<PathToSetupPrerequisiteFiles>	セットアップの前提条件ファイルのパスを指定します。 このパスは、PrerequisiteComp キーに設定した値に応じて、ダウンロードしたファイルを保存するか、ダウンロード済みのファイルを見つけるために使われます。
	AdminConsole	状況によって異なる	0 または 1 0 = インストールしません。 1 = インストールします。	Configuration Manager コンソールをインストールするかどうかを指定します。 このキーは、ServerRecoveryOptions キーを 4 以外の値に設定した場合に必要です。
	JoinCEIP	○	0 または 1 0 = 参加しません。 1 = 参加します。	カスタマー エクスペリエンス向上プログラムに参加するかどうかを指定します。
SQLConfigOptions	SQLServerName	○	<SQLServerName>	サイト データベースをホストする SQL Server を実行しているサーバー、またはクラスター化されている場合はインスタンス名。 障害が発生する前にサイト データベースをホストしていたサーバーを指定する必要があります。
	DatabaseName	○	<SiteDatabaseName> または <InstanceName>\<SiteDatabaseName>	中央管理サイト データベースをインストールするために作成または使用する SQL Server データベースの名前。 障害が発生する前に使用していたデータベース名と同じ名前を指定する必要があります。 重要 既定のインスタンスを使用しない場合は、必ず、インスタンス名とサイト データベース名を指定してください。
	SQLSSBPort	×	<SSBPortNumber>	SQL Server で使用する SQL Server Service Broker (SSB) のポート番号を指定します。 通常、TCP ポート 4022 に構成しますが、別のポートもサポートされています。 障害が発生する前に使用していた SSB ポート番号と同じ番号を指定する必要があります。

プライマリ サイトの無人回復

次の情報を、無人セットアップ用スクリプト ファイルを使ってプライマリ サイトを回復するときの参考にしてください。

セクション	キー名	必須	値	説明
Identification	操作	○	RecoverPrimarySite	プライマリ サイトを回復します。
RecoveryOptions	ServerRecoveryOptions	○	1、2、4 1 = サイト サーバーと SQL Server を回復します。 2 = サイト サーバーだけを回復します。 4 = SQL Server だけを回復します。	セットアップでサイト サーバーと SQL Server のいずれか、または両方を回復するかを指定します。 ServerRecoveryOptions の設定値によって、関連するキーの設定が異なります。 値 = 1:サイトのバックアップを使ってサイトを回復したい場合は、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。 DatabaseRecoveryOptions キーを 10 に設定して、バックアップからサイト データベースが復元されるようにした場合は、BackupLocation キーを指定する必要があります。 値 = 2:サイトのバックアップを使ってサイトを回復したい場合は、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。 値を 4 に設定した場合:DatabaseRecoveryOptions キーを 10 に設定して、バックアップからサイト データベースが復元されるようにした場合は、BackupLocation キーを指定する必要があります。
	DatabaseRecoveryOptions	状況によって異なる	10、20、40、80 10 = バックアップからサイト データベースを復元します。 20 = 別の方法を使って手動で回復されたサイト データベースを使用します。 40 = サイトの新しいデータベースを作成します。 サイト データベースのバックアップがない場合に、このオプションを使用してください。 80 = データベースの回復をスキップします。	セットアップで SQL Server のサイト データベースをどのように回復するかを指定します。 このキーは、ServerRecoveryOptions キーを 1 または 4 に設定したときに必要です。
	SiteServerBackupLocation	×	<PathToSiteServerBackupSet>	サイト サーバーのバックアップ セットがある場所を指定します。 このキーは、ServerRecoveryOptions キーを 1 か 2 に設定したときにオプションで指定するキーです。 サイトのバックアップを使ってサイトを回復したい場合に、SiteServerBackupLocation キーでバックアップの場所を指定します。 値を指定しなかった場合は、バックアップを使わずにサイトが再インストールされます。
	BackupLocation	状況によって異なる	<PathToSiteDatabaseBackupSet>	サイト データベースのバックアップ セットがある場所を指定します。BackupLocation キーは、ServerRecoveryOptions キーを 1 か 4 に設定したときに必要です。このキーを指定したときは、DatabaseRecoveryOptions キーを 10 に設定してください。
Options	ProductID	○	xxxxx-xxxxx-xxxxx-xxxxx-xxxxx Eval	インストールする Configuration Manager のプロダクト キー。必ず、ダッシュも入力してください。Configuration Manager の試用版をインストールする場合は、Evalと入力します。
	SiteCode	○	<SiteCode>	階層内のサイトを識別する固有の英数字 3 文字。 障害が発生する前にサイトに付いていたサイト コードを指定する必要があります。 サイト コードの制限の詳細については、「Configuration Manager サイトの名前付け」トピックの「Configuration Manager のサイトのインストールと階層の作成」セクションを参照してください。
	SiteName	○	<SiteName>	このサイトの説明。
	SMSInstallDir	○	<ConfigMgrInstallationPath>	Configuration Manager のプログラム ファイルのインストール フォルダーを指定します。 > [!メモ] > <P>System Center 2012 R2 Configuration Manager から、Configuration Manager の任意のインストール パスを指定できるようになりました。 これより前のバージョンでは、サイトで障害が発生する前に使っていたパスしか指定できませんでした。</P> </div> </td>
	SDKServer	○	<SMS プロバイダーの FQDN>	SMS プロバイダーをホストするサーバーの FQDN を指定します。 障害が発生する前に SMS プロバイダーをホストしていたサーバーを指定する必要があります。 初期インストールが終わった後で、他の SMS プロバイダーを追加して構成することができます。 SMS プロバイダーの詳細については、「Configuration Manager のサイト システムの役割」トピックの「Configuration Manager のサイト システムの計画」セクションを参照してください。
	PrerequisiteComp	○	0 または 1 0 = ダウンロードします。 1 = 既にダウンロードされています。	セットアップの前提条件ファイルが既にダウンロード済みかどうかを指定します。 この値を 0 に設定すると、セットアップ時にファイルがダウンロードされます。
	PrerequisitePath	○	<PathToSetupPrerequisiteFiles>	セットアップの前提条件ファイルのパスを指定します。 このパスは、PrerequisiteComp キーに設定した値に応じて、ダウンロードしたファイルを保存するか、ダウンロード済みのファイルを見つけるために使われます。
	AdminConsole	状況によって異なる	0 または 1 0 = インストールしません。 1 = インストールします。	Configuration Manager コンソールをインストールするかどうかを指定します。 このキーは、ServerRecoveryOptions キーを 4 以外の値に設定した場合に必要です。
	JoinCEIP	○	0 または 1 0 = 参加しません。 1 = 参加します。	カスタマー エクスペリエンス向上プログラムに参加するかどうかを指定します。
SQLConfigOptions	SQLServerName	○	<SQLServerName>	サイト データベースをホストする SQL Server を実行しているサーバー、またはクラスター化されている場合はインスタンス名。 障害が発生する前にサイト データベースをホストしていたサーバーを指定する必要があります。
	DatabaseName	○	<SiteDatabaseName> または <InstanceName>\<SiteDatabaseName>	中央管理サイト データベースをインストールするために作成または使用する SQL Server データベースの名前。 障害が発生する前に使用していたデータベース名と同じ名前を指定する必要があります。 重要 既定のインスタンスを使用しない場合は、必ず、インスタンス名とサイト データベース名を指定してください。
	SQLSSBPort	×	<SSBPortNumber>	SQL Server で使用する SQL Server Service Broker (SSB) のポート番号を指定します。 通常、TCP ポート 4022 に構成しますが、別のポートもサポートされています。 障害が発生する前に使用していた SSB ポート番号と同じ番号を指定する必要があります。
HierarchyExpansionOption	CCARSiteServer	状況によって異なる	<SiteCodeForCentralAdministrationSite>	プライマリ サイトを Configuration Manager 階層構造に含めるときに、アタッチする中央管理サイトを指定します。 障害が発生する前にプライマリ サイトが中央管理サイトにアタッチされていた場合は、この設定が必要です。 障害が発生する前に中央管理サイトに付いていたサイト コードを指定する必要があります。
	CASRetryInterval	×	<Interval>	中央管理サイトとの接続が切断されたときに、接続を再試行する間隔 (分) を指定します。 たとえば、プライマリ サイトと中央管理サイトの接続が切断されると、プライマリ サイトは、このキーで指定された時間だけ待ってから、もう一度接続しようとします。
	WaitForCASTimeout	×	<Timeout>	プライマリ サイトから中央管理サイトに接続するときのタイムアウトの最大値 (分) を指定します。 たとえば、プライマリ サイトから中央管理サイトに接続できなかった場合は、プライマリ サイトは、WaitForCASTimeout キーで指定された時間が経過するまで、CASRetryInterval キーの値に従って、中央管理サイトとの接続を再試行します。 0 ～ 100 に指定できます。

回復後の作業

サイトを回復した後で行わなければならない作業がいくつかあります。 次のセクションの情報を、サイトの回復プロセスを完了させるときの参考にしてください。

ユーザー アカウントのパスワードを再入力する

サイト サーバーの回復が終わったら、そのサイトに指定していたユーザー アカウントのパスワードを再入力する必要があります。これは、サイトの回復中にパスワードがリセットされるためです。 これらのアカウントは、サイトの回復が終わったときに、セットアップ ウィザードの [完了] ページに一覧され、回復したサイト サーバーの C:\ConfigMgrPostRecoveryActions.html に保存されます。

サイトの回復後にユーザー アカウントのパスワードを再入力するには

1. Configuration Manager コンソールを開き、回復したサイトに接続します。

2. Configuration Manager コンソールで、[管理] をクリックします。

3. [管理] ワークスペースで、[セキュリティ] を展開してから、[アカウント] をクリックします。

4. パスワードを入力する必要のあるアカウントごとに、次の操作を行います。

   1. サイトの回復が終わったときに保存されたアカウントの一覧で、アカウントを選択します。 この一覧は、回復したサイト サーバーの C:\ConfigMgrPostRecoveryActions.html にあります。

   2. [ホーム] タブの [プロパティ] グループで、[プロパティ] をクリックしてアカウントのプロパティを開きます。

   3. [全般] タブで、[設定] をクリックしてから、アカウントのパスワードを再入力します。

   4. [確認] をクリックし、選択したユーザー アカウントの適切なデータ ソースを選択します。[接続のテスト] をクリックして、そのユーザー アカウントでデータ ソースに接続できるかどうかを確認します。

   5. [OK] をクリックしてパスワードの変更を保存してから、[OK] をクリックします。

サイドローディング キーの再入力

System Center 2012 R2 Configuration Manager 以降:

サイト サーバーの回復が終わったら、そのサイトに指定していた Windows サイドローディング キーを再入力する必要があります。これは、サイトの回復中にサイドローディング キーがリセットされるためです。 サイドローディング キーを再入力すると、Configuration Manager コンソールで Windows サイドローディング キーの [使用済みライセンス認証数] 列内のカウントがリセットされます。 たとえば、サイト エラーが発生する前に、[合計ライセンス認証数] カウントが 100 に設定され、[使用済みライセンス認証数] がデバイスで使用されていたキーの数に相当する 90 になっていたとします。 サイトの回復後、[合計ライセンス認証数] 列には 100 と表示されますが、[使用済みライセンス認証数] 列には誤って 0 と表示されます。 しかし、新しく 10 台のデバイスがサイドローディング キーを使用すると、ライセンスの残りがなくなってしまうので、11 台目以降、キーを取得できなくなります。 サイドローディング キーの指定については、「モバイル デバイスの登録を準備する」の「Configuration Manager と Microsoft Intune を使用してモバイル デバイスを管理する」セクションを参照してください。

IIS を使用するサイト システムの役割の SSL を構成する

IIS を実行するサイト システムを回復し、障害が発生する前に、そのシステムが HTTPS 接続用に構成されていた場合は、IIS で Web サーバー証明書を使用するように再構成する必要があります。 詳細については、「IIS を実行するサイト システム用のWeb サーバー証明書の展開」の「Configuration Manager PKI 証明書の展開手順の例:Windows Server 2008 証明機関」セクションにある「IIS で Web サーバー証明書を使用するように構成する」を参照してください。

回復したサイト サーバーに修正プログラムを再インストールする

サイトの回復が終わったら、障害が発生する前にサイト サーバーに適用されていた修正プログラムを再インストールする必要があります。 これらの修正プログラムは、サイトの回復が終わったときに、セットアップ ウィザードの [完了] ページに一覧され、回復したサイト サーバーの C:\ConfigMgrPostRecoveryActions.html に保存されます。

Reporting Services を実行しているコンピューターで使用していたカスタム レポートを復元する

Reporting Services で障害が発生する前に、Reporting Services のカスタム レポートを作成していた場合は、レポート サーバーのバックアップ (存在する場合) から、カスタム レポートを復元することができます。 Reporting Services のカスタム レポートの復元の詳細については、SQL Server 2008 Books Online の「Reporting Services インストールのバックアップおよび復元操作」を参照してください。

コンテンツ ファイルを回復する

サイト データベースには、サイト サーバーでのコンテンツ ファイルの保存場所に関する情報が含まれていますが、コンテンツ ファイル自体は、バックアップと復元プロセスで、バックアップも復元もされません。 コンテンツ ファイルを完全に回復するには、コンテンツ ライブラリのファイルとパッケージ ソース ファイルを元の場所に復元する必要があります。 コンテンツ ファイルを回復する方法はいくつかありますが、一番簡単なのは、サイト サーバーのファイル システムのバックアップからファイルを復元する方法です。

パッケージ ソース ファイル復元用のファイル システムのバックアップがない場合は、最初にパッケージを作成したときと同じようにして、ファイルを手動でコピーしたりダウンロードしたりする必要があります。 すべてのパッケージとアプリケーションのパッケージ ソースの場所を見つけるには、SQL Server で SELECT * FROM v_Package というクエリを実行します。 パッケージ ID の先頭の 3 文字を見ると、パッケージ ソースのサイトがわかります。 たとえば、CEN00001 というパッケージ ID では、CEN がソース サイトのサイト コードです。 パッケージのソース ファイルを復元するときは、障害発生前と同じ場所に復元する必要があります。

コンテンツ ライブラリが含まれているファイル システムのバックアップがない場合は、次の方法でコンテンツ ファイルを復元できます。

• 事前設定済みのコンテンツ ファイルをインポートする:Configuration Manager 階層構造がある場合は、別の場所にあるすべてのパッケージとアプリケーションの事前設定済みコンテンツ ファイルを作成し、そのファイルをインポートして、サイト サーバーのコンテンツ ライブラリを回復します。 事前設定済みコンテンツ ファイルの詳細については、「コンテンツの事前設定」の「Configuration Manager のコンテンツ管理の操作とメンテナンス」セクションを参照してください。

• コンテンツを更新する:パッケージまたはアプリケーションの展開の種類のコンテンツの更新操作を開始すると、コンテンツがパッケージ ソースからコンテンツ ライブラリにコピーされます。 この処理が正常に完了するには、パッケージ ソース ファイルが元の場所になければなりません。 回復したいパッケージとアプリケーションごとに、コンテンツの更新操作を行う必要があります。 コンテンツの更新の詳細については、「配布ポイントのコンテンツの更新」の「Configuration Manager のコンテンツ管理の操作とメンテナンス」セクションを参照してください。

Updates Publisher を実行していたコンピューターのカスタム ソフトウェア更新プログラムを回復する

Updates Publisher 2011 データベース ファイルをバックアップに含めていた場合は、Updates Publisher 2011 を実行していたコンピューターで障害が発生したときに、そのデータベースを回復できます。 Updates Publisher の詳細については、System Center TechCenter ライブラリの「System Center Updates Publisher 2011」を参照してください。

次の手順に従って、Updates Publisher 2011 データベースを復元します。

Updates Publisher 2011 データベースを復元するには

1. 回復したコンピューターに Updates Publisher 2011 をインストールします。

2. バックアップしていたデータベース ファイル (Scupdb.sdf) を、Updates Publisher 2011 を実行するコンピューターの %ユーザー プロファイル%\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.0000\ にコピーします。

3. コンピューターで複数のユーザーが Updates Publisher 2011 を実行する場合は、それぞれのユーザー プロファイルの適切な場所に、データベース ファイルをコピーする必要があります。

ユーザー状態の移行データ

状態移行ポイントのサイト システムのプロパティを設定するときに、ユーザー状態の移行データを保存するフォルダーを指定しています。 ユーザー状態の移行データを保存するフォルダーのあるサーバーを回復したら、障害発生前にデータを保存していたフォルダーと同じフォルダーに、ユーザー状態の移行データを手動で復元する必要があります。

クラウドベースの配布ポイントに使用する証明書の更新

System Center 2012 Configuration Manager SP1 以降:

Configuration Manager では、サイト サーバーからクラウドベースの配布ポイントへの通信に使用する管理証明書が必要です。 サイトの回復後に、クラウドベースの配布ポイントの証明書を更新する必要があります。 詳細については、「クラウドベースの配布ポイントのサブスクリプションと証明書について」トピックの「Configuration Manager のコンテンツ管理の計画」セクションを参照してください。

障害発生前にプロビジョニングしていた Intel AMT 搭載コンピューターを再プロビジョニングする

サイトの回復が終わったら、次の構成手順に従います。

1. AMT プロビジョニング証明書を取得し直し、帯域外サービス ポイントのプロパティで、その証明書を選択します。

2. 帯域外管理コンポーネントのプロパティで、次のアカウントのパスワードを再構成します。

   • MEBx アカウント

   • AMT プロビジョニングの削除アカウント

   • AMT プロビジョニングと探索アカウント

この手順の詳細については、「Configuration Manager でAMT ベースのコンピューターをプロビジョニングし、設定する方法」を参照してください。

次に、以下の手順に従って、前にプロビジョニングされていた Intel AMT 搭載コンピューターを再プロビジョニングします。

Intel AMT 搭載コンピューターを再プロビジョニングするには

1. 帯域外管理コンポーネントのプロパティで、AMT プロビジョンングの削除アカウントを構成していることを確認します。

2. Intel AMT 搭載コンピューターから、ATM プロビジョニング情報を削除します。

   - \[**自動プロビジョニングを無効にする**\] は選択しません。
   
   - \[**AMT プロビジョニングの削除アカウントを使用する**\] を選択します。
   

   AMT プロビジョニング情報を削除する方法の詳細については、「AMT 情報を削除する方法」を参照してください。

3. コンピューターの AMT の次の状態を確認します。

   - **プロビジョニングされていません**:この状態のコンピューターは、Configuration Manager で再プロビジョニングする準備ができています。
   
   - **検出**:この状態のコンピューターは、Configuration Manager で再プロビジョニングできません。Configuration Manager で AMT プロビジョニング情報を削除できなかった場合は、コンピューターの BIOS 拡張を構成して、この情報を手動で削除する必要があります。
   
     <div class="alert">
   
   
     > [!メモ]
     > <P>監査証跡が有効でロック解除されている場合や、AMT プロビジョニングの削除アカウント用に構成されているアカウントが、そのコンピューターの AMT ユーザー アカウントでない場合は、AMT プロビジョニングの削除アカウントで、プロビジョニング情報を削除することはできません。</P>
   
   
     </div>
   

4. コレクションのプロパティの [帯域外管理 ] タブで、[AMT 搭載コンピューターのプロビジョニングを有効にする] チェック ボックスがオンになっていることを確認します。

5. AMT の状態が "プロビジョニング済み" に変わったことを確認します。 帯域外管理コントローラーが搭載されているコンピューターを表示するレポートを実行して、AMT のプロビジョニング状態を確認することもできます。

セカンダリ サイトの回復

System Center 2012 Configuration Manager SP1 以降:

Configuration Manager はセカンダリ サイトのデータベースのバックアップをサポートしていませんが、セカンダリ サイトの再インストールによる回復はサポートしています。 セカンダリ サイトの回復は、Configuration Manager セカンダリ サイトで障害が発生した場合に必要になります。Configuration Manager コンソールの [サイト] ノードから、[セカンダリ サイトの回復] アクションを使用してセカンダリ サイトを回復することができます。 中央管理サイトまたはプライマリ サイトの回復とは異なり、セカンダリ サイトの回復ではバックアップ ファイルを使用せず、代わりに障害が発生したセカンダリ サイトのコンピューターにセカンダリ サイトのファイルを再インストールします。 次に、セカンダリ サイトのデータが、親プライマリ サイトからのデータで再初期化されます。 回復プロセスで、Configuration Manager は、セカンダリ サイトのコンピューターにコンテンツ ライブラリが存在することと、適切なコンテンツが使用できることを確認します。 適切なコンテンツが含まれている場合、セカンダリ サイトでは、既存のコンテンツ ライブラリが使用されます。 それ以外の場合、回復したセカンダリ サイトのコンテンツ ライブラリを回復するには、回復したサイトにコンテンツを再配布するかまたは事前設定する必要があります。 詳細については、「Configuration Manager のコンテンツ管理の操作とメンテナンス」をご覧ください。 使用する配布ポイントがセカンダリ サイトに存在するのではない場合は、セカンダリ サイトの回復中に配布ポイントを再インストールする必要はありません。 セカンダリ サイトの回復後に、サイトが配布ポイントと自動的に同期されます。

Configuration Manager コンソールの [サイト] ノードから [インストール ステータスの表示] アクションを使用して、セカンダリ サイトの回復のステータスを確認することができます。

重要
セカンダリ サイトを適切に回復するには、障害が発生したコンピューターと同じ構成 (FQDN など) のコンピューターを使用する必要があります。 コンピューターがセカンダリ サイトのすべての前提条件を満たしており、適切なセキュリティ権限が構成されていることも必要です。 また、障害が発生したサイトに使用したのと同じインストール パスを使用してください。

重要
コンピューターに SQL Server Express がインストールされていない場合、セカンダリ サイトの回復中に Configuration Manager によってインストールされません。 そのため、セカンダリ サイトを回復する前に、SQL Server Express または SQL Server を手動でインストールする必要があります。 障害が発生する前にセカンダリ サイト データベースで使用していたのと同じバージョンの SQL Server および同じ SQL Server インスタンスを使用する必要があります。

参照

Configuration Manager でのサイト管理の操作とメンテナンス