Allen Houchins
4d55e96f9f
**Related issue:** NA Adds an article and companion guide on putting **Microsoft Store apps** into Windows self-service using winget and `.ps1` script-only packages. | File | Category | URL | |---|---|---| | `build-your-own-windows-self-service-with-winget-and-script-only-packages.md` | `articles` | `/articles/build-your-own-windows-self-service-with-winget-and-script-only-packages` | | `build-your-own-windows-self-service-with-winget-and-script-only-packages-guide.md` | `guides` | `/guides/build-your-own-windows-self-service-with-winget-and-script-only-packages-guide` | ## What changed and why Fleet 4.89.0 added an uninstall script, pre-install query, and post-install script to script-only packages. On Linux that was enough to build a [self-service catalog on apt and dnf](https://fleetdm.com/articles/build-your-own-linux-self-service-with-script-only-packages). These are the Windows counterparts, scoped specifically to Store apps. The per-app work is two lines: ```powershell winget install --id <StoreId> --source msstore --accept-package-agreements --accept-source-agreements --disable-interactivity winget uninstall --id <StoreId> --accept-source-agreements --disable-interactivity ``` Everything else in each script is boilerplate, and the generator emits it. ## The constraint both pieces are built around Fleet's agent runs Windows scripts as SYSTEM (`orbit/pkg/scripts/exec_windows.go:17`), and Store apps cannot be installed that way: - The `msstore` source rejects device-wide installs outright: "Device wide install for msstore type is not supported under admin context" ([winget-cli#3553](https://github.com/microsoft/winget-cli/issues/3553)). Store packages are per-user by design. - winget's CLI is [not supported in the system context](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting) at all, because App Installer is an MSIX package that cannot be registered for `NT AUTHORITY\SYSTEM`. - Running winget in the system context is still [an open feature request](https://github.com/microsoft/winget-pkgs/issues/346975). So the scripts run winget inside the logged-on user's session via a short-lived scheduled task, mirroring the pattern already used by Fleet's own per-user Windows maintained apps (`ee/maintained-apps/inputs/winget/scripts/figma_install.ps1`). ## Two things worth a reviewer's attention Both are corrections that fall out of the Store focus, and both would have produced silently wrong content: 1. **Verification uses `Get-AppxPackage -AllUsers`, not the registry.** Store apps never register in the HKLM uninstall keys, so a registry check fails on a perfectly good install. This is called out explicitly in the guide's Troubleshoot section, since it's a natural wrong instinct if you've built tiles for ordinary Windows installers. 2. **`winget install --scope machine` is documented as a trap, not a shortcut.** For a Store package it [installs under the SYSTEM account](https://github.com/microsoft/winget-cli/issues/4748) instead of provisioning the app, which reports success and leaves users with nothing. The scheduled task's exit code also doesn't propagate back to the calling script, so the install reports success whenever the task ran. Both pieces treat the post-install verification as mandatory rather than optional because of this. ## Machine-wide path For apps that must exist for every user, the content documents `winget download` plus `Add-AppxProvisionedPackage`, which does work as SYSTEM, along with its two costs: license download [requires Entra ID authentication](https://learn.microsoft.com/en-us/windows/package-manager/winget/download) by a Global Administrator, User Administrator, or License Administrator, and you now have a file to host, so it wants a Fleet custom package rather than a script-only one. ## Notes for reviewers - **Content only.** No Go, frontend, migration, or config changes, so no changes file is needed and the code-focused template sections below are removed as the template instructs. - **The PowerShell has not been executed.** There is no `pwsh` on the authoring machine. The generator's here-string escaping was traced by hand but not run. Worth one execution on a real Windows host before publish. - **`Microsoft.CompanyPortal` / `9WZDNCRFJ3PZ`** are used as the worked example. Both identifiers are now verified (PackageFamilyName `Microsoft.CompanyPortal_8wekyb3d8bbwe`), and the guide still tells readers to derive both themselves. - **A verification pass was run over every claim** (Fleet docs, Microsoft Learn, winget-cli issues). It caught one real bug: `winget uninstall` with no flags can hang on an msstore source-agreement prompt ([winget-cli#1736](https://github.com/microsoft/winget-cli/issues/1736)), invisible inside the scheduled task. All uninstalls now carry `--accept-source-agreements`, both directions carry `--disable-interactivity`, and the explorer.exe owner lookup takes the first result so multiple explorer processes can't break `Register-ScheduledTask`. - **`articleImageUrl` is intentionally absent** from the article. The build treats it as optional, but the Linux article has one, so a `1200x627@2x.png` in `website/assets/images/articles/` plus the meta tag would bring it to parity. The guide has none, matching the Linux guide. - **`publishedOn` is `2026-08-05`** on both. Update if these are being scheduled. Checked against the build's enforced constraints (`website/scripts/build-static-content.js`): valid `category`, `articleTitle` matches each H1 exactly, descriptions are 133 and 125 characters (limit 150), `publishedOn` matches the required ISO pattern, no `@fleetdm.com` addresses. `check-pr-template` does not run on this PR, since it only triggers on `frontend/**`, `**/*.go`, `go.mod`, and `go.sum`. # Checklist for submitter ## Testing - [ ] QA'd all new/changed functionality manually Not applicable to content-only changes. Verified instead by running the website build's own validation rules against both files, and by sourcing every technical claim to Microsoft Learn, `winget-cli` issues, or Fleet's docs and code. The PowerShell samples are unexecuted, as noted above.
News · Report a bug · Docs · Why open source? · Art
Open-source platform for IT and security teams with thousands of computers. Designed for APIs, GitOps, webhooks, YAML, and humans.
What's it for?
Fleet gives you a single system to secure and maintain all your computing devices over the air. You can do MDM, patch stuff, deploy software, and verify anything, all from one place, across every OS your organization uses.
Fleet works directly with data and events from the native operating system, down to the bare metal. Strong diagnostics let you investigate errors on end-user devices and collect accurate audit evidence in minutes.
Get started
You can try Fleet out for yourself, or grab time with one of the maintainers to chat.
Is it any good?
Fleet is used in production by IT and security teams managing thousands of devices. Many deployments support tens of thousands of hosts, and a few large organizations manage 400,000 or more.
Supported platforms
- Linux (all distros)
- macOS
- Windows
- Chromebooks
- iOS and Android (BYOD or corporate-owned)
- Amazon Web Services (AWS)
- Google Cloud (GCP)
- Azure (Microsoft cloud)
- Data centers
- Containers (kube, etc)
- Linux-based IoT devices
Infrastructure as code
Manage your fleet with GitOps, or use the GUI, REST API, webhook events, and the fleetctl command-line tool.
Linux support
First-class support for all major distros. Linux gets the same attention and visibility as macOS and Windows.
Visibility and compliance
Fleet can report on hundreds of attributes across your devices and ships with CIS benchmarks for macOS and Windows and comprehensive operating system, hardware, and software data. Check out the table reference documentation to see what's available.
Open by design
Fleet is open source and transparent about what it can and can't see. End users can verify exactly how the agent works and what data their company collects. Fleet collects only the data needed to manage and secure devices, not private activity like keystrokes, emails, or webcams.
Good neighbors
Ready-to-use, enterprise-friendly integrations exist for Snowflake, Splunk, GitHub Actions, Vanta, Elastic Jira, Zendesk, and more. Fleet also works with tools such as Munki, Chef, Puppet, Ansible, CrowdStrike, and SentinelOne.
Lighter than air
Fleet is lightweight and modular. You can use it for MDM without using it for security, and vice versa. You can turn off features you are not using.
Free as in free
The free version of Fleet will always be free. Fleet is independently backed and actively maintained with the help of many amazing contributors.
Longevity
The company behind Fleet is founded (and majority-owned) by true believers in open source. The company's business model is influenced by GitLab (NYSE: GTLB), with great investors, happy customers, and the capacity to become profitable at any time.
Fleet Device Management's company handbook is public and open source. You can read about the history of Fleet and our commitment to improving the product.
Chat
The Fleet community is full of kind and helpful people. Whether or not you are a paying customer, if you need help, just reach out.
Contributing 
Contributions are welcome, whether you answer questions on Slack / GitHub / LinkedIn, improve the documentation or website, write a tutorial, give a talk at a conference or local meetup, give an interview on a podcast, troubleshoot reported issues, or submit a patch. The Fleet code of conduct is on GitHub.
License
The free version of Fleet is available under the MIT license. The commercial license is also designed to allow contributions to paid features for users whose employment agreements allow them to contribute to open source projects. (See LICENSE.md for details.)
Fleet is built on osquery, nanoMDM, Nudge, and swiftDialog.