Gren, blad og resultat

  • Gren: Defender / Intune
  • Blad: Intune proactive remediations, Get-MpComputerStatus, Update-MpSignature, Microsoft Defender Antivirus engine/platform versions
  • Resultat: Fjerner manuell sjekk av Defender-versjon per enhet etter en sikkerhetsmelding eller et oppdateringskrav.

Problemet

Når Microsoft Defender engine- eller platform-versjon faktisk betyr noe, er ikke portalvisning alene alltid nok for operativ oppfølging.

I et multi-site endpoint-miljø er spørsmålet ikke bare “er Defender aktivert?” Spørsmålet er:

  • hvilke endpoints er under påkrevd engine- eller platform-versjon,
  • kan endpointet trigge Defender update path,
  • og kan jeg dokumentere før/etter-status uten å åpne hver enhet?

Det passer godt for Intune proactive remediations.

Rammer

Jeg ville at mønsteret skulle være kjedelig og auditable:

  • detection må være read-only,
  • remediation skal bare trigge Microsoft Defender update mechanisms,
  • minimumsversjoner må være konfigurerbare,
  • logger må vise før og etter,
  • utrulling må starte med pilot,
  • skriptet skal ikke trenge tenant-spesifikke data.

Valg

Jeg brukte et Intune remediation-par:

  • detection sjekker Defender engine og platform version,
  • remediation kjører Defender update mechanisms,
  • begge skript logger lokalt og bruker tydelige exit codes.

Det viktigste valget var å holde scope smalt. Skriptet prøver ikke å løse all Defender health. Det svarer på ett operativt spørsmål: er dette endpointet på eller over konfigurert Defender version baseline?

Implementering

Portalsti:

Intune admin center > Devices > Scripts and remediations > Remediations

Anbefalte innstillinger:

  • Run this script using the logged-on credentials: No
  • Run script in 64-bit PowerShell: Yes
  • Assignment: pilot først, deretter staged rollout

Detection-scriptet bruker Get-MpComputerStatus og sammenligner lokale verdier med konfigurerte minimumsversjoner.

$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

Remediation-scriptet kjører Update-MpSignature, forsøker lokal Defender command-line update path som fallback, og leser deretter versjonene på nytt.

Fullt public script pair:

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

Frem til script-PR er merget, bruk review-PR:

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

Hva jeg prøvde først

Første instinkt er å behandle Defender update state som et dashboard-problem.

Det hjelper for synlighet, men det fjerner ikke den operative løkken. Noen må fortsatt sjekke berørte enheter, trigge action og dokumentere hva som endret seg.

Det nyttige skiftet var å la Intune gjøre løkken: detect, remediate, validate, report.

Validering

Jeg ville validert dette tre steder:

  1. Intune remediation status for detection/remediation-resultat.
  2. Lokale loggfiler for Defender-versjon før og etter.
  3. Microsoft Defender portal for bredere endpoint health context.

Det viktige er at skriptet logger versjon før remediation og etter remediation. Hvis endpointet fortsatt er under konfigurert minimum, returnerer skriptet non-zero slik at det forblir synlig.

Målt effekt

Den manuelle oppgaven som fjernes er å sjekke Defender engine/platform versions per endpoint og manuelt trigge oppdateringsforsøk.

Offentlig ville jeg beskrevet resultatet som mindre repetitiv manuell verifisering og bedre evidens under sikkerhetsoppfølging. Jeg ville ikke publisert eksakte enhetstall, policy names eller interne rollout-metrikker.

Avveininger

  • Minimumsversjoner må oppdateres fra advisory eller intern baseline.
  • En feilet oppdatering kan skyldes nettverk, service health, policy eller platform issues. Remediation bør gjøre det synlig, ikke skjule det.
  • Pilot først. Defender updates er normalt trygt, men bred remediation fortjener staged rollout.
  • Ikke gjør dette til et generelt health script. Hold scope smalt nok til at resultatet er til å stole på.

Relevante Microsoft-lenker