Windows - Security - Windows Defender Scan Scheduler

What the Defender scan schedule enforcer does

This Automox Worklet™ enforces a Microsoft Defender scan schedule on Windows endpoints. The Worklet reads the current Defender preferences with Get-MpPreference, compares each value to the policy baseline, and applies Set-MpPreference parameters where the endpoint has drifted. The evaluation phase is read-only, so dry-run policy runs surface non-compliant endpoints without touching configuration.

The remediation script targets the five Defender properties that govern scheduled scanning: ScanScheduleDay, ScanScheduleTime, ScanScheduleQuickScanTime, ScanParameters (1 = quick, 2 = full), and ScanOnlyIfIdleEnabled. Scan times are written in the local endpoint timezone using a TimeSpan value. ScanScheduleDay accepts 0 (Everyday) through 7 (Sunday), so a single policy can target weekday-only sweeps, weekend full scans, or a fleet-wide nightly quick scan.

Before any Set-MpPreference call runs, the Worklet confirms Microsoft Defender is the active antivirus product. It uses Get-CimInstance against the root/SecurityCenter2 namespace and inspects the AntiVirusProduct class for a productState that indicates Defender is enabled. If a third-party agent such as CrowdStrike, SentinelOne, or Sophos has registered itself as the primary AV, the Worklet exits 0 with an informational message and writes no changes. Mixed-AV fleets stay quiet in Automox activity logs instead of throwing false failures.

Why enforce a Defender scan schedule

Scheduled antivirus scanning is the baseline control behind the Windows Defender Antivirus sections of the CIS Microsoft Windows Benchmark, NIST 800-53 SI-3, PCI-DSS 5.2, and HIPAA 164.308(a)(5)(ii)(B). Auditors want evidence that every Windows endpoint runs a Defender scan on a known cadence and that real-time protection has not been silently disabled. Endpoints that have drifted off the schedule (sometimes after a user-mode disable, a Group Policy gap on a remote laptop, or a Defender update that reset preferences) fail the audit even when the rest of the security stack is healthy.

MpPreference values drift in ways Group Policy alone does not catch. A user disables a scheduled scan from the Defender app because it slows their morning, a refurbished image ships without the baseline applied during OOBE, a Defender platform update temporarily resets ScanScheduleDay during the post-update reconcile pass. The Worklet calls Get-MpPreference on every cycle, compares ScanScheduleDay, ScanScheduleTime, ScanParameters, ScanOnlyIfIdleEnabled, and DisableRealtimeMonitoring against the policy variables, and calls Set-MpPreference against any value that diverges so the scan baseline holds against domain-joined workstations, Azure AD-joined laptops, and standalone servers under management.

How Defender scan schedule enforcement works

1. Evaluation phase: The Worklet runs Get-MpPreference and pipes the result through Select-Object to read ScanScheduleDay, ScanScheduleTime, ScanScheduleQuickScanTime, ScanParameters, ScanOnlyIfIdleEnabled, and DisableRealtimeMonitoring. Each value is compared against the policy variables (scanDay, scanTime, scanType, scanOnlyIfIdleEnabled, enableRealtimeProtection). Any mismatch flags the endpoint as non-compliant and exits non-zero. The evaluation script is purely read-only against MpPreference, so the policy can run on a daily cadence without producing remediation events on already-compliant endpoints.

2. Remediation phase: The remediation script first calls Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct and confirms Defender is the registered product. It then issues targeted Set-MpPreference calls – Set-MpPreference -ScanScheduleDay, Set-MpPreference -ScanScheduleTime, Set-MpPreference -ScanScheduleQuickScanTime, Set-MpPreference -ScanParameters, and Set-MpPreference -DisableRealtimeMonitoring $false – for each drifted property. The script then re-reads the preferences and exits 0 on success, or non-zero with an error written to stderr if Defender is unavailable or a Set-MpPreference call fails.

Defender scan schedule requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 with the Defender PowerShell module installed

• Microsoft Defender registered as the active antivirus product in root/SecurityCenter2 (the Worklet exits silently when a third-party AV is primary)

• Automox agent running in its default SYSTEM context, which already satisfies the administrator requirement for Set-MpPreference

• Policy variables set in the Worklet: scanOnlyIfIdleEnabled ($true / $false), enableRealtimeProtection ($true / $false), scanType (1 = quick, 2 = full), scanTime (24-hour format, e.g. 23:00:00), scanDay (0 = Everyday, 1 = Sunday … 7 = Saturday)

• Scan times are written in the local endpoint timezone, so geographically distributed fleets get the same off-hours behavior without a central scheduler

• If a competing schedule has been written by Group Policy or a Register-ScheduledTask job under Microsoft\Windows\Windows Defender, decide which source owns the schedule before scheduling this Worklet on a recurring policy

Expected Defender state after enforcement

After a successful remediation, Get-MpPreference returns the policy values for ScanScheduleDay, ScanScheduleTime, ScanScheduleQuickScanTime, and ScanParameters, and DisableRealtimeMonitoring reports False. The hidden scheduled task at Task Scheduler Library › Microsoft › Windows › Windows Defender › Windows Defender Scheduled Scan reflects the new trigger; you can confirm by running Get-ScheduledTask -TaskName 'Windows Defender Scheduled Scan' | Select-Object -ExpandProperty Triggers. The Worklet does not call Register-ScheduledTask directly – Defender owns its task definition and recreates it from the MpPreference values.

For audit evidence, capture three artifacts per endpoint after the policy run: Get-MpPreference | Select-Object Scan* output, Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled, AntivirusEnabled, and a single on-demand sanity scan via MpCmdRun.exe -Scan -ScanType 1. Subsequent Automox policy runs report the endpoint as compliant without re-running Set-MpPreference, because the evaluation phase finds every property already aligned with the baseline. Exit code 0 in Automox activity logs maps to a fully enforced schedule; any non-zero exit ships a diagnostic message that names the failed preference.