注
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。
Microsoft Dynamics Lifecycle Services を使用して、サンドボックス ユーザー受け入れテスト (UAT) 環境でデータベースを更新します。 データベースの更新では、トランザクション および財務レポート データベースが運用環境からターゲット サンドボックス UAT 環境にコピーされます。 別のサンドボックス環境がある場合は、その環境からターゲット サンドボックス UAT 環境にデータベースをコピーすることもできます。
重要
営業時間中またはピーク時に運用データをコピーすると、運用システムに影響を与える可能性があります。 ピーク時間外にデータベースの更新操作をスケジュールし、操作を一度に 1 回の更新に制限します。
運用レポートを目的としてサンドボックス環境に運用データをコピーすることはできません。
データベースのセルフサービスリフレッシュ
人間または手動のプロセスに依存せずにデータ アプリケーション ライフサイクル管理 ( DataALM とも呼ばれます) 機能を提供するために、Lifecycle Services チームは、 データベース の自動更新アクションを導入しました。 次のプロセスでは、アクションの概要を示します。
- [環境の詳細] ページでターゲット サンドボックスにアクセスし、Maintain>Move データベースを選択します。
- データベースをリフレッシュ オプションを選択し、ソース環境を選択します。
- ソース環境からコピーされない警告とデータ要素の一覧を確認します。
- 更新操作はすぐに開始されます。
更新操作が失敗しました
操作が失敗した場合、更新プロセスは自動的にロールバックします。 ターゲット サンドボックス環境は、更新が開始される前の状態に復元されます。 この復元は、Azure SQL のポイントインタイム リストア機能が原因で可能です。 ターゲット サンドボックスに存在するカスタマイズが、新しく更新されたデータとのデータベース同期を完了できない場合、復元が必要になることがよくあります。
失敗の根本原因を特定するには、環境変更履歴 ページを使用して、失敗した操作のログをダウンロードします。
更新中にはコピーされないデータ要素
このセクションの情報には、データベース更新操作中にターゲット環境にコピーされないデータベースの特定の要素が一覧表示されます。
サンドボックス環境またはサンドボックスから別のサンドボックス環境に運用環境を更新する場合
- LogisticsElectronicAddress テーブル内の電子メール アドレス。
- SysEmailParameters テーブルの SMTP 中継サーバー。
- PrintMgmtSettings と PrintMgmtDocInstance テーブルの印刷管理設定。
- 管理者以外のすべてのユーザーは 無効 のステータスに設定されます。
- DIMENSIONHASHMESSAGELOG、DIMENSIONDATAINTEGRITYLOG、DIMENSIONVALUERENAMEAUDIT、DIMENSIONVALUEDELETEAUDIT、DIMENSIONATTRIBUTEVALUECOMBINATIONSTATUS、DIMENSIONATTRIBUTEVALUEGROUPSTATUS、DIMENSIONDATAENTITYSFKCACHE、DIMENSIONREFERENCES などの分析コード ログおよびキャッシュ ステータス テーブル。
サンドボックス環境から運用環境に更新する場合
この操作は、 ゴールデン構成の昇格とも呼ばれます。
- バッチ ジョブ履歴は、BatchJobHistory、BatchHistory、および BatchConstraintHistory テーブルに格納されています。
これらの要素は、すべてのデータベースの更新操作で削除されます
- 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 file ファイルにある値にリセットされます。 この値は、ライフサイクル サービスの Administrator 値と一致する必要があります。 このアカウントをプレビューするには、ライフサイクル サービスのターゲット サンドボックス 環境の詳細 ページにアクセスします。 環境を最初にデプロイするときに選択した [ 環境管理者 ] フィールドの値は、トランザクション データベースのシステム管理者になります。 この変更は、環境のテナントが環境管理者のテナントであることを意味します。
環境で管理ユーザー プロビジョニング ツールを使用して web.config ファイルを別の値に変更すると、ライフサイクル サービスの内容と一致しない可能性があります。 別のアカウントが必要な場合は、ターゲット サンドボックスの割り当てを解除して削除し、別のアカウントを選択して再デプロイします。 この手順の後、別のデータベース更新アクションを実行してデータを復元できます。
あるテナントから別のテナントに環境を更新することはできません。 この制限は、onmicrosoft.com テナントにも適用されます。 ソース環境とターゲット環境の管理者アカウントが同じテナント ドメインから取得されていることを確認します。
データベース更新の条件
次の一覧では、データベース更新操作の要件と条件について説明します。
- 更新操作により、元のターゲット データベースが削除されます。
- ターゲット環境は、データベースのコピーがターゲット サーバーに到達するまで使用できます。 その後、更新プロセスが完了するまで、環境はオフラインになります。
- 更新は、アプリケーションおよび Financial Reporting データベースにのみ影響します。
- ある環境から別の環境に、Azure Blob Storage に保管してあるファイルはコピーされません。 この制限には、 ドキュメントの添付ファイルとカスタム Microsoft Office テンプレートが含まれます。 これらのドキュメントは変更されず、現在の状態のままです。
- 管理者ユーザー、およびその他の内部サービス ユーザー アカウントを除くすべてのユーザーは使用できません。 このプロセスにより、ほかのユーザーがシステムに復帰する前に管理者ユーザーがデータを削除または難読化できます。
- 管理者ユーザーは、特定のサービスまたは URL に統合エンドポイントを再接続するなど、必要な構成の変更を加える必要があります。
- 復元を開始する前に、すべてのデータ管理フレームワークの定期的なインポートおよびエクスポート ジョブをターゲット システムで完全に処理して停止する必要があります。 さらに、すべての定期的なインポートおよびエクスポート ジョブが完全に処理された後で、ソースからデータベースを選択します。 この手順により、いずれかのシステムから Azure Storage に孤立したファイルが存在しないようにします。 この状態は、データベースがターゲット環境に復元された後に孤立したファイルを処理できないため、重要です。 復元後、インテグレーションジョブを再開できます。
- ライフサイクル サービスのプロジェクト所有者または環境マネージャーのロールを持つユーザーは、すべての非運用環境の 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 Units の初期化
データベースをサンドボックスのユーザー受け入れテスト (UAT) または運用環境に移動する場合は、データベースの移動操作が完了した後に、Commerce Scale Unit を初期化する必要があります。 ソース環境からの Commerce Scale Unit の関連付けは、移行先の環境にコピーされません。
Commerce のセルフサービス インストーラーの同期
本部内の Commerce セルフサービス インストーラーにアクセスできるようにするには、データベースの移動操作が完了した後にセルフサービス インストーラーを同期する必要があります。
重要
環境の再プロビジョニング手順は、データベース移動操作の一部として完全に自動化されており、これ以上手動で実行する必要はありません。 環境再ビジョニング ツールは引き続きアセット・ライブラリで利用可能ですが、Commerce バージョン 10.0.37 以前を実行している開発環境にデータベースを復元する場合にのみ必要です。 Commerce Version 10.0.38 以降を実行している開発環境では、シールされた CSU を使用する環境なので、環境の再プロビジョニング ツールは適用されません。
移行先の環境で環境の再プロビジョニング ツールを実行するには、次の手順を実行します。
- ソフトウェア配置可能パッケージ セクションにある自身のプロジェクトの アセット ライブラリ で、 インポートを選択します。
- 共用資産の一覧から、 環境再プロビジョニング ツールを選択します。
- 移行先環境の 環境の詳細 ページで、 管理>更新プログラムを適用を順に選択します。
- 先ほどアップロードした 環境再プロビジョニング ツールを選択し、 適用 を選択してパッケージを適用します。
- パッケージの配置の進捗を監視します。
配置可能なパッケージの適用方法についての詳細は、 配置可能なパッケージを作成するを参照してください。 配置可能パッケージを手動で適用する方法の詳細については、 配置可能 な パッケージ を コマンド ライン から インストール するを参照してください。
POS デバイスの再アクティブ化
販売時点管理 (POS) デバイスを使用する場合は、データベースをインポートした後、POS デバイスを再度アクティブ化する必要があります。 移行先環境で以前にアクティブ化されたデバイスは、機能しなくなります。 詳細については、販売時点管理 (POS) デバイスのライセンス認証 を参照してください。
既知の問題
サンドボックスのカスタマイズが運用データと互換性がない場合、復元操作は失敗します
サンドボックス環境にカスタマイズを正常に追加した場合 (つまり、お客様の AOT デプロイ可能パッケージがライフサイクル サービスを介して正常にインストールされた場合)、運用データでは成功しない可能性があります。 たとえば、顧客が仕入先名の一意のインデックスを VendTable テーブルに追加します。 サンドボックス環境に重複するベンダー名がない場合は、このカスタマイズを正常にインストールできます。 ただし、運用データベースを復元操作の一環として使用した場合、サンドボックス環境にインバウンドするデータセットに重複があると、インストールが失敗することがあります。 このデータセットの重複はサポートされていません。 したがって、復元操作を成功させる前に、カスタマイズを削除する必要があります。
プラットフォーム 更新プログラム 20 以前が稼働している環境では、更新処理は拒否されます
現在、環境がプラットフォーム更新プログラム 20 またはそれ以前を実行している場合は、データベースの更新プロセスを完了することはできません。 詳細については、現在サポートされているプラットフォーム更新の一覧 を参照してください。
ソース環境とターゲット環境間での Financial Reporting の互換性のないバージョン
実行対象とする環境の Financial Reporting のバージョンが実行元の環境よりも古い場合は、データベースの更新プロセス (セルフサービスまたはサービス要求経由) を正常に完了できません。 この問題を解決するには、両方の環境で Financial Reporting が最新バージョンとなるように更新を行ってください。
実行対象と実行元の環境でインストールしたバージョンを確認するには、 詳細バージョン情報を表示 のリンクを確認します。これは 環境の詳細 ページにあります。
MRApplicationService を検索し、対象となる環境が実行元の環境と同等かそれ以上のバージョンあることを確認してください。
バージョン 8.1 またはそれ以降を使用している顧客:
- 更新 のタイルメニューを開き、UAT環境を更新します。 更新内容をプロジェクトの資産ライブラリに保存します。
- このパッケージをUAT環境に適用します。
- エラーが解決されたことを検証します。
バージョン 8.0 またはそれ以前を使用している顧客:
- 実行元環境の環境履歴を確認します。 具体的には、「プラットフォームおよびアプリケーションのバイナリ パッケージ」のいずれかが実行元の環境に展開されていることを確認します。対象の環境ではありませんのでご注意ください。
- このバイナリパッケージをターゲット環境に適用します。
- エラーが解決されたことを検証します。
ソース環境とターゲット環境間での互換性のないアプリケーション バージョン
運用環境がターゲット サンドボックスよりも新しい場合は、更新の前にターゲット サンドボックスをアップグレードするか、更新を実行する前にサンドボックスの割り当てを解除、削除、再デプロイする必要があります。