Skip to content

Resend Windows configuration profiles when custom variables change #44852

Description

@noahtalerman

Goal

User story
As a Fleet user,
I want Fleet to resend Windows configuration profiles when custom variables change
so that I can make sure my Windows hosts get profiles with the latest value.

Changes

Product

  • UI changes: No changes
  • CLI (fleetctl) usage changes: No changes
  • YAML changes: No changes
  • REST API changes: No changes
  • Fleet's agent (fleetd) changes: No changes
  • Fleet server configuration changes: No changes
  • Exposed, public API endpoint changes: No changes
  • fleetdm.com changes: No changes
  • GitOps mode UI changes: No changes
  • GitOps generation changes: No changes
  • Activity changes: No changes—the existing resent_configuration_profile activity type should also fire for Windows profiles.
  • Permissions changes: No changes
  • Changes to paid features or tiers: No changes
  • My device and fleetdm.com/better changes: No changes
  • Usage statistics: No changes
  • Other reference documentation changes: No changes
  • First draft of test plan added
  • Once shipped, requester has been notified
  • Once shipped, dogfooding issue has been filed

Engineering

  • Test plan is finalized
  • Contributor API changes: No changes
  • Feature guide changes: Update guide to mention Apple and Windows support. Remove coming soon note: https://github.com/fleetdm/fleet/pull/44850/changes#diff-04287cce606713f6929a1fa642bd0998160469b963e13a491699bbc255ea12a3R45
  • Database schema migrations: No changes
  • Load testing: Not required — small behavioral change extending existing Apple resend mechanism to Windows, not a new high-volume path.
  • Pre-QA load test: Not required — no change to Fleet's load profile; same resend pattern already runs for Apple profiles.
  • Load testing/osquery-perf improvements: Not required — no osquery-perf or load test environment changes needed.
  • This is a premium only feature: Yes

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

  • Requires testing in a hosted environment: No
  • Requires load testing: No
  • Risk level: Low
  • Risk description: Low risk — extending existing Apple profile resend to Windows, no new code paths.

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

  • Create a Windows configuration profile that uses a custom variable (e.g., $FLEET_VAR_*)
  • Assign the profile to a Windows host and verify it's delivered with the correct substituted value
  • Update the custom variable's value in Fleet
  • Verify the profile is automatically resent to the host with the updated value
  • Confirm the profile status transitions: verified → pending → verifying → verified
  • Verify a resent_configuration_profile activity entry appears in host activity after the profile is resent
  • Repeat steps 1-5 using a Fleet secret variable and verify the profile is resent correctly with the updated secret value

Edge cases

  • Verify updating a variable to the same value does not trigger a resend or produce a resent_configuration_profile activity
  • Verify updating a variable shared across multiple teams only resends profiles where the value genuinely changed
  • Change a variable twice in rapid succession while the Windows host is offline or MDM-unenrolled, then bring it back and verify it receives only the latest value and the status doesn't get stuck in pending
  • Delete or unset a variable still referenced by a Windows profile, and verify the profile fails with a clear error rather than being delivered with an empty or literal $FLEET_VAR_* value
  • Verify a variable change resends only to in-scope Windows hosts, not label-excluded hosts
  • Verify Apple resend behavior is unchanged
  • Verify BitLocker and OS settings profiles are unaffected

Supplemental testing

Testing notes

Confirmation

  1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
  2. QA: Added comment to user story confirming successful completion of test plan.
  3. QA: Determined whether this story needs Playwright automation.
    • Needs automation: Yes / No
    • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation": TODO

Metadata

Metadata

Assignees

Labels

#g-power-to-pcPower to the PC working groupstoryA user story defining an entire feature~product-maturityContributes to Fleet's product maturity goals for the current year~windows-workstationProduct maturity category

Type

No type

Projects

Status
No status
Status
🥚 Ready

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions