インスタンスのアップグレードに関する FAQ - よくある質問Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事では、インスタンスのアップグレードに関するよくある質問への回答と、関連する一般的な問題について説明します。 この情報は、ベースシステムインスタンスに適用されます。インスタンスのカスタマイズは、ここで説明する動作に影響を与える可能性があります。 注:On-premises (セルフホスト) インスタンスについては、KB0598275 - Upgrade Best Practices for Self-Hosted Customers を参照してください。 1.ServiceNow サポートでアップグレードの変更をスケジュール/変更/キャンセルする方法を教えてください。2.パッチ適用プログラムとサポート終了アップグレードプログラムに関する KB3.アップグレードに関して従うべき一般的なガイドラインは何ですか？4.ServiceNow サポートの変更でアップグレードが開始されず、開始予定時刻を過ぎたのはなぜですか？5.アップグレードを予行演習する最善のプロセスは何ですか？6.アップグレードの実行時間はどれくらいですか？7.アップグレード中、インスタンスで何が発生しますか？8.アップグレード前にアドホックバックアップを行うことはできますか？9.アップグレード後にデータ破損が発生した場合、データを復旧するための選択肢は何ですか？10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？11.アップグレード中はどのようにユーザーを制限しますか？12.ServiceNow テクニカルサポートはアップグレードを監視できますか？13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？14.アップグレードをロールバック/ダウングレードできますか？15. 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。16.スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？17. Upgrade Summary と Upgrade History レコードの間でスキップされた更新の数が異なるのはなぜですか？18. アップグレードの進行中にキャンセルすることはできますか？19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか？(Paris 以降の新機能)20.インスタンスで予定されているアップグレードを通知する方法21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送する22.アップグレード中に、適用されたワークアラウンドが固定された OOB レコードで上書きされるようにする方法23.以前のアップグレードのアップグレードサマリーレポートを表示できますか？ 1.ServiceNow サポートを使用してインスタンスのアップグレードをどのようにスケジュール/変更/キャンセルしますか？ インスタンスのアップグレードは、Now Support ポータルを通じて customer_admin がスケジュールする必要があります。ServiceNow がスケジュールするのは、Patching および End-of-Life (EOL) アップグレード変更のみであり、対象インスタンスが該当プログラムに登録されると自動的に処理されます。ServiceNow では、お客様向けのアドホックなインスタンスアップグレードをスケジュールすることはできません。 以下を参照してください。 KB0541128 - How to manage and schedule instance upgrades KB1320862: Missing time slots for instance Upgrade アップグレード変更を作成できない場合、その原因として最も可能性が高いのは、すでに有効なアップグレード変更（Patching/EOL）が存在していることです。そのような場合は、既存の変更を再スケジュールし、必要に応じて WAR バージョンも更新してください。 これらのアクティビティの管理は、専任の Patching Team が担当しています。Customer Support がこれらの自動化された変更に対して実施できる操作には制限があります。お問い合わせ内容を PARENT 変更レコードに追加して、適切に更新してください。Patching Team は Parent Change（EOL/Patching）を通じて回答します。 この KB には、Support ポータルで Parent Change を見つけるためのスクリーンショットと手順が含まれています。 KB1644913: How to request support for patching and end-of-life changes in Now Support Patching Team では、通常、要求の確認および対応に数営業日を要するため、十分なリードタイムを確保してください。これらの Parent Change は通常、お客様が計画を立て、自社の開発サイクルに合わせてアップグレードを調整できるよう、数か月前に作成されます。 セキュリティ上の懸念によりパッチが撤回された場合、新しいリリースバージョンがアップグレード変更に自動的に反映されます。関連するお問い合わせについては、Parent Change 内で提供されるコミュニケーションを通じて案内されます。 2.パッチ適用プログラムとサポート終了アップグレードプログラムに関する KB KB0696901 - ServiceNow Patching Program FAQsKB0610454 - End of Life aka Unsupported Release Family Upgrades FAQKB0828060 - About the instance status "Nearing end of life"KB0598977 - Definition of Unsupported ReleaseKB0999993 - Patching & Upgrades Landing PageKB3146385 – Weekly Security Hot FixesKB3141691 - What is an "m" release? 3.アップグレードに関して従うべき一般的なガイドラインは何ですか？ アップグレードガイドラインについては、Upgrade your instance および、YouTubeのこのビデオUpgrading to a New Release を参照して下さい。 4. アップグレードが開始されなかった理由、および ServiceNow Support の変更で計画開始時刻を過ぎてしまった理由は何ですか？ ServiceNow Support の変更の計画開始時刻は、インスタンスの ServiceNow インスタンスレコードで割り当てられた WAR バージョンが変更されるタイミングを決定します。 アップグレードは、インスタンス上の「Check distribution for possible upgrade」ジョブによってトリガーされます。このジョブは1時間ごとに実行され（ベースシステム）、ServiceNow インスタンスレコードで割り当てられた WAR バージョンを1時間ごとに確認します。新しい WAR バージョンが見つかると、その新しい WAR バージョンをダウンロードします。 注意：インスタンスのアップグレードは、ServiceNow Support の変更の計画開始時刻から最大1時間後にインスタンスでトリガーされる場合があります。 実際のアップグレードがインスタンスでトリガーされると、ServiceNow Support の変更に実際の作業開始時刻が更新されます。 インスタンス上の以下の URL からアップグレードジョブを確認できます。 https://INSTANCENAME.service-now.com/sys_trigger_list.do?sysparm_query=name%3DCheck%20database%20for%20possible%20upgrade%5EORname%3DCheck%20distribution%20for%20possible%20upgrade&sysparm_view= "Check distribution for possible upgrade""Check database for possible upgrade" 「Check distribution for possible upgrade」ジョブの System ID の値が空白になっていることを確認してください。値が設定されている場合は、--None-- に変更してください。 System ID をハードコーディングすることは推奨されません。選択されたノードが遠隔ノード（AHA の場合はセカンダリ DC のノード）になる可能性があり、アップグレードに長時間かかる場合があります。 アップグレードジョブは WAR ファイルをダウンロードし、このジョブがトリガーされたノードをアップグレードします。このノードが再起動されると、2つ目のジョブ「Check Upgrade Script/Check database for possible upgrade」がシステム起動時にトリガーされ、アップグレードが続行されます。これらのジョブはどちらもワーカースレッドで実行されます。 ServiceNow Support の変更の「計画開始時刻」を過ぎた後に「Check distribution for possible upgrade」ジョブの Next action time を変更することは推奨されません。問題が発生する可能性があります。 変更の「計画開始時刻」は、このジョブの実行時刻の10〜15分前に設定することをお勧めします。または、変更の「計画開始時刻」の2〜3時間前に Next action time（分）を調整することで、変更開始時刻に合わせてジョブを実行し、数サイクル正常に実行できるようにすることもできます。 5.アップグレードを予行演習する最善のプロセスは何ですか？ 本番アップグレードの ETA（推定完了時間） や動作を把握することは非常に重要です。 正しいタイムライン/動作を記録するには、次の 2 つのオプションがあります。 本番から準本番への完全クローンを開始します。その際、[Attachments]、[Audit and log]、および [Exclude tables specified in Exclusion list] をクローンに含める必要があります (デフォルトは除外)。すべてのチェックボックスをオフにして含めるようにしてください。その後、準本番インスタンスをアップグレードします。上記のテーブルを含めることは非常に重要です。これらのテーブルはインスタンス上で最も大きなテーブルであり、これらのテーブルへのインデックス作成/スキーマ変更にアップグレード時間の大部分が費やされる可能性があるためです。除外した場合、その時間は計画されたアップグレード作業に組み込むことができません。London では、クローン作成中にタスクテーブルのデータ量を選択できます (デフォルトは 90 日間)。正しいタイムラインを分析するには、タスクテーブル全体が必要となるため、"Full" を選択してください。準本番インスタンスが正確なレプリカになるように、本番インスタンスのバックアップの準本番インスタンスへの復元を要求します。準本番環境をアップグレードすることで、アップグレード実行時間の明確な ETA（推定完了時間） を得ることができます。 アップグレードの予行演習は複数回実行する必要があります。非本番環境でアップグレードを適切にテストすれば、本番環境でのアップグレードは問題なく進むと考えられます。また、予期しない問題を調査するためのサポートも利用できます。利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 類似した環境を比較していることを確認する必要があります。production インスタンスの最新のクローンではない non-production インスタンスと、production インスタンスのアップグレード動作を比較することはできません。同様に、1 か月前のクローンで、多数の構成変更 (プラグインやアプリのインストール、異なるアップグレードパスなど) が行われた non-production インスタンスは、正確に比較することができません。詳細については、次のナレッジベース記事を参照してください。 production インスタンスでのアップグレード動作を正確に検証するには、クローン作成後すぐに non-production インスタンスのドライランアップグレードを完了してください。 KB2715225 - Differences in the list of active applications or plugins between instances following an upgrade? Platform Academy: ServiceNow Upgrades with Version Checklists and True-Up Essentials 6.アップグレードの実行時間はどれくらいですか？ これは広範な質問であり、Support は完了予定時刻を提供できません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間は、インスタンス上のデータ量およびカスタマイズの範囲に応じて異なります。お使いの環境における正確な見積もりを得る唯一の方法は、予行演習を実施することです。 7.アップグレード中、インスタンスで何が発生しますか？ アップグレード中でもユーザーはインスタンスにログオンし、通常通り作業できます。影響は最小限に抑えられ、ユーザーが接続しているノードがアップグレードされると、ユーザー接続が 1 回リセットされます。 レコードの作成および作成されたレコードはアップグレードの影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 1 つのノードがノードをアップグレードし、スキーマ/DB のアップグレードをトリガーすることでプロセス全体を実行します。並行して、他のノードでアップグレードを実行し、アップグレード後にノードが再起動され、接続がリセットされます。 したがって、ノードが再起動されると、ノードは新しいバージョンになり、データベースのアップグレードが完了するまで DB は新しいバージョンになりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。そうすることで、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用することができます。 8.アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリデータベースとセカンダリデータベース（利用可能な場合）については、それぞれ個別のバックアップが取得されます。 バックアップサイクルは、毎週の完全バックアップと毎日の差分バックアップで構成され、14～28 日間 (保持ポリシーに基づく)のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細については、記事「 Backup Request for ServiceNow instance including Production」を参照してください 。 バックアップと保持の詳細については、ホワイトペーパー「Delivering Performance, Scalability, and Availability on The ServiceNow Cloud（ServiceNow クラウドでのパフォーマンス、スケーラビリティ、可用性の実現）」で説明しています。 Instance backup and recovery 9.アップグレード後にデータ破損が発生した場合、データを復旧するための選択肢は何ですか？ お客様のデータは安全です。本番環境でデータ破損が発生するという極めて可能性の低い状況では、Support は、本番インスタンスを TEMP インスタンスにポイントインタイムリストアし、TEMP インスタンス上でデータを特定の時点まで戻して比較することができます。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップまで復元し、指定された残りのデータを bin ログ/トランザクションログから再作成することで実行されます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームが関与する手動プロセスであり、重大な状況においてのみ開始されます。フェイルオーバー/リカバリ/切り戻し/ロールバック方法として扱うことはできません。 注: 本番環境では PIT リストアを直接行わず、Fix Forward のみ実施します。PIT リストアは、TEMP/SUBproduction インスタンスでのデータ比較とデータリカバリにのみ使用されます。 TEMP インスタンスを使用してアップグレード前後のデータを比較し、復旧計画を作成します。Support は、変更管理を通じて SOP に従って支援できます。 Fix Forward vs Restore from Backup 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？ 更新セットのプレビュー/コミットおよびプラグイン/アプリのインストールは、アップグレード中は利用できません。次のメッセージが表示されます : Info MessageUpdate set preview and commit are unavailable because the system is currently upgrading. Click here for the Upgrade Monitor これは、アップグレードの完了 (変更のクローズ) 後に再開されます 影響の詳細については、次の記事を参照してください。 KB0622951 - データベースのアップグレード中に影響を受ける機能 アップグレード中にいずれかの統合が機能しない場合、そのジョブが「Upgrade Safe」としてリストされていない可能性が高くなります。 アップグレード中に変更を行った結果として生じる影響について Support は助言できないため、アップグレード中は変更を行わないことをお勧めします。 カスタムスケジュール済みジョブを「Upgrade Safe」に設定しないでください。このフィールドには、アップグレードの妨げにならないようにするという目的があります。 アップグレードにはノードの再起動が伴います。KB2295695 の統合セクションを参照し、非本番環境でのドライランですべてのカスタム統合を検証してください。ServiceNow はベースシステムの動作のみをベンチマーク対象とし、アップグレード中のカスタム統合への影響についての情報提供はできません。 11.アップグレード中はどのようにユーザーを制限しますか？ アップグレード中にユーザーを制限するためのベースシステムオプションはありません。 これを実現するための回避策とカスタマイズがいくつかありますが、お客様の開発者またはパートナーとともに実装する必要があり、Customer Support の対応範囲外です。 利用可能ないくつかのオプションを紹介します。 インスタンスにシングルサインオンが実装されている場合は、SSO/SAML のポータル/ID プロバイダー経由でアクセスを制限できます。カスタムスクリプトを実行して、変更/アップグレード期間の前にログインしているすべてのユーザーをログアウトさせることもできます。また、ローカル管理者アカウントを作成し、管理者ユーザーのみが SAML/SSO ログインをスキップしてインスタンスのローカルアカウントでアクセスできるようにします。 Allow Only admin Role Users to Login to an Instance**この記事のすべてのスクリプトは提案にすぎず、お客様は展開する前にこれらのカスタマイズを慎重にテストする必要があります。 12.ServiceNow テクニカルサポートはアップグレードを監視できますか？ アップグレードは自動化されたプロセスであり、アップグレードが開始された後に FastTrack することはできません。 アップグレード中に発生する機能/運用面の問題については、アップグレードが完了するまで待つ必要があります。アップグレード中に発生したほとんどの問題は、アップグレード後に自然に解消されることが確認されています。アップグレード中には、新しいフィールドや機能の追加・削除など不確定要素が多数あるためです。 毎秒最大 150 行がバックエンドで作成されるため、バックエンドの localhost ノードログからアップグレードを監視することは現実的な方法ではありません。 アップグレードを監視する最善の方法は、Upgrade Monitor を使用することです。前述の理由から、Customer Support も Upgrade Monitor を使用してアップグレードを監視します。詳細については、Upgrade Monitor Overview を参照してください。 アップグレードモニターには、実行時の残りのプラグイン数、アップグレード内容に関する推定、プラグインごとの残っているレコードの推定が示されます。 sys_update テーブルにはアップグレード中の各処理の所要時間が記録されるため、進行状況を確認する上で重要な情報源となります。したがって、更新/アップグレードがスタックしていると思われる場合は、non-production DRY RUN (production のフル クローンの場合のみ) でこのテーブルを探して、production アップグレードと比較するための大まかな見積もりを取得できます。 特定のケースでは、テクニカルサポートは準本番ドライラン中に追跡・修正された既知の問題についてアップグレードを監視し、アクティブなケースを通じてお客様にご連絡します。 上記の理由で、テクニカルサポートがアップグレードを監視するためのプレースホルダーケースを作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。機能ごとに担当モジュールと SME チームが異なり、各問題のケースはそれぞれの担当チームが対応する必要があるため、プレースホルダーケースを作成しても役に立ちません。 アップグレード中/アップグレード後に問題が発生した場合は、 Now Support ヘルプセンター にアクセスしてサポートを受けることをお勧めします。その特定の問題についてサポートいたします。 更なる詳細は、ServiceNow Monitoring - Overview and Insight をご覧ください。 13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM です。ノードにデータは保存されていないため、ノードがダウンしてもインスタンスへの影響はなく、これを自動的に解決するための自動監視とルールが設定されています。 解決されるまでの間、ユーザートラフィックはすべて利用可能なノードに転送されます。 アップグレード中にいずれかのノードで問題/ダウン/障害が発生していることに気づいた場合は、アップグレードの変更が自動クローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20～30 分かかります。 問題が解決しない場合は、カスタマーサポートにご連絡ください。当社が手作業でノードをアップグレードするか、新しいバージョンの新しいノードを起動し、古いノードを無効にします。 14.アップグレードをロールバック/ダウングレードできますか？ 残念ながら、異なるファミリにアップグレードした場合は、ロールバックを実行できません。ロールバックできるのはパッチバージョンへのアップグレードのみです。 カスタマーサポートが変更管理を介して本番のロールバックを開始する場合は、これをサブ本番でテストして、意図した結果セットが得られていることを確認する必要があります。 このために、production を non-production に復元し、ロールバックを試して意図した結果セットを取得しているかどうかを確認し、お客様の確認を取得してから、production で実行します。 注意: ロールバックでは、スキーマの削除（テーブルまたは列の削除。ただし、インデックスの削除は記録されます）、再ペアレント化、列の昇格、テーブルの切り捨て、テーブルまたは列の名前変更、列タイプの変更、列幅の縮小は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレード後や偶発的なアップグレード後に予期しない致命的な問題が発生した場合に Fix Forward をお勧めします。 前方修正 (Fix Forward)：重大な問題ごとに個別のケースを作成し、各 SME チームが優先的に対応できるようにしてください。これらのケースにはアップグレード変更の詳細を記載してください。これらのケースについては、アップグレードの変更の詳細を記載してください。 この KB はデータ損失の観点で作成されたものですが、このシナリオでも範囲は同様であり、前方修正をお勧めします。前方修正とバックアップからの復元 また、データ回復オプションの詳細については、「アップグレード後にデータ破損が発生した場合、データを復旧するための選択肢は何ですか？」を参照してください。 上記の詳細については、ドキュメントを参照してください。 ロールバックと削除の復旧 ロールバックでは、ロールバック前のバージョンに設定されたプロパティ「glide.war.no_upgrade」が作成されます。このプロパティが存在すると、インスタンスがそのバージョンにアップグレードされないようになります。 London 以降、インスタンス管理者は以下をトリガーできます。 パッチのアップグレードまたはプラグインのアクティブ化のロールバック Upgrade Rollback Mechanism インスタンスのダウングレードは、どのインスタンスでもオプションではありません。インスタンスが非本番インスタンスの場合は、より低いバージョンの本番インスタンスまたはその他のインスタンスからクローンまたは復元できます。これにより、クローン/復元後の自動化で、ターゲットインスタンスが同じバージョンのソースインスタンスと一致するようになります。 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事では、非本番インスタンスでスキップされたレコードをレビューし、その結果を本番環境のアップグレード後に再利用できるよう更新セットに取得する手順について説明します。 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法 更新セットは、Disposition、Resolution、Comment などのアップグレードログ情報をキャプチャしません。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングのために、これらのログエントリ (必要な列) を、インポートセットを使用して転送する必要があります。 Paris 以降、この手順は変更されています。詳細については、以下の KB を参照してください。KB0955553: Skipped Update Records Resolution Tracking - Upgrade related changes in Paris version Tokyo 以降ではさらに多くの機能が追加され、アップグレード後のアクティビティの多くを自動化できるようになりました。詳細については、以下の KB を参照してください。 Upgrade Plan module FAQ (Tokyo+) Upgrade Plan モジュールは、同じ組織に関連付けられた複数の本番スタックが、複数のビルダーインスタンスで同じ apprepo を使用している場合、その組織ではサポートされません。 16. スキップされたレコード数が non-production インスタンスと異なるのはなぜですか？ 同等の環境間でのみ比較が可能です。インスタンスが同期していない場合、レコードの数はインスタンス間で異なります。 Support では、本番環境と非本番環境でレコード数が異なるこの問題が確認されています。これは、non-production が production のフルクローンではない場合 (ログ/監査が除外された可能性がある)に発生します。「アップグレードを予行演習する最善のプロセスはどれですか？」を参照してください。 KB0955553:スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください。 17. Upgrade Summary と Upgrade History レコードの間でスキップされた更新の数が異なるのはなぜですか？ 詳細については、この記事を参照してください: Skipped updates count mismatch between "Upgrade Summary Report in Upgrade Monitor" vs "Skipped updates widget on Upgrade History" vs "disposition Group by from sys_upgrade_history_log" table. アップグレード中に発生した内容の一覧を確認するには、sys_upgrade_history_log テーブルで「Disposition」によるグループ化を使用するのが最適です。 18. アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルが完了するまで実行させ、アップグレード後の問題は ServiceNow サポートチケットを通じて対処する必要があります。 利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか？(Paris 以降の新機能) KB0955553:スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください 。 20.インスタンスで予定されているアップグレードを通知する方法 How to notify upcoming upgrade on your own instance. 21.カスタマイズされたレコードをベースシステムに戻し、アップグレード可能性のための更新セットを介して転送する この KB を確認してください。 Revert customized record to OOB and transfer via Update-set for Upgradeability 22.アップグレード中に、適用された回避策が修正済みのベースシステムレコードで上書きされるようにする方法 この KB を確認してください。How to ensure workarounds applied are overwritten with fixed OOB records during the upgrade 23.以前のアップグレードのアップグレードサマリーレポートを表示できますか？ はい、できます。アップグレードモニターモジュールをクリックすると、常に最新のアップグレードに移動します。ただし、以前のアップグレードのサマリーレポートを表示するには、アップグレード履歴モジュールを開いてアップグレードレコードを開くと、フォームの Related Link にある View Upgrade Summary Report を選択します。 これにより、指定したアップグレードのサマリーレポートが開きます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }