Installing Windows Configuration Designer via the Windows Package Manager (winget) is one of the quickest, most repeatable ways to add Microsoft’s provisioning-tool to your toolkit — especially when you want to script deployments, avoid Store UI friction, or include the tool in a golden-image workflow. The one-line winget approach is fast, deterministic, and integrates cleanly into provisioning scripts; however, there are important caveats (Store source behavior, offline scenarios, server edge cases) that every sysadmin should understand before rolling it out at scale. This feature walks through the commands, verification steps, automation recipes, and operational risks — and validates the main claims against Microsoft documentation and the published Store/ADK guidance.
Background / Overview
Windows Configuration Designer (WCD), historically called Imaging and Configuration Designer (ICD), is Microsoft’s provisioning tool for building .ppkg provisioning packages that apply settings during first run or post-deployment. You can preconfigure Wi‑Fi, local accounts, device naming, Microsoft Entra (Azure AD) enrollment, certificate installs, Start menu layout and more — which makes WCD a valuable time-saver for labs, small fleets, or technician workflows that don’t require a full image rebuild. The tool is available in three common ways: from the Microsoft Store (UWP/MSIX), as part of the Windows Assessment and Deployment Kit (Windows ADK), or via winget (msstore source). Microsoft’s documentation confirms WCD as a Store app and as an ADK component. The winget route is particularly appealing for automation: it avoids manual Store clicks, fits into PowerShell workflows, and can be added to an image build script or provisioning task sequence. The rest of this article explains how to install it with winget, how to verify the install, how to script and troubleshoot it, and which scenarios still require the ADK or a different approach.
What winget actually installs (and what WCD is)
- Windows Configuration Designer (WCD) — the provisioning-authoring tool used to build .ppkg provisioning packages for Windows client and some device families. It appears in the Microsoft Store with product id 9NBLGGH4TX22 and is also offered as an ADK component for offline or air‑gapped installs.
- Winget (Windows Package Manager) — the command-line package manager that can install Store apps (msstore source) and community manifests (winget source). It’s distributed as part of the App Installer system component and runs on modern Windows 10 and Windows 11 clients; it can be added to Server SKUs with extra steps or via the App Installer artifacts.
Key takeaway: you’re not installing a separate “winget build” of WCD — winget orchestrates the Store/MSIX install of the official Windows Configuration Designer package (or can pull from a manifest that points at the Store product id). That’s why the msstore source or the Store account state can affect the behavior.
Quick install: exact command and what it does
Here are the exact commands you’ll use from an elevated terminal (PowerShell or Command Prompt run as Administrator):
- Basic name-based install:
- winget install "Windows Configuration Designer"
- Deterministic ID-based install (recommended for scripts):
- winget install --id 9NBLGGH4TX22 --source msstore
Why the ID? Using the Store product ID (9NBLGGH4TX22) avoids ambiguity if a display name changes or multiple similarly-named manifests appear. The msstore source forces winget to use the Microsoft Store channel for the package, which is important because the package is Store-published. Microsoft’s winget guidance supports both name and id installs and recommends exact identifiers for repeatability. Practical flags you should consider in unattended scripts:
- --accept-source-agreements — auto-accepts the repository terms so scripts don’t block waiting for your input.
- --accept-package-agreements — auto-accepts package-specific license terms.
- --accept-package-agreements and --accept-source-agreements are commonly used together for unattended installs; use them only after auditing the terms you’ve agreed to.
Example unattended command:
- winget install --id 9NBLGGH4TX22 --source msstore --accept-source-agreements --accept-package-agreements
Step-by-step: install with context and checks
1. Open a terminal as Administrator
- Right-click Start → Terminal (Admin) on Windows 11, or search PowerShell and choose Run as Administrator on Windows 10.
- Run the install from elevated context to avoid UAC prompts in automation.
2. Confirm winget is available
- Run: winget --version
- If the command is not found, you need App Installer (the Store package that contains the winget client) installed. On most modern Windows 11 builds, winget comes preinstalled; on older Windows 10 you may need to add App Installer from the Microsoft Store or install the winget client from the GitHub releases.
3. Install WCD with winget
- Option A (name): winget install "Windows Configuration Designer"
- Option B (id + source, recommended): winget install --id 9NBLGGH4TX22 --source msstore --accept-source-agreements --accept-package-agreements
This calls the Store/installation pipeline and will download the Store/MSIX bundle and its dependencies.
4. What to expect during install
- Typical Store/MSIX installs are quick (tens of megabytes for the app itself), and you’ll see progress in the terminal. Some environments (corporate image, restricted networks) will trigger additional prompts or failures if the Store is restricted.
- If winget prompts to accept source or package agreements, type y (or include the acceptance flags above in scripts).
Note: an exact size for the installer can vary by build and localization; the Store page shows package metadata but the client downloads the necessary MSIXbundle and dependencies on demand. If you require a precise byte count for bandwidth planning, capture the download once in your environment and measure it — Store-resident packages and dependency resolution can change over time. (This download-size estimate in many blog posts — “~30–50 MB” — is a practical ballpark but can’t be guaranteed across locales or future builds. Treat that as illustrative, not contractual.
Verify the installation
- Start menu: press Start and type “Windows Configuration Designer” — the app should appear.
- winget list --name "Windows Configuration Designer" — shows the package in winget’s installed list if the install came from a winget-tracked source.
- Launch the app and check the About / version inside the app to confirm the installed build; the app’s UI opens to a project-selection screen where you can create or open provisioning packages. Microsoft’s documentation explains WCD’s UI and supported scenarios.
Alternatives and when to use them
Microsoft Store (manually)
- Open Microsoft Store, search “Windows Configuration Designer”, and click Install.
- Pros: easy for one-off installs, automatic Store updates.
- Cons: not scriptable; may require an MSA or organizational Store sign-in depending on device configuration.
Windows ADK (recommended for offline/air‑gapped scenarios)
- If you need a fully offline, re-deployable package or you’re building images, install the Windows ADK and select the Configuration Designer feature during ADK setup.
- ADK includes other deployment tooling (DISM, WinPE, USMT) and is the right choice for image-based workflows or air-gapped environments. Microsoft explicitly documents WCD as part of ADK toolsets.
Which to pick:
- Use winget for quick, repeatable, scripted installs on internet-connected machines.
- Use Store when you prefer automatic updates and GUIs for single machines.
- Use ADK for offline installations, imaging, or when you need the rest of ADK’s toolkit.
Server, offline, and enterprise caveats
Winget on Windows Server
- Winget is primarily a desktop client (Windows 10/11). It can be installed on Server SKUs (Server 2019/2022) but often needs additional manual steps (Appx/MSIX dependencies, license XML, or App Installer artifacts). Community guides and Microsoft notes document the manual approach and varying degrees of support depending on server version. Expect extra work and test thoroughly before trusting winget in server-side automation.
msstore source and Microsoft account state
- Winget can install from the msstore source, but historically some Store packages required that the user sign into the Microsoft Store UI (MSA) for the Store source to work. The winget project has addressed many of these friction points, but behavior depends on Windows and App Installer versions and on whether the device policy or Store settings block sign-in. In practice:
- For many deployments, winget install --source msstore works without interactive sign-in.
- In some enterprise images or locked-down devices, you may need to sign into the Microsoft Store app or pre-provision Store licenses before script-driven msstore installs succeed. Treat msstore installs as conditional on your environment’s Store/account policy.
Offline installation limitations
- The Store/MSIX variant of WCD expects the Store delivery model and its dependencies; truly offline installs are not straightforward for the Store package. If offline deployment is required, use the Windows ADK route and include Configuration Designer in your ADK installer payload. The ADK enables truly offline provisioning tool installs suitable for air‑gapped or restricted networks.
Automation recipe: a production-ready PowerShell snippet
Below is a copy-ready pattern for a scripted install in a provisioning or imaging pipeline. It’s defensive, logs results, and accepts Store/package agreements to avoid interactive prompts. Test in a sandbox before broad rollout.
- Save as Install‑WCD.ps1 and run as Administrator:
- $ErrorActionPreference = 'Stop'
- $log = 'C:\Temp\wcd-install.log'
- Write-Output \"Starting WCD install: $(Get-Date)\" | Tee-Object -FilePath $log -Append
- if (-not (Get-Command winget -ErrorAction SilentlyContinue) { Write-Output 'winget not found; aborting' | Tee-Object -FilePath $log -Append; exit 2 }
- winget install --id 9NBLGGH4TX22 --source msstore --accept-source-agreements --accept-package-agreements 2>&1 | Tee-Object -FilePath $log -Append
- if ($LASTEXITCODE -eq 0) { Write-Output 'WCD installed successfully' | Tee-Object -FilePath $log -Append } else { Write-Output \"WCD install failed, exit code: $LASTEXITCODE\" | Tee-Object -FilePath $log -Append; exit $LASTEXITCODE }
Notes:
- Add network/proxy checks if your environment requires proxy auth.
- For fully automated, non-interactive provisioning, add --disable-interactivity (where supported) and audit each package’s silent behavior.
- The explicit --id usage ensures the script does not accidentally match another package name.
Operational best practices (governance + testing)
- Always run initial installs in a disposable VM or Windows Sandbox. Validate the provisioning package and the created device state before mass deploys.
- Pin to an ID and test upgrade paths. Package names and manifests can be edited in repositories; an ID is the most deterministic selector for scripts. Use winget show --id to inspect a manifest before install.
- Use private winget sources for enterprise governance when exposing only approved packages to endpoints. Winget supports private REST sources and manifests; this shifts trust from community manifests to your org’s CI/CD validation tooling.
- Maintain an audit trail of accepted package and source agreements for compliance. Document which agreements your unattended installs accept.
- Validate silent-install behavior for each package. Winget’s --silent flag is a request translated to underlying installer switches; not every EXE/MSI honors the same switches.
Security, supply chain, and risk analysis
Installing from a package manager reduces risks compared with clicking random vendor sites, but it is not risk-free.
Strengths:
- Scriptable, reproducible installs and export/import workflows improve auditability and repeatability across workstations and test rigs. Winget’s JSON export/import flow is excellent for building a documented baseline.
- Installing the Store-signed package reduces exposure to repackaged installers (Store apps are validated by Microsoft).
Risks and limits:
- msstore sign-in nuance — some Store packages historically required the device’s Store account state; behavior can differ across OS/Store/App Installer versions. Test in your environment before rolling out msstore-based scripts.
- Silent install unpredictability — winget mediates installs but the underlying installer ultimately controls whether the install is truly silent.
- Server complications — winget on Server SKUs often needs extra steps and is not as straightforward as on desktop Windows. Use ADK or alternate packaging for server-side automation if you need strong reliability.
- Private-repo governance burden — hosting a private winget source gives control but pushes vetting, signing, and CI/CD responsibility onto the organization.
- Offline installs — the Store/MSIX model is not friendly to pure offline scenarios; use ADK when you need full offline support.
Cross-checks and verification versus published guidance
- Microsoft’s WinGet documentation describes install modes, use of sources, and scripting flags for unattended installs; it signals that winget is a client delivered via App Installer and supports msstore and community sources. That documentation is the authoritative reference for winget usage.
- Microsoft’s provisioning docs confirm Windows Configuration Designer is available from the Microsoft Store for Windows 10/11 clients and enumerate supported scenarios; they also point out ADK as the offline alternative. That verifies both the Store presence and ADK inclusion.
- Community experience (issues and discussions in the winget GitHub and community guides) documents real-world edge cases — especially msstore sign-in behavior and Server SKU installation steps. Those practical reports explain why some admins see sign-in prompts or need to bootstrap Appx dependencies on Server SKUs. Treat those as operational context for test planning.
Where an assertion cannot be deterministically verified:
- Exact download bytes for the Store package (e.g., “30–50 MB”) vary by build and region; therefore any fixed size claim should be treated as an estimate. If you have tight bandwidth constraints, measure downloads in your environment or use ADK offline payloads.
Final verdict: when to use winget for Windows Configuration Designer
Use winget when:
- You want a fast, scriptable, reproducible install on internet-connected client devices.
- You’re building day-one provisioning scripts for labs, VMs, or test fleets.
- You prefer deterministic ID-based installs for automation and auditing.
Prefer Microsoft Store (GUI) when:
- You’re installing on a single machine and prefer a graphical flow with automatic updates.
- Your environment already uses Store sign-ins and automatic maintenance.
Use the Windows ADK when:
- You need offline or air‑gapped deployment capability.
- You require the rest of the ADK toolset (DISM, WinPE, USMT) and a single offline installer payload.
Conclusion
Installing Windows Configuration Designer using winget is a clean, repeatable, and scriptable approach that fits well into modern provisioning pipelines. The command is simple — winget install --id 9NBLGGH4TX22 --source msstore — but productionizing that line requires attention to a few important operational details: acceptance of Store/package agreements, Store-account behavior in your environment, offline/Server workflows, and verifying silent-install behavior for unattended runs.
Test the command in a sandbox or canary ring, pin the exact ID in scripts, and document any accepted package or source agreements. For air‑gapped or fully controlled enterprise environments, use the Windows ADK path. With those precautions, winget provides a fast, auditable, and compact method to get Windows Configuration Designer installed and ready to produce provisioning packages for your fleet.
Source: How2shout
How to Install Windows Configuration Designer Using Winget Command