This fall I rebuilt how our reports get handled. The goal wasn't to let a machine decide what's phishing. It was to put each report in front of a technician with a score and, more importantly, the reasons behind the score, so they can make the call in seconds instead of digging through headers.

What you need

• A self-hosted n8n instance (the community edition is fine)
• A shared mailbox where reported messages land, readable through Microsoft Graph or Gmail
• Somewhere to post results for your techs (we use a Google Chat space)
• A list of the domains and vendors your organization really uses

Why rules instead of AI

I considered handing each message to a language model and asking "is this phishing?" I didn't, for two reasons. First, the reported messages contain staff email and sometimes student information, and I didn't want that leaving our systems for a yes/no answer. Second, a model's answer is hard to argue with. When a tech disagrees with "73% likely phishing", there's nothing to fix.

A rule-based score is boring, and that's the point. Every point comes with a sentence a person can read, and when the score is wrong, I can see exactly which rule caused it and tune it.

How the score works

A small Code node in n8n runs a list of checks against the reported message. Each check that fires adds (or subtracts) points and records why. The total is clamped to 0–100 and mapped to a band:

const factors = [];
const add = (points, reason) => factors.push({ points, reason });

if (spoofsOurDomain)   add(35, 'Claims to be from our domain, but Microsoft says we did not send it');
if (lookAlikeDomain)   add(25, 'Uses a look-alike of our name: ' + lookAlike);
if (replyToFreemail)   add(20, 'Replies go to a personal email account');
if (riskyAttachment)   add(30, 'Has a risky attachment type (' + ext + ')');
if (usesShortener)     add(15, 'Uses a link shortener that hides the real destination');
if (fromInside)        add(-10, 'Sent from inside the organization');

const score = Math.max(0, Math.min(100, factors.reduce((s, f) => s + f.points, 0)));
const band = score >= 60 ? 'Likely phishing'
           : score >= 35 ? 'Suspicious, look closer'
           : score >= 15 ? 'Low risk, a few flags'
           : 'Probably fine';

The full rubric, sanitized with a CONFIG block for your own domain and names, is on GitHub: Phishing Triage Score.

The checks fall into a few groups:

• Sender authentication. I only trust the verdicts Microsoft itself stamped on the message (its own Authentication-Results header), not whatever an attacker might have added further down. Spoofing our own domain is the heaviest single signal.
• Look-alike names. Domains are decoded from punycode, common look-alike characters (Cyrillic "а" for Latin "a", "rn" for "m") are folded, and anything within a couple of edits of our name scores high. Other organizations that legitimately share part of our name score lower.
• Where replies and links go. Reply-to a personal Gmail, links to free hosting or form builders, raw IP addresses, and link shorteners all add points.
• Lures. Mentions of leadership from an outside address, "document" PDFs from strangers, messages with almost no readable text.
• History. If mail from the same sender was reported before, the earlier verdict nudges the score up or down.

What the tech sees

The result posts as a card: the band, the score, the top three reasons in one line, and the full list below. A typical card reads something like "Suspicious, look closer · Replies go to a personal email account · Links go to free website hosting · Mentions leadership but isn't from a district address." From the card, a tech marks it Malicious, Legitimate or Needs Investigation. Malicious reports can kick off a follow-up workflow that finds and pulls the same campaign from other mailboxes.

We're also piloting an email back to the person who reported it, with the result and the reasons. My bet is that closing that loop matters as much as the score: people keep reporting when they hear back, and the reasons teach them what to look for.

Lessons so far

• Use the real address, not the display name. My first version read the sender from the display name, which an attacker controls completely. "Helpdesk" can be anyone.
• Don't double count. "Outside sender" plus "outside link" plus "outside reply-to" can stack into a scary score for an ordinary newsletter. Signals that describe the same thing should share points.
• Keep the lists editable. Trusted vendors, risky top-level domains and file-sharing senders are plain arrays at the top of the script, so tuning doesn't mean touching logic.
• Run new pieces in shadow or test mode first. New workflows run quietly, or send only to me, until their output has been checked against what a person would have decided.

