スキャンの問題

ソフトウェア・スキャンの最も一般的な問題は、ソフトウェア・スキャンの状態ウィジェットで報告されます。ウィジェットで報告された問題を解決する方法、およびその他のスキャン関連の問題の解決策については、このトピックを参照してください。

ソフトウェア・スキャンの状態ウィジェット

ソフトウェア・スキャンの状態ウィジェットは、インフラストラクチャーで実行されているスキャンの状態を示します。スキャンに問題がある特定のコンピューターに関するレポートにドリルダウンできます。レポートの列をソートすれば、どのコンピューターが具体的にどのソフトウェア・スキャン・タイプで障害が発生したかをすぐに把握できます。

失敗したスキャン: 少なくとも 1 種類のソフトウェア・スキャン (カタログ・ベース、ファイル・システム、パッケージ・データ、またはソフトウェア・タグ) が正常に完了しませんでした。
この問題は、コンピューターのスペース不足、コンピューターの構成の誤り、またはスキャンの停止が原因で発生する可能性があります。
欠落しているスキャン: 少なくとも 1 種類のソフトウェア・スキャン (カタログ・ベース、ファイル・システム、パッケージ・データ、またはソフトウェア・タグ) の開始が最後に試行されたのは 30 日より前です。
この問題は、コンピューターのスペース不足、コンピューターの構成の誤り、またはスキャンの停止が原因で発生する可能性があります。
古いカタログ: エージェント上のカタログのバージョンが、サーバーで使用可能なバージョンよりも古くなっています。
BigFix Inventory にソフトウェア・カタログをアップロードするか、カスタム・カタログを編集する場合、インポートを実行するまでカタログのステータスが保留中になります。インポート時に、エンドポイント・カタログが作成され、「ソフトウェア・カタログ」ウィジェットに表示されるカタログのバージョンが更新されます。次にエンドポイント・カタログがインフラストラクチャー内のコンピューターに配布されます。

エンドポイント・カタログがコンピューターにいつ到達するかは、例えば、コンピューターの接続状況などによって異なります。エンドポイント・カタログがコンピューター上で更新されると、カタログの新規バージョンに関する情報が「ソフトウェア・スキャンのステータス」分析によって収集されます。次回のインポート後に、コンピューター上で利用可能なカタログのバージョンに関する情報が BigFix Inventory で更新されます。

このフロー全体に少し時間がかかる場合があるため、問題がない場合であっても、コンピューターのステータスが「古いカタログ」になる可能性があります。アクションが必要かどうかを確認するには、以下の手順を実行します。

  1. 「ソフトウェア・カタログ」ウィジェットで、カタログの最終編集日を確認します。
  2. 「ソフトウェア・スキャンの状態」ウィジェットで、「古いカタログ」をクリックして、影響を受けるコンピューターのリストを表示し、「前回のソフトウェア変更」列の日付を確認します。
    • 最後のスキャン・インポートが、カタログの最終編集日より前に行われた場合は、次回スキャンとそれに続くインポートまで待ちます。前述のとおり、コンピューターへのエンドポイント・カタログの配布と、コンピューターから BigFix Inventory へのバージョンの報告には、少し時間がかかる場合があります。
    • 最後のスキャン・インポートが、カタログの最終編集日より後に行われた場合は、ソフトウェア・カタログを強制的にコンピューターに配布します。詳しくは、こちらを参照してください:スキャナー・カタログの更新
スキャンがアップロードされていない: カタログ・ベースのスキャンまたはファイル・システム・スキャンの結果は、BigFix サーバーにアップロードされませんでした。
この問題が発生する原因として、コンピューターまたはリレーがオフラインであるか、ネットワーク障害があるか、または最後のスキャン試行から経過した日数が 30 日を超えていることが考えられます。レポートにリストされた各コンピューターが稼働中かどうか、またスキャンの結果が定期的にサーバーにアップロードされているかを確認してください。ソフトウェア・スキャンのステータス分析では、すべてのタイプのソフトウェア・スキャンについて最後のスキャン試行の時刻を調べることができます。

問題が解決しない場合、エンドポイントへのカタログの初期ダウンロードが失敗したことを示している可能性があります。問題を解決するには、最新のカタログをエージェントにアップロードしてください。詳しくは、こちらを参照してください:スキャナー・カタログの更新

IBM i IBM i コンピューター・スキャンは、「スキャンがアップロードされていない」検査から除外されます。

スキャンしない共有ディスク: エージェントはリモート共有ディスクをスキャンしません。
スキャンしない共有ディスクにインストールされている IBM ソフトウェアのライセンス使用状況が、少なくレポートされる場合があります。この問題を解決するには、リモート共有ディスクのスキャンを有効にします。

9.2.12 状況は、基本モードを使用した共有ディスクのスキャンに基づいています。アプリケーションの更新 9.2.12 以降、最適化モードを使用して共有ディスクにインストールされているソフトウェアを検出することができます。このモードでは、共有ディスク上にスキャンが生成するロードを削減できます。詳しくは、こちらを参照してください:共有ディスク上のソフトウェアの検出

その他のスキャンの問題

10.0.5 IBM Clarity Data Collection の検出に config.xmlファイルを使用しているシグニチャーが原因で起こるスキャンの長時間実行

IBM Clarity Data Collection 6.6 および 7.2 の検出に config.xml を使用していたシグニチャーが原因で、スキャンの実行時間が長くなっていました。BigFix Inventory バージョン 10.0.5 では、これらのシグニチャーは LMT カタログから削除されました。

「ソフトウェア・スキャンの開始」タスクが適用されないため、ソフトウェア・スキャンが開始できない
ソフトウェア・スキャンには、スキャナーがソフトウェアをディスカバーするために使用するスキャナー・カタログが必要です。スキャナー・カタログは、ソフトウェア・カタログを BigFix Inventory にアップロードすると作成されます。ソフトウェア・スキャンを実行できない場合は、カタログが作成されていない可能性があります。スキャナー・カタログを手動で更新する前に、以下のステップを実行してこの問題の原因を確認してください。
  1. このタスクが適用されないコンピューターで、<BES_Client>\LMT\CIT ディレクトリーに移動します。
  2. catalog.bz2 ファイルが存在するか確認します。このファイルにスキャナー・カタログが含まれています。
  3. BigFix コンソールにログインします。
  4. ナビゲーション・バーで、「アクション」をクリックします。
  5. 右上のペインで、「カタログのダウンロード (バージョン version)」アクションを見つけて選択します。
  6. アクションの詳細を確認します。どのコンピューターでアクションが失敗したかを確認し、失敗したステップを調査することができます。問題の原因の判別と修正を試行してください。

原因を判別できない場合は、カタログを手動で更新してください。詳しくは、こちらを参照してください:スキャナー・カタログの更新

ソフトウェア・スキャンのステータス分析で、ソフトウェア・スキャンのステータスが「失敗」「アーカイブ・ファイル・サイズが超過しているかどうか」列の値が「True」となります
この問題は、スキャン・ファイルが、BigFix クライアントが送信できる最大アーカイブ・ファイル・サイズを超えている場合に発生します。この問題を解決するには、以下のステップを実行します。
  1. BigFix クライアント・ログで、上限を超えたファイルのサイズに関する情報を調べます。このログのデフォルトの場所は以下のとおりです。
    • Linux /var/opt/BESClient/__BESData/__Global/Logs
    • Windows C:\Program Files (x86)\BigFix Enterprise\BESClient\__BESData\__Global \Logs
  2. BigFix コンソールにログインします。
  3. 左側のナビゲーションで、「コンピューター」をクリックし、スキャンが失敗したコンピューターを右クリックしてから「コンピューター設定の編集」をクリックします。
  4. _BESClient_ArchiveManager_MaxArchiveSize パラメーターの値を増加させます。
