インスタンスのアップグレードに関する 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: ; } } この記事では、インスタンスのアップグレードに関するよくある質問への回答と、関連する一般的な問題の緩和について説明します。 この情報は、標準提供 (OOTB) のインスタンスに適用されます。インスタンスに存在するカスタマイズはリストされた動作に影響を与える可能性があるため、各セクションのリンクを確認して詳細情報を参照してください。 セルフホスト/オンプレミスのお客様は、この KB も参照してください KB0598275 - セルフホストのお客様のアップグレードのベストプラクティス 1.ServiceNow サポートでアップグレードの変更をスケジュール/変更/キャンセルする方法を教えてください。2.パッチ適用プログラムとサポート終了アップグレードプログラム KB3.アップグレードに関して従うべきベストプラクティスは何ですか？4.ServiceNow サポートの変更でアップグレードが開始されず、開始予定時刻を過ぎたのはなぜですか？5.アップグレードを予行演習する最善のプロセスは何ですか？6.アップグレードの実行時間はどれくらいですか？7.アップグレード中、インスタンスで何が発生しますか？8.アップグレード前にアドホックバックアップを行うことはできますか？9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？11.アップグレード中はどのようにユーザーを制限しますか？12.ServiceNow テクニカルサポートはアップグレードを監視できますか？13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？14.アップグレードをロールバック/ダウングレードできますか？15. 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。16.スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？18. アップグレードの進行中にキャンセルすることはできますか？19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか？(Paris 以降の新機能)20.P+インスタンスで予定されているアップグレードを通知する方法21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送する22.アップグレード中に、適用されたワークアラウンドが固定された OOB レコードで上書きされるようにする方法23.以前のアップグレードのアップグレードサマリーレポートを表示できますか？ 1.ServiceNow サポートを使用してインスタンスのアップグレードをどのようにスケジュール/変更/キャンセルしますか？ KB0541128 - インスタンスのアップグレードを管理およびスケジュールする方法を参照してください。 インスタンスアップグレードのタイムスロットがありません。 2.パッチ適用プログラムとサポート終了アップグレードプログラム KB KB0696901: ServiceNow パッチ適用プログラムに関する FAQKB0610454: サポート終了 別名 サポートされていないリリースファミリー アップグレード FAQKB0828060: インスタンスステータス「サポート終了間近」についてKB0598977: サポートされていないリリースの定義 3.アップグレードに関して従うべきベストプラクティスは何ですか？ ドキュメントのこの章では、アプリケーションのアップグレードのベストプラクティスについて説明します。 インスタンスのアップグレード。 YouTubeチャンネルのこのビデオにも興味があるかもしれません。新しいリリースへのアップグレード 4.ServiceNow サポートの変更でアップグレードが開始されず、開始予定時刻を過ぎたのはなぜですか？ ServiceNow サポートの変更の開始予定により、ServiceNow インスタンスレコードでインスタンスに割り当てられた WAR バージョンをいつ変更する必要があるかが決まります。 アップグレードは、インスタンス上で 1 時間間隔 (OOB) で実行される "Check distribution for possible upgrade" ジョブによってトリガーされます。このジョブは、割り当てられた WAR バージョンについて、ServiceNow インスタンスレコードを 1 時間ごとにチェックします。割り当てられた新しい WAR バージョンを検出すると、新しい WAR バージョンをダウンロードします。 注意:ServiceNow サポート変更の開始予定時刻から、インスタンスでアップグレードがトリガーされるまで最大 1 時間かかる場合があります。 実際のアップグレードがインスタンス上でトリガーされると、ServiceNowサポート変更の作業開始時刻が更新されます。 インスタンスで以下の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」ジョブのシステムIDの値が空白になっていることを確認してください。値が設定されている場合は、必ず「--None--」を選択してください。 システム ID をハードコーディングすることは推奨されません。選択されたノードが遠隔ノード (AHA の場合はセカンダリ DC のノード) である可能性があり、アップグレードに長時間かかる場合があります。 アップグレードジョブはWARファイルをダウンロードし、このジョブがトリガーされたノードをアップグレードします。その後、このノードが再起動され、システム起動時に2番目のジョブ「アップグレードスクリプトの確認/データベースのアップグレード可能性の確認」がトリガーされ、アップグレードが続行されます。これらのジョブは両方ともワーカースレッドで実行されます。 ServiceNowサポート変更の「予定開始時刻」を過ぎた後に「ディストリビューションのアップグレード可能性の確認」ジョブの次のアクション時刻を変更することは、問題が発生する可能性があるため推奨されません。 変更の「予定開始時刻」は、このジョブの実行時刻の約10～15分前に設定してください。または、次のアクションの時間（分）を、変更の「予定開始時間」の2～3時間前に調整して、変更の開始の代わりに実行し、数回のサイクルを正常に実行することもできます。 5.アップグレードを予行演習する最善のプロセスは何ですか？ 本番アップグレードの ETA/動作を取得することは非常に重要です。 正しいタイムライン/動作を記録するには、次の 2 つのオプションがあります。 本番から準本番への完全クローンを開始します。その際、[添付ファイル]、[監査とログ]、および [Exclude tables specified in Exclusion list] (除外リストで指定されたテーブルを除外する) をクローンに含める必要があります (デフォルトは除外)。すべてのチェックボックスをオフにして含めるようにしてください。その後、準本番インスタンスをアップグレードします。上記のテーブルを含めることは非常に重要です。これらのテーブルはインスタンス上で最も大きなテーブルであり、これらのテーブルへのインデックス作成/スキーマ変更にアップグレード時間の大部分が費やされる可能性があるためです。除外した場合、その時間は計画されたアップグレード作業に組み込むことができません。London では、クローン作成中にタスクテーブルのデータ量を選択できます (デフォルトは 90 日間)。正しいタイムラインを分析するには、タスクテーブル全体が必要となるため、「完全」を選択してください。準本番インスタンスが正確なレプリカになるように、本番インスタンスのバックアップの準本番インスタンスへの復元を要求します。準本番環境をアップグレードできます。これにより、アップグレード実行時間の正確な ETA がわかります。 アップグレードの予行演習を複数回実行する必要があります。SUB PROD でアップグレードの適切なテストを行うと、PROD のアップグレードは正常に行われ、予期しない問題を調査するためのサポートを利用できます。利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 類似した環境を比較していることを確認する必要があります。PROD インスタンスの最新のクローンではない SUBPROD インスタンスと、PROD インスタンスのアップグレード動作を比較することはできません。同様に、1 か月前のクローンで、多数の構成変更 (プラグインやアプリのインストール、異なるアップグレードパスなど) が行われた SUBPROD インスタンスは、正確に比較することができません。詳細については、次のナレッジベース記事を参照してください。 アップグレード後にインスタンス間でアプリ/プラグインのアクティブリストが異なるのはなぜですか？ PROD インスタンスでのアップグレード動作を正確に検証するには、クローン作成後すぐに SUBPROD インスタンスのドライランアップグレードを完了してください。 6.アップグレードの実行時間はどれくらいですか？ これはより広範な質問であり、これに対する ETA を提供することはできません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間はインスタンスのデータ/カスタマイズの範囲に応じて異なります。予行演習はこの情報を取得できる唯一の方法です。 7.アップグレード中、インスタンスで何が発生しますか？ アップグレード中でもユーザーはインスタンスにログオンし、通常通り作業できます。影響は最小限に抑えられ、ユーザーが接続しているノードがアップグレードされると、ユーザー接続が 1 回リセットされます。 レコード作成および作成されたレコードはアップグレードによる影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 1 つのノードがノードをアップグレードし、スキーマ/DB のアップグレードをトリガーすることでプロセス全体を実行します。並行して、他のノードでアップグレードを実行し、アップグレード後にノードが再起動され、接続がリセットされます。 したがって、ノードが再起動されると、ノードは新しいバージョンになり、データベースのアップグレードが完了するまで DB は新しいバージョンになりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。そうすることで、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用することができます。 8.アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリ DB とセカンダリ DB (利用可能な場合) 用に別々にバックアップを取ります。 バックアップサイクルは、毎週の完全バックアップと毎日の差分バックアップで構成され、14～28 日間 (保持ポリシーに基づく)のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細については、記事「 本番環境を含む ServiceNow インスタンスのバックアップ要求」を参照してください 。 バックアップと保持の詳細については、ホワイトペーパー「Delivering Performance, Scalability, and Availability on The ServiceNow Cloud（ServiceNow クラウドでのパフォーマンス、スケーラビリティ、可用性の実現）」で説明しています。 データのバックアップとリカバリ 9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ データは ServiceNow が安全に保護しています。本番環境でデータ破損が発生するきわめてまれなケースでは、PROD インスタンスを TEMP インスタンスにポイントインタイムリストアして、PROD インスタンス上のデータを TEMP インスタンス上のデータ比較のためにその特定の時間 (特定の分) に戻すことができます。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップまで復元し、指定された残りのデータを bin ログ/トランザクションログから再作成することで実行されます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームが関与する手動プロセスであり、重大な状況においてのみ開始されます。フェイルオーバー/リカバリ/切り戻し/ロールバック方法として扱うことはできません。 注: 本番環境では PIT リストアを直接行わず、フォワードでのみ修正します。PIT リストアは、TEMP/SUBPROD インスタンスでのデータ比較とデータリカバリにのみ使用されます。 TEMP インスタンスにデータを取得したら、これを使用してアップグレード後のバージョンとアップグレード前のバージョン間のデータを比較し、データ復旧計画を策定できます。変更管理プロセスを介して個々のケースに基づいてデータを分析および復旧するための SOP を定義しているため、問題が発生した場合は支援いたします。 前方修正とバックアップからの復元 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？ 更新セットのプレビュー/コミットおよびプラグイン/アプリのインストールは、アップグレード中は利用できません。「Info Message: Update set preview and commit are unavailable because the system is currently upgrading. Click here for the Upgrade Monitor」（情報：現在システムのアップグレード中のため、更新セットのプレビューとコミットはご利用いただけません。アップグレードモニターについては、こちらをクリックしてください。） これは、アップグレードの完了 (変更のクローズ) 後に再開されます 影響の詳細については、次の記事を参照してください。 KB0622951 - データベースのアップグレード中に影響を受ける機能 アップグレード中にいずれかの統合が機能しない場合、そのジョブが「アップグレードセーフ」としてリストされていない可能性が高くなります。 影響についてコメントできないため、アップグレード中に変更しないことをお勧めします。 カスタムスケジュール済みジョブを [アップグレードセーフ] に設定しないでください。このフィールドには、アップグレードの妨げにならないようにするという目的があります。 11.アップグレード中はどのようにユーザーを制限しますか？ アップグレード中にユーザーを制限するための OOB オプションはありません。 これらの実装はお客様の開発者/パートナーが行う必要があり、カスタマーサポートの範囲外となります。 利用可能ないくつかのオプションを紹介します。 インスタンスにシングルサインオンが実装されている場合は、SSO/SAML のポータル/ID プロバイダー経由でアクセスを制限できます。カスタムスクリプトを実行して、変更/アップグレード期間の前にログインしているすべてのユーザーをログアウトさせることもできます。また、ローカル管理者アカウントを作成し、管理者ユーザーのみが SAML/SSO ログインをスキップしてインスタンスのローカルアカウントでアクセスできるようにします。 管理者ロールのユーザーのみにインスタンスへのログインを許可します**この記事のすべてのスクリプトは提案にすぎず、お客様は展開する前にこれらのカスタマイズを慎重にテストする必要があります。 12.ServiceNow テクニカルサポートはアップグレードを監視できますか？ アップグレードは自動化されたプロセスであり、ひとたび開始されると、アップグレードをファストトラックすることはできません。 アップグレード中に発生する機能/運用面の問題については、アップグレードが完了するまで待つ必要があります。アップグレード中に発生したほとんどの問題は、アップグレード後に修正されます。アップグレード中には、新しいフィールドや機能の追加・削除など不確定要素が多数あるためです。 毎秒最大 150 行がバックエンドで作成されるため、バックエンドの localhost ノードログからアップグレードを監視することは現実的な方法ではありません。 アップグレードを監視する最善の方法は、アップグレード モニターウィンドウを使用することです。前述の理由から、カスタマーサポートもこのウィンドウを使用してアップグレードを監視します。詳細については、アップグレードモニターの概要 を参照してください。 アップグレードモニターには、実行時の残りのプラグイン数、アップグレード内容に関する推定、プラグインごとの残っているレコードの推定が示されます。 「sys_update」は、アップグレード中に各アクティビティの期間が格納される非常に重要なテーブルです。したがって、更新/アップグレードがスタックしていると思われる場合は、SUB PROD DRY RUN (PROD のフル クローンの場合のみ) でこのテーブルを探して、PROD アップグレードと比較するための大まかな見積もりを取得できます。 特定のケースでは、テクニカルサポートは、SUB 本番リハーサル中に追跡および修正された、以前に報告されたアクティブな問題のアップグレードを監視し、アクティブなケースを介してお客様に連絡されます。 上記の理由で、テクニカルサポートがアップグレードを監視するためのプレースホルダーケースを作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。プレースホルダーケースは個々の問題に対して個別のチームで対処する必要があるため、アップグレード監視には有効ではありません。 アップグレード中/アップグレード後に問題が発生した場合は、 Now Support ヘルプセンター にアクセスしてサポートを受けることをお勧めします。その特定の問題についてサポートいたします。 更なる詳細は、ServiceNow Monitoring - 概要とインサイト をご覧ください。 13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM にすぎません。ノードにデータは保存されていないため、ノードがダウンしてもインスタンスへの影響はなく、これを自動的に解決するための自動監視とルールが設定されています。 解決されるまでの間、ユーザートラフィックはすべて利用可能なノードに転送されます。 アップグレード中にいずれかのノードで問題/ダウン/障害が発生していることに気づいた場合は、アップグレードの変更が自動クローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20～30 分かかります。 問題が解決しない場合は、カスタマーサポートにご連絡ください。当社が手作業でノードをアップグレードするか、新しいバージョンの新しいノードを起動し、古いノードを無効にします。 14.アップグレードをロールバック/ダウングレードできますか？ 残念ながら、異なるファミリにアップグレードした場合は、ロールバックを実行できません。ロールバックできるのはパッチアップデートのみです。 カスタマーサポートが変更管理を介して本番のロールバックを開始する場合は、これをサブ本番でテストして、意図した結果セットが得られていることを確認する必要があります。 このために、PROD を SUB PROD に復元し、ロールバックを試して意図した結果セットを取得しているかどうかを確認し、お客様の確認を取得してから、PROD で実行します。 注意: ロールバックでは、スキーマの削除 (テーブルまたは列、インデックスの削除は問題ありません)、再ペアレント化/列の昇格、テーブルの切り捨て、テーブル/列の名前変更、列タイプの変更、または列幅の減少は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレード後や偶発的なアップグレード後に予期しない致命的な問題が発生した場合に 前方修正 をお勧めします。 前方修正 (Fix Forward)：重大な問題に対して個々のケースを作成し、各 SME チームが優先度に基づいて作業できるようにします。これらのケースについては、アップグレードの変更の詳細を記載してください。 この KB はデータ損失の観点で作成されたものですが、このシナリオでも範囲は同様であり、前方修正をお勧めします。前方修正とバックアップからの復元 また、データ回復オプションの詳細については、「アップグレード後にデータが破損した場合、データを復旧するために何ができますか？」を参照してください。 上記の詳細については、ドキュメントを参照してください。 ロールバックと削除の復旧 ロールバックでは、ロールバック前のバージョンに設定されたプロパティ「glide.war.no_upgrade」が作成されます。このプロパティが存在すると、インスタンスがそのバージョンにアップグレードされないようになります。 London 以降、インスタンス管理者は以下をトリガーできます。 パッチのアップグレードまたはプラグインのアクティブ化のロールバック アップグレードロールバックメカニズム インスタンスのダウングレードは、どのインスタンスでもオプションではありません。インスタンスが SUB 本番インスタンスの場合は、下位バージョンの本番/インスタンスからクローン/復元できます。これにより、クローン/復元後の自動化で、ターゲットインスタンスが同じバージョンのソースインスタンスと一致するようになります。 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事は、PROD でのアップグレード後に再利用できる SUB PROD インスタンスのスキップされたレコードのレビューをキャプチャする手順に役立ちます。 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法 更新セットは、インスタンスのアップグレードログから処分、解決、コメントなどをキャプチャしません。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングのために、これらのログエントリ (必要な列) を、インポートセットを使用して転送する必要があります。 Paris 以降、この手順は変更されています。詳細については、以下の KB を参照してください。スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点 Tokyo 以降ではさらに多くの機能が追加され、アップグレード後のアクティビティの多くを自動化できるようになりました。詳細については、以下の KB を参照してください。 アップグレードプランモジュールのFAQ(Tokyo+) 「アップグレードプラン」モジュールは、同じ組織にリンクされた複数の本番スタックを持つ組織ではサポートされていません。これらの本番スタックは複数のビルダーインスタンスで同じ apprepo を使用するためです。 16. スキップされたレコード数が SUB PROD インスタンスと異なるのはなぜですか？ 同等の環境間でのみ比較が可能です。インスタンスが同期していない場合、レコードの数はインスタンス間で異なります。 この問題は、本番環境と準本番環境の間でカウントが異なる場合に発生します。これは、SUB PROD が PROD のフルクローンではない場合 (ログ/監査が除外された可能性がある)に発生します。「アップグレードを予行演習する最善のプロセスはどれですか？」を参照してください。 KB0955553:スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください。 17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？ 詳細については、この記事を参照してください:スキップされた更新の数が "アップグレードモニターでのアップグレードサマリーレポート" と "アップグレード履歴でのスキップされた更新ウィジェット" と "sys_upgrade_history_log からのグループごとの処分" テーブル間で不一致 アップグレード中に何が起こったかをまとめたリストを取得するのに最適な場所は、テーブル sys_upgrade_history_log と「処分」によるグループ化です 18. アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルが完了するまで実行させ、アップグレード後の問題は ServiceNow サポートチケットを通じて対処する必要があります。 利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか？(Paris 以降の新機能) KB0955553:スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください 。 20.P+インスタンスで予定されているアップグレードを通知する方法 自分のインスタンスで予定されているアップグレードを通知する方法。 21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送する この KB を確認してください カスタマイズされたレコードを OOB に戻し、アップグレード性のための更新セットを介して転送 22.アップグレード中に、適用されたワークアラウンドが固定された OOB レコードで上書きされるようにする方法 この KB を確認してください。アップグレード中に、適用されたワークアラウンドが固定 OOB レコードで上書きされるようにする方法 23.以前のアップグレードのアップグレードサマリーレポートを表示できますか？ はい、できます。アップグレードモニターモジュールをクリックすると、常に最新のアップグレードに移動します。ただし、以前のアップグレードのサマリーレポートを表示するには、アップグレード履歴モジュールを開いてアップグレードレコードを開くと、フォームに関連リンクが表示されます。 アップグレードサマリーレポートを表示します。 これにより、指定したアップグレードのサマリーレポートが開きます。 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: ; } }