サンドボックス環境への運用データベースのポイントインタイム復元

Microsoft Dynamics Lifecycle Services (LCS) を使用すると、ユーザー受け入れテスト(UAT)のサンドボックス環境に対して、運用データベースのポイント イン タイム復元(PITR)を実行できます。 Microsoft は、業務および財務報告用のデータベースの自動バックアップを、運用環境の場合は 28 日間、サンドボックス環境の場合は 7 日間維持します。

重要

Microsoft は、運用レポートを目的とした運用データのサンドボックス環境へのコピーには対応していません。

セルフ サービスによる運用環境からサンドボックスへのポイント イン タイム復元

Lifecycle Services チームは、手動または手動のプロセスに依存しないデータ アプリケーション ライフサイクル 管理 (DataALM) 機能を顧客に提供するために、データベースの自動復元アクションを導入しました。 セルフ サービス データベースの復元‎を実行するプロセスの概要を次に示します。

1. 対象とするサンドボックスの環境詳細ページに移動し、管理>データベースの移動ボタンを選択します。
2. 運用環境からサンドボックス環境へのポイント イン タイム復元 オプションを選択し、対象とする時点を選択します。
3. 警告に注意し、元の環境の前の時点からコピーされていないデータ要素のリストを確認します。
4. 復元操作がすぐに開始されます。

重要

セルフ サービスのポイントインタイム復元 (PITR) は、異なる地域にある環境間ではサポートされていません。 詳細については、この記事の後にある、既知の問題セクションを参照してください。

運用環境からサンドボックスへの復元に適用できるシナリオ

運用データベースをサンドボックス環境に復元すると、運用環境で誤ってデータを失った場合に役立ちます。 この方法を使用すると、データを回復し、運用環境に再設定することができます。 運用環境からサンドボックス環境へのポイントインタイム復元を実行し、サンドボックス環境に接続して復元されたデータベースからデータを回復し、それを 運用環境に再設定します。

失敗した操作の復元

復元が成功しなかった場合は、自動的に ロールバック されます。 ターゲットのサンドボックス環境は、復元が開始される前の状態に復元されます。 ロールバックは Azure SQL Database の PITR 機能によって実現しています。 対象とするサンドボックス環境に存在するカスタマイズが、新たに復元されたデータでデータベースの同期を完了できない場合に、これらが必要になります。

失敗の根本原因を特定するには、環境変更履歴 ページを使用して、ロールバックした操作のログをダウンロードします。

復元のコピー処理の過程でコピーされなかったデータ要素

運用環境をサンドボックス環境に、またはサンドボックス環境を別のサンドボックス環境に更新する際に、対象の環境にコピーされない特定のデータベース要素が存在します。 次にいくつか例を挙げます。

• LogisticsElectronicAddress テーブル内の電子メール アドレス。
• SysEmailParameters テーブルの シンプル メール トランスファー プロトコル (SMTP) リレーサーバー。
• PrintMgmtSettings と PrintMgmtDocInstance テーブルの印刷管理設定。
• SysServerConfig、SysServerSessions、SysCorpNetPrinters、SysClientSessions、BatchServerConfig、および BatchServerGroup テーブル内の環境固有のレコード。
• Azure Blob Storage に保存されているすべてのファイル。 これには、ドキュメントの添付ファイル (DocuValue テーブルおよび DocuDeletedValue テーブルから)、およびカスタム Microsoft Office テンプレート (DocuTemplate テーブルから) が含まれます。
• 管理者以外のすべてのユーザーは 無効 のステータスに設定されます。
• すべてのバッチ ジョブは、 保留 状態に設定されます。
• すべてのユーザーのパーティション値は "初期" パーティション レコード ID にリセットされます。
• 別のデータベースサーバーでは解読できないため、すべての Microsoft 暗号化フィールドはクリアされます。 次の例は、sysemailsmtppasswordテーブルの パスワード フィールドです。
• 二重書き込みの構成。 この操作に成功した後にターゲット環境に新しいリンクを設定するには、「統合の有効化 」を参照 Power Platform してください。

