すべての ePolicy Orchestrator イベントの解析に失敗し、最終的にイベントフォルダに残ってしまう

技術的な記事 ID: KB86011
最終更新: 2022/03/21

環境

McAfee ePolicy Orchestrator (ePO) 5.x

問題

すべての ePO イベントの解析に失敗し、最終的にイベントフォルダに残ってしまいます。

EventParser.log ファイルに次のメッセージが表示される可能性があります。

20151023122405 E #08888 EPOEVENTS epoevents_dao.cpp(776): COM Error 0x80040E31, source=Microsoft OLE DB Provider for SQL Server, desc=Query timeout expired, msg=IDispatch error #3121
20151023122405 E #08888 EPOEVENTS epoevents.cpp(50): COM Error 0x80040E31, source=Microsoft OLE DB Provider for SQL Server, desc=Query timeout expired, msg=IDispatch error #3121

When you check the SQL Activity Monitor in SQL Server Management Studio, you might find a query similar to the following blocking many other queries, including insert event queries:

select count(*) as 'count' datepart( YEAR dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ) ) as 'EPOEvents.DetectedUTC.year' datediff(week dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) + 1 + case when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 < 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 >= 7 then 1 when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 >= 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 < 7 then -1 else 0 end as 'EPOEvents.DetectedUTC.week' datepart( YEAR dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ) ) as 'EPOEvents.DetectedUTC.year' datediff(week dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) + 1 + case when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 < 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 >= 7 then 1 when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 >= 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 < 7 then -1 else 0 end as 'EPOEvents.DetectedUTC.week' from [EPOEvents] where ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( ( [EPOEvents].[Analyzer] is null or ( [EPOEvents].[Analyzer] <> N'DATALOSS2000' )) and ( EPOEvents.AgentGUID IN ( SELECT lnd.AgentGUID FROM EPOLeafNode lnd inner join EPOBranchNode bnd on bnd.AutoID = lnd.ParentID inner join EPONodePermissions npr on npr.NodeID = bnd.AutoID WHERE lnd.AgentGUID IS NOT NULL and npr.GroupID in (5 6) ) and ( [EPOEvents].[ThreatCategory] LIKE 'av%' and ( [EPOEvents].[DetectedUTC] between '2015-07-23T20:10:16.288' and '2015-10-22T20:10:16.288' ) ) ) ) ) ) ) ) ) group by datepart( YEAR dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ) ) datediff(week dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) + 1 + case when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 < 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 >= 7 then 1 when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 >= 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 < 7 then -1 else 0 end order by datepart( YEAR dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ) ) asc datediff(week dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) + 1 + case when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 < 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 >= 7 then 1 when datepart(weekday dateadd(year datediff(year 0 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] )) 0) + @@datefirst - 7) - 1 >= 7 and datepart(weekday dateadd(day @@datefirst - 7 dateadd( MILLISECOND -18000000 [EPOEvents].[DetectedUTC] ))) - 1 < 7 then -1 else 0 end asc

Reference the following Microsoft article for more information about opening SQL Activity Monitor: https://msdn.microsoft.com/en-us/library/ms175518.aspx#SSMSProcedure.

原因

この問題は EPOEvents テーブル内のイベント数の大きさによって悪化します。ノングローバル管理者アカウントによって、イベントクエリが実行された場合、ePO はグループと製品それぞれのクエリイベントのアクセス権を持っているかを確認するため、アカウントに対して権限のチェックを実行する必要があります。このプロセスは非常に SQL 内のリソースを消費し、大量のディスク I/O、メモリ、および CPU リソースを使用します。 ePO がこのタイプのクエリを実行し、数百万のイベントが存在する場合、クエリに非常に時間がかかり、イベントを挿入しようする時に ePO がイベントテーブルにアクセス出来なくなるという可能性を引き起こします。

この問題は、SQL サーバに以下を含む限られたリソースがある場合にも発生します。

SQL サーバーにインストールされているメモリの不足、または SQL に割り振られているメモリの不足
ディスク I/O パフォーマンスの不足
SQL サーバでの高い CPU 使用率
データベースの断片化