It's still being tuned, and it always will be. But the techs now start from a short, readable list of reasons instead of a raw message, which is the whole point.

My car already reports its location to Home Assistant, and the form is just a spreadsheet. So I'm connecting them. The spreadsheet side and the link from Home Assistant are working; the last piece, the zone automation that spots each trip on its own, is what I'm finishing now.

What you need

• Home Assistant, with a way to see where your car or phone is (I use the car maker's integration; the Companion app on your phone works too)
• A Google Sheet copy of your expense form, with your organization's mileage chart on its own tab
• Google Apps Script, published as a small web app, so Home Assistant has somewhere to send trips

The rules come first

Before writing any automation, I wrote down the rules in plain language, because that's where all the edge cases live:

• A claimable leg is one work site to the next work site. Stopping at home or for lunch in between doesn't break the leg, and detours aren't claimed.
• Driving from home to my regular office, and from my last stop back home, is commuting and isn't claimed.
• If I drive from home straight to a different site, I claim it, using the shorter of home-to-site or office-to-site, which is what the form's policy says.
• Miles always come from the official chart, not from GPS.
• Anything odd gets marked Pending for me to approve: a work stop that isn't a school (a hardware store run), or a trip outside normal hours (evening games where I'm running audio and video).

Home Assistant: zones and one REST call

The plan for Home Assistant is simple: each school is a zone, and an automation watches the car arrive at a zone and remembers the last work site it left. When it arrives at a different site, it sends the leg to the spreadsheet. The sending part is already in place, a single rest_command:

# configuration.yaml
rest_command:
  mileage_log_trip:
    url: !secret mileage_url
    method: POST
    content_type: "application/json"
    payload: !secret mileage_payload

The web app's address and its shared token live in secrets.yaml, not in the automation, so the config can be shared or backed up without leaking them.

Google Sheets: the form does the math

The Apps Script web app checks the token, looks up the two sites on the mileage chart tab, and appends a row to a Trip Log tab: date, description, chart miles, status, and where the trip came from. The expense form tab never gets typed into directly. Its trip lines are formulas that pull approved trips for the pay period from the log, so the totals, rates and meal allowances calculate exactly as they did on the paper form.

That split matters. The log is messy and editable: I can fix a description, mark a pending trip approved, or add a meal. The form stays clean and always matches the official layout.

Closing out the month

At the end of the month, one menu item in the sheet does the paperwork:

1. Makes a copy of the form and freezes the formulas into plain values, so it can't change later.
2. Fills in the date and adds my signature image.
3. Saves a PDF to a Drive folder and emails it to me.
4. Includes a one-time link that sends it on to my supervisor once I've checked it.

There's also a "preview" option that only emails me, which I used a lot while getting the layout right.

What I'd tell you before you build one

• Write the rules down first. Every bug I hit was a rule I hadn't stated, not a code problem.
• Keep a human in the loop for the odd cases. Pending-for-approval is what makes it trustworthy enough to sign.
• Never type into the official form. Feed it from a log with formulas, and it will always match the original.
• Back up the sheet. It's now the record of money I'm owed.

Once the zones are in, the miles will match the chart without retyping, and month-end becomes one menu click and a quick check.

Now it's one Ansible playbook run from Semaphore. It's safe to run again at any time, and running it again is how we check for drift.

What you need

• Ansible, and ideally a UI to run it from (we use Semaphore, self-hosted in Docker)
• An inventory of your servers, grouped however makes sense for you
• Secrets (API tokens, enrollment keys) stored in your runner, never in the repo

One playbook made of small ones

The baseline itself has no tasks. It just imports a series of focused playbooks, each of which can also be run on its own:

---
# Universal Ubuntu server baseline. Safe to re-run; also used for drift checks.
- ansible.builtin.import_playbook: configure-certificates.yml
- ansible.builtin.import_playbook: configure-ssh.yml
- ansible.builtin.import_playbook: configure-time.yml
- ansible.builtin.import_playbook: configure-updates.yml
- ansible.builtin.import_playbook: provision-monitoring-agent.yml
- ansible.builtin.import_playbook: provision-security-agent.yml