これらの要素は、環境固有のものであるためコピーされません。 BatchServerConfig と SysCorpNetPrinters のレコードを含む例。 その他の要素は、サポート チケットのデータ量が多くなる懸念があるためコピーされません。 たとえば、簡易メール転送プロトコル (SMTP) は UAT 環境でも有効になっているため、重複する電子メールが送信されてしまう可能性があります。また、バッチ ジョブも有効になっており、無効な統合メッセージが送信されてしまう可能性もあるため、管理者が復元後クリーンアップを行う前にユーザーが有効化してしまう可能性があります。

環境管理者

対象の環境のシステム管理者アカウント (AdminのUserId値を持つアカウント) が、対象の環境に存在する web.config ファイルで検出された値にリセットされます。 この値は、LCS の管理者アカウントの値と一致している必要があります。 このアカウントをプレビューするには、LCS で対象とするサンドボックス環境の 環境の詳細 ページに移動します。 環境が最初に展開されたときに選択された 環境管理者 フィールドの値は、トランザクション データベースのシステム管理者アカウントと一致するように更新されます。 したがって、環境のテナントは、環境管理者のテナントにもなります。

環境で管理者ユーザー プロビジョニング ツールを使用して、web.config ファイルの値を変更した場合、この値は LCS の値と一致しない可能性があります。 別のアカウントを使用する必要がある場合は、対象のサンドボックス環境の割り当てを解除して削除し、再度展開して別のアカウントを選択する必要があります。 その後、別のデータベース復元アクションを実行してデータを復元できます。

あるテナントから別のテナントに環境を復元することはできません。 この制限は、onmicrosoft.com テナントにも適用されます。 ソース環境とターゲット環境の管理者アカウントが、同じテナント ドメインからのものであることを確認する必要があります。

運用環境の PITR コピーをサンドボックス環境にコピーする条件

以下は、データベースの復元に関する要件と動作条件の一覧です:

• 復元処理では、実行対象のデータベースで削除が実行されます。
• ターゲット環境は、データベースのコピーがターゲット サーバーに達するまで使用可能です。 その時点以降は、復元プロセスが完了するまで、ターゲット環境はオフラインになります。
• 復元は、アプリケーションおよび Financial Reporting データベースにのみ影響します。
• ある環境から別の環境に、Azure Blob Storage に保管してあるファイルはコピーされません。 これには、ドキュメントの添付ファイルやカスタム Microsoft Office テンプレートが含まれます。 これらのドキュメントは変更されず、現在の状態のままになります。
• 管理者ユーザー、およびその他の内部サービス ユーザー アカウントを除くすべてのユーザーは使用できなくなります。 そのため、管理者ユーザーは他のユーザーがシステムに復帰する前にデータの削除や難読化することができます。
• 管理者ユーザーは、特定のサービスまたは URL に統合エンドポイントを再接続するなど、必要な構成の変更を加える必要があります。
• 定期的なインポートおよびエクスポート ジョブを持つすべてのデータ管理フレームワークは、復元を開始する前に、対象のシステムを完全に処理して停止する必要があります。 さらに、すべての定期的なインポートおよびエクスポート ジョブが完全に処理された後に、データベースをソースから選択することをお勧めします。 このようにして、Azure ストレージ内のいずれのシステムからも孤立ファイルがないことを確認してください。 対象の環境でデータベースを復元した後は、孤立したファイルを処理できないため、この手順は重要となります。 復元後、統合ジョブを再開することができます。
• ビジネス イベントは、同じ終了点が使用されないように、データベースが復元される環境で終了ポイントを削除して再構成する必要があります。 また、ビジネスイベントを非アクティブにし、環境で構成されていた新しいエンドポイントに対して、再度有効化する必要があります。
• LCSにてプロジェクトの所有者、または環境マネージャの役割を持つすべてのユーザーは、すべての非運用環境の SQL およびマシンの資格情報にアクセスできます。
• データベースが Spartan で管理されていない場合は、データベースを同じ地理上の Azure リージョンでホストする必要があります。 SQL server の完全修飾アドレスの一部に ' spartan ' が含まれていれば、データベースは Spartan に管理されています。
• 実行元の環境で割り当てられたデータベースの容量は、実行対象の環境のデータベースの最大容量よりも小さくする必要があります。

