クローンに関する FAQ - よく寄せられる質問Descriptionこの記事では、ソースインスタンスからターゲットインスタンスへのクローンに関して、ServiceNow テクニカルサポートに寄せられるクローン作成に関する最もよく寄せられる質問を一覧表示します。詳細については、「バックアップ」、「ポストクローン作成」、「エクスクルーダー」、「プリザーバー」、「クリーンアップスクリプト」を参照してください。 この記事は、クローンに関する次の 3 回シリーズの一部です。 クローンの基本クローンのヒントとコツ .mce-toc { background-color: #f7f7f7; padding: 10px; border-radius: 5px; border: 1px solid #dedede; width: 70%; min-width: 500px; } Table of Contents よくある 3 つの質問バックアップに関するその他の質問ポストクローン除外と保存スクリプトのクリーンアップその他のよくある質問その他のバックアップに関する質問クローン除外者と保持者クリーンアップスクリプトその他の FAQ よくある 3 つの質問 特定の日付からクローンを作成できますか？ デフォルトでは、クローン リクエストではソース インスタンスの最新のバックアップが使用されます。 フレッシュ/オンデマンド バックアップ: クローンに対して新しい「オンデマンド バックアップ」を作成すると、夜間のバックアップではまだキャプチャされていない大きな変更が本番環境にあった際、この変更をクローンに反映させたい場合に役立ちます。 オンデマンド バックアップをリクエストする方法については、以下の次の質問に進んでください。 バックアップ復元リクエスト: インスタンスを以前の状態に復元するには (古いバックアップを使用)、Now Support サービス カタログで「インスタンスの復元」をリクエストできます: https://support.servicenow.com/now?id=ns_automation_store クローン実行前にバックアップを取ることを要求できますか？ はい。 オンデマンド バックアップを作成するには 2 つの方法があります。 オプション 1: Clone Admin Console 内のオンデマンド バックアップ オプション - Clone Admin Console の Innovation Lab ストアリリースには、オンデマンド バックアップ オプションがあります。 このオプションを選択すると、指定したクローン開始時刻に新しいバックアップが開始されます。 オプション 2: Now Support を通じてケースを提起することで、「オンデマンド バックアップ リスト」への追加をリクエストできます。 インスタンスがこのリストに追加されると、クローンごとに新しいバックアップが作成されます。 インスタンスで利用可能なバックアップを確認するにはどうすればよいですか？ Now Support から「インスタンスの利用可能なバックアップのリスト」を取得します。 Now Support (HI) にログインします。「Automaction Store (オートメーションストア)」をクリックしますカタログメニューの「Instance Management (インスタンス管理)」を選択します。「List of backups for the instance (インスタンスのバックアップのリスト)」タイルをクリックします。 バックアップに関するその他の質問 クローンを作成すると、どのバックアップファイルが使用されますか? クローンは常に、クローンターゲットインスタンスのデータセンターに関連する最新のバックアップファイルを使用します。たとえば、本番インスタンスに、LHR データセンターに 2 つのノード、AMS データセンターに 2 つのノードがある場合、これら 2 つのデータセンターの毎日のバックアップ ファイルが作成されます。その後、AMS データセンターに Dev インスタンスがあり、LHR に Test インスタンスがある場合、Dev のクローンでは最新の AMS バックアップが使用され、Test のクローンでは最新の LHR バックアップが使用されます。 オンデマンドバックアップからのクローン作成について聞いたことがありますが、どのように機能しますか? テクニカルサポートは、お客様からの要求に応じて、オンデマンドバックアップリストにインスタンスを追加できます。これにより、クローン作成前の準備の一環として新しいバックアップが作成されるため、クローン作成に余分な手順が追加されます。クローンの準備手順は、スケジュールされたクローン時刻の数時間前に実行されるため、バックアップファイルはソースインスタンスの現在の状態に非常に近くなります。オンデマンドバックアップリストからインスタンスを削除するには、テクニカルサポート用のケースを再度作成する必要があります。 本番インスタンスを「オンデマンドバックアップ」リストに追加すると、バックアップ作成時の本番環境のパフォーマンスに影響しますか? いいえ、オンデマンドバックアップの生成中にパフォーマンスが低下することはありません。 ポストクローン クローンの後、なぜコメント/更新はすべて別のユーザーと時間として表示されるのでしょうか? これはデザインどおりで、エクスクルーダーを使用してクローンを作成すると、sys_audit テーブルが除外されます。sys_audit テーブルは、各コメントと更新のユーザー、日付、時刻を保持するために使用されるため、sys_audit が無い場合、レコード上のすべてのコメントに対して sys_created_by フィールドと sys_created_at フィールドが使用されます。 レコードの履歴を表示すると、すべての更新が update 0 と表示されます 詳細については、「KB0690828: Cloning - Activity formatter and Audit not showing correct user and time.」を参照してください。 クローンの MFA をリセットするにはどうすればよいですか? このビデオでは、クローンインスタンスの MFA をリセットする方法を説明します。 クローン後にログインできないのはなぜですか? これはよりも頻繁に起こります。 インスタンスのクローンを作成すると、本番環境から設定が取得され、これには SSO およびログイン機能が含まれる可能性があり、アップグレード後にサブ本番インスタンスにログインできなくなる可能性があります。 これは、クローン作成のためだけでなく、いつでもログインできるローカルアカウントを常に持つことの利点を示しています。 クローン作成でこの問題が発生しないようにするには、次の操作を行います。 方法 1: ソース インスタンスにローカル管理者ユーザーを作成します。 ソースインスタンスにローカルパスワードを持つローカル管理者ユーザーを作成します。準本番インスタンスのクローンを作成します。side_door.doを使用して、ステップ1のユーザー名とパスワードでインスタンスにログインします。 方法2:ターゲットインスタンスにローカル管理者ユーザーを作成し、プリサーバーを含めます。 ターゲットインスタンスにローカルパスワードを持つローカル管理者ユーザーを作成します。ユーザー(sys_user)、ユーザーロール[sys_user_has_roles]、およびユーザーグループ[sys_user_grmember]のクローンプリザーバーを作成します。準本番インスタンスのクローンを作成します。side_door.doを使用して、ステップ1のユーザー名とパスワードでインスタンスにログインします ターゲットとしてデモまたはpovインスタンスにクローンを作成すると、「有効な容量マッピングのクローンプリフライトチェックが失敗しました」というメッセージが表示され、クローンが失敗しました。 このエラーメッセージは、小さすぎてサイズを拡大するように設定されていないインスタンスのクローンを作成しようとした場合に発生します。 デモインスタンスとPOVインスタンスは特定のサイズまでのみ拡張するように構築されているため、ソースインスタンスも小さい場合はクローンを作成できますが、特定のサイズに成長すると、デモインスタンスまたはPOVインスタンスをクローン作成に使用することはできません。次に、準本番インスタンス(サイズを拡大する機能がある)のクローンを作成する必要があります。 また、デモまたはPOVインスタンスのサイズを増やすことはできないことに注意する必要があり、常に準本番インスタンスのクローンを作成するようにしてください。 クローンの後にテキスト検索が実行されないのはなぜですか? インスタンスのクローンを作成すると、テキスト検索が機能しないという問題が発生する可能性があります。 これは、クローン完了後に実行されるクローンクリーンアップスクリプトの1つが、検索用にこのインスタンスのインデックスを再作成しますが、この実行中は検索が機能しないためです。 実行中のジョブを見ると、テキストインデックスイベントプロセスが表示され、stats.do を見ると、次のようなものが表示されます。 完了すると、検索機能が動作し始めます。 特定のテーブルを除外しましたが、クローン作成後もデータは残っていますか? これは非常に一般的な質問です。エクスクルーダーを入力しても、クローン作成後もデータは残ります。 これには、さまざまな原因が考えられます。 クローンでテーブルを除外するチェックボックスをオフにた。除外対象としてブラックリストに登録されているテーブルを選択しました。 Task テーブルの子テーブルを除外すると、子テーブルは除外されます。親タスクテーブルを子テーブルと一緒に除外する必要はありませんが、これはTPHまたはTPC拡張モデルで機能します 除外と保持 除外はどのように機能しますか? すべての除外設定は、ソースインスタンスで設定する必要があります。テーブルごとに作成されるため、条件ベースの除外を使用することはできません。これらは、ソース データに対してのみ処理されます。テーブルを除外すると、テーブルが切り捨てられるため、ソース インスタンスからのデータは保持されません。階層別のテーブル拡張モデルを使用するタスクテーブルの子テーブルを除外する場合、子テーブルは除外されます。親タスク テーブルを子テーブルと共に除外する必要はありません。デフォルトでは、クローン作成には除外オプションが選択されています。クローン作成前に除外するオプションを削除しても、データは除外されません。同じテーブルを除外および保持できます。 プリザーバーはどのように機能しますか? すべてのプリサーバー設定は、ソースインスタンスで設定する必要があります。保持できるのはデータのみで、テーブルや列は保持できません。テーブルごとに作成され、条件を使用して特定のデータのみを保持できます。これらは、ターゲットデータに対してのみ処理されます。データは、除外が処理された後にインポートされます。これらは常にすべてのクローンで実行されます。同じテーブルを除外および保持できます。ターゲットインスタンスのテーブルを保持できるのは、ソースインスタンスにもテーブルが存在する場合のみです (テーブル構造はデータのみを保存できないため)。また、プリサーバーは大量のデータではなく重要なデータを保持するためのものです。大量のデータを保持すると、クローンが破損したり、実行に非常に長い時間がかかる可能性があります。大量のデータを保存しないことをお勧めします。 詳細については、「KB0717012 - 除外とプレサーバー構成に基づく結果の複製」を参照してください。 除外リストとプリザーバーリストの両方にテーブルを追加すると、どうなりますか? 結果として、テーブルはクローン後もターゲットインスタンス上でクローン前とまったく同じになります。クローンの前にテーブルに5つのレコードがあった場合、同じ5つのレコードがクローン後に存在します。 ターゲットインスタンスのプラグインを保持できますか? ターゲットインスタンスでプラグインをテストする際に、これらのプラグインを保持して、テストを続行して作業できるようにしたい場合があります。 残念ながら、クローンを作成する方法では、新しいデータベースを介してソースインスタンスを復元するため、クローンの作成後、プラグインを再度アクティブ化するか、必要に応じて Now Support (HI) 経由でプラグインを要求する必要があります。 レコードを保存する場合、添付ファイルも保持する必要がありますか? クローンを作成する場合、たとえば一部のインシデントなど、ターゲットインスタンスの特定のレコードを保持する場合があり、クローンの作成後に、これらのインシデントにリンクされた添付ファイルも保持されるようにすることもできます。 現在、自動化では、添付ファイルを含むレコードを保持すると、添付ファイル テーブル専用の別のプリザーバーを作成しなくても、それらの添付ファイルが自動的に保持されます。 プリサーバーとエクスクルーダを変更した場合、次のクローンですぐに機能しますか? よくある質問ですが、エクスルーダーまたはプリザーバーを調整したばかりで、クローンを作成する前にしばらく待つ必要があるかどうかを知りたいです。答えはNOです。除外者とプリサーバーを変更すると、それらの変更は次に要求されたクローンに適用されます。 除外オプションのチェックを外しましたが、クローンを作成した後も除外機能はまだ実行されていますか? 最近、この問題が増加しています。クローンを要求し、クローンの後に除外オプションのチェックを外した後、除外機能がまだ実行されているように見えます。 これはリクエストフォームのUIの変更に関連しており、一部の顧客はフォームをカスタマイズしていたため、変更を反映されませんでした。 UI が変更され、クリックして開いて表示する必要があるオプション タブで除外するオプションが非表示になりました。これが発生したため、一部の顧客はフォームをカスタマイズしているか、非表示セクションのオプションを表示する代わりにフォームを既にカスタマイズしているため、フォームにフィールドが2回表示される可能性があります。 ここでの問題は、値は常に最後に見つかった値が取得されるため、メインフォームのオプションをオフにすると、それが最後に見つかったフィールドの値としてオプションから値が取得されることです。 これを修正するには、フィールドがフォーム上のすべてのセクションに一度だけ表示されるようにフォームを更新する必要があります。これが修正されると再び発生しません。 既存のテーブルをプリサーバーに追加できませんか? 特定のテーブルのデータプリザーバーを追加する際、リストにデータプリザーバーが見つからないことがあります。これはおそらくテーブルのスコープによるものです。 特定のスコープの一部であるテーブルを保持する場合は、次の操作を行う必要があります。 右上の歯車アイコン(歯車アイコン)をクリックしてテーブルのスコープに切り替え>[開発者]に移動して > テーブルのスコープを選択します。次に、データ保存テーブルに移動します。データプリザーバーを作成し、その特定のテーブルを選択して保存できるようになります。 スクリプトのクリーンアップ クローンクリーンアップスクリプトはどのように機能しますか? クローンが完了すると、すべてのクリーンアップ スクリプトがスケジュールされたジョブとして作成され、完了するまで実行されます。クリーンアップスクリプトには順序はなく、異なる順序で実行されますソースインスタンスで定義する必要があります。 インスタンスごとにクリーンアップスクリプトを使用できますか? 特定のインスタンス専用のクリーンアップスクリプトを作成することはできません。ただし、クリーンアップスクリプトでインスタンス名システムプロパティをチェックし、結果に応じて特定のジョブを実行するように定義できます。例： var instanceName = gs.getProperty('instance_name');if (instanceName == 'testdev'){// Do specific jobs for dev instance}else if (instanceName == 'testsandbox'){// Do specific jobs for sandbox instance} その他のよくある質問 ドラフトとは何ですか?これらを削除できないのはなぜですか? UIをクリックしてクローンを送信すると、クローンテーブルにレコードが作成されます。クローンを続行しない場合、ポップアップ ウィンドウの外をクリックした場合、レコードは「ドラフト」としてシステムに残りますが、これは無視しても問題ありません。これらを削除できない理由は、クローンリクエストを管理するServiceNowの内部インスタンスへのリンクがあるためです。 クローンが「保留中」になっているのはなぜですか? クローンの状態が「保留」に設定されている場合、サーバがクローンリクエストを拒否したことを意味します。最も一般的な理由のいくつかを次に示します。 クローンはスケジュールされた時刻までに実施する準備ができていませんでした。ターゲットインスタンスはダウングレードされません。クローンに使用されるバックアップに問題があります。 詳細については、KB0694499 - 「保留」状態の複数のクローンを参照してください。 別のインスタンスにクローンを作成した場合、リリースは変更されますか? クローンを作成するときと同様に、ソースインスタンスのレプリカを作成しているため、テーブル構造とバージョンが一致します。 したがって、San Diegoリリースのインスタンスを Tokyo リリースのインスタンへローンする場合、ターゲットインスタンスはSan Diegoリリースになります。 逆に、Tokoリリースのインスタンスを San Diego リリースインスタンスへクローンすると、ターゲットインスタンスはTokyoリリースになります。 スタンバイ・データベースとソース・インスタンスの違いは何ですか。 クローン作成時に、[スタンバイ データベース] と [ソース インスタンス] のいずれかを選択するオプションが表示される場合があります。 これは古いオプションであり、クローンを要求するときに不要になり、新しいリリースでは削除され、表示されないはずですが、それでも表示される場合は、このオプションを無視して安全に使用できます。 「クローン元:」フィールドとは何ですか?これにより、クローンがライブ・データベースとバックアップのどちらを使用するかが決まりますか? クローンをスケジュールするときに、このフィールドを使用して、バックアップ・ファイルからクローンを作成するか、ライブ・データベースからクローンを作成するかを決定できるというのは、よくある誤解です。このフィールドは、実際には以前のアプリ内クローンエンジンに関連するレガシーフィールドであり、バックアップからの新しいクローン機能には目的がありません。 クローンを要求する際、または認証ステップでクローン ターゲットを作成する際に、「ユーザー名またはパスワードが無効です」というプロンプトが表示されます。 この問題は、以下の 2 つのいずれかが原因で発生します。 (I) 対象インスタンスでマルチファクション認証が有効になっているか確認してください。これを確認するには、 [sys_properties] テーブルに移動し、プロパティ [glide.authenticate.multifactor] を検索します。このプロパティの値が true の場合、インスタンスで多要素認証が有効になっています。 (II) 対象インスタンスに含まれるBasicAuthスクリプトがカスタマイズされているか確認してください。どちらの場合も、クローンターゲットを作成しようとすると、ログで次のようなものを見つけることができます。 Script: InstanceRetrieverAjax: Sending request to /HAGetParams.do?SOAPWARNING *** WARNING *** OUTBOUND USAGE ANALYTICS - OutboundUsageAnalytics : OutboundUsageAnalytics: Usage analytics send failedOperation against file 'instance' was aborted by Business Rule 'Target Instance Validate^c16a7406db00c890cd7efafc0f9619dd'. Business Rule Stack:Target Instance ValidateSlow business rule 'Target Instance Validate' on instance: time was: 0:00:00.506Error in user input caused action to be cancelled クローンターゲットの作成を認証する場合、またはクローンをスケジュールするときに、ローカル管理者ユーザーを使用することを推奨します。 使用されるローカル管理者ユーザー ID の「Web サービスアクセスのみ」がチェックされていない場合、認証に失敗し、「ユーザー名またはパスワードが無効です」というエラーメッセージが表示されます。これは、ビジネス ルール「ターゲット インスタンスの検証」が、「InstanceRetrieverAjax」を含むスクリプトから送信された SOAP 呼び出しを介してターゲット インスタンスを検証できないことが原因です。 詳細: クローンターゲットの作成中に「無効な挿入」や「無効なユーザー名とパスワード」などのエラーメッセージが表示される ターゲットインスタンスへのクローン認証が「無効なユーザー名またはパスワード」で失敗する データを除外しているにもかかわらず、メールアカウントがターゲットに複製されるのはなぜですか? クローン作成後、電子メールを有効にする前に、本番環境のメールアカウントが準本番インスタンスにコピーされています。[テーブルを除外する]オプションはオンになっています。When this issue has happened it is because normally on one occasion you have cloned to a sub prod and not excluded the table, therefore the sys_email_account has been copied across to your target instance, then you have a preserver for sys_email_account so it would have been preserved every clone after that. この問題が発生した場合は、通常、過去にテーブルを除外せずに準本番インスタンスにクローンを作成したため、sys_email_accountがターゲットインスタンスにコピーされ、sys_email_accountのプリサーバーがあるため、その後すべてのクローンで保持されることになります。 回避策: クローンクリーンアップスクリプト 本番インスタンスへログインします。準本番インスタンスに含めないメールアカウントのすべてのsys_idを確認します。本番インスタンスで、これらの sys_id を持つすべての電子メール アカウントを削除するクローン クリーンアップ スクリプトを作成します。 スクリプトの例: // Add sys_ids to the encoded query (queryString)// Like queryString = "sys_idIN206594e8db9eb3002e14c6fc34961998,6ab25213db003300eaf8e64305961927"var queryString = "sys_idIN";var emailclean = new GlideRecord('sys_email_account');emailclean.addEncodedQuery(queryString);emailclean.deleteMultiple(); これは、すべてのクローン作成後に、クローンされたかどうかに関係なく、これらのsys_email_accountsを削除することを意味します。新しい電子メールアカウントを追加する場合は、このスクリプトに追加する必要がありますが、これにより、電子メールアカウントがソースインスタンスから送信されることがなくなります。