---
sourceDocument: Yokohama Now Platform 機能
sourceDocumentLink: https://www.servicenow.com/docs/r/ja-JP/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama Now Platform 機能

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

MID サーバーのアップグレード
================

MID サーバーのアップグレード {#ariaid-title1}
=================================

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：20分

MID サーバーを手動でアップグレードするか、インスタンスから自動的にアップグレードします。インスタンスがアップグレードされ、MID サーバーのバージョンが同じでなくなると、MID サーバーの自動アップグレードがトリガーされます。新しい MID サーバーパッケージが install.service-now.com からダウンロードされ、古いパッケージが置き換えられ、MID サーバーが新しいバージョンで起動します。  
警告:  
Windows アプリケーションエクスペリエンスサービスがオフになっている場合、Windows ホストでは MID サーバーを自動アップグレードできません。表示されるエラーおよびこのサービスを再度有効にする方法については、[KB0597552](https://support.servicenow.com/kb_view.do?sysparm_article=KB0597552#appex) を参照してください。

MID サーバーのアップグレード要件 {#c_UpgradeAndTestMIDServer__section_u3z_xdf_1qb}
--------------------------------------------------------------------

MID サーバーのダウンロード サイトへのアクセス
:   MID サーバーのホストコンピューターは、自動でアップグレードするために install.service-now.com の ServiceNow ダウンロードサイトにアクセスできる必要があります。ダウンロードサイトへのアクセスをブロックする自己ホスト ServiceNow 環境の場合は、MID Server インストーラーパッケージを MID サーバーのホストに手動でインポートする必要があります。手順については、自己ホストされたナレッジベースの「[KB0760123](https://support.servicenow.com/kb_view.do?sysparm_article=KB0760123)」を参照してください。

OCSP への MID サーバーのアクセスをブロック
:   ファイアウォールとプロキシの構成によって、OCSP Entrust サーバーと DigiCert サーバーへの呼び出しがブロックされ、MID サーバーが機能しなくなる可能性があります。OCSP トラフィックが通過するように、ファイアウォールの権限を変更する必要がある場合があります。詳細と解決策については、HI ナレッジベースの記事 [\[KB1216223\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1216223) を参照してください。

MID サーバーのオペレーティングシステムの互換性
:   32 ビットのオペレーティングシステムを使用した Windows または Linux MID サーバーのアップグレードはサポートされていません。詳細については、[\[KB0863694\]](https://support.servicenow.com/nav_to.do?uri=/kb?id=kb_article_view&sysparm_article=KB0863694) を参照してください。

Windows アプリケーションエクスペリエンスサービスがオフになっている場合、Windows ホストでは MID サーバーをアップグレードできません。表示されるエラーおよびこのサービスを再度有効にする方法については、[KB0597552](https://support.servicenow.com/kb_view.do?sysparm_article=KB0597552#appex&_ga=2.137899701.402632408.1615226320-1555493315.1610383440) を参照してください。

MID サーバーのアップグレードは、Windows ホストで実行されている一部のアンチウイルスによってブロックされています。エラーとこれらのアンチウイルスリストの詳細については、[KB0870329](https://support.servicenow.com/nav_to.do?uri=/kb?id=kb_article_view&sysparm_article=KB0870329) を参照してください。

Madrid 以前のシステムでサービスがインストールされている Linux MID サーバーのアップグレードは、アップグレード後にサービスを再インストールする必要があります。以前のアップグレードでサービスを手動で再インストールしておらず、MID サーバーサービスが引き続き Madrid 以前のバージョンでインストールされると、アップグレード中に MID サーバーによってサービスが自動的に再インストールされます。サービスを再インストールするには、MID サーバーを admin ユーザーとして実行する必要があります。MID サーバーのアップグレードでサービスを再インストールする必要がある場合は、MID サーバーのユーザーが admin であることを確認してください。そうでない場合は、アップグレード前にサービスを手動で再インストールできます。サービスを手動で再インストールする方法については、[KB0821436](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0821436) を参照してください。

MID サーバーをアップグレードする必要のあるタイミング {#c_UpgradeAndTestMIDServer__section_o1l_n2f_1qb}
------------------------------------------------------------------------------

インスタンスのバージョンと異なるバージョンの MID サーバーは、アップグレードする必要があります。次の 2 つのシステムプロパティが、すべての MID サーバーのバージョンを管理します。

* mid.buildstamp：ビルドの日付に基づく識別子で MID サーバーのバージョンを識別します。このプロパティは、mm-dd-yyyy-hhmm という形式を使用します。MID サーバーは、1 時間ごとにバージョン情報を確認します。上書きバージョンが設定されていない場合、MID サーバーは使用するバージョンの mid.buildstamp プロパティを調べます。このプロパティは、インスタンスの再起動時またはアップグレード時にデフォルト バージョン (インスタンス バージョンと一致するバージョン) にリセットされるため、その時点でユーザーによる変更は失われます。リリース名とパッチ情報が日付と時刻の形式に追加されます。  
  警告:  
  このプロパティはデフォルトでは表示されず、構成する必要があります。
* mid.version.override：環境内のすべての MID サーバーに対して、現在のバージョンの上書き条件を設定します。このアクションは、MID サーバーを単一のバージョンに固定し、自動アップグレード機能を無効にします。このプロパティはベースシステムでは表示されず、設定するときはシステム プロパティ \[sys_properties\] テーブルに追加する必要があります。詳細については、「[Add a system property (システムプロパティを追加する)](https://www.servicenow.com/docs/access?context=r_AvailableSystemProperties&version=yokohama&pubname=yokohama-platform-administration&section=t_AddAPropertyUsingSysPropsList&ft:locale=en-US)」を参照してください。

{#c_UpgradeAndTestMIDServer__ul_pdt_r2f_1qb}

MID サーバーは、1 時間ごとにバージョンを確認するときに、まず mid.version.override プロパティを調べます。このプロパティが空の場合、MID サーバーは mid.buildstamp プロパティからバージョン情報を取得します。上書きバージョンが設定されている場合、MID サーバーはその値を使用し、mid.buildstamp プロパティのバージョン情報は無視します。この上書き値はインスタンスが再起動されても残り、MID サーバーに渡されます。mid.version.override プロパティの値はアップグレード中に消去されます。これにより、MID サーバーが mid.buildstamp プロパティのバージョンに自動的にリセットされます。

MID サーバーのバージョンは、mid.version.override に加えて、MID サーバーを特定のバージョンに固定する設定パラメーター mid.pinned.version で制御することもできます。MID サーバーを固定するには、各 MID サーバーの config.xml ファイルの mid.pinned.version パラメーターをバージョンの名前で設定します。\<version\>-mm-dd-yyyy の形式を使用します。この設定は、固定される MID サーバーのバージョンのプロパティ設定を上書きします。手順については、「[MID サーバーのパラメーターを追加する](https://www.servicenow.com/docs/z5mXwzuBoaJ2~yb0kl9WCw#mid-server-parameters "パラメーターは特定の MID サーバーの動作を制御し、MID サーバープロパティよりも優先順位が低いです。")」を参照してください。このパラメーターに設定された値は、アップグレードの影響を受けません。  
警告:  
mid.version.override と mid.pinned.version の使用は推奨されていません。MID サーバーとインスタンスのバージョンが異なると、MID サーバーで機能停止の問題が発生する可能性があります。

アップグレード手法
---------

自動
:   自動アップグレードは、インスタンスまたは MID サーバー自体によってトリガーできます。この機能はデフォルトで利用可能です。次の場合に自動アップグレードが行われます。

    * インスタンスがアップグレードされ、そのバージョンの MID サーバーが現在 MID サーバー上にあるバージョンと異なる場合。インスタンスは、接続されている MID サーバーに autoUpgrade システムコマンドを送信します。
    * MID サーバーは、1 時間ごとにインスタンスをチェックして、アップグレード可能な別のバージョンがあるかどうかを確認します。この時間間隔を変更することはできません。
    {#c_UpgradeAndTestMIDServer__ul_gyx_3ff_1qb}

マニュアル
:   MID サーバーレコードの関連リンクをクリックして、手動でアップグレードを開始します。次の 1 時間ごとの自動更新まで待てない場合や、アップグレードに失敗した後に強制的にアップグレードする場合は、この手法を使用します。手順については、「[手動での MID サーバーのアップグレード](https://www.servicenow.com/docs/TScWgxuq14ebxFJDcfxNcw "自動アップグレードを待てない場合は、いつでも MID サーバーを手動でアップグレードできます。")」を参照してください。

アップグレードの手順 {#c_UpgradeAndTestMIDServer__section_tl1_prm_1qb}
------------------------------------------------------------

1. アップグレード前のチェック：実際の MID サーバーのアップグレードプロセスを開始する前に、MID サーバーは一連のテストを実行して、ホストマシンが最小要件を満たしていることを確認します。この自動テスト中にエラーが発生すると、問題が解決されるまでアップグレードが実行されなくなります。アップグレード前のテストはデフォルトで有効になっていますが、システムプロパティを追加して設定することで無効にできます。詳細については、「[アップグレード前の MID サーバーのチェック](https://www.servicenow.com/docs/Y8m5LRCbXSIrWrsRKqtQ4w "アップグレードの前に、MID サーバーはテストを実行して、アップグレードプロセスが失敗したり、MID サーバーが機能停止したりする可能性がある問題を特定します。")」を参照してください。
2. パッケージのダウンロード：MID サーバーは、install.service-now.com からアップグレードパッケージをダウンロードします。これらのパッケージは zip 形式であり、package/incoming フォルダーの agent フォルダーにダウンロードされます。
3. デジタル署名検証

   すべてのパッケージをダウンロードした後、 MID サーバーはパッケージのデジタル署名を確認します。検証が失敗した場合は例外がスローされます。エラーは、エージェントログと MID サーバーの問題テーブルに記録されます。

   パッケージを手動でダウンロードして置換する場合は、署名を手動で確認できます。インストールまたはアップグレードパッケージの署名を手動で検証するには、JDK で無料で入手できる jarsigner ツールを使用します。検証を開始する jarsigner コマンドは、`Jarsigner -verify -verbose -certs -strict <zip-file>` です。  
   出力は次の例のようになります。

       - Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
       Digest algorithm: SHA-256
       Signature algorithm: SHA256withRSA, 2048-bit key
       Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
       Timestamp digest algorithm: SHA-256
       Timestamp signature algorithm: SHA256withRSA, 2048-bit key
        
       jar verified.
        
       The signer certificate will expire on 2021-08-09.
       The timestamp will expire on 2029-03-22.

4. Zip ファイルの展開：必要なすべてのパッケージをダウンロードした後、MID サーバーは zip ファイルを展開します。
   * Rome 以前：オペレーティングシステムで定義された一時フォルダーの下のフォルダーに zip ファイルが解凍されます。フォルダー名はランダムに生成された番号です。オペレーティングシステムの一時フォルダーは、システムプロパティ java.io.tmpdir で指定されます。UNIX ホストでは、このプロパティの値は通常 /tmp または /var/tmp です。
   * Rome 以降：MID サーバーは、MID サーバーのアップグレード中にオペレーティングシステムで定義された一時フォルダーの使用を回避します。zip ファイルは、agent フォルダーの下の work/upgrade_temp フォルダー内のフォルダーに展開されます。フォルダー名形式はランダムに生成された番号です。以前の動作に切り替えてオペレーティングシステムで定義された一時フォルダーを使用する場合は、MID サーバーの config.xml ファイルに mid.upgrade.use_os_temp_folder を追加して true に設定します。すべての MID サーバーの動作を切り替えるには、\[MID サーバー\] フィールドを空白にして、MID サーバーのプロパティ \[ecc_agent_property\] に動作を追加します。

   {#c_UpgradeAndTestMIDServer__ul_ll5_msm_1qb}  
   注:  
   [KB0747569](https://support.servicenow.com/nav_to.do?uri=/kb?id=kb_article_view&sysparm_article=KB0747569) を使用して java.io.tmpdir を変更し、Rome からの今後のアップグレードのためにこれを保持したい場合は、Rome へのアップグレード後に mid.upgrade.use_os_temp_folder を true に設定します。mid.upgrade.use_os_temp_folder が true に設定されていない場合、MID サーバーのアップグレード中に java.io.tmpdir は適用されず、agent\\work\\upgrade_temp の下のフォルダーが使用されます。
5. 古いパッケージをアップグレードされたパッケージに置き換える：アップグレードパッケージをダウンロードして展開した後、MID サーバーは古いファイルを新しいファイルに置き換え、新しいバージョンで起動します。パッケージを置き換えるために、MID サーバーは ServiceNow プラットフォームディストリビューションアップグレード というプロセスを開始し、シャットダウンします。ServiceNow プラットフォームディストリビューションアップグレードは、MID サーバーが適切にシャットダウンするのを待ってから、次のように必要なファイルを置き換えます。
   * Rome 以前：このプロセスでは、bin、lib、jre フォルダー内のすべてのファイルとフォルダーが削除され、新しいファイルがこれらのフォルダーにコピーされます。
   * Rome 以降：ファイルの新しいバージョンが古いバージョンと異なる場合にのみ、bin、lib、jre 内のファイルが置き換えられます。ServiceNow プラットフォームディストリビューションアップグレード では、アップグレードファイルは消去されず、変更されていないファイルは保持されます。

   {#c_UpgradeAndTestMIDServer__ul_kwc_htm_1qb}MID サーバーのアップグレードの一環として再インストールサービスが必要な場合、ServiceNow プラットフォームディストリビューションアップグレードは、MID サーバーを起動する前にサービスを再インストールします。詳細については、[KB0821436](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0821436) を参照してください。  
   注:  
   このステップで MID サーバーのアップグレードが失敗した場合、MID サーバーは \[ダウン\] のままになります。一部のアンチウイルスソフトウェアは、このステップでファイルの置き換えをブロックします。詳細については、[KB0870329](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0870329) を参照してください。
6. MID サーバーの起動：必要なすべてのファイルを新しいバージョンに置き換えた後、ServiceNow プラットフォームディストリビューションアップグレードは MID サーバーを起動します。MID サーバーが新しいバージョンを起動すると、アップグレードファイルの抽出に使用されたすべての一時フォルダーがクリーンアップされます。
{#c_UpgradeAndTestMIDServer__ol_jzk_hsm_1qb}

アップグレード時のログメッセージ {#c_UpgradeAndTestMIDServer__section_b2s_xtm_1qb}
------------------------------------------------------------------

MID サーバーのログメッセージは、次のログファイルで確認できます。

* アップグレード前のチェックログメッセージは、agent/logs フォルダーの agent.log ファイルにあります。\[アップグレード前の検証テストを実行しています。(Performing pre-upgrade validation tests.)\] というメッセージは、 アップグレード前のチェックが開始されたことを示します。すべての必須テストに合格した場合、「アップグレード前の検証テストは成功です (Pre-upgrade validation tests successful)」というメッセージが表示されます。アップグレードプロセスを続行します。(Pre-upgrade validation tests successful. Continuing with upgrade process.)\] というメッセージは、アップグレード前のチェックの終了を示します。

* ダウンロード時の不足しているファイルのログメッセージも、agent.log で確認できます。すべてのパッケージのダウンロードは、「https://install.service-now.com/ PACKAGEINFO からパッケージを PACKAGENAME.ZIP にダウンロード中 (Downloading package to PACKAGENAME.ZIP from https://install.service-now.com/ PACKAGEINFO)」というメッセージから始まります。ダウンロードの進行状況とダウンロードされたファイルのサイズは、ログで監視されます。すべてのパッケージをダウンロードした後、「パッケージは https://install.service-now.com/ PACKAGEINFO から正常にダウンロードされました (Package was successfully downloaded from https://install.service-now.com/ PACKAGEINFO)」というメッセージで、ダウンロードが成功したことが示されます。

* zip ファイルの展開は、agent.log で利用可能な最後のステップです。「MID サーバーのアップグレード中 (Upgrading MID server)」というメッセージはこのステップが開始されたことを示し、「パッケージ PACKAGE.ZIP を EXTRACT_TMP_FOLDER に展開中 (Extracting package PACKAGE.ZIP to EXTRACT_TMP_FOLDER)」というメッセージは、各パッケージの展開を示しています。必要なすべての zip ファイルが正常に展開されると、MID サーバーは ServiceNow プラットフォームディストリビューションアップグレードプロセスを開始し、\[MID サーバーを停止しています。アップグレードのブートストラップ中 (Stopping MID server. Bootstrapping upgrade)\] メッセージでこのステップが終了したことを示し、その後 MID サーバーが停止します。

{#c_UpgradeAndTestMIDServer__ul_c2f_ztm_1qb}  
ServiceNow プラットフォームディストリビューションアップグレードログには、プロセスの起動と MID サーバーのアップグレード中にファイルを置き換えるためのログメッセージが含まれています。アップグレードログメッセージは、メッセージ \[\*\*\*\*\*\*\*\*\*\*\*アップグレードメインログイン開始 (\*UPGRADE MAIN LOGIN START) \*\*\*\*\*\*\*\*\*\*\] と \[\*\*\*\*\*\*\*\*\*\*\*アップグレードメインログイン終了 (UPGRADE MAIN LOGIN END) \*\*\*\*\*\*\*\*\*\*\*\] の間に配置されます。ServiceNow プラットフォームディストリビューションアップグレードのログメッセージは、次のログファイルで確認できます。

* 一時展開フォルダーの glide-dist-upgrade.log ファイル。このファイルは、temp 展開フォルダーの下の upgrade-wrapper/logs フォルダーにあります。このログファイルには、プロセスログメッセージとアップグレードログメッセージが含まれています。
* agent\\logs フォルダーの dist-upgrade.log ファイル。このファイルには、ログメッセージのアップグレード部分のみが含まれます。プロセスのスタートアップに問題があった場合は、glide-dist-upgrade.log を確認する必要があります。
* Agent\\logs フォルダーの wrapper.log。ファイルを置き換えた後、ServiceNow プラットフォームディストリビューションアップグレードは、wrapper.log ファイルに glide-dist-upgrade.log を追加します。
{#c_UpgradeAndTestMIDServer__ul_z1h_k5m_1qb}

upgrade-wrapper-override.conf でラッパー構成を更新します {#c_UpgradeAndTestMIDServer__section_bvp_ybl_fzb}
---------------------------------------------------------------------------------------------

glide-dist-upgrade のラッパー構成は、upgrade-wrapper-override.conf ファイルを使用して更新できます。agent/conf フォルダーに upgrade-wrapper-override.conf という名前のファイルを作成します。upgrade-wrapper-override.conf のすべての構成は、アップグレードのプロセス中に使用されます。

upgrade-wrapper-override.conf を使用して構成を変更すると、dist-upgrade ラッパーのレベルでデバッグログを有効にし、変更をテストできます。

たとえば、デフォルトのタイムアウトの長さが、特定の JVM レベルのコマンドに対して十分でない場合があります。dist-upgrade ラッパー構成の upgrade-wrapper-override.conf を使用すると、タイムアウトを増やすことができます。

MID サーバーの状況 {#c_UpgradeAndTestMIDServer__section_t1p_jc4_1qb}
-------------------------------------------------------------

アップグレード中
:   アップグレードの実行中に、MID サーバーのステータスは、\[アップグレード中\] に変更されます。\[アップグレード中 (Upgrading)\] ステータスは、[\[一時停止\]](o6nWNLlX5EHisyMyOnMh5A#t_PauseTheMIDServer "MID サーバーを一時停止して、作業用の ECC キューをポーリングしたり、検出結果をインスタンスに送り返したりすることを一時的に防止します。") ステータスと似ています。これは、アップグレード中に新しいバージョンのインスタンスと以前のバージョンの MID サーバーとの間で発生する可能性がある通信エラーを回避します。\[アップグレード中\] 状態の間は、MID サーバーを再開または再起動することはできません。ただし、MID サーバーが \[一時停止\] 状態のときに実行できるアクションと同じアクションは実行できます。  
    注:  
    Istanbul インスタンスを使用していて、Istanbul 以前の MID サーバーを Istanbul にアップグレードする場合は、これらのアップグレード状況は利用できません。既に Istanbul である MID サーバーにのみ利用できます。

アップグレード失敗
:   アップグレード前のチェックステップまたはパッケージのダウンロード/展開ステップでアップグレードが失敗した場合、失敗したアップグレードはアップグレードしているバージョンに基づいて異なる方法で処理されます。

    * 別のメジャーリリースへのアップグレード (Istanbul から次のフルリリースなど)：ステータスが \[アップグレード失敗\] に変更されます。
    * リリース内のマイナー バージョンからのアップグレード (Jakarta パッチ 1 からパッチ 2 など)：MID サーバーは現在実行中のバージョンを使用し続けます。MID サーバーは既に正常に機能しているとみなされ、アップグレードは実行されず、ステータスは最終的に \[稼働\] に変更されます。
    * 最後のステップでアップグレードが失敗し、古いバージョンのパッケージが新しいバージョンのパッケージに置き換えられた場合、MID サーバーは \[ダウン (Down)\] のままになります。
    {#c_UpgradeAndTestMIDServer__ul_k4q_rc4_1qb}

MID サーバーのアップグレード履歴 {#c_UpgradeAndTestMIDServer__section_xml_lly_qhb}
--------------------------------------------------------------------

MID サーバーのアップグレードに関する問題のトラブルシューティングを行うには、MID サーバーアップグレード履歴モジュールを使用します。モジュールには、各インスタンスのアップグレードのレコードが含まれています。これらのレコードは、各 MID サーバーのアップグレードプロセスの詳細なステータスを段階的に提供します。エラーが発生した場合は、ステップに記載され、詳細が記載されたメッセージが動的に生成されます。テーブルクリーンアップジョブは、ステータスに関係なく、30 日間検出されなかった問題を自動的に削除します。詳細については、「[MID サーバーアップグレード履歴](https://www.servicenow.com/docs/eaNdydGYz4wr3d8u4Td7Kw "このモジュールを使用して、MID サーバーのアップグレードプロセス中に発生するエラーのトラブルシューティングを行います。MID サーバーアップグレード履歴テーブルには、各インスタンスアップグレードのレコードが含まれます。MID サーバーのアップグレードステージテーブルには、各 MID サーバーのステータスと、発生したエラーを含むアップグレードの進捗状況が表示されます。")」を参照してください。

JRE 更新中の JRE トラストストア証明書の移行 {#c_UpgradeAndTestMIDServer__section_nc5_cs5_4nb}
----------------------------------------------------------------------------

Quebec にアップグレードした後の JRE 更新の場合、MID サーバーは、JRE トラストストア内の既存の自己署名証明書を新しい JRE バージョンのトラストストアに移行します。これらの証明書が移行されると、エイリアスの先頭に文字列「snc_」が追加されます。

証明書を移行するには、次の条件を満たしている必要があります。

* X509 証明書
* 証明書標準 v3
* 基本制約拡張が false に設定されている (つまり、CA が発行されていない)

{#c_UpgradeAndTestMIDServer__ul_wb3_fs5_4nb}

MID サーバーは、JRE のアップグレードが行われようとしていることを識別し、移行プロセスを開始します。移行前に、MID サーバーは障害発生時のフォールバックとして元のトラストストアのバックアップを作成します。障害が発生した場合は、バックアップのトラストストアを手動で復元できます。
* **[アップグレード前の MID サーバーのチェック](https://www.servicenow.com/docs/Y8m5LRCbXSIrWrsRKqtQ4w)**   
  アップグレードの前に、MID サーバーはテストを実行して、アップグレードプロセスが失敗したり、MID サーバーが機能停止したりする可能性がある問題を特定します。
* **[MID サーバーを特定のバージョンに固定する](https://www.servicenow.com/docs/wIaapZ620KvqYn_UJ2T1SA)**   
  システム プロパティを設定して、環境内のすべての MID サーバーを特定のバージョンに「固定」することも、個々の MID サーバーに特定のバージョンを設定することもできます。
* **[手動での MID サーバーのアップグレード](https://www.servicenow.com/docs/TScWgxuq14ebxFJDcfxNcw)**   
  自動アップグレードを待てない場合は、いつでも MID サーバーを手動でアップグレードできます。

**関連概念**   

* [MID サーバーダッシュボード](https://www.servicenow.com/docs/9GlLNgsbKWtTdQIkSFPTTw "MID サーバーダッシュボードは、MID サーバーユーザーが進行中の操作を監視するための中心的な場所です。このダッシュボードは、MID サーバーステータス テーブルの情報を表示するレポートとゲージで構成されています。")
* [MID サーバーファイルクリーナー](https://www.servicenow.com/docs/Z74ezsZkY9Q1wrOft_QIGg "MID サーバーでは 1 つのモニタースレッドが実行されます。これは、古いファイルをクリーンアップし、インストールフォルダー内のファイルのサイズと量を管理しやすい状態に保ち、MID サーバーのパフォーマンスの問題を防止します。")
* [MID サーバー特権コマンド](https://www.servicenow.com/docs/kkRo6NTyQGaT1FY5Aq4OXQ#c_PrivilegedCommandsForMIDServer "ホスト サーバー上の特定の情報を検出するには、MID サーバーでより高い権限で SSH コマンドを実行する必要があります。プラットフォームでは、MID サーバーで使用されるデフォルトの特権コマンドと、システムに他のコマンドを追加する機能が用意されています。")  
**関連タスク**   

* [MID サーバーを手動で起動、停止、再起動する](https://www.servicenow.com/docs/LlnCUPKwuWAPU35~VS~8tQ "インストール手順の最後で MID サーバー を起動しなかった場合は、MID サーバーを手動で起動することができます。")
* [MID サーバーの JVM メモリサイズを設定する](https://www.servicenow.com/docs/RLfgtagrebSzRcfZslvZMA "MID サーバーはデフォルトの JVM メモリ割り当てで開始しますが、この設定は構成ファイルで変更できます。")
* [MID サーバーを一時停止](https://www.servicenow.com/docs/o6nWNLlX5EHisyMyOnMh5A#t_PauseTheMIDServer "MID サーバーを一時停止して、作業用の ECC キューをポーリングしたり、検出結果をインスタンスに送り返したりすることを一時的に防止します。")  
**関連資料**   

* [MID サーバーのシステム要件](https://www.servicenow.com/docs/~4_f5CFeQvlUkOv99pxHnA "これらの最小システム要件を使用して、MID サーバー をホストするコンピューターにリソースを割り当てます。")
* [MID サーバーの問題の解決](https://www.servicenow.com/docs/I63TMkKzyejd7ySjuUgrbA "MID サーバーの問題のトラブルシューティングを行い、解決策を見つけます。MID サーバーを監視して、問題が発生したときにアラートを受信します。MID サーバーの特定の問題を解決するためのトラブルシューティング手順があります。Hi のナレッジベースには、MID サーバーの問題のトラブルシューティングに役立つ記事がいくつか含まれています。")
* [MID サーバープロパティ](https://www.servicenow.com/docs/AYxCPUqc1919YrxRkokdBQ#r_MIDServerProperties "すべての MID サーバーまたは特定の MID サーバーの動作をプロパティが制御します。")
* [MID サーバーパラメーター](https://www.servicenow.com/docs/z5mXwzuBoaJ2~yb0kl9WCw#mid-server-parameters "パラメーターは特定の MID サーバーの動作を制御し、MID サーバープロパティよりも優先順位が低いです。")
* [MID サーバー設定パラメーターの設定と優先度](https://www.servicenow.com/docs/Yh4TGLGx~1TrFBtpoxCbOQ "MID サーバーの設定は複数のテーブルに存在し、MID サーバーは設定された順序でそれらの設定に優先順位を付けます。MIDConfigParameter は、正しい型スタイルビルダーで定義する必要があります。")
* [MID サーバーで保護されているレコードと予約文字](https://www.servicenow.com/docs/tSyvPxEvgqgn_9MC4Griwg "変更できない MID サーバーレコード一部の特殊文字は XML で事前定義されており、パスワードには使用できません。")
* [MIDSystem メソッド](https://www.servicenow.com/docs/AITMvbmUOYmFFekn3~vVkw "MIDSystem 変数 (変数名 ms で参照される) は、MID サーバーに関する情報を取得するためのさまざまなメソッドを提供します。")
* [MID サーバーのハートビート](https://www.servicenow.com/docs/9rh~o3tN_J2GySBxvCJm3w "インスタンスは、代理トランザクションモニタリングシステムを使用して、5 分ごとに MID サーバーの応答を確認します。")