コマース機能を使用する環境で復元後に実行する手順

重要

Commerce headquarters データベース (以前の AOS データベース) を移行する際、関連付けられている Commerce Scale Units (CSUs) は移動されません。 場合によっては、使用する機能に応じて、CSU の再配置が必要になる場合があります。 次に、データを CSU に完全に同期して、再配置を行う必要があります。 データの不一致が残っている場合は、最終的なアクションとして CSU を削除し、新しい CSU を置き換え、新しい CSU に対するデータの完全同期を実行することです。

環境固有のレコードの中には、自動的なデータベース移動操作に含められないものがあり、その手順を追加する必要があります。 次のような役割があります。

• コマース セルフサービス インストーラー参照。
• Commerce Scale Unit チャネル データベースのコンフィギュレーション レコード。

環境間でデータベースをコピーすると、次の追加の手順を実行しない限り、移行先環境の Commerce の機能は完全には機能しません。

Commerce Scale Unit の初期化

データベースをサンドボックスのユーザー受け入れテスト (UAT) または運用環境に移動する場合は、データベースの移動操作が完了した後に、Commerce Scale Unit を初期化する必要があります。 ソース環境からの Commerce Scale Unit の関連付けは、移行先の環境にコピーされません。

Commerce のセルフサービス インストーラーの同期

本部内の Commerce セルフサービス インストーラーにアクセスできるようにするには、データベースの移動操作が完了した後にセルフサービス インストーラーを同期する必要があります。

重要

環境の再プロビジョニング手順は、データベース移動操作の一部として完全に自動化されており、これ以上手動で実行する必要はありません。 環境再ビジョニング ツールは引き続きアセット・ライブラリで利用可能ですが、Commerce バージョン 10.0.37 以前を実行している開発環境にデータベースを復元する場合にのみ必要です。 Commerce Version 10.0.38 以降を実行している開発環境では、シールされた CSUを 使用する環境なので、環境の再プロビジョニング ツールは適用されません。

移行先の環境で環境の再プロビジョニング ツールを実行するには、次の手順を実行します。

1. ソフトウェア配置可能パッケージ セクションにある自身のプロジェクトの アセット ライブラリ で、 インポートを選択します。
2. 共用資産の一覧から、 環境再プロビジョニング ツールを選択します。
3. 移行先環境の 環境の詳細 ページで、 管理>更新プログラムを適用を順に選択します。
4. 先ほどアップロードした 環境再プロビジョニング ツールを選択し、 適用 を選択してパッケージを適用します。
5. パッケージの配置の進捗を監視します。

配置可能なパッケージの適用方法についての詳細は、 配置可能なパッケージを作成するを参照してください。 配置可能パッケージを手動で適用する方法の詳細については、 配置可能 な パッケージ を コマンド ライン から インストール するを参照してください。

POS デバイスの再アクティブ化

販売時点管理 (POS) デバイスを使用する場合は、データベースをインポートした後、POS デバイスを再度アクティブ化する必要があります。 移行先環境で以前にアクティブ化されたデバイスは、機能しなくなります。 詳細については、販売時点管理 (POS) デバイスのライセンス認証 を参照してください。

既知の問題

サンドボックスのカスタマイズが運用データと互換性がない場合、復元操作は失敗します

カスタマイズがサンドボックス環境に正常に追加された場合 (つまり、顧客の AOT 配置可能パッケージが LCS 経由で正常にインストールされた場合)、運用データに対して成功しない可能性があります。 たとえば、顧客が仕入先名の一意のインデックスを VendTable テーブルに追加します。 このカスタマイズは、サンドボックス環境に重複した仕入先名がない場合、正常にインストールされます。 ただし、運用データベースを復元操作の一環として使用した場合、サンドボックス環境にインバウンドするデータセットに重複があると、インストールが失敗することがあります。 このデータセットの重複はサポートされていません。 したがって、復元操作を成功させる前に、カスタマイズを削除する必要があります。

