Agent User Guide

How it fits together

https://storepackager.download queries the official Microsoft catalog and Windows Update endpoints, works out the correct main package and every framework dependency for your target architecture, and signs the result into a manifest. The agent picks the job up — by polling (storepkg run) or by requesting one directly (storepkg pull) — and downloads the actual package files straight from Microsoft's CDN, verifying each one against the hash in the manifest. It then writes a complete source folder: the main package, every dependency, Install.ps1 / Uninstall.ps1 / Detect.ps1, AppInfo.json, New-CmApplication.ps1, and on request a .intunewin file and a ZIP.

Because the agent talks to Microsoft directly, package bytes never cross through StorePackager Cloud — which is also what makes the offline workflows further down possible.

Installing the agent

certutil -hashfile storepkg.exe SHA256

Connecting to your organisation

1. Create an agent record. In the web app, go to Agents → Create an agent, give it a label, and click Create. The token is shown once — copy it immediately.
2. Log in from the target machine:

   storepkg login --url https://storepackager.download --token spa_xxxxxxxx

   This stores a local config file with the token and your organisation's manifest signature key — the key that lets this agent verify manifests offline.

3. Confirm it took:

   storepkg status

Behind a proxy, add it at login time and it's remembered for every later command:

storepkg login --url https://storepackager.download --token spa_xxxxxxxx \
  --proxy http://proxy.contoso.local:8080 --proxy-user svc-storepkg --proxy-password '...'

Each token is scoped to one organisation and can be revoked from the Agents page at any time — useful when decommissioning a server.

Building your first package

The quickest path — resolve and build in one command:

storepkg pull 9WZDNCRFHVN5 --arch x64

Accepts a Store product ID, an apps.microsoft.com link, or an ms-windows-store://pdp/?ProductId=... URI. The agent prints what it found, downloads everything with hash verification, and reports the result back to https://storepackager.download so it shows up on the Packages page. Add --zip or --intunewin for extra artefacts, or --sccm to create the ConfigMgr application in the same pass.

Command reference

Shared flags (pull and build)

ConfigMgr flags (pull only)

Running unattended

For a package server that should keep working through the day's queue:

storepkg run

It polls for the next ready job, builds it, reports back, and immediately checks for another — so a burst of queued packages gets worked through back-to-back, not one every 30 seconds. Ctrl+C stops it after the current job finishes; --once does a single pass and exits.

There's no built-in Windows service installer, so wire it up with Task Scheduler: either a task triggered at startup running storepkg.exe run with "restart on failure" enabled for a supervised long-running process, or a task every few minutes running storepkg.exe run --once if you'd rather not keep a process alive. Run it as a service account with write access to the output folder and, for ConfigMgr application creation, your usual ConfigMgr permissions.

Deploying the result

Every source folder is deployment-ready on its own:

• ConfigMgr — run New-CmApplication.ps1 from the folder, or use --sccm at build time. It creates a script deployment type that installs via Add-AppxProvisionedPackage in the SYSTEM context, since ConfigMgr's built-in Windows app package deployment type is user-only.
• Intune — build with --intunewin, then either import the file into the Intune admin center by hand or add --intune-upload to have the agent create and publish the Win32 app itself — see Uploading to Intune via Microsoft Graph below. IntuneApp.json already carries the install/uninstall command lines, the detection script, and the return-code mapping either way.
• Anything else — --zip gives a portable archive for PDQ, Ansible, or a golden image pipeline; the scripts inside have no runtime dependency on StorePackager.

Uploading to Intune via Microsoft Graph

Building a .intunewin file is only half the job — someone still has to open the Intune admin center and click through the Win32 app wizard. --intune-upload does that part too: the agent creates the app, uploads and commits the encrypted package, and optionally assigns it to a device group, all via Microsoft Graph.

This is deliberately agent-side, the same way package downloads are. Your Intune credentials are stored only in the agent's local configuration file and are never sent to https://storepackager.download — uploading to your tenant is between this machine and Microsoft.

Signing in

