How do I stop users from disabling the EDR agent? (We use Trend Micro)

That's a classic problem with local admin rights. For Apex One, you need to lock down both the service control and the UI tray application. Group Policy is indeed the right tool.

Start with these two Computer Configuration policies:
- **Service Control**: Create a policy to deny "Stop, Start, and Pause" for the Trend Micro service (usually "TMBMServer" or similar). You'll find this under Windows Settings > Security Settings > System Services.
- **File System Permissions**: Block write/modify/execute access to the client UI executable, often something like `C:Program FilesTrend MicroUniClientUiFrmWrkuiSeAgnt.exe`. This prevents users from launching the tray icon to change settings.

The bigger architectural question is whether those users truly need local admin. That's often the root cause, and technical controls like these are just a workaround for a problematic permission model. Have you considered using a privileged access management tool instead?

Group Policy is the right path, but you'll need to go further than just the service. The tray icon is the real weak point because that's where the "Disable Real-time Scan" button lives.

Beyond the service lock, use a Software Restriction Policy or AppLocker rule to outright block the UI executable, usually `uiSeAgnt.exe`. Also, check the agent's own policy within the Trend console - there should be a setting to password-protect the client interface. Set that with a strong passphrase your users don't know.

Frankly, the sustainable fix is clawing back local admin rights. Every other measure is just a band-aid on a gaping wound. If your boss saw it in the console, use that as ammunition to start that conversation.

Start by looking in the Trend console itself. There's a client-specific setting to require a password to access the tray icon or change agent settings. Set that with a strong password your team keeps and users don't. It's the first lock you should turn.

The other replies cover the GPO side well, but that console password is your immediate, built-in stopgap.

Good advice in here already. The immediate win is definitely that built-in password in the Trend console. It's quick.

But I'd tackle the GPO stuff in this order for a new admin:
1. Set that console password first.
2. Then lock down the Trend service via Group Policy.
3. After that, block the UI executable path.

Doing it that way gives you layered protection while you figure out the permissions. And yeah, the real fix is taking admin rights away, but that's a longer battle. Start with these locks.

Yeah, that console password is the quickest win. But I'd test it after you set it - on some versions the password only protects the main settings menu, not the right-click "disable" option on the tray icon itself.

If you're already seeing this in your console alerts, you could also set up a Prometheus alert to fire if an agent goes offline. That way you're not just relying on someone checking the dashboard.

Good point on testing it. I've seen that exact behavior on older Apex One builds. The password just guards the front door while the tray icon has a back window wide open.

Prometheus for Windows agent monitoring? Overkill. You can just set a simple scheduled task to check the service state and mail you if it's stopped. No need to stand up a whole monitoring stack.

But really, if they can stop the service, they can kill your scheduled task too. The root problem is the admin rights, not the alerting.

Oh, that's a great practical note about testing the password. I would've totally assumed it covered everything, thanks for the heads up.

I also like the simpler idea for a scheduled task alert instead of setting up a whole new monitoring system. Makes sense for a beginner like me.

But yeah, you're both right about the core issue. I'm taking all these notes back to my boss to show we need a real plan for those admin rights.

Totally agree with the layered approach order. It's like putting locks on the doors while you're still working on the fence.

That said, I'd flip steps 2 and 3 from a practical standpoint. If you're new to GPO, locking down the service is straightforward in the GUI. Hunting down and blocking the exact UI executable path can be a little trickier, especially if you're worried about breaking something.

So I'd do: Console password -> GPO service lock -> then the executable block once you're comfortable. Both are necessary, but the service lock might be the easier GPO win to build confidence.

That's a really good point about the learning curve with GPO. Blocking an executable via path can get messy if the installer decides to change locations in a future update, while the service name is pretty stable. Starting with the service lock is a solid confidence builder.

I'd add that before you block the UI exe, you can test the policy impact by just denying *execute* permissions for the user group on that file via the security tab. It's a manual one-off, but it lets you verify the exact path and behavior before rolling it out via GPO. Saved me from a bad policy a couple times.

Love the locks-on-doors analogy, spot on.

You've picked up on the critical operational detail: testing the actual behavior. That's where most layered security models fail - they assume policy intent translates directly to enforcement, but the data flow from policy console to agent endpoint can have gaps.

Your point about the scheduled task alert is pragmatic for immediate visibility. However, from a data consistency standpoint, that method creates a secondary, unsynchronized state signal. The agent's status in the Trend console is your source of truth; a local task checking the service introduces a separate data stream that can diverge. It's better to treat the console's alerting capability as the primary integration point. If its internal alerting is insufficient, see if you can configure it to forward events via syslog or webhook to a simple monitoring endpoint you control, rather than building a parallel, independent check. This keeps the state authority centralized.

Spot on about the tray icon being the actual attack surface. Everyone goes for the service first, but that's just the first gate.

If you're going the Software Restriction Policy route, be warned that some Trend updates silently change the hash of that UI executable, which'll break a hash-based rule. A path rule is simpler but brittle for the same reason. The real fun begins when the installer decides `uiSeAgnt.exe` belongs in a new folder next patch Tuesday.

And you're dead right about the band-aid. All this GPO wrangling is just playing whack-a-mole while users have the hammer.

That console password is the right first step, but you've got to test it on the exact agent version you're running. On some older builds, the password only locks the settings window, not the right-click "Disable" option on the tray icon itself. I've been burned by that assumption before.

Set the password, then have a test user try every possible way to stop the agent - tray icon, services.msc, even task manager. If the tray icon disable still works, you'll know your first layer is weaker than you thought and you need to move to the service lockdown faster.

You're getting good tactical advice on GPO and testing, but you're missing the root cause data. This isn't a policy problem, it's a privilege audit problem.

Your first question shouldn't be "what do I block," it should be "why do these users have local admin rights?" Pull a report of all accounts with admin rights on the machines showing agent tampering. I guarantee you'll find service accounts, legacy users, and people who "just needed it once" five years ago. That list is your actual remediation plan. Every GPO you create is just overhead to manage a permissions problem you didn't fix.

Start by exporting that list from your directory. Show your boss the 80/20: 20% of those admin accounts probably cause 80% of your agent issues. Removing those rights is permanent, requires no ongoing GPO maintenance, and solves a dozen other security problems you haven't noticed yet.

You're focusing on the wrong question. You're asking how to block users from doing something they should never have the power to do in the first place.

Every GPO you create to lock down that service is just a tax you're paying on a bad decision - giving users admin rights. You're now spending your time building barricades inside a castle you've already handed them the keys to.

Pull a list of who has local admin on those machines. I bet half of them are from people who left the company. That's your actual step one. Everything else is just making a process to clean up a mess you keep making.