解決策

次のベストプラクティスは大量のイベントが存在し、SQL サーバの資源が限られている際に推奨される解決方法です。

EPOEvents テーブルから不要なイベントを削除します。 SQL Server Management Studio (KB68961 を参照してください。) を使用して ePO 削除タスク、または手動で削除することができます。
SQL サーバにメモリを追加する、またはこちらの Microsoft の記事 https://msdn.microsoft.com/en-us/library/ms178067.aspx を参照して SQL が使用するメモリを更に割り当てます。
ご利用環境内の SQL ハードウェアの設定を調整します。これには、ハードディスクの空き容量、CPU リソース、およびメモリが含まれます。方法については、ePolicy Orchestrator 5.1 ベストプラクティスガイド (PD25838) を参照してください。
ノード数が 10,000 以上の環境の場合、SQL が物理サーバにインストールされているかを確認します。 ( 組織規模に応じたハードウェア要件については、ePolicy Orchestrator 5.1 ベストプラクティスガイド (PD25838 を参照してください。) for hardware recommendations for various sized organizations) 。
データベースインデックスの断片化を確認し、必要な場合はインデックスの再構築をします。 (ePO データベースの推奨されるメンテナンス計画は、KB67184 を参照してください。) 。

注: 参照されているコンテンツは、ログインしているサービスポータルユーザーのみ使用できます。コンテンツを表示するには、リンクをクリックし、プロンプトが表示されたらログインします。

回避策

SQL アクティビティモニタを用いてブロッキングクエリを見つける方法

[ プロセス ] ペインを展開し、[ ヘッドブロッカー ]とラベル付けされたカラムを探します。 (カラムラベルは通常、文字が切り詰められています。カーソルをカラム名に合わせるかカラムサイズを拡張することで、フルネームを見ることが出来ます。)
そのカラムにあるドロップダウン矢印をクリックし、[ 1 ] を選択します。すると、ブロッキングクエリが表示されます。 [ 1 ] という番号が無く、[ 全て ] という言葉しか表示されない場合は、ブロッキングクエリが存在しないため、この記事に記載されている問題は考慮する必要はありません。
コマンド([ コマンド ]カラムに表示されています。) を右クリックし、クエリ全体を表示するために [ 詳細 ] を選択します。

ブロッキングしている上記のようなクエリがある場合、そのクエリを強制終了すること (クエリを右クリックし、[ 強制終了 ] を選択します。) 、およびクエリがイベントの解析の開始を許可するかどうかを検査することが出来ます。問題解決のため一時的にこのクエリを強制終了する場合、SQL アクティビティモニタで発見したクエリのインスタンスを Orion ログで検索します。 (Orion デバッグロギングを有効にする方法については、KB52369 を参照してください。) 。

Orion ログでクエリのインスタンスを見つけることによって、このクエリが生成したものを特定することが出来ます。この種類のクエリは ePO 内のユーザのダッシュボードから実行されたクエリの結果がほとんどです。その場合、同じく一時的に問題が解決するかどうかを確認するため、すべてのユーザーのすべてのオープン ePO コンソールを終了することが出来ます。

免責事項

この記事の内容のオリジナルは英語です。英語の内容と翻訳に相違がある場合、常に英語の内容が正確です。一部の内容は Microsoft の機械翻訳による訳文となっています。

影響を受ける製品

言語:

この記事は、次の言語で表示可能です:

Knowledge Center

すべての ePolicy Orchestrator イベントの解析に失敗し、最終的にイベントフォルダに残ってしまう

環境

問題

原因

解決策

回避策

免責事項

影響を受ける製品

言語:

Title

Title

Knowledge Center

すべての ePolicy Orchestrator イベントの解析に失敗し、最終的にイベント フォルダに残ってしまう

環境

問題

原因

解決策

回避策

免責事項

影響を受ける製品

言語:

地域を選択してください

Title

Title

すべての ePolicy Orchestrator イベントの解析に失敗し、最終的にイベントフォルダに残ってしまう