Automate Dev Machine Setup with WinGet Configuration

In this blog post Automate Dev Machine Setup with WinGet Configuration on Windows we will walk through how to turn a brand-new Windows laptop into a ready-to-code dev machine using a single, repeatable command. If you’ve ever copied a checklist from Confluence, installed 20 tools by hand, then spent hours fixing “it works on my machine” gaps, WinGet Configuration is built for you.

At a high level, WinGet Configuration is “infrastructure as code” for developer workstations. You describe the desired state of a machine (apps, tools, and certain settings) in a YAML file, then Windows applies it consistently. That means faster onboarding, fewer missed steps, and a clean path to standardising environments across teams—without turning every dev into a Windows packaging expert.

What is WinGet Configuration

WinGet is Microsoft’s Windows Package Manager. Most people know it for installing apps with commands like winget install. WinGet Configuration extends that idea: instead of installing one tool at a time, you apply an entire development environment definition in one go.

Microsoft’s winget configure command reads a configuration file and brings the machine to that desired state. It can install packages, set up dependencies, and apply configuration through DSC resources (Desired State Configuration). It’s designed to be declarative: you define what you want, not a fragile script of steps to run in the “right order”.

The technology behind it (how it actually works)

WinGet Configuration combines three key pieces:

A YAML configuration file that defines the desired state. It uses a schema so editors can validate the structure and help with autocomplete.
WinGet (Windows Package Manager) to install and manage software packages.
DSC resources (Desired State Configuration) to apply settings in a predictable way, rather than relying only on ad-hoc scripting. WinGet can download the required modules/resources as part of the run.

In practice, the flow looks like this:

You run winget configure -f yourfile.winget.
WinGet parses and validates the file.
It resolves and downloads any required configuration resources (DSC modules/resources).
It checks your current state and applies only what’s needed to reach the desired state.

This “desired state” model is the big win. Re-running the same config is normal and expected—useful for drift correction after a dev machine has been used for months.

Prerequisites and versions (don’t skip this)

OS: Windows 10 1809 (build 17763) or later, or Windows 11.
WinGet: WinGet version 1.6.2631 or later for winget configure.

These requirements matter because older WinGet builds may not understand configuration files or may behave differently.

Why IT leaders and dev teams should care

Faster onboarding: new starters can be productive the same day.
Consistency: standard toolchains reduce “works on my machine” issues.
Auditability: your dev machine baseline becomes a versioned file in Git.
Scalability: one definition can support dozens or hundreds of endpoints.

Authoring a WinGet Configuration file

WinGet Configuration files are YAML. Microsoft also recommends using VS Code with a YAML extension so schema validation catches formatting mistakes early.

Here’s a practical starter example you can adapt for a typical developer setup (Git, VS Code, Windows Terminal, PowerShell, containers tooling). The exact IDs can differ by organisation, so treat this as a pattern.

#$schema: https://aka.ms/winget-configuration.schema.json

properties:
 configurationVersion: 1.0.0

resources:
 - resource: Microsoft.WinGet.DSC/WinGetPackage
 id: install-git
 directives:
 description: Install Git
 settings:
 id: Git.Git

 - resource: Microsoft.WinGet.DSC/WinGetPackage
 id: install-vscode
 directives:
 description: Install Visual Studio Code
 settings:
 id: Microsoft.VisualStudioCode

 - resource: Microsoft.WinGet.DSC/WinGetPackage
 id: install-windows-terminal
 directives:
 description: Install Windows Terminal
 settings:
 id: Microsoft.WindowsTerminal

 - resource: Microsoft.WinGet.DSC/WinGetPackage
 id: install-powershell
 directives:
 description: Install PowerShell 7
 settings:
 id: Microsoft.PowerShell

What’s going on here:

resources is the list of desired outcomes.
Microsoft.WinGet.DSC/WinGetPackage is a resource type that installs software packages via WinGet.
settings.id is typically the WinGet package ID you’d use with winget install.

Naming and storing the file

Microsoft’s guidance is to use the .winget extension (for example, configuration.winget) and, for Git-based projects, store the default configuration under ./config/configuration.winget.

Running the configuration

Once the file is ready:

Inspect the file (and any referenced modules/resources) before executing.

Preview details:

winget configure show -f .\config\configuration.winget

Validate the file structure:

winget configure validate -f .\config\configuration.winget

Test compliance (see what would change):

winget configure test -f .\config\configuration.winget

Apply it:

winget configure -f .\config\configuration.winget

These subcommands are part of the WinGet configure workflow and help you treat the config like a real deployment artifact rather than a “hope this works” script.

Handling admin-required steps cleanly (UAC once, not 10 times)

Some machine setup steps require elevation (admin rights). Recent WinGet previews introduced an experimental capability to handle elevation more gracefully during configuration runs. With the right experimental feature enabled, you can mark specific resources to run elevated and avoid repeated prompts. (newreleases.io)

In practice, this can make a big difference for developer experience, especially when onboarding a laptop that needs a mix of user-scoped tools and system-scoped prerequisites.

Practical patterns for real teams

1) Split “baseline” and “project” configs

Baseline config: OS-level and common tools (Terminal, Git, browsers, security tools, editors).
Project config: language SDKs, CLIs, local databases, emulators, and project-specific tooling.

This keeps your baseline stable while letting teams iterate quickly on their own stacks.

2) Put configs in Git and version them

Treat your .winget file like application code:

Pull requests for changes
Code review for new packages/resources
Tagged releases for known-good onboarding baselines

3) Use “test” in CI before you roll it out

A simple pipeline job can run validation checks (and, where possible, apply the config in a disposable VM). If the config breaks, you catch it before the next new starter does.

Security and trust (a quick but important word)

Configuration files can install software and apply system changes. That’s powerful, and it also means you should treat configs as privileged artifacts:

Only run configs from sources you trust.
Review changes in PRs.
Prefer internal mirrors or approved repositories for critical tooling.
Test in an isolated environment before broad rollout.

Microsoft explicitly warns to review configuration contents and verify credibility before running.

Troubleshooting tips that save time

Check WinGet version: winget --version. If it’s older than required, update App Installer.
Open logs: winget configure --logs to jump to the logs folder.
Corporate networks: Store access/proxy/SSL inspection can impact downloads. If you’re in a locked-down enterprise, validate connectivity to the sources your configuration needs.

Where WinGet Configuration fits in your automation stack

WinGet Configuration is not trying to replace endpoint management (Intune), server configuration tooling, or full platform automation. It shines in a very specific gap: repeatable developer workstation setup with a friendly, Windows-native workflow.

If your team already uses Intune, you can still use WinGet Configuration as a developer-focused layer: IT owns the secure baseline, and engineering owns the project toolchain definition—with both expressed as code.

Next steps

Create a baseline configuration.winget for your standard dev machine.
Run winget configure validate and winget configure test on a clean VM.
Pilot with one team, then iterate.
Move it into Git, add review gates, and make onboarding a one-command experience.

Done well, WinGet Configuration becomes the quiet hero of onboarding: less tribal knowledge, fewer manual steps, and more time spent building.

Discover more from CPI Consulting -Specialist Azure Consultancy

Subscribe to get the latest posts sent to your email.