Microsoft.Windows/FirewallRuleList: `unspecifiedRulesAction` is always reported as drift, so `test` and `set` never converge

[boaz-raz]

Steps to reproduce

Tested on dsc 3.3.0-preview.4, Microsoft.Windows/FirewallRuleList v0.2.0, Windows Server 2025, elevated.

Create a rule, then declare it exactly as it exists so there is genuinely no drift:

New-NetFirewallRule -Name 'DSC-Repro' -DisplayName 'DSC-Repro' -Direction Inbound `
  -Action Allow -Protocol TCP -LocalPort 32921 -Enabled True -PolicyStore PersistentStore

# repro.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: fw
  type: Microsoft.Windows/FirewallRuleList
  properties:
    unspecifiedRulesAction: ignore   # documented as "same as if not specified, does nothing"
    rules:
    - name: DSC-Repro
      direction: Inbound
      action: Allow
      protocol: 6
      localPorts: '32921'
      enabled: true

dsc config test -f repro.dsc.yaml

Expected

inDesiredState: true. unspecifiedRulesAction: ignore is documented as "same as if not specified, does nothing", so it should be indistinguishable from omitting the property.

Actual

{ "inDesiredState": false, "differingProperties": ["unspecifiedRulesAction"] }

Removing the unspecifiedRulesAction line from the same config yields inDesiredState: true with differingProperties: []. The only variable is the property itself — actual firewall state is identical in both cases.

All three enum values reproduce it:

config	inDesiredState	differingProperties
property omitted	true	[]
unspecifiedRulesAction: ignore	false	["unspecifiedRulesAction"]
unspecifiedRulesAction: disable	false	["unspecifiedRulesAction"]
unspecifiedRulesAction: remove	false	["unspecifiedRulesAction"]

Cause

get_rules() returns unspecified_rules_action: None unconditionally, and the field is skip_serializing_if = "Option::is_none", so dsc resource get never emits the property:

{"actualState":{"rules":[{"name":"DSC-Repro","protocol":6,"localPorts":"32921", ... }]}}

The engine's synthetic test then compares a desired state that has the property against an actual state that lacks it, and records a difference. This matches the intent stated in #1579 that the property be write-only and absent from output state — but combined with synthetic test, "absent from output" produces permanent false drift.

Also affects set convergence reporting

After a set has fully converged, a second identical set still reports:

{ "changedProperties": ["unspecifiedRulesAction"] }

The underlying rule work is correctly idempotent (already-disabled rules are skipped), but every run reports a change. For fleet reporting this means a converged estate never shows as converged.

Suggested fix

Two options, in preference order:

1. Exclude the property from state comparison. In Implement canonical _purge on Microsoft.Windows/FirewallRuleList for authoritative rule management #1579, Steve Lee (@SteveL-MSFT) argued for a canonical _-prefixed property (_disableUnspecified) partly for schema discoverability. A canonical write-only property would also sidestep this, since the engine already knows not to diff canonical metadata. If a resource-specific name is preferred, the resource or engine needs an equivalent "write-only, do not compare" marker.
2. Echo the property back from get, defaulting to ignore when absent, so desired and actual agree.

Option 1 seems more correct — the property is an instruction, not observable state — but it needs a mechanism that doesn't exist for non-canonical properties today.

Impact

Any configuration using unspecifiedRulesAction permanently reports out-of-desired-state and reports a change on every run, regardless of actual firewall state. This makes the property unusable for compliance reporting, which is its primary use case.

Refs: #1579, #1599

[SteveL-MSFT]

The WG didn't like this to be canonical at this time. I think longer term, it makes sense for the JSONSchema to be able to inform the synthetic test to skip certain properties via x-instruction. For now, it would be simpler to implement option 2 even if aesthetically unpleasing. Created #1668 to discuss the longer term solution.

[SteveL-MSFT]

After further thinking, I think using the JSON Schema default value make sense for all cases, so going with that approach

[boaz-raz]

Thanks for the quick turnaround, and for opening #1668 to capture the general case.

One clarification on the default-value approach, because I think it may only cover part of the problem — and the fault is partly mine for leading with ignore in the repro.

If the engine substitutes the schema default for a property the resource's get doesn't emit, then the comparison becomes:

Desired	Actual (absent, substituted with default: ignore)	Comparison
ignore	ignore	match — fixed
disable	ignore	still differs
remove	ignore	still differs

So the headline repro in this issue gets fixed, but disable and remove — the two values anyone actually enforces with — would still report permanent drift. The table in the issue body does show all three values reproducing it; I chose ignore for the repro only because it's documented as a no-op and therefore the least arguable case, which in hindsight made the bug look narrower than it is.

Your first suggestion — option 2, having get echo the property back (defaulting to ignore when absent) — does cover all three, because the echoed value is whatever was requested rather than a fixed constant.

Have I misread how the default substitution would work? If it applies to the desired side when the property is omitted, rather than to the absent actual side, I don't think it changes the comparison in any of the three rows above either. Happy to be wrong here — just wanted to raise it before implementation rather than after, since the distinction only shows up for the non-default values.

For what it's worth, if x-instruction from #1668 ever lands, that would be the cleanest outcome from our side: the property is an instruction, not observable state, so "don't compare it" matches the semantics better than any value we could echo.

[SteveL-MSFT]

Boaz Raz (@boaz-raz) thanks for the details. You're right that the default implementation wouldn't cover the non-default cases. Let me discuss with the WG tomorrow on which approach we want to take here.

[SteveL-MSFT]

Using #1668 to discuss with WG