Rolling back a security agent across two hundred machines

Pulling a device inventory, testing the uninstall on myself first, and planning a fleet-wide change by site instead of by hope.

A security agent the company no longer wanted was installed on most of the fleet, and removing it cleanly was going to be a real project. I got assigned the start of it, and the first thing I did was refuse to guess at the size of the problem.

I pulled the endpoint inventory out of Microsoft Intune. It covered about two hundred and nineteen devices. Of those, roughly one hundred and thirty-eight had the agent installed and eighty had already failed to install it, which is its own kind of mess. That single report turned a vague task into a number.

The second thing I did was test the uninstall on my own laptop before touching anyone else's machine. That is a rule I now apply to every fleet-wide change: be the first beta tester, on the device you can rebuild yourself if it breaks. The uninstall needed admin rights I did not have, so I escalated that blocker early rather than discovering it on the two hundredth machine.

The same week I sent a company-wide phishing warning about a spoofed vendor campaign and sorted the replies into junk versus real phishing. I also gave five users access to a shared team site in a single morning through the admin center. Those were quick wins. The endpoint project was the real one.

The lesson I keep coming back to is that fleet work is inventory work first. You cannot remove something from two hundred machines if you cannot first list exactly which two hundred they are, which of them already failed, and who uses each one. The moment I had the report, the project stopped being scary and became a spreadsheet.

Be the first test case. Get the inventory before the plan. Escalate rights and access early. Those three habits saved me more time in that project than any clever command did.

← All writing · Portfolio