You'd want to understand why the mass of 1095 events are occurring.
1095 is a "would be blocked" access protection event, so you need to know which AP rule it is (or maybe there are multiple).
Also make note of what process is violating the rule.
Then, knowing the rule and the process that's triggering it, determine if that behavior is safe or expected of the affected process.
If not, investigate why it's behaving that way.
If expected, consider revising the policy for that rule... do you need the Report option ON still, or should the affected process be added as an exclusion to the rule?
If you just want the noise to stop, turn off the reporting option for the rule. But you should look into the behavior at some point to make sure it's understood why it's occurring.
mass 1095 is due to policy settings - i was considering turning on some additional rules but it generates too manu events.
Generaly speaking i resolved this problem.
First there was problem with orion.log switching (orion9.log file was corrupted - which i found on the end
2nd orion.log couldnt switch at some time and it was rising until consumed all space on disk C: (size over 9GB) (limit set to 2MB)
3rd problem was damaged extension (bacause of lack of space on drive C i assume) - that was why i couldnt login to console.
I connected directly to DB via Management Studio listed table with installed extensions and deleted all recently installed extensions (after dB backup)
then i deleted that extensions on epo filesystem ,
then i changed orion.log location to d drive .
after taking control of epo back i decided to install newer version of epo5.3 on another VM and redirected agents to new machine (after importing all tree structure, systems, polices , assigments, repository packages and extensions)
now i have over 90% of systems reporting to new EPO
can you provide me steps for changing drive for orion.log
Thanks in advance
Changing the location of the orion.log is not supported. I would strongly caution against that and would suggest working with support to determine why the log would a) need to be moved and b) why it wouldn't rollover like it's supposed to.
i found location of orion.log in one of configuration files - changed path there
it was :
c:\Program Files\McAfee\ePolicy Orchestrator\Server\conf\orion\logconfig.xml
as I recall. (epo4.69)
anyway I dont use this epo as production it remains still on waiting for lost workstations to redirect them to new epo 5.3