Click on the Category button to get more articles regarding that product.
Had a case where the McAfee EPO DB almost blew due to an EPO issue or, let’s say, McAfee prevented it from happening by encountering SQL Express limitations. We’re relieved that since EPO 5.X, they’ve implemented two databases; one for EPO and one for Events; effectively splitting the load in size and safeguarding the crucial elements. This should prevent occurrences of false alarms or attacks. In the past, we frequently had to truncate Events using Batch and OSQL to keep everything running smoothly. Additionally, there are McAfee Pre-Defined Tasks that might serve the same purpose.
But we still have it here with seperate SQL DB for the Events.
https://kcm.trellix.com/corporate/index?page=content&id=KB90100
Mcafee/Trellix: Logon Failed die ti a full database disk EPO 5.X
https://kcm.trellix.com/corporate/index?page=content&id=KB90100
Check the disk space c: d: on EPO Server
Try the lazy method:
Worked because we gained some pace. Now find the source. You want to know why….
Trellix included some info in EPO itself so you don’t have to query in SQL.
Inspect the large tables.
In this case it’s just some Mcafee “TAGS” and MOVE Intervall we do every second because we have to PRE-TANK VDI machines asap as they rise up from birth. So no Attack or logon/DDOS Service hack.
So we still have to mreove some data by hand sometimes. Here is a sample to do that:
|
TRUNCATE, Just cut off old logs, Try this IF this fails you will have to handle the large amount of data with 1000 steps next step |
|
use EPO_BUTSCHEPO2 go DELETE FROM epoEventsMT WHERE (DetectedUTC < GETDATE() – 14) go DELETE FROM EPOServerEventsMT WHERE (Eventtime < GETDATE() – 14) go DELETE FROM EPOProductEventsMT WHERE (DetectedUTC < GETDATE() – 14) go DELETE FROM OrionAuditLogMT WHERE (StartTime < GETDATE() – 14) go DELETE FROM OrionAuditLog WHERE (StartTime < GETDATE() – 14) go DELETE FROM OrionSchedulerTaskLogMT WHERE (StartDate < GETDATE() – 14) go DELETE FROM OrionSchedulerTaskLogDetailMT WHERE (MessageDate < GETDATE() – 14) go DELETE FROM DLP_EventInfo WHERE (InsertionTime < GETDATE() – 30) go Use master GO |
If you can’t run it in SQL Managment Studio because that crashed you may have to use OSQL Command line tools.
|
This will CLEAN the large AUDIT Logs in small steps of 1000 per loop |
|
DECLARE @Deleted_Rows INT; SET @Deleted_Rows = 1;
WHILE (@Deleted_Rows > 0) BEGIN — Delete some small number of rows at a time DELETE TOP (1000) OrionAuditLog WHERE StartTime < dateadd(DAY,-18,GETDATE())
SET @Deleted_Rows = @@ROWCOUNT; END |
|
If it works try in SQL Managment Studio |
|
|
If this RUNS forever STOP it after some hour and then SHRINK the DB again as middle step. Ugly approach but often the qucik and dirty saves money here. And you need EPO up and running asap.
The re-run the 1000 step script and the shrink again etc.
Take a backup at some point to ship TS-logs depending on how you had recovery Model.
https://www.butsch.ch/post/mcafee-epo-server-4-x-database-or-space-growing-epoevents/
https://www.butsch.ch/post/mcafee-trellix-epo-database-sql-shrink-size-in-small-steps-via-osql/