MID Server のアップグレードに関する問題のトラブルシューティングIssue Table of Contents トラブルシューティング |症状トラブルシューティング |詳細トラブルシューティング |質問と回答 インスタンスは最近、手動でアップグレードされましたか、それとも QPP パッチを適用してアップグレードされましたか？MID Server は稼働していますか？エージェントログを読むことができますか？「The MID Server was unable to download」「Unable to delete file」「User is unable to authenticate」ファイルが見つかりませんいいえ、インスタンスは最近アップグレードされていません MID Server のデバッグを続行 トラブルシューティング |症状 MID Server リストのMID Server のステータスはダウン (Down) ですDiscovery スキャンがスタックするMID Server が実行を継続しないMID Server のステータスは 稼働 (Up) ですが、応答していません トラブルシューティング |詳細 インスタンスがアップグレードされると、そのインスタンスを指す MID Server は同じバージョンへの自動アップグレードを試みます。2016 年初めに開始された四半期ごとのパッチプログラム (Quarterly Patching Program (QPP)) では、インスタンスを次のパッチにアップグレードする必要があります。パッチは同じリリースファミリ内で実施され (たとえば、Geneva パッチ 1 から Geneva パッチ 12)、リリースファミリ外へはアップグレードされません (たとえば、Geneva パッチ 1 は Helsinki パッチ 4 に自動アップグレードされません)。これは、インスタンスに接続されている MID Server が少なくとも四半期に 1 回自動アップグレードされることを意味します。アップグレードの頻度が増えると、MID Server がインストールされているマシンでまれな予期しない状態が発生する可能性があります。 トラブルシューティング |質問と回答 インスタンスは最近、手動でアップグレードされましたか、もしくは 四半期ごとのパッチプログラム (Quarterly Patching Program (QPP))でアップグレードされましたか？ わからない インスタンスが最近更新されたかどうかを確認するには： [システム診断] > [アップグレード履歴] に移動します。終了 (To) 列で、インスタンスが新しいパッチにアップグレードされたことを示すエントリを検索します。次のようになります。 glide-RELEASE_FAMILY-03-09-2015_06-22-2016_1932.zip はい、インスタンスは最近アップグレードされました アップグレードのステータスを判断するには、MID Server ログを参照してください。 MID Server は稼働していますか？ わからない [ MID Server] > [サーバー]に移動します。リストで MID Server を見つけます。実行中の場合は、 Up を緑色のドットで報告します。 MID Server] > [サーバー]に移動します。リストで MID Server を見つけます。MID Server レコードを開きます。関連リンク フォームセクションで、[MID ログを取得]を選択します。ECC キューリストには、 agent0.log.0 用と wrapper.log 用の 2 つのログコマンドが表示されます。要求が返されたら、ECC キューレコードを開き、エージェントログをダウンロードします。 いいえ、MID Server は稼働していません。 停止した MID Server を使用して MID Server のアップグレードのステータスを評価するには： MID Server が実行されているホストマシンにログオンします。ファイルシステムで、 [ Agent] > [Logs] ディレクトリに移動します。エージェントログを開きます。 はい、MID Server は稼働しています。 エージェントログを読むことができますか？ はい、エージェントログを読み取ることができます。 エージェントログファイルを開き、次のフレーズを検索します。 「The MID Server was unable to download」 根本原因： MID Server をダウンロードできない場合は、MID とインスタンス間の通信が中断されていることを示しています。解決策： MID とインスタンス の間の通信をトラブルシューティングし、MID Server のアップグレードを再試行します。 「Unable to delete file」 根本原因： アップグレードプロセスの一環として、MID Server は特定のファイルを削除して置き換える必要があります。何らかの理由でこれらのファイルの 1 つを削除できない場合、MID Server のアップグレードは失敗します。残念ながら、Istanbul リリースの時点では、復旧してアップグレードを続行する方法はありません。ファイルシステムの問題が解決したら、MID Server を再インストールする必要があります。解決策：MID Server ホスト のローカル環境の問題を解決し、MID Server のアップグレードを再試行します。 「User is unable to authenticate」 根本原因： すべての MID Server は、MID Server ホストマシンの config.xml ファイルに入力されたユーザーとパスワードによって認証されます。認証情報は、パラメーターの mid.instance.username と mid.instance.password に保存されます。この構成ファイルのユーザーは、[システム] > [ユーザー] テーブルのインスタンスにも存在する必要があります。MID ユーザーには、少なくとも mid_server ロールが必要です。アップグレード中に認証に失敗すると、MID とアップグレードサービス自体の両方がハングアップする可能性があります。解決策： MID Server 資格情報のトラブルシューティング を行い、MID Server のアップグレードを再試行してください。 ファイルが見つかりません "SEVERE:com.snc.dist.mid_upgrade.UpgradeExecption: java.io.FileNotFoundException:" AND"\bin\mid.bat (Access is denied)" 根本原因： 提供されている 2 つの検索可能なフレーズを含む完全な例： com.snc.dist.mid_upgrade.UpgradeException: java.io.FileNotFoundException: D:\ServiceNow\agent\bin\mid.bat (Access is denied)。このメッセージは、MID Server が存在するホストマシンが、アプリケーションエクスペリエンスが無効になっている Windows マシンであることを示している可能性があります。Microsoft のセキュリティドキュメントによると、このサービスは内部であり、実際には無効にすることはできません。Windows 環境でこれを無効にすると、サービスの呼び出しが停止するだけです。サービスの実行は停止しません。一般に、アプリケーションエクスペリエンスの目的は、インストールされている既存のソフトウェアに対するアプリケーション更新の互換性を評価することです。実行中のサービスは要求を受信しないため、評価は行われず、更新のインストールは失敗します。これがMID Serverで 起こっていることです 解決策：ローカル環境の問題を解決し、MID Server のアップグレードを再試行します。 いいえ、エージェントログを読み取ることはできません。 このトラブルシューティングガイドに従ってもエージェントログにアクセスできない場合は、ネットワーク管理者またはシステム管理者にお問い合わせください。MID Server ホストマシンの電源がオフになっているか、誤ってネットワークから切断されている可能性があります。ネットワークまたはハードウェアの問題を解決し、MID Server のアップグレードを再試行してください。 いいえ、インスタンスは最近アップグレードされていません MID Server のデバッグを続行MID Server と証明書