Sign in yourself, no app registration needed — the agent defaults to Microsoft's own first-party "Microsoft Intune PowerShell" client and walks you through a device code sign-in:

storepkg intune login --tenant contoso.onmicrosoft.com

It prints a URL and a short code. Open the URL on any device, enter the code, and sign in with an account that holds Intune app management permissions. The agent stores a refresh token and silently renews it on every later use. If Conditional Access blocks first-party Microsoft apps in your tenant, register your own public client app instead and pass its id with --client-id.

Your own app registration, no interactive sign-in — for unattended servers, create an app registration with DeviceManagementApps.ReadWrite.All application permission (admin-consented once) and a client secret, then:

storepkg intune login --tenant contoso.onmicrosoft.com \
  --client-id <app-id> --client-secret <secret>

Either way, storepkg intune status shows what's currently signed in, and storepkg intune logout forgets it.

Uploading

Add --intune-upload to pull or build:

storepkg pull 9WZDNCRFHVN5 --arch x64 --intune-upload
storepkg pull 9WZDNCRFHVN5 --arch x64 --intune-upload --intune-group <group-id> --intune-intent required

The agent reports progress as it goes — creating the app, uploading the package in chunks, waiting for Intune to finish processing it — and finishes with a link to the app in the Intune admin center. That link is also included in the status this run reports back to https://storepackager.download, so it shows up in the package's History without any extra steps.

For storepkg run, uploads only happen when you explicitly opt in with --intune-auto-upload — having a stored sign-in is not by itself enough, since run is meant for unattended use and an upload to your live tenant is not something to trigger implicitly. If a later step fails after the app was already created in Intune, the error message includes the app id so you can find and remove it by hand.

Offline and air-gapped environments

"Offline" covers two genuinely different situations, and which one you're in decides which command to use.

Scenario A — restricted network, but Microsoft is reachable

The target network can reach Microsoft's catalog and delivery endpoints, but company policy keeps it from calling any third-party SaaS — including StorePackager Cloud itself.

1. On a connected machine, resolve the package and download its manifest from the package detail page (Download manifest), or via the API:

   curl -H "Authorization: Bearer spk_..." \
     https://storepackager.download/api/manifest/<job-id> -o package.manifest.json

2. Copy the manifest file onto the restricted machine through your normal internal transfer process.
3. Build it there — the agent verifies the signature, then downloads the package bytes directly from Microsoft. No call to StorePackager Cloud happens at any point in this command:

   storepkg build --manifest package.manifest.json --intunewin

Scenario B — fully air-gapped, no internet at all

Nothing inside a genuine air gap can reach Microsoft either, so the download happens on a staging machine and the finished folder crosses the gap, not just the manifest.

1. Build completely on an internet-connected staging machine:

   storepkg pull 9WZDNCRFHVN5 --arch x64 --zip

2. Verify it's complete before it travels:

   storepkg verify C:\ProgramData\StorePackager\Packages\...

3. Transfer the ZIP or folder through your approved process — removable media, a transfer diode, etc.
4. Inside the isolated network, run storepkg verify again as a final integrity check, then run New-CmApplication.ps1 or import into Intune exactly as in a connected deployment. No agent, cloud, or Microsoft access is needed at this stage.

Both scenarios keep the same guarantee: nothing that reaches the isolated network came from anywhere other than Microsoft's own signed delivery infrastructure, and the hash and manifest checks mean a corrupted or tampered transfer is detected rather than silently deployed.

Signature verification, explained

Every manifest is signed with an HMAC key unique to your organisation. login fetches that key once and stores it locally; build checks the signature before touching the network and rejects the file outright if it's been modified. That matters most in Scenario A above: the machine building the package can't ask https://storepackager.download "is this really yours?" because it can't reach that URL at all — the signature answers that question instead. To check a manifest on a machine that was never logged in, pass the key explicitly:

storepkg build --manifest package.manifest.json --key <organisation-manifest-key>

The key itself is never displayed in the web app; it only ever travels to an agent during login, over the same authenticated connection as the login token.

Troubleshooting

FAQ