プラットフォーム 更新プログラム 20 以前が稼働している環境では、復元操作は拒否されます

現在、環境がプラットフォーム更新プログラム 20 またはそれ以前を実行している場合は、データベースの復元プロセスを完了することはできません。 詳細については、現在サポートされているプラットフォーム更新の一覧 を参照してください。

実行元の環境と実行対象の環境に互換性のないバージョンの Financial Reporting が存在します

実行対象とする環境の Financial Reporting のバージョンが実行元の環境のバージョンよりも古い場合は、データベースの復元プロセス (セルフ サービスまたはサービス リクエスト経由) が正常に完了できません。 この問題を解決するには、両方の環境で財務報告が最新バージョンとなるように更新を行ってください。

実行対象と実行元の環境にインストールされているバージョンを確認するには、環境の詳細 ページの 詳細バージョン情報を表示する のリンクを確認してください。 続いて、MRApplicationServiceを検索し、実行対象の環境のバージョンが実行元の環境のバージョンと同じであるか、高いバージョンであることを確認します。

バージョン 8.1 またはそれ以降を使用しているお客様は、次の手順を実行する必要があります。

1. 更新 のタイルメニューを開き、UAT環境を更新します。 更新内容をプロジェクトの資産ライブラリに保存します。
2. パッケージを UAT 環境に適用します。
3. エラーが解決されたことを確認してください。

バージョン 8.0 またはそれ以前を使用しているお客様は、次の手順を実行する必要があります。

1. 実行元の環境の環境履歴を確認してください。 具体的には、「プラットフォームおよびアプリケーションのバイナリ パッケージ」のいずれかが実行元の環境に展開されていることを確認します。実行対象の環境ではありませんのでご注意ください。
2. バイナリ パッケージを実行対象の環境に適用します。
3. エラーが解決されたことを確認してください。

実行元の環境と実行対象の環境間での互換性のないアプリケーション バージョンが存在します

実行元の環境のアプリケーション リリースと実行対象の環境のアプリケーション リリースが異なる場合は、データベースの復元プロセス (セルフ サービスまたはサービスリクエスト経由) を完了できません。 これは、データの更新プロセスが、更新などのデータベースの移動操作によって実行されず、データ損失が発生する可能性があるためです。

新しいアプリケーション バージョンにサンドボックス UAT 環境をアップグレードする場合は (たとえば、7.3 から 8.1 など)、必ずアップグレードを開始する前にデータベースの復元アクションを実行してください。 サンドボックス環境が新しいバージョンにアップグレードされた後は、サンドボックス UAT 環境に古い運用環境データベースを復元することはできません。

逆に、運用環境が実行対象のサンドボックス環境よりも新しい場合は、更新前に対象のサンドボックス環境をアップグレードするか、復元の実行前に環境の割り当て解除、削除、および再展開をする必要があります。

異なるインフラストラクチャ (Microsoft による管理対セルフ サービス) 上にあるソースおよびターゲット

PITR プロセスは、ソースとして Microsoft 管理環境と、行先としてのセルフサービス環境の間ではサポートされません。 たとえば、運用環境が Microsoft によって管理されており、米国東部にある場合、また、セルフサービスで米国東部にあるサンドボックス環境に PITR が必要な場合です。 PITR はサポートされていません。 代わりに、運用環境をセルフ サービスに移動するか、定期的なデータベース更新を選択することもできます。

異なる地域で、両方ともセルフ サービスにあるソースとターゲット間のポイントインタイム復元

PITR プロセスは、異なる地域間のセルフ サービス環境間ではサポートされていません。 たとえば、運用環境が米国東部にあり、セルフ サービスのサンドボックス環境に PITR が必要な場合、西ヨーロッパでは PITR はサポートされていません。 代わりに、環境を両方とも同じ地域にするか、定期的なデータベース更新を選択することもできます。