「ソフトウェア・スキャンの開始」がコンピューターで適切でないため、ソフトウェア・スキャンを LPAR で実行できません
WPAR が LPAR に存在する場合、すべての WPAR プロセスはその LPAR のレベルで表示されます。ソフトウェア・スキャンが WPAR で実行される場合、プロセスは LPAR のレベルで表示されるため、「ソフトウェア・スキャンの開始」Fixlet は LPAR で適切ではありません。LPAR でソフトウェア・スキャンを実行するには、WPAR でスキャンが終了するまで待ってください。または、以下の手順を実行します。
  1. BigFix コンソールにログインします。
  2. 「ソフトウェア・スキャンの開始」Fixlet を選択してから、「アクションの実行」をクリックします。
  3. 「対象」タブで、「プロパティーに応じて動的に対象を指定」を選択します。
  4. 「取得プロパティー別」を展開してから、「コンピューター名別」を展開します。
  5. ソフトウェア・スキャンを実行する LPAR コンピューターを選択して、「OK」をクリックします。
スキャナーのアップグレードが WPAR で失敗する
WPAR が LPAR 上に存在する場合、まず、LPAR 上のスキャナーをアップグレードしてから、WPAR 上でアップグレードする必要があります。

ソフトウェア・スキャンが失敗します。スキャンが失敗するコンピューターには、「導入の状態」ウィジェットに「低ディスク・スペース」ステータスがあります。
この問題は、スキャナー・キャッシュのディスク・スペースが十分でないことが原因で発生する可能性があります。この問題を解決するには、スキャナー・キャッシュ・フォルダーを別の場所に移動するか、キャッシュを最適化してください。詳しくは、こちらを参照してください:スキャナー・キャッシュ構成の最適化

AIX で /usr/lpp ディレクトリーにインストールされているソフトウェア・コンポーネントが検出されない
この問題が発生するのは、デフォルトでは /usr/lpp ディレクトリーはソフトウェア・スキャンから除外されているためです。スキャナーのバージョン 2.8.0.5000 から、このディレクトリーはソフトウェア・スキャンに組み込まれるようになっており、このディレクトリーにインストールされているコンポーネントはディスカバーされます。そのため、この問題を解決するには、スキャナーをバージョン 2.8.0.5000 以降に更新し、次のスケジュールされたソフトウェア・スキャンまで待ってください。あるいは、/usr/lpp ディレクトリーをソフトウェア・スキャンに手動で組み込むこともできます。詳しくは、こちらを参照してください:除外されたディレクトリーをスキャンにもう一度含める

スキャナーの更新後、AIX で検出されるソフトウェア・コンポーネントの数が増え、重複が表示された
以前、/usr/lpp ディレクトリーは、ソフトウェア・スキャンから除外されていました。したがって、シグニチャーがこのディレクトリーにのみ存在しているコンポーネントは、ディスカバーされませんでした。そのため、スキャナー・バージョン 2.8.0.5000 から、/usr/lpp ディレクトリーがソフトウェア・スキャンに組み込まれるようになりました。それにより、ディスカバーされてレポートに表示されるコンポーネントの数が増えました。ただし、/usr/lpp にインストールされているコンポーネントは、他のディレクトリーでもディスカバーされることがあります。そのような場合、重複したコンポーネントがレポートに表示されます。この問題を解決するには、重複を抑止します。詳しくは、こちらを参照してください:ソフトウェア・インスタンスの除外または抑止。また、/usr/lpp および他のディレクトリーでディスカバーされたコンポーネントを抑止するカスタム・ルールを作成することもできます。詳しくは、こちらを参照してください:カスタム・ルールの作成と管理

ソフトウェア・スキャンのステータス分析の結果を確認する方法
ソフトウェア・スキャンのステータスを確認するには、ソフトウェア・スキャンのステータス分析の結果を表示します。
  1. Bigfix コンソールにログインします。
  2. ナビゲーション・ツリーで、「サイト」>「外部サイト」> 「BigFix Inventory v10」 >「分析」に移動します。
  3. 「ソフトウェア・スキャンのステータス」分析を選択します。
  4. 下部ペインで、「結果」タブを開きます。
