fix(schtasks): use DAILY schedule for scan frequencies of 24h+#151
Open
raysubham wants to merge 1 commit into
Open
fix(schtasks): use DAILY schedule for scan frequencies of 24h+#151raysubham wants to merge 1 commit into
raysubham wants to merge 1 commit into
Conversation
schtasks caps the HOURLY /mo modifier at 23, so a 24-hour scan frequency produced `/sc HOURLY /mo 24`, which schtasks rejects with "Invalid value for /MO option". The install custom action then exits non-zero and the MSI rolls back, surfacing under Intune as 0x80070643 (and failing identically on a manual MSI install, since the deferred custom action runs the same command). Map intervals of 24h or more to `/sc DAILY /mo <hours/24>` (24->1, 48->2), clamped to the DAILY ceiling of 365 and floored at 1, so no scan-frequency value can produce an invalid /mo. Sub-24h intervals keep the existing HOURLY behavior unchanged. Add scheduleFor() with table-driven unit coverage (boundaries 23/24, the 24h case, and pathological 0/100000 inputs) plus a regression guard that the hourly path and the admin /ru INTERACTIVE binding are untouched.
There was a problem hiding this comment.
Pull request overview
Fixes Windows scheduled-task creation for scan frequencies ≥ 24 hours by avoiding invalid schtasks /sc HOURLY /mo <n> values (where n > 23) and ensuring a valid schedule/modifier pair is always emitted.
Changes:
- Route scheduled-task argument generation through a new
scheduleFor(hours)helper that selectsHOURLYfor<24handDAILYfor>=24h, with appropriate modifier clamping. - Update
buildCreateArgsto use the computed schedule/modifier instead of always emittingHOURLY. - Add focused unit tests covering
scheduleForbehavior and ensuring/ru INTERACTIVEis preserved for admin installs when switching toDAILY.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
internal/schtasks/schtasks.go |
Adds scheduleFor(hours) and uses it in buildCreateArgs to avoid invalid schtasks /mo values for 24h+ intervals. |
internal/schtasks/schtasks_test.go |
Adds tests validating the new schedule mapping and argument emission for both hourly and daily cases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A Windows MSI/Intune deployment configured with a 24-hour scan frequency fails to install with
Fatal error during installation (0x80070643). The MSI rolls back; a manual MSI install fails the same way.Root cause
schtaskscaps the HOURLY/momodifier at 23.buildCreateArgsalways emitted/sc HOURLY /mo <hours>, so a frequency of24produced:The
RunInstallScheduledTaskcustom action (agent install) then exits non-zero → MSI 1603 → Intune0x80070643.schtasksvalidates/mobefore/ru, so this is purely the modifier range — independent of the run-as account or locale. It reproduces on manual installs too, because the deferred custom action runs the identical command.This only surfaced for frequencies ≥ 24h; sub-24h values (incl. the built-in default of 4) were always valid, which is why it wasn't caught earlier.
Fix
Introduce
scheduleFor(hours)and routebuildCreateArgsthrough it:hours >= 24→/sc DAILY /mo <hours/24>(24→1, 48→2), clamped to the DAILY ceiling of 365.hours < 24→/sc HOURLY /mo <hours>— unchanged, floored at 1.The clamps guarantee no scan-frequency value can ever emit an invalid
/moagain./ru INTERACTIVEfor admin installs is preserved.Testing
TestScheduleFor— table-driven: 1/4/12/23 stay HOURLY, 24/48/72 → DAILY, plus pathological 0→HOURLY/1 and 100000→DAILY/365.TestBuildCreateArgs_DailyForTwentyFourHours— asserts/sc DAILY /mo 1and that/ru INTERACTIVEsurvives the switch.TestBuildCreateArgs_HourlyUnchanged— regression guard for the 1/4/12/23 hourly path.gofmt,go build ./...,go vet ./..., andgo test ./internal/schtasks/all clean.