Detect Failed Microsoft Store App Deployments · CloudEngineerHub
Detection & Remediation8 min read4 views
Detecting Failed Microsoft Store App Deployments with PowerShell
Check Appx package status for your required store apps, scan the AppXDeployment-Server event log for errors, and verify Store services - all detection-only.
C
CloudEngineerHub Team
Published: September 9, 2026· Last Updated: September 28, 2026·8 min read
Store apps fail quietly in a way Win32 apps do not. There is no AgentExecutor process to inspect and no IME exit code to read; the deployment runs through the AppX deployment stack and the Store services, and when something breaks there, the device simply never gets the app while the admin center keeps showing whatever state was last reported. Because several Intune deployment types ride on that stack - Store apps (new), line-of-business Appx, and app packages synced from the Store for Business era - a device with a broken Appx pipeline can fail in ways that look like app-specific problems but are really infrastructure.
Visual Walkthrough
The engine behind every “Detect with PowerShell” runbook on this site.
Exit 1 flips the device into the remediation queue for this package.
remediate
3
Remediation executes
Fix script runs silently as SYSTEM with a 5-minute budget.
verify
4
Re-run detection
The same detection script must now exit 0 — proof, not hope.
telemetry
5
Results report
Per-device outcome lands in Reports → Remediations for trend analysis.
6
Repeat on schedule
The loop continues — drift gets caught the day it appears.
Continuous cycle
Proactive Remediations — The Detect → Fix → Verify Loop. 1. Detection script runs: Scheduled (daily/hourly): exit 0 healthy, exit 1 unhealthy — nothing more. — 2. Verdict: unhealthy: Exit 1 flips the device into the remediation queue for this package. — 3. Remediation executes: Fix script runs silently as SYSTEM with a 5-minute budget. — 4. Re-run detection: The same detection script must now exit 0 — proof, not hope. — 5. Results report: Per-device outcome lands in Reports → Remediations for trend analysis. — 6. Repeat on schedule: The loop continues — drift gets caught the day it appears.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
This post ships a detection-only script that checks the three things a broken Store deployment touches: the presence and status of the Appx packages you actually care about, the error stream of the AppX deployment machinery itself, and the configuration of the services that stack depends on. Detection-only is a deliberate choice here. The Appx stack has its own repair mechanisms (re-registration, reset, servicing), and reaching into it blindly from a remediation script risks damaging per-user app state that users notice immediately. The script reports; your runbook decides.
Symptoms
Store app deployment problems show up as a mix of portal and device-side signals:
A Store app assigned as required never appears on the device, and the app's device status stays on an older state or reports an error without a meaningful description.
Get-AppxPackage in a console on the device finds nothing for a package name that should be present for every user.
Event Viewer's Microsoft-Windows-AppXDeploymentServer/Operational log shows error-level events around the time deployments were attempted.
Company Portal reports store apps as "pending" or fails silently on specific devices only.
The Microsoft Store app itself cannot install or update anything, even manually, which points away from Intune entirely.
That last one is a useful fork in the road: if manual Store installs fail too, the problem is local; if they succeed, suspect the Intune assignment or licensing side.
Possible Causes
The package is not provisioned or not licensed
Store apps depend on licensing. A device that cannot reach licensing endpoints, or an app without the right license association, fails deployment even though the package content is fine.
Appx package corruption
A package's payload can get damaged by disk issues or interrupted updates. The package is still listed but its status is no longer Ok, and launch or update attempts fail until the package is remediated.
Deployment stack errors
The AppX deployment server handles staging and registration. Permission problems, stale staging directories, or servicing faults produce error events in its operational channel and block further deployments.
Store services disabled by policy or tooling
Hardening baselines sometimes disable InstallService (Microsoft Store Install Service) or wsservice (Microsoft Store Service) to "turn off the Store". The side effect is that managed store app deployment stops working with it.
User-context registration gaps
Appx packages register per user. A broken user profile, a new user who has never registered provisioned packages, or profile sync conflicts can leave a package missing for one user while present for others.
Connectivity to Store endpoints
Devices behind proxies or filtered egress that block Store and licensing endpoints fail downloads in ways that look identical to configuration errors - check connectivity when failures cluster by network location.
Detection Script
The script below is read-only and finishes in a few seconds as SYSTEM in 64-bit Windows PowerShell. It takes the list of store apps you care about as a parameter (package name prefixes, matching how Get-AppxPackage accepts names), scans the Microsoft-Windows-AppXDeploymentServer/Operational event channel for error-level events in a lookback window, and checks whether the Store services are disabled. It changes nothing.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
#Requires -RunAsAdministrator
[CmdletBinding()]
param(
[string[]] $RequiredStoreApps = @('Microsoft.WindowsStore', 'Microsoft.DesktopAppInstaller'),
[int] $EventLookbackHours = 24
)
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Detection script (detection-only): checks the health of a configured
list of Microsoft Store (Appx) packages, scans the AppX deployment
event log for recent errors, and verifies the configuration of the
Store services that app deployment depends on.
.NOTES
Intended for Intune Scripts and Remediations, 64-bit SYSTEM context.
This script NEVER changes the system and is detection-only.
Exit 0 = all checks pass,
1 = a package is missing or unhealthy, AppX deployment errors were
logged, or a Store service is Disabled,
2 = misconfiguration - the required package list is empty,
3 = unexpected error.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'StoreAppDetection.log'$eventLogName = 'Microsoft-Windows-AppXDeploymentServer/Operational'$storeServices = @('InstallService', 'wsservice')
function Write-DetectionLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
try {
Write-DetectionLog 'INFO''Store app deployment detection run started.'$issues = 0 # ---- Check 1: required Appx packages present and healthy ----if ($RequiredStoreApps.Count -eq0) {
Write-DetectionLog 'ERROR''RequiredStoreApps is empty - there is nothing to check. Configure the package name list before assigning this package.'
exit 2
}
foreach ($appNamein$RequiredStoreApps) {
$packages = @(Get-AppxPackage -Name ($appName + '*') -AllUsers -ErrorAction SilentlyContinue)
if ($packages.Count -eq0) {
Write-DetectionLog 'ERROR'"No Appx package matching '$appName' is installed for any user."$issues++
continue
}
$distinct = @($packages | Sort-Object -Property PackageFullName -Unique)
foreach ($packagein$distinct) {
if ($package.Status -ne'Ok') {
Write-DetectionLog 'ERROR'"Package $($package.PackageFullName) reports status '$($package.Status)' (expected 'Ok')."$issues++
}
else {
Write-DetectionLog 'INFO'"Package $($package.PackageFullName) is installed with status Ok."
}
}
}
# ---- Check 2: recent AppX deployment errors in the event log ----$channelAvailable = $truetry { $null = Get-WinEvent -ListLog$eventLogName -ErrorAction Stop }
catch { $channelAvailable = $false }
if ($channelAvailable) {
$since = (Get-Date).AddHours(-1 * $EventLookbackHours)
$appxQuery = @{
LogName = $eventLogName
Level = 2
StartTime = $since
}
$errorEvents = @(Get-WinEvent -FilterHashtable$appxQuery -ErrorAction SilentlyContinue)
Write-DetectionLog 'INFO'"AppXDeployment-Server errors in the last $EventLookbackHours hour(s): $($errorEvents.Count)."foreach ($evtin ($errorEvents | Select-Object -First5)) {
$message = $evt.Message
if ($null -eq$message) { $message = '(no message text available)' }
if ($message.Length -gt300) { $message = $message.Substring(0, 300) }
Write-DetectionLog 'WARN' ("AppX deployment error at {0}: {1}" -f$evt.TimeCreated, $message)
}
if ($errorEvents.Count -gt0) { $issues++ }
}
else {
Write-DetectionLog 'WARN'"Event channel '$eventLogName' is not available on this build - the event check was skipped."
}
# ---- Check 3: Store service configuration ----foreach ($serviceNamein$storeServices) {
$service = Get-Service -Name$serviceName -ErrorAction SilentlyContinue
if ($null -eq$service) {
Write-DetectionLog 'WARN'"Service '$serviceName' is not present on this build - not treated as a failure."continue
}
$startMode = (Get-CimInstance -ClassName Win32_Service -Filter"Name='$serviceName'").StartMode
Write-DetectionLog 'INFO'"Service '$serviceName': Status=$($service.Status) StartMode=$startMode."if ($startMode -eq'Disabled') {
Write-DetectionLog 'ERROR'"Service '$serviceName' is Disabled - Store app deployment cannot rely on it."$issues++
}
}
if ($issues -gt0) {
Write-DetectionLog 'ERROR'"Store app deployment health check found $issues issue(s)."
exit 1
}
Write-DetectionLog 'INFO''Store app deployment health looks good.'
exit 0
}
catch {
Write-DetectionLog 'ERROR'"Unexpected failure: $($_.Exception.Message)"
exit 3
}
finally {
Write-DetectionLog 'INFO''Store app deployment detection run ended.'
}
Detection Logic
Required package check. For each entry in RequiredStoreApps, the script runs Get-AppxPackage -AllUsers with a trailing wildcard. -AllUsers matters in SYSTEM context: without it you only see registrations visible to the calling context, not the per-user registrations your users experience. Zero matches is a failure - the app is simply not installed. Matches with a Status other than Ok are also failures; Ok is the Appx model's healthy value, and anything else means the package is flagged by the servicing stack.
Deployment event scan. The script first verifies the Microsoft-Windows-AppXDeploymentServer/Operational channel exists (some builds and configurations can have it disabled) and then queries error-level events - Level 2 - from the lookback window using a filter hashtable, which keeps the query server-side and fast. Error events are counted and the first few messages are logged, truncated, for your report. These events carry the real deployment failure text, which is exactly what the admin center rarely shows you.
Store service configuration.InstallService and wsservice are checked via Get-Service plus a Win32_Service CIM query for the start mode. A stopped service is not a failure - both are trigger-started services that the system starts on demand - but a Disabled start mode is configuration drift that breaks deployment and is treated as an issue. A service that is absent on a given build is logged as informational, not failed, because service presence varies across Windows versions.
Exit 1 fires when any required package is missing or unhealthy, when deployment error events exist in the window, or when a Store service is disabled. All three conditions are logged individually, so you always know which one tripped.
Remediation Approach
This is detection-only by design, and the reasoning is worth stating: the Appx stack stores per-user registration state that users interact with directly, and heavy-handed local "fixes" - force-removing packages, re-registering everything under every identity - cause more visible damage than the original fault. The repair belongs in a controlled process:
Triage by signal. Missing package: check the Intune assignment and the device's licensing/connectivity state. Unhealthy status: plan a package reset or re-registration for the affected user, executed interactively with the user's knowledge. Deployment events: read the event message first - it names the package and the failing stage, which usually identifies the fix on its own.
Respect the event log. The AppXDeployment-Server error text is the most honest diagnostic you have. Work from it rather than from generic repair recipes.
Fix services through policy, not scripts. If a hardening baseline disabled InstallService or wsservice, correct the baseline so the change is enforced and auditable, rather than flipping the service back locally where the next policy refresh will undo it.
Escalate with evidence. When the event channel and package status both look clean but the app still will not deploy, the failure is likely in assignment, licensing, or connectivity - gather the detection log output and open the case with that evidence attached.
Deploying Through Intune
Deploy the detection script alone:
In the Microsoft Intune admin center, navigate to Devices → Scripts and remediations and select + Add on the Windows 10/11 tab.
On Basics, name it Detect - Store app deployment health and describe it as read-only detection with no remediation script.
On the Detection script tab, upload detect.ps1. Set Run script in 64-bit PowerShell: Yes and Run this script using signed-on credentials: No - the checks are machine-scoped and -AllUsers requires the SYSTEM context to be meaningful.
On the Remediation script tab, select No remediation script.
On Schedule, choose Daily. Store app failures are worth seeing within a day; the read-only checks cost seconds.
On Assignments, start with a pilot ring of standard user devices. Because the script only reads, extending to all Windows devices afterwards is low risk. Leave Enforce script signature check: No unless you sign and distribute your own certificates.
Review and create. The Device status view becomes your store-app health report.
Post-specific notes:
Edit the RequiredStoreApps parameter before assigning: the defaults (Microsoft.WindowsStore, Microsoft.DesktopAppInstaller) prove the mechanics but your estate's real required store apps belong there.
The event lookback defaults to 24 hours to match a daily schedule. If you schedule weekly, raise EventLookbackHours accordingly or accept that only recent failures are visible.
Exit 2 never appears unless you assign the package with an empty package list - treat that as a configuration bug in the assignment, not a device problem.
Visual Walkthrough
Pick and validate the detection strategy before blaming the deployment.
Decision TreeApp Detection Rules — Which One Matches?5/5
Decision gate
What proves the app exists?
Detection is the contract between installer and Intune.
MSI product code
1
Read the MSI code
Copy the product code — the tooling never lies about MSI.
2
Rule: MSI-based
IME checks the installed-product table directly.
3
Exit 0 path
Code present → app detected → state "installed".
Custom rule
1
File / registry / script
Path+version, key+value, or PowerShell exit code 0.
2
Test the rule locally
Run the detection script as SYSTEM — context changes results.
3
Shape the installer
If detection can’t succeed, fix the installer, not the rule.
App Detection Rules — Which One Matches?. Gate: What proves the app exists? — MSI product code: Read the MSI code — MSI product code: Rule: MSI-based — MSI product code: Exit 0 path — Custom rule: File / registry / script — Custom rule: Test the rule locally — Custom rule: Shape the installer — Custom rule: Exit 0 path
Exit Codes
Intune treats any non-zero detection exit as "remediation needed"; with no remediation script, the code is a reporting signal only:
Code
Meaning
0
All required packages present with status Ok, no AppX deployment errors in the window, no Store service disabled
1
One or more of: package missing or unhealthy, deployment error events present, Store service Disabled
2
Misconfiguration - RequiredStoreApps is empty
3
Unexpected script error - inspect the log
Because several independent checks feed exit 1, always read the log lines to see which check fired before opening a ticket against the device.
Logging
The script appends to C:\ProgramData\Company\Logs\StoreAppDetection.log, creating the directory on first run. Lines carry a UTC timestamp, a level, and a message. Per run you get: one line per distinct package with its full name and status, the deployment error count for the window (with up to five error messages excerpted), and one line per Store service with status and start mode. The final summary line states the issue count. Growth is a handful of lines per run; monthly rotation fits any bounded-retention standard. When you need the full text of an AppX deployment error, open Applications and Services Logs\Microsoft\Windows\AppXDeploymentServer\Operational in Event Viewer on the device.
Troubleshooting the Script
Every device reports packages missing. Check that your package name prefixes match how Get-AppxPackage sees them - use the exact package name from Get-AppxPackage on a working device, not the Store product name.
Get-AppxPackage errors on older builds. The Appx module is built into Windows PowerShell on supported Windows 10/11 builds; a failure usually means a 32-bit session. Confirm the 64-bit setting on the package.
Event check always skips. The channel is missing or disabled on that build. The script logs this and continues; decide per your baseline whether an absent channel is itself a finding.
Deployment error events for apps you do not manage. The event scan is device-wide by nature. Read the package names in the logged messages - unrelated store apps can produce noise; shorten the lookback window if that noise dominates.
No log file appears. The script never ran. Verify assignment, device check-in, and that nothing (AMSI, tamper protection) blocked execution.
How to Validate the Fix
On a lab device, run the script in an elevated 64-bit console. Expect exit 0 (or 1 if the device genuinely has a store problem) and log lines naming each checked package.
Validate the missing-package path: add a package name that does not exist to RequiredStoreApps for a test run and expect exit 1 with the "No Appx package matching" error line.
Validate the service path: disable wsservice on the lab device (if present on your build), re-run, expect exit 1 with the Disabled finding, then restore the start mode.
Remove the bogus package entry and re-run. Expect exit 0 and a summary with zero issues.
In the admin center, confirm the Device status view reflects the lab device's final compliant state after sync.
Production Considerations
Execution context. SYSTEM in 64-bit Windows PowerShell. The script reads package registrations for all users, one event channel, and service configuration - nothing else.
Idempotency. Detection-only: it writes nothing to the device, so schedule frequency has no cost beyond a few seconds of reads.
Side effects. None on the device. The operational risk is misreading the report - which the per-check logging is designed to prevent, since every exit-1 run names the exact findings.
Security. No credentials, no secrets, no network calls; all data comes from local package and event APIs. Have your PowerShell automation SME and security team review the script and validate it on a pilot ring before broad rollout, consistent with how you treat any device script that reports on security-relevant configuration like disabled services.
Scope control. The package list parameter is your scope lever: checking only the apps your organization genuinely requires keeps the report signal high and the noise low.
Why is a stopped Store service not treated as a failure?InstallService and wsservice are on-demand services - Windows starts them when a deployment or Store operation needs them, and they stop again afterwards. A stopped state is normal. A Disabled start mode, however, prevents those on-demand starts from ever succeeding, so that is the condition the script flags.
Can the script also fix packages it finds unhealthy?
Not in this package, deliberately. Appx repair touches per-user state that users notice, and the right repair (reset, re-register, provisioning) depends on what the deployment events say went wrong. Automating that choice would automate the wrong answer regularly.
Does this cover apps deployed as Win32-wrapped Store packages?
No - Win32-wrapped content is handled by the Intune Management Extension and belongs to the failed-Win32-apps workflow. This script covers packages the Appx deployment stack delivers, including Store apps assigned through Intune's native Store app types.
Comments
0No comments yet — be the first to share your thoughts.