WinGet Configure for Windows 11: Build and Test a YAML PC Rebuild Kit

In a recent hands-on experiment published by XDA Developers, computing writer Shekhar Vaidya decided to retire that ritual by turning his PC setup into a declarative YAML configuration powered by Microsoft’s Windows Package Manager (winget). His walkthrough, paired with Microsoft’s official WinGet Configuration documentation, reveals both the genuine time-saving power of declarative Windows provisioning and the sharp boundaries between an automated baseline and a true system backup.

Why winget export Is Only Half the Battle​

Most command-line regulars on Windows already know winget as Microsoft’s native answer to Linux package managers, capable of searching, installing, upgrading, and removing software from the terminal. Its simplest batch-provisioning trick pairs winget export with winget import, a workflow that writers at publications like MakeUseOf have also highlighted for moving software lists between machines and recovering from network timeouts simply by re-running the import.

In the XDA experiment, Vaidya began by dumping his installed software list along with version numbers into a JSON file:

winget export -o apps.json --include-versions

That single command captured more than 150 packages across the default winget repository and the Microsoft Store. However, as Microsoft’s winget export documentation explains, the tool can only export applications when it can match Windows Add/Remove Programs metadata against a manifest in an available configured source. When it cannot find a match, it throws a warning and moves on.

In Vaidya’s case, several everyday essentials that he had originally installed manually—including Brave, Discord, Postman, and Android Studio—did not make the initial export cut. Furthermore, the raw JSON inventory contained duplicate entries where both user-scope and system-scope installations existed on the same PC.

More importantly, a standard winget export produces a JSON file designed for winget import, which only installs packages in serial fashion. If you want to install applications and configure Windows operating system settings in a single pass, you need winget configure—and winget configure speaks YAML, not the export JSON schema.

JSON Import vs. YAML Configuration​

Understanding which tool fits your next rebuild starts with knowing how Microsoft separates these two features in its official documentation:

Because Vaidya wanted a file that handled system preferences alongside his software stack, he converted and curated his list into YAML, added his missing packages manually, stripped out the duplicates, and inserted three Windows settings by hand: enabling Developer Mode, showing file extensions and hidden files, and turning on dark mode. (While WinGet Configuration can also manage Visual Studio Code extensions, he skipped those after shifting much of his daily coding workflow toward Antigravity and Claude Code.)

To keep his provisioning modular, he ultimately split his 100-plus item list into two YAML files:

• File 1 (Core Workstation): Development tools, everyday productivity software, and homelab access utilities.
• File 2 (Hardware & Leisure): Vendor-specific hardware utilities, game launchers, and flight simulation tools.

Section Summary: Running winget export gives you a helpful JSON starting inventory, but it will miss unmatched manual installs and cannot natively toggle Windows OS settings. Moving to winget configure requires curating a declarative YAML file powered by PowerShell Desired State Configuration (DSC).

Inside the Clean VM Test: Elevation Traps and UAC Prompts​

A configuration file you have never tested on a blank machine is just wishful thinking stored as plain text. Lacking a spare physical laptop, Vaidya spun up a clean Windows 11 26H2 virtual machine in VMware, installed all pending Windows Updates, and verified that the fresh installation included winget v1.11.510—well above Microsoft’s minimum prerequisite of v1.6.2631.

Rather than waiting on all 150-plus packages inside a virtual machine, he tested a reduced configuration file (workstation-vm-test.dsc.yaml) containing his three Windows settings and 14 core applications. Even in that controlled test, three practical friction points surfaced that every Windows power user should anticipate:

1. Enabling Configuration Components: His first attempt to check the file with winget configure validate failed outright because the configuration feature was not yet active on the fresh install. Running winget configure --enable (which Microsoft notes requires Microsoft Store access) unlocked the feature and allowed validation to pass with zero issues.
2. The Non-Admin PowerShell Trap: He then executed the configuration inside a Measure-Command block to time the run:
   Measure-Command { winget configure -f workstation-vm-test.dsc.yaml --accept-configuration-agreements }
   All 14 applications installed, but only two of the three Windows settings applied. Because PowerShell was running in a standard user context rather than as Administrator—and because wrapping the call in Measure-Command masked the failure output—one setting silently failed to apply. Microsoft’s WinGet Configuration troubleshooting documentation confirms that insufficient administrative access for a PowerShell DSC resource is the single most common reason configurations fail.
3. Unattended Does Not Mean Prompt-Free: During the first timed test, which took 14 minutes and 26.8 seconds, several User Account Control (UAC) prompts popped up and sat waiting while he was away from the screen. On a second run in a fresh VM where he caught the prompts promptly, the 14-app and 3-setting deployment finished in under 12 minutes. Microsoft’s security guidance notes that running winget configure in an elevated administrative shell suppresses prompts for admin-context system changes, whereas running in standard user context may still trigger UAC elevation prompts.

Why Installed Versions Changed Despite --include-versions​

