Branch, leaf, outcome

  • Branch: Defender / Intune
  • Leaf: Intune proactive remediations, Get-MpComputerStatus, Update-MpSignature, Microsoft Defender Antivirus engine/platform versions
  • Outcome: Removes the manual task of checking Defender version state device by device after a security advisory or update requirement.

The problem

When Microsoft Defender engine or platform versions matter, the portal view is not always enough for operational follow-up.

In a multi-site endpoint environment, the practical question is not just “is Defender enabled?” The question is:

  • which endpoints are below the required engine or platform version,
  • can the endpoint trigger the Defender update path,
  • and can I prove the before/after state without opening each device?

That is a good fit for Intune proactive remediations.

Constraints

I wanted this pattern to be boring and auditable:

  • detection must be read-only,
  • remediation must only trigger Microsoft Defender update mechanisms,
  • minimum versions must be configurable,
  • logs must show before and after state,
  • rollout must start with a pilot group,
  • no tenant-specific data should be needed in the script.

Decision

I used an Intune remediation pair:

  • detection checks Defender engine and platform versions,
  • remediation runs Defender update mechanisms,
  • both scripts write local logs and return clear exit codes.

The key decision was to keep the script narrow. It does not try to solve every Defender health issue. It answers one operational question: is this endpoint at or above the configured Defender version baseline?

Implementation

Portal path:

Intune admin center > Devices > Scripts and remediations > Remediations

Recommended settings:

  • Run this script using the logged-on credentials: No
  • Run script in 64-bit PowerShell: Yes
  • Assignment: pilot first, then staged rollout

The detection script uses Get-MpComputerStatus and compares the local values against configured minimums.

$Status = Get-MpComputerStatus -ErrorAction Stop
$EngineVersion = [version]$Status.AMEngineVersion
$PlatformVersion = [version]$Status.AMProductVersion

$EngineCompliant = $EngineVersion -ge $MinimumEngineVersion
$PlatformCompliant = $PlatformVersion -ge $MinimumPlatformVersion

if ($EngineCompliant -and $PlatformCompliant) {
    exit 0
}

exit 1

The remediation script runs Update-MpSignature, then calls the local Defender command-line update path as a fallback, and finally reads the version state again.

Full public script pair:

https://github.com/Thugney/eriteach-scripts/tree/main/intune/remediations/defender-kev-version-compliance

Until the script PR is merged, use the review PR:

https://github.com/Thugney/eriteach-scripts/pull/3

What I tried first

The first instinct is to treat Defender update state as a dashboard problem.

That helps for visibility, but it does not remove the operational loop. Someone still has to check affected devices, trigger action, and prove what changed.

The useful shift was to make Intune do that loop: detect, remediate, validate, report.

Validation

I would validate this in three places:

  1. Intune remediation status for detection/remediation result.
  2. Local log files for before/after Defender versions.
  3. Microsoft Defender portal for broader endpoint health context.

The important validation point is that the script logs the version before remediation and after remediation. If the endpoint remains below the configured minimum, the script exits non-zero so it stays visible.

Measured outcome

The manual task removed is checking Defender engine/platform versions one endpoint at a time and manually triggering update attempts.

Publicly, I would describe the result as reduced repeated manual verification and better evidence during security update follow-up. I would not publish exact device counts, policy names, or internal rollout metrics.

Trade-offs and watch-outs

  • Minimum versions must be updated from the advisory or internal baseline you are responding to.
  • A failed update can be caused by network, service health, policy, or platform issues. The remediation should expose that, not hide it.
  • Pilot first. Defender update behavior is usually safe, but broad remediation still deserves staged rollout.
  • Do not turn this into a general health script. Keep the scope narrow enough to trust the result.