Splitting it up this way means each piece can be fixed or re-run on its own. If a server only needs its certificates refreshed or its time settings corrected, that's one small job, not the whole baseline.

What each piece does

• Certificates. Installs our internal root CA into the system trust store, then verifies against it before moving on, so internal HTTPS services work from the server.
• SSH. Key-based access only. The new settings go in a drop-in file, the whole SSH configuration is validated with sshd -t, and only then is SSH reloaded. A typo can't lock you out.
• Time. Sets the time zone, installs chrony, points it at our internal time servers, and then waits until the clock actually syncs instead of assuming it will.
• Updates. Turns on unattended security upgrades, but never reboots on its own. Reboots happen when we choose.
• Monitoring and security agents. Installs and enrolls the Zabbix and Wazuh agents (and our endpoint protection), using keys that come from Semaphore's secret store at run time.

Patterns worth stealing

Validate before you apply. Anything that could break access gets tested first. SSH config goes through sshd -t; Zabbix config goes through zabbix_agent2 -T. If validation fails, the play stops before anything changes.

Assert what you expect. The monitoring maintenance playbook checks that each server's agent config files exist and aren't empty before it touches anything, and fails with a message that says exactly which step to run first:

- name: Require existing configuration and enrollment
  ansible.builtin.assert:
    that:
      - item.stat.exists
      - (item.stat.size | default(0)) > 0
    fail_msg: "Missing or empty {{ item.item }}. Run the install/enrollment playbook first."
  loop: "{{ monitoring_files.results }}"

Pin and hold versions. Agents are installed at an approved version and held with dpkg_selections, so a routine apt upgrade can't move an agent ahead of its server.

Go one at a time when it matters. Playbooks that restart services use serial: 1. If something goes wrong, it goes wrong on one server.

Running it

In Semaphore, the baseline is a template with an inventory and a variable group holding the secrets. A brand-new server gets one earlier job that sets up administrator access; after that, it's "run the baseline" and wait for green. Because every step is safe to repeat, re-running it doubles as a drift check: anything that reports changed on a server that was already baselined is worth a look.

I've put a sanitized copy of the playbooks, with organization-specific values moved into an example variables file, on GitHub: Linux Server Baseline.

The biggest win isn't speed, though that's nice. It's that "a properly set up server" now has a definition, and the definition lives in git where anyone on the team can read it.

What you need

• SCCM (Configuration Manager) task sequences for imaging
• Devices registered in Windows Autopilot
• An Entra ID (Azure AD) app registration with Intune read/write permissions, so the script can update devices and trigger a sync

The old way: fat images and provisioning packages

For years we used "fat" images, with every application preinstalled. When Intune first came in, for high school student laptops during the Covid lockdowns, technicians applied provisioning packages by hand on top of that fat image. They had to pick the right task sequence too: the standard one, or an Intune one that skipped the ConfigMgr client and rebooted to the out-of-box experience (OOBE).

The first two things I changed were dropping the fat image, so software installed during the task sequence, and merging the two task sequences, so the variables chosen in the UI++ step decided whether a device was set up for Intune and got the provisioning package before rebooting.

Some of that had to be walked back. Intune devices weren't ready when they were handed to people, because software was still installing after the first sign-in, and imaging took longer because software installed during the task sequence. I kept the merged task sequence but went back to the fat image, so imaging stayed fast and Intune devices had the basics installed before anyone signed in.

The new way: Autopilot and clean images

Later we moved all staff laptops, and student laptops at more schools, to Intune, and I wanted to make real use of Autopilot. My first idea was to run the Autopilot hash upload script from a flash drive at OOBE on new devices. I wrote a Windows Forms front end so techs could set the location and asset number for the device name, then upload the hash, wait about six minutes for the profile to be assigned, and reboot. It worked, but it added too many steps for the techs.

So it had to happen during imaging. The catch is that you can't upload a device hash from Windows PE, because it doesn't have the WMI namespaces the hash upload needs.

