New EPM Extras Tool - Log and/or Policy Tracer

Products Endpoint Policy Manager Ideas
, , , ,
1

What is a one sentence summary of your feature request?

This new tool would track the entire “EPM flow” for a specific exe, script, process, etc., then produce a report of the specific handoffs, policy matches, EPM actions, etc. in chronological order.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

The EPM logs are great… … …ALL 500 MILLION OF THEM! Troubleshooting why an Endpoint Privilege Manager policy is or is not applying as desired can become a daunting task trying to sync and monitor the multiple EPM logs while tracking possible ephemeral PIDs during some of the more “fun” application processes. Svchost can be both wonderful and frustrating, and I’ve seen strange behavior with some of the child processes (or what you would expect to be “child processes”) that are started via executing various command line entries and/or invoking various DLLs. My most recent “fun” is trying to figure out why an EPM auto-elevate policy suddenly stopped elevating the application. I assume it’s because of another policy we implemented, but I’m not even seeing the application match any policies (elevate, block, allow, prompt, or otherwise) while monitoring the logs. I assume it’s because of a “strange way” the application launches that EPM isn’t even registering (again, this could be self-inflicted because of our other rules and/or exceptions).

I would LOVE a tool that I could start, specify a target, then launch the target. The tool would then track the “process flow” (including any spawned child and/or secondary processes) along with any EPM log entries related to the respective target. This would allow us to more easily identify at least a few things:

  • At what part of the process does EPM “lose track” of what’s executing and/or what’s next?
  • At what part of the process does the “final EPM policy” match/hook?
  • Possible unintended policy conflicts

How do you currently solve the challenges you have by not having this feature?

Long hours of stepping through test groups, policy edits, EPM logs, Microsoft event logs, Task Manager, and other 3rd party and Sysinternals tools…

1 Like
2

Okay. I get the idea; I think.

So if I run abc.exe … when EPM is involved or even if it’s not involved… have maybe an interactive window with running logs about “EPM’s involvement around abc.exe”.

Is that the gist?

3

Yeah, I think that’s more or less it. The ‘apps being launched by someone else’ is a challenge to track down, and the EPM logs don’t necessarily show that super smoothly.

4

OOF! Sorry for the delay. Matt’s addition of “apps being launched by someone else” is also a good point. Also, yes, your summary is correct.

Yes, the logs are great, but I’ve encountered multiple scenarios when it seemed like everything just… stopped. The logs showed SOMETHING in the beginning, but then… black box. Following the Parent Process bread crumbs would usually lead back to Explorer.exe or something just as nebulous. I honestly cannot remember all the details of the last scenario, but I do remember it involved comparing at least 4 logs at the same time… plus monitoring Windows event logs. MOST of the time the ppUser_operational and ppService logs suffice, but Murphey’s Law is real for these scenarios. The times when those 2 logs are not enough are during mission critical outages or application updates. As our policies (and exceptions) continue to grow, there is a greater chance of unintended policy interaction. A tool like this would immensely help the troubleshooting experience.

As I write this, I’m reminded of another desired aspect of the tool that I forgot to outline. Identifying the process it was handed TO during the “live view” also would be suuuuper helpful, not just the parent process. Tracing parent and child processes is much easier when you know what process to check. I’m not asking you to recreate Sysinternals’ ProcMon, but I’m not NOT asking you to recreate it! :rofl: In all seriousness, though, sometimes the process is “filtered through” a DLL or service. Who knows what that DLL or service does next. Understanding which step of the process when things “go black,” when the live view suddenly stops, will greatly reduce the troubleshooting time spent on these issues.