[JohnMcPMS]

📖 Description

Add a protected, per-user administrator settings file so selected settings from the ordinary, user-writable file cannot control elevated operations. The new admin-settings.json uses the existing settings schema and protected storage, separate from the existing administrator capability controls.

• Classify every setting by its permitted file source and execution context. With a full token, ignore ordinary-file values for module/install roots, portable package roots, the download directory, and portable-package deletion behavior.
• Overlay eligible administrator values onto user settings. Shared overrides apply to normal and elevated runs; module and install roots support separate values for each context. An explicit eligible null selects the default. Invalid protected values do not fall back to ordinary-file values; unrecoverable protected-file load failures warn and leave both files' settings unapplied.
• Add winget settings --admin, adminSettingsFile in settings export, -Admin on the user-setting PowerShell cmdlets, and target selection on the PowerShell and native DSC settings-file resources. Protected mutations require elevation; existing files can be opened without elevation. Headless creation supports provisioning without launching an editor.
• Resolve implicit configuration module roots in the receiving processor. Elevated processors use a protected default module directory and remove the inherited ordinary WinGet module directory before applying explicit caller paths. Defer DSC imports until paths are configured, use CreateDefault2, and tolerate malformed inherited module-path entries with diagnostics.

Existing Group Policy precedence, explicit CLI/API path selections, and authoritative in-process settings content remain unchanged. This does not automatically migrate settings or copy ordinary modules into protected storage, and does not restrict every other PowerShell discovery path.

🔍 Validation

Added or updated native, managed, and PowerShell tests for source/context precedence, null and invalid values, backup recovery, policy behavior, protected storage permissions, management target selection, warnings, explicit module roots, inherited path cleanup, and deferred imports.

Microsoft Reviewers: Open in CodeFlow

[ranm-msft]

One ask inline: reconcile custom-content forwarding with the newly added regression test.

[ranm-msft]

This unconditional return appears inconsistent with the new ConfigurationModulePath_CustomContentForwarded test. With no module-path argument, both generated cases return here before Location is set, so REQUIRE(factory->LocationSet) cannot pass. Should this gate distinguish file-backed settings from authoritative custom content, or should the stated contract and test be revised?

[ranm-msft]

Please address the implicit module-root case and rerun the new null-location test.

[ranm-msft]

The implicit settings-based case still enters the Location == Default branch, so effectiveModulePath is ignored and SetLocation(Default, null) retains the built-in default. The new null-location test therefore cannot obtain its expected configured root; please distinguish implicit settings selection from an explicitly selected Default location.

[JohnMcPMS]

Default and WinGetModulePath are aliases for the same enum value.

[ranm-msft]

The x86 build is blocked by signed/unsigned mismatches in the new settings assertions.

[ranm-msft]

One policy-precedence issue to address before sign-off.