Configuration Manager サイトを回復する
Configuration Manager (現在のブランチ) に適用
サイトが失敗した後、またはサイト データベースでデータ損失が発生した後に、Configuration Managerサイトの回復を実行します。 データの修復と再同期は、サイトの回復の中核となるタスクであり、操作の中断を防ぐために必要です。
この記事のセクションは、Configuration Manager サイトの回復に役立ちます。 バックアップを作成するには、「Configuration Managerのバックアップ」を参照してください。
サイトを復旧する前の考慮事項
重要
この情報は、サイトの回復シナリオにのみ適用されます。 オンプレミスインフラストラクチャをアップグレードし、障害が発生したサイトをアクティブに復旧していない場合は、次の記事の情報を確認してください。
サーバー ハードウェアを準備する
サイト サーバーに既存の構成が存在しないことを確認します。 以前の構成では、サイトの回復プロセス中に競合が発生する可能性があります。 サーバー ハードウェアには、次のいずれかのオプションを使用します。
一般的な要件と復旧要件を満たす新しいサーバーを使用します。
ディスクをフォーマットし、既存のサーバーに OS を再インストールします。 一般的な要件と復旧要件を満たしていることを確認します。
クリーンアップした既存のサーバーを再利用する
次のいずれかの手順を使用して、既存のサーバーをクリーンします。
サイト サーバーの回復専用に既存のサーバーをクリーンアップする
- SMS レジストリ キーを削除します。
HKLM\Software\Microsoft\SMS - で始まる
SMSレジストリ エントリを からHKLM\System\CurrentControlSet\Services削除します。 例:- SMS_DISCOVERY_DATA_MANAGER
- SMS_EXECUTIVE
- SMS_INBOX_MONITOR
- SMS_INVENTORY_DATA_LOADER
- SMS_LAN_SENDER
- SMS_MP_FILE_DISPATCH_MANAGER
- SMS_SCHEDULER
- SMS_SITE_BACKUP
- SMS_SITE_COMPONENT_MANAGER
- SMS_SITE_SQL_BACKUP
- SMS_SITE_VSS_WRITER
- SMS_SOFTWARE_METERING_PROCESSOR
- SMS_STATE_SYSTEM
- SMS_STATUS_MANAGER
- SMS_WSUS_SYNC_MANAGER
- SMSvcHost 3.0.0.0
- SMSvcHost 4.0.0.0
- Configuration Manager コンソールをアンインストールする
- サーバーを再起動する
- 上記のレジストリ キーがすべて削除されていることを確認します。
これで、サーバーはConfiguration Manager復元手順の準備ができました。
サイト データベースの復旧専用に既存のサーバーをクリーンアップする
- サイト データベースをバックアップします。 WSUS など、他のサポート データベースもバックアップします。
- SQL Server名とインスタンス名を必ず書き留めます
- SQL Serverからサイト データベースを手動で削除する
- SQL Serverを再起動する
これで、サーバーはConfiguration Manager復元手順の準備ができました。
完全復旧のために既存のサーバーをクリーンアップする
- サイト データベースをバックアップします。 WSUS など、他のサポート データベースもバックアップします。
- コンテンツ ライブラリのコピーを作成する
警告
次の手順 - Configuration Manager サイトをアンインストールする - スタンドアロン プライマリ サイト、またはサーバーの全体管理サイト (CAS) とネットワーク経由で通信できない子プライマリ サイトでのみ実行する必要があります。 階層のサイトをアンインストールすると、CAS はその子プライマリと通信する機能が失われ、復元プロセスは失敗します。 子プライマリ サイトの場合は、代わりに、上記の手順 でのみ、サイト サーバーの回復のために既存のサーバーをクリーンアップ するに従います。
- SQL Serverからサイト データベースを手動で削除する
- Configuration Manager サイトをアンインストールする
- Configuration Managerインストール フォルダー、関連するレジストリ、およびその他のConfiguration Manager フォルダーを手動で削除する
- サーバーを再起動する
- コンテンツ ライブラリと WSUS などの他のデータベースを復元します。
これで、サーバーはConfiguration Manager復元手順の準備ができました。
サポートされているバージョンと同じエディションのSQL Serverを使用する
可能であれば、同じバージョンのSQL Serverを使用します。 ただし、データベースを新しいバージョンに復元することがサポートされています。
SQL Server エディションは変更しないでください。 Standard エディションから Enterprise エディションへのサイト データベースの復元はサポートされていません。
その他のSQL Server構成要件:
- SQL Serverをシングル ユーザー モードに設定することはできません。
- MDF ファイルと LDF ファイルが有効であることを確認します。 サイトを回復する場合、ファイルの状態にチェックはありません。
可用性グループのSQL Server Always On
SQL Server Always On可用性グループを使用してサイト データベースをホストする場合は、「SQL Server Always Onを使用するための準備」の説明に従って復旧計画を変更します。
データベース レプリカ
データベース レプリカ用に構成したサイト データベースを復元したら、各レプリカを再構成します。 データベース レプリカを使用する前に、パブリケーションとサブスクリプションの両方を再作成します。
回復オプションを決定する
プライマリ サイト サーバーと中央管理サイト (CAS) の復旧には、サイト サーバーとサイト データベースConfiguration Manager考慮すべき 2 つのメイン領域があります。 次のセクションは、復旧シナリオに最適なオプションを選択するのに役立ちます。
注:
Configuration Managerセットアップでサーバー上の既存のサイトが検出されると、サイトの回復を開始できますが、サイト サーバーの回復オプションは制限されます。 たとえば、既存のサイト サーバーでセットアップを実行した場合、回復を選択すると、サイト データベース サーバーを復旧できますが、サイト サーバーを回復するオプションは無効になります。
サイト サーバーの回復オプション
Configuration Manager インストール フォルダーの外部Configuration Manager作成した CD.Latest フォルダーのコピーからセットアップを開始します。
サイト サーバーの [スタート ] メニューからセットアップを実行した場合、[ サイトの回復 ] オプションは使用できません。
バックアップを作成する前に、Configuration Manager コンソール内から更新プログラムをインストールした場合、次の場所のセットアップを使用してサイトを再インストールすることはできません。
- インストール メディア
- Configuration Managerインストール パス
次に、[ サイトの回復 ] オプションを選択します。 障害が発生したサイト サーバーには、次の回復オプションがあります。
既存のバックアップを使用してサイト サーバーを回復する
このオプションは、サイト障害が発生する前からサイト サーバーのConfiguration Managerバックアップがある場合に使用します。 サイトは、 バックアップ サイト サーバー のメンテナンス タスクの一部としてこのバックアップを作成します。 サイトが再インストールされ、バックアップされたサイトに基づいてサイト設定が構成されます。
サイト サーバーを再インストールする
サイト サーバーのバックアップがない場合は、このオプションを使用します。 サイト サーバーが再インストールされ、初期インストール時と同様にサイト設定を指定する必要があります。
失敗したサイトが最初にインストールされたときに使用したのと同じサイト コードとサイト データベース名を使用します。
新しい OS バージョンを実行する新しいコンピューターにサイトを再インストールできます。
サーバーは、元のサイト サーバーと同じホスト名と完全修飾ドメイン名 (FQDN) を使用する必要があります。
サイト データベースの回復オプション
セットアップConfiguration Manager実行すると、サイト データベースに対して次の回復オプションがあります。
バックアップ セットを使用してサイト データベースを復旧する
このオプションは、データベース障害が発生する前からサイト データベースのConfiguration Managerバックアップがある場合に使用します。 サイトは、 バックアップ サイト サーバー のメンテナンス タスクの一部としてこのバックアップを作成します。 階層では、プライマリ サイトを復元すると、回復プロセスによって、最後のバックアップ後にサイト データベースに加えられた変更が CAS から取得されます。 CAS を復元すると、復旧プロセスは参照プライマリ サイトからこれらの変更を取得します。 スタンドアロン プライマリ サイトのサイト データベースを復旧すると、最後のバックアップ後にサイトの変更が失われます。
階層内のサイトのサイト データベースを復旧する場合、CAS サイトとプライマリ サイトでは復旧動作が異なります。 また、最後のバックアップがSQL Server変更追跡保持期間の内部または外部にある場合も動作が異なります。 詳細については、この記事の 「サイト データベースの回復シナリオ 」セクションを参照してください。
注:
バックアップ セットを使用してサイト データベースを復元することを選択したが、サイト データベースが既に存在する場合、回復は失敗します。
このサイトの新しいデータベースを作成する
サイト データベースのバックアップがない場合は、このオプションを使用します。 階層では、復旧プロセスによって新しいサイト データベースが作成されます。 子プライマリ サイトを復元するときに、CAS からレプリケートすることでデータを復旧します。 CAS を復元すると、参照プライマリ サイトからデータがレプリケートされます。 スタンドアロン プライマリ サイトまたはプライマリ サイトを持たない CAS を復旧する場合、このオプションは使用できません。
手動で復旧されたサイト データベースを使用する
このオプションは、Configuration Manager サイト データベースを既に復旧しているが、復旧プロセスを完了する必要がある場合に使用します。
Configuration Managerは、次のいずれかのプロセスからサイト データベースを復旧できます。
Configuration Managerバックアップメンテナンスタスク
Data Protection Manager (DPM) を使用したサイト データベースのバックアップ
別のバックアップ プロセス
Configuration Managerの外部にあるメソッドを使用してサイト データベースを復元した後、セットアップを実行し、このオプションを選択してサイト データベースの復旧を完了します。
注:
DPM を使用してサイト データベースをバックアップする場合は、CONFIGURATION MANAGERで復元プロセスを続行する前に、DPM 手順を使用してサイト データベースを指定した場所に復元します。 DPM の詳細については、 Data Protection Manager のドキュメント ライブラリを参照してください。
階層では、プライマリ サイト データベースを復旧すると、回復プロセスによって、最後のバックアップ後にサイト データベースに加えられた変更が CAS から取得されます。 CAS を復元すると、復旧プロセスは参照プライマリ サイトからこれらの変更を取得します。 スタンドアロン プライマリ サイトのサイト データベースを復旧すると、最後のバックアップ後にサイトの変更が失われます。
データベースの復旧をスキップする
このオプションは、Configuration Manager サイト データベース サーバーでデータ損失が発生していない場合に使用します。 このオプションは、サイト データベースが回復しているサイト サーバーとは異なるコンピューター上にある場合にのみ有効です。
変更追跡の保持期間をSQL Serverする
Configuration Managerでは、SQL Serverのサイト データベースの変更追跡が有効になります。 変更追跡Configuration Manager、前の時点以降にデータベース テーブルに加えられた変更に関する情報を照会できます。 保持期間は、変更追跡情報を保持する期間を指定します。 既定では、サイト データベースは保持期間が 5 日間に設定されています。 サイト データベースを復旧すると、バックアップがリテンション期間の内側または外部にある場合、回復プロセスは異なる方法で続行されます。 たとえば、SQL Serverが失敗し、最後のバックアップが 7 日経過した場合、保持期間外になります。
変更追跡の内部SQL Server詳細については、SQL Server チームからのブログ投稿「Change Tracking クリーンアップ - パート 1」および「Change Trackingクリーンアップ - パート 2」を参照してください。
サイトまたはグローバル データの再初期化
サイトまたはグローバル データを再初期化するプロセスは、サイト データベース内の既存のデータを別のサイト データベースのデータに置き換えます。 たとえば、サイト ABC がサイト XYZ からのデータを再初期化すると、次の手順が実行されます。
- データはサイト XYZ からサイト ABC にコピーされます。
- サイト XYZ の既存のデータは、サイト ABC のサイト データベースから削除されます。
- サイト XYZ からコピーされたデータは、サイト ABC のサイト データベースに挿入されます。
シナリオ 1 の例: プライマリ サイトが CAS からのグローバル データを再初期化する
復旧プロセスでは、プライマリ サイト データベース内のプライマリ サイトの既存のグローバル データが削除され、データが CAS からコピーされたグローバル データに置き換えられます。
シナリオ 2 の例: CAS によってプライマリ サイトからのサイト データが再初期化される
復旧プロセスでは、CAS データベース内のそのプライマリ サイトの既存のサイト データが削除されます。 データは、プライマリ サイトからコピーされたサイト データに置き換えられます。 他のプライマリ サイトのサイト データは影響を受けません。
サイト データベースの回復シナリオ
サイト データベースがバックアップから復元された後、Configuration Managerは、最後のデータベース バックアップ後にサイトとグローバル データの変更の復元を試みます。 Configuration Managerは、サイト データベースがバックアップから復元された後に、次のアクションを開始します。
回復されたサイトは CAS です
変更追跡保有期間内のデータベース バックアップ
グローバル データ: バックアップ後のグローバル データの変更は、すべてのプライマリ サイトからレプリケートされます。
サイト データ: バックアップ後のサイト データの変更は、すべてのプライマリ サイトからレプリケートされます。
変更追跡保有期間より古いデータベース バックアップ
グローバル データ: CAS は、参照プライマリ サイトからグローバル データを指定した場合に再初期化します。 その後、その他のすべてのプライマリ サイトは、CAS からのグローバル データを再初期化します。 参照サイトを指定しない場合、すべてのプライマリ サイトが CAS のグローバル データを再初期化します。 このデータは、バックアップから復元したデータです。
サイト データ: CAS は、各プライマリ サイトのサイト データを再初期化します。
回復されたサイトはプライマリ サイトです
変更追跡保有期間内のデータベース バックアップ
グローバル データ: バックアップ後のグローバル データの変更は、CAS からレプリケートされます。
サイト データ: CAS は、プライマリ サイトからのサイト データを再初期化します。 バックアップが失われた後の変更。 クライアントは、プライマリ サイトに情報を送信するときに、ほとんどのデータを再生成します。
変更追跡保有期間より古いデータベース バックアップ
グローバル データ: プライマリ サイトは、CAS からのグローバル データを再初期化します。
サイト データ: CAS は、プライマリ サイトからのサイト データを再初期化します。 バックアップが失われた後の変更。 クライアントは、プライマリ サイトに情報を送信するときに、ほとんどのデータを再生成します。
サイトの回復手順
サイト サーバーとサイト データベースを回復するには、次のいずれかの手順を使用します。
セットアップ ウィザードでサイトの回復を開始する
CD.Latest フォルダーを、Configuration Manager インストール フォルダーの外部の場所にコピーします。 CD.Latest フォルダーのコピーから、Configuration Manager セットアップ ウィザードを実行します。
[はじめに] ページで、[サイトの回復] を選択し、[次へ] を選択します。
サイトの回復に適したオプションを使用して、ウィザードを完了します。
復旧中に、セットアップによって、SQL Serverによって使用される SQL Server Service Broker (SSB) ポートが識別されます。 復旧中にこのポート設定を変更しないでください。または、復旧が完了した後にデータ レプリケーションが正常に動作しません。
セットアップ ウィザードで、Configuration Managerインストールに使用する元のパスまたは新しいパスを指定できます。
無人サイトの復旧を開始する
サイトの回復に必要なオプションの無人インストール スクリプトを準備します。 詳細については、「 無人サイトの復旧」を参照してください。
コマンド ライン オプションConfiguration Manager使用してセットアップを
/script実行します。 たとえば、 をConfigMgrUnattend.iniセットアップ初期化ファイル を 作成します。 セットアップをC:\Temp実行しているコンピューターのディレクトリに保存します。 次のコマンドを使用します。setup.exe /script C:\temp\ConfigMgrUnattend.ini
注:
CAS を復旧すると、子サイトからの一部のサイト データのレプリケーションが確立されない可能性があります。 このデータには、ハードウェア インベントリ、ソフトウェア インベントリ、およびステータス メッセージを含めることができます。
この問題が発生した場合は、データベース レプリケーション用に ConfigMgrDRSSiteQueue を再初期化します。 SQL Server マネージャーを使用して、CAS のサイト データベースに対して次のクエリを実行します。
IF EXISTS (SELECT * FROM sys.service_queues WHERE name = 'ConfigMgrDRSSiteQueue' AND is_receive_enabled = 0)
ALTER QUEUE [dbo].[ConfigMgrDRSSiteQueue] WITH STATUS = ON
復旧後のタスク
サイトを復旧した後、サイトの回復が完了する前に考慮すべきいくつかの復旧後タスクがあります。 サイトの回復プロセスを完了するには、次のセクションを使用します。
ユーザー アカウント パスワードを再入力する
サイト サーバーの回復後、サイト内の任意のユーザー アカウントのパスワードを再入力します。 これらのパスワードは、サイトの回復中にリセットされます。 アカウントは、サイトの回復が 完了した 後、セットアップ ウィザードの [完了] ページに一覧表示されます。 一覧は、回復されたサイト サーバーにも保存されます C:\ConfigMgrPostRecoveryActions.html 。
サイトの回復後にユーザー アカウント パスワードを再入力する
Configuration Manager コンソールを開き、回復したサイトに接続します。
[管理] ワークスペースに移動し、[セキュリティ] を展開し、[アカウント] を選択します。
アカウントごとに、次の手順を実行してパスワードを再入力します。
サイトの復旧後に特定された一覧からアカウントを選択します。
リボンで [プロパティ] を選択します。
[ 全般 ] タブで、[ 設定] を選択し、アカウントのパスワードを再入力します。
[ 確認] を選択し、選択したユーザー アカウントの適切なデータ ソースを選択し、[ 接続のテスト] を選択します。 この手順では、ユーザー アカウントがデータ ソースに接続できることをテストし、資格情報を検証します。
[ OK] を 選択してパスワードの変更を保存し、[ OK] を 選択してアカウントのプロパティ ページを閉じます。
PXE パスワードを再入力する
Configuration Manager コンソールで、[管理] ワークスペースに移動し、[配布ポイント] ノードを選択します。 PXE 列の [はい ] を持つオンプレミスの配布ポイントは、 PXE に対して有効になっており、再入力するためのパスワードを持つ場合があります。
PXE 対応配布ポイントを選択し、リボンで [プロパティ ] を選択します。
[ PXE ] タブに切り替えます。
[コンピューターで PXE を使用するときにパスワードを要求する] オプションが有効になっている場合は、パスワードを入力して確認します。
[ OK] を選択 してプロパティを保存して閉じます。
他の PXE 対応のオンプレミス配布ポイントに対して、このプロセスを繰り返します。
タスク シーケンス パスワードを再入力する
Configuration Manager コンソールで、[ソフトウェア ライブラリ] ワークスペースに移動し、[オペレーティング システム] を展開して、[タスク シーケンス] ノードを選択します。
タスク シーケンスを選択し、リボンで [編集] を選択 します。
パスワードを再入力するには、次の手順を確認します。
Windows 設定の適用: ローカル管理者パスワードを有効にして指定した場合は、パスワードを再入力して確認します。
[ネットワーク設定の適用]: ドメインに参加するためのアクセス許可を持つアカウントで、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
オペレーティング システム イメージのキャプチャ: 移行先へのアクセスに使用するアカウントの場合は、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
ネットワーク フォルダーへの接続: ネットワーク フォルダーの接続に使用するアカウントの場合は、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
BitLocker を有効にする: キー管理オプション TPM と PIN を使用する場合は、PIN を再入力します。
[ドメインまたはワークグループに参加する]: ドメインに参加するためのアクセス許可を持つアカウントで、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
コマンド ラインの実行: [ 次のアカウントとしてこの手順を実行する] オプションを使用する場合は、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
PowerShell スクリプトの実行: [ 次のアカウントとしてこの手順を実行する] オプションを使用する場合は、[ 設定] を選択します。 パスワードを入力して確認し、[ 確認] を選択します。
すべてのタスク シーケンスに対してこのプロセスを繰り返します。
PKI 以外の環境で起動可能なメディアと事前設定されたメディアを再作成する
PKI 以外の環境では、起動可能なメディアと事前設定されたメディアの自己署名証明書は、メディアが作成されたサーバーのマシン キーに基づいています。 このため、ハードウェアが変更された場合、または OS が回復の一部として再インストールされた場合は、そのサーバー上に作成された起動可能なメディアと事前設定済みメディアを再作成する必要があります。 起動可能なメディアと事前設定されたメディアを作成する方法の詳細については、「 起動可能な メディアの作成」と「 事前設定されたメディアの作成」を参照してください。
サイドローディング キーを再入力する
サイト サーバーの復旧後、サイトに指定された Windows サイドローディング キーを再入力します。 これらのキーは、サイトの回復中にリセットされます。 サイドローディング キーを再入力すると、サイトは Windows サイドローディング キーに 使用されるライセンス認証 列の数をリセットします。
たとえば、サイトの障害が発生する前に、 アクティブ化の合計数は100 と表示されます。 デバイスが使用したキーの数 ( ライセンス認証が使用されている) は 90 です。 サイトの復旧後も、[ アクティブ化の合計] の値には 100 が表示されますが、[ 使用したライセンス認証 ] 列に 正しく 0 が表示されません。 10 台の新しいデバイスがサイドローディング キーを使用した後、サイドローディング キーはもう存在せず、11 番目のデバイスはサイドローディング キーの適用に失敗します。
Azure サービスを再作成する
サイトの復旧後、cloudmgr.log に次のエラーが表示される場合があります。
Index (zero-based) must be greater than or equal to zero
この問題を解決するには、Azure テナント接続ごとに 秘密キーを更新 します。
CAS で外部通知のサブスクリプションを削除して再作成する
CAS を復旧したら、外部通知のサブスクリプションを削除して再作成する必要があります。 詳細については、「 外部通知」を参照してください。
IIS を使用するサイト システムの役割に対して HTTPS を構成する
IIS を実行するサイト システムを復旧し、HTTPS 用に構成した場合は、Web サーバー証明書を使用するように IIS を再構成します。
修正プログラムを再インストールする
サイトの回復後、サイト サーバーに適用された 帯域外の修正プログラム を再インストールする必要があります。 サイトの回復後、セットアップ ウィザードの [完了] ページで、以前にインストールした修正プログラムの一覧を表示します。 この一覧は、回復されたサイト サーバーにも保存されます C:\ConfigMgrPostRecoveryActions.html 。
カスタム レポートを回復する
一部のお客様は、SQL Server Reporting Servicesでカスタム レポートを作成します。 このコンポーネントが失敗した場合は、レポート サーバーのバックアップからレポートを回復します。 Reporting Servicesでのカスタム レポートの復元の詳細については、「Reporting Servicesのバックアップおよび復元操作」を参照してください。
コンテンツ ファイルを回復する
サイト データベースは、サイト サーバーがコンテンツ ファイルを格納する場所を追跡します。 コンテンツ ファイル自体は、バックアップと回復プロセスの一部としてバックアップまたは復元されません。 コンテンツ ファイルを完全に回復するには、コンテンツ ライブラリとパッケージ ソース ファイルを元の場所に復元します。 コンテンツ ファイルを回復するには、いくつかの方法があります。 最も簡単な方法は、サイト サーバーのファイル システム バックアップからファイルを復元することです。
パッケージ ソース ファイルのファイル システム バックアップがない場合は、手動でコピーまたはダウンロードします。 このプロセスは、最初にパッケージを作成したときと似ています。 SQL Serverで次のクエリを実行して、すべてのパッケージとアプリケーションのパッケージ ソースの場所を検索します。 SELECT * FROM v_Package パッケージ ID の最初の 3 文字を確認して、パッケージ ソース サイトを特定します。 たとえば、パッケージ ID がCEN00001されている場合、ソース サイトのサイト コードは CEN です。 パッケージ ソース ファイルを復元するときは、エラーの前と同じ場所に復元する必要があります。
コンテンツ ライブラリを含むファイル システム バックアップがない場合は、次の復元オプションがあります。
事前設定されたコンテンツ ファイルをインポートする: Configuration Manager階層では、別の場所からすべてのパッケージとアプリケーションを含む事前設定されたコンテンツ ファイルを作成できます。 次に、事前設定されたコンテンツ ファイルをインポートして、サイト サーバー上のコンテンツ ライブラリを回復します。
コンテンツの更新: Configuration Managerパッケージ ソースからコンテンツ ライブラリにコンテンツをコピーします。 このアクションを正常に完了するには、パッケージ ソース ファイルを元の場所で使用できる必要があります。 各パッケージとアプリケーションでこのアクションを実行します。
カスタム ソフトウェア更新プログラムを回復する
バックアップ プランに System Center 更新 Publisher データベース ファイルを含めた場合は、更新 Publisher コンピューターが失敗した場合にデータベースを復旧できます。 パブリッシャー更新詳細については、「System Center 更新 Publisher」を参照してください。
更新 Publisher データベースを復元する
回復したコンピューター更新 Publisher に再インストールします。
データベース ファイル Scupdb.sdf をバックアップ先
%USERPROFILE%\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.0000\から Publisher 更新実行するコンピューターにコピーします。複数のユーザーがコンピューター上更新 Publisher を実行する場合は、各データベース ファイルを適切なユーザー プロファイルの場所にコピーします。
ユーザー状態移行データ
状態移行ポイントのプロパティの一部として、ユーザー状態データを格納するフォルダーを指定します。 状態移行ポイントを復旧したら、サーバー上のユーザー状態データを手動で復元します。 エラーが発生する前にデータを格納したフォルダーに復元します。
配布ポイントの証明書を再生成する
サイトを復元した後、distmgr.log には、1 つ以上の配布ポイントの次のエントリが一覧表示される場合があります。 Failed to decrypt cert PFX data このエントリは、配布ポイントの証明書データをサイトで暗号化解除できないことを示します。 この問題を解決するには、影響を受ける配布ポイントの証明書を再生成または再インポートします。 Set-CMDistributionPoint PowerShell コマンドレットを使用します。
データベース暗号化証明書を復元する
データベース全体または特定のテーブルにSQL Server暗号化を使用する場合は、サイト データベースを復元した後に証明書を復元する必要がある場合があります。 たとえば、BitLocker 管理のために回復データを暗号化する場合などです。 詳細については、「 BitLocker 管理用の証明書の復元」を参照してください。
セカンダリ サイトを回復する
Configuration Managerでは、セカンダリ サイトでのデータベースのバックアップはサポートされませんが、セカンダリ サイトを再インストールすることで復旧をサポートします。 セカンダリ サイトConfiguration Manager障害が発生した場合は、セカンダリ サイトの復旧が必要です。
要件
サーバーは、すべてのセカンダリ サイトの前提条件を満たし、適切なセキュリティ権限が構成されている必要があります。
失敗したサイトに使用されたのと同じインストール パスを使用します。
失敗したサーバーと同じ構成のサーバーを使用します。 この構成には、完全修飾ドメイン名 (FQDN) が含まれます。
サーバーには、障害が発生したサイトと同じSQL Server構成が必要です。
セカンダリ サイトの回復中に、Configuration Managerがコンピューターにまだインストールされていない場合、SQL Server Expressはインストールされません。
障害が発生する前にセカンダリ サイト データベースに使用したのと同じバージョンのSQL Serverと同じSQL Serverインスタンスを使用します。
プロシージャ
Configuration Manager コンソールの [サイト] ノードから [セカンダリ サイトの回復] アクションを使用します。 他の種類のサイトとは異なり、セカンダリ サイトの回復ではバックアップ ファイルは使用されません。 このプロセスでは、障害が発生したサーバーにセカンダリ サイト ファイルが再インストールされます。 サイトが再インストールされると、セカンダリ サイト データは親プライマリ サイトから再初期化されます。
回復プロセス中に、Configuration Managerは、コンテンツ ライブラリがセカンダリ サイト サーバーに存在するかどうかを確認します。 また、適切なコンテンツが使用可能であることを確認します。 セカンダリ サイトには、適切なコンテンツが含まれている場合、既存のコンテンツ ライブラリが使用されます。 それ以外の場合は、セカンダリ サイトのコンテンツ ライブラリを復旧するには、コンテンツをサーバーに再配布または事前設定します。
セカンダリ サイト サーバー上にない配布ポイントがある場合は、セカンダリ サイトの復旧中に配布ポイントを再インストールする必要はありません。 セカンダリ サイトの復旧後、サイトは配布ポイントと自動的に同期されます。
セカンダリ サイトの回復の状態を確認するには、Configuration Manager コンソールの [サイト] ノードの [インストール状態の表示] アクションを使用します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示