One subtle surprise in Vaidya’s test was that the virtual machine ended up with newer software builds than his host PC, even though his initial JSON export had used --include-versions. Specifically, his test environment installed:

• Node.js: 22.23.2 instead of 22.14
• Python: 3.13.15 instead of 3.13.3
• Git: 2.55.0 instead of 2.53.0

Why did that happen? In a standard JSON winget import, the Version field is optional, and --ignore-versions can force latest builds, while omitting a pinned version defaults to the newest available package. When translating a package inventory into a YAML WinGet Configuration file, version pinning only holds if the specific version property is explicitly preserved in each YAML resource definition and that exact historical version remains available from the upstream source. If your development workflow depends on a locked runtime build, you must verify that the version key is explicitly written into your YAML resource block—and that the repository still hosts that older installer.

Section Summary: Testing a reduced 14-app YAML file in a Windows 11 VM took under 12 minutes when UAC prompts were answered promptly, but proved that running PowerShell without Administrator privileges will cause system-level DSC settings to fail.

Security and Trustworthiness: Read Before You Run​

Before you download a stranger’s "Ultimate Windows 11 Setup" YAML file from a public repository and fire it off with --accept-configuration-agreements, pause and consider what happens under the hood.

According to Microsoft Learn, winget configure parses your YAML file and automatically downloads the required PowerShell modules containing DSC resources—by default storing them under %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. Microsoft explicitly warns that:

• DSC resources can execute arbitrary code, including downloading additional binaries or running custom Get, Set, and Test PowerShell script blocks via the Script DSC resource.
• The PowerShell Gallery is not verified by Microsoft. It hosts community modules from many publishers that should never be trusted blindly. Microsoft advises checking the Owner metadata field on the PowerShell Gallery (which is tied to the account) rather than relying solely on the Author text field, and running Get-PSRepository in PowerShell to inspect configured module sources.
• Enterprise admins can block the feature entirely if unmanaged DSC execution poses a compliance risk, using the Group Policy Objects EnableWindowsPackageManagerConfiguration and EnableWindowsPackageManagerConfigurationExplanation.

Always inspect a configuration file first with winget configure show -f <file>, check its syntax with winget configure validate -f <file>, and test untrusted configurations inside Windows Sandbox or an isolated virtual machine before running them on your daily driver. And once a configuration finishes, run winget configure test -f <file> to verify whether your PC actually conforms to the desired state, since winget continues running independent tasks even when one assertion or resource fails.

How to Build Your Own Declarative Windows Rebuild Kit​

If you want to replicate this workflow without falling into the traps above, follow this structured procedure:

1. Export Your Current Inventory:
   Open PowerShell and run:
   winget export -o apps.json --include-versions
   Watch the terminal output for warnings about unmatched applications so you know which manual installs (or standalone installers) were skipped.
2. Generate or Author Your YAML Configuration:
   Instead of hand-converting everything from scratch, note that modern versions of WinGet also support winget configure export -o config.dsc.yaml --all to export package configurations directly into configuration resources, or --package-id / --module and --resource to export specific items. Clean up duplicate user/system entries and add any missing packages that exist in the winget catalog.
3. Add Supported DSC OS Settings:
   Append your desired PowerShell DSC resources—such as Developer Mode or File Explorer visibility toggles—to the YAML file. Because WinGet Configuration is declarative rather than sequential, the order of entries in the file does not matter unless you explicitly link resources using dependsOn assertions.
4. Validate and Inspect:
   On your target machine (or test VM), enable the configuration engine and validate the file:
   
   Code:

   winget configure --enable
   winget configure validate -f config.dsc.yaml
   winget configure show -f config.dsc.yaml

5. Apply from an Elevated Terminal and Verify State:
   Open PowerShell as Administrator so system-wide DSC resources do not fail, apply the configuration, and then test conformance:
   
   Code:

   winget configure -f config.dsc.yaml --accept-configuration-agreements
   winget configure test -f config.dsc.yaml

A Repeatable Baseline, Never a Full Backup​

The sharpest takeaway from Vaidya’s experiment is his distinction between an application being installed and being configured. When his virtual machine finished running the YAML file, the apps were present on disk, but none of them knew who he was.

Browsers opened to blank profiles without bookmarks, history, or saved passwords. Utility apps sat waiting at sign-in screens. Commercial suites like Microsoft Office and Adobe Creative Cloud still demanded manual license authentication. Sensitive items like SSH keys and Git credentials were intentionally kept out of the YAML file—and rightly so, since plain-text configuration files are no place for private keys or tokens. Likewise, hardware-specific device drivers and untested layout tweaks (such as custom taskbar pins, Start menu layouts, default file associations, and display scaling) remain separate chores.

That is not a failure of winget configure; it is the exact boundary of what declarative provisioning is meant to do. Pair a curated WinGet Configuration YAML file with a proper file backup, a secure password manager, and cloud-synced browser profiles, and your next clean Windows 11 install stops being an all-weekend ordeal—turning instead into a single command and a twelve-minute coffee break.