ヒント: 右にスクロールして、関連するすべてのデータを表示します。

新規ソフトウェア・タイトルがカタログに追加され、データ・インポートが実行されたが、そのソフトウェアが BigFix Inventory Web ユーザー・インターフェースに表示されない
BigFix Inventory UI にソフトウェア・タイトルが表示されない理由の 1 つとして、非標準のファイル・タイプがソフトウェア・シグニチャーに使用されたことが挙げられます。非標準のファイル拡張子を持つルールを追加した場合は、カタログ・データ・フローのすべてのステップが完了するまで待機するか、それらのステップを手動で実行します。正確なインベントリー・データが表示されるようにするには、以下の手順を実行します。
  1. データ・インポートを実行して、カタログをエンドポイントに伝搬します。
  2. カタログが正常に伝搬されたことを確認します。
  3. BigFix Inventory サーバーにスキャン・データをアップロードします
  4. 別のデータ・インポートを実行します。
32 ビットの Linux x86 でスキャナーを更新できない
この問題は、最後の使用可能なスキャナー・バージョンが 2.8.0.3000 である libstdc++.so.5 ライブラリーが含まれている 32 ビットの Linux x86 で発生します。この問題を解決するには、ライブラリーを libstdc++.so.6 に更新します (使用可能な場合)。そうしないと、スキャナーを更新できません。
9.2.5 IBM i IBM i でのソフトウェア・スキャンの状態の制限
IBM i 環境では、デフォルトで、ファイル・システム・スキャンの結果は肯定になります。「ファイル・システム・スキャン成功」列は常に「はい」に設定されます。

Unix 多数のマウント・ポイントまたは共有ドライブがある大規模システム上でスキャンを実行した後に、メモリー不足に関連した複数の戻りコードがログ・ファイルに含まれている
多数のマウント・ポイントまたは共有ドライブがある大規模サーバーで実行されるファイル・スキャンまたはソフトウェア・スキャン時には、スキャナーのメモリー所要量が多くなります。スキャナーが動作するために十分なメモリーが使用可能でない場合、ログ・ファイルに以下の戻りコードが含まれる可能性があります。
  • 125。メモリー割り振り失敗を示します。
  • 134。オペレーティング・システム・シグナル 6 - SIGABRT に変換されます。
  • 139。オペレーティング・システム 11 - SIGSEGV に変換されます。
詳しくは、こちらを参照してください:ソフトウェア・スキャンの戻りコード

この問題がメモリーの問題に関連しているかどうかを確認するには、スキャナーのメモリー使用量をモニターし、システムで設定されている制限に達しているかどうかを判別します。使用している制限で、スキャナーが適切に機能できるようにしてください。例えば、20,000 のマウント・ポイントまたは共有ドライブがあるサーバーでのスキャナーの場合、必要なメモリーは約 500 MB の RAM です。そのため、data seg size の ulimit (ulimit -d) は、500000 以上に設定する必要があります。詳しくは、こちらを参照してください:Ulimit コマンド (AIX の場合)

多数のマウント・ポイントまたは共有ドライブがある大規模システムをスキャンする場合は、以下の側面について考慮してください。
  • スキャンが遅くなる可能性があります。
  • スキャナーのロギングは、そのような環境ではパフォーマンスに大きな影響を及ぼすため、最小に設定する必要があります。
  • CPU しきい値を設定しないか、必要な場合は、制限が小さくなりすぎないようにしてください。
Windows Windows 上で共有ディスクの最適化されたスキャンが完了しません
共有ディスクの最適化されたスキャンを有効にすると、スキャンが完了しません。BigFix コンソールでは 、「アクション」に移動すると、「最適化された共有ディスクのスキャンのリソース・リストの更新」アクションのステータスが「ダウンロードの保留中」になり、「要約」セクションに次のエラーが表示されます。
HTTP Error 28: Timeout was reached: Connection timed out after 10000 milliseconds" 
この問題は、複数のインターフェースを持つ Windows システムで発生します。問題を解決するには、次を参照してください。分離したネットワークでのサーバーの構成