There was a second catch. We have a wide mix of models, some of them consumer devices, and having TPM 2.0 doesn't guarantee a device supports attestation for Autopilot self-deploying mode. (Our HP 255 G7 laptops were the main problem there.) I tested every student laptop model, and since they all worked, I added a task sequence step that sets a TPMSupport variable to true for those models. I've added other models as I've tested them. Devices that can't self-deploy still get the fat image, but we're moving in the right direction.

What the script decides

The script runs inside the task sequence and does two things:

1. Checks whether the device is already registered in our tenant, which means it has an Autopilot profile.
2. Based on that, the task sequence either lays down a clean image and boots to OOBE for the enrollment status page, or applies the fat image and uses a provisioning package to join Azure AD with a bulk enrollment token.

See the original script on GitHub

How the script works

• Graph app credentials. The script starts with the client ID, client secret and tenant ID for an Entra ID app with Intune read/write permissions. Replace the placeholders with your own, and keep the real values out of source control.
• Environment setup. It sets LOCALAPPDATA, which isn't defined when running as SYSTEM, and works from the system's temp folder.
• Modules. It makes sure PowerShellGet and PackageManagement are present, installs them if not, then installs and imports the Autopilot and Intune modules it needs.
• Task sequence variables. It opens the task sequence environment through its COM object and reads values like TPMSupport, the computer name and the Autopilot profile.
• Serial number. It reads the device's serial number through WMI. If that fails, it sets the ProfileAssigned task sequence variable to False and stops.
• Connect to Microsoft Graph with the app credentials. On failure, ProfileAssigned is set to False.
• Find and update the device. It looks the device up in Autopilot by serial number, updates its details, and starts an Autopilot sync. If the device isn't found or the update fails, ProfileAssigned is set to False.

The rest of the task sequence can then use ProfileAssigned to choose between the clean-image path and the fat-image path.

Update: a version without modules

A few weeks after this post I replaced the script with UpdateAutopilotGraph.ps1. Windows PE can't install modules natively, so instead of adding steps to make the PowerShell Gallery work there, the new version calls the Microsoft Graph REST API directly to find the device by serial number and update its display name and group tag. It reads OSDComputerName and GroupTag from the task sequence, and can also run outside one with those passed as parameters.

If you're working through a similar mix of SCCM and Intune, feel free to use and adapt either version. Happy scripting!

The problem

In our domain, user accounts are deleted after a period of inactivity, which is standard practice. But deleting the account left the user's folder behind in C:\Users.

When that person signed in again later, Windows didn't reuse the leftover folder. It created a new profile folder next to it, so the same user ended up with duplicate folders. On student laptops with 64 GB drives, that filled the disk quickly.

What you need

• Intune Remediations (formerly Proactive Remediations), or any way to run a detection and remediation script as SYSTEM
• The two scripts linked below, with the variables at the top adjusted for your organization

The solution

I wrote a detection script and a remediation script. Detection finds orphaned folders; remediation removes them. Deleting a folder whose owner no longer exists often runs into broken permissions, so the remediation tries several approaches, from simplest to most forceful.

See the scripts on GitHub

How the remediation works

1. Set up. It sets its variables, creates its log and cleanup paths if they don't exist, and logs which accounts are on the device before it starts.
2. Find orphans. It compares the folders in C:\Users with the user profiles registered in Windows. Any folder without a matching profile is orphaned. (The Public folder and its own cleanup folder are skipped.)
3. Try a normal delete. It attempts to delete each orphaned folder.
4. Fix permissions and try again. If that fails, it gives the SYSTEM account ownership and full control, then deletes the folder recursively, continuing past errors.
5. Go file by file. If the folder is still there, it collects the remaining files into a list and fixes permissions on each one and deletes it individually, then does the same for the remaining subfolders.
6. Move it out of the way. If anything still survives, it moves the folder into a cleanup directory, so C:\Users stays clean and the duplication doesn't keep happening.

The script works out whether it's running as SYSTEM or as a user and puts its log file in the right place, under an organization folder in ProgramData or AppData.

Results

This fixed our orphaned folder problem: student laptops no longer fill up with duplicate profile folders. It's a good example of how a little scripting can solve a problem that looks bigger than it is.

If you're seeing the same thing, feel free to use and modify the scripts. Happy scripting!