Full Diagnostic Tree & Step-by-Step Overview
What type of detection rule logic is configured for the failing Win32 application in Microsoft Intune?
- A custom PowerShell script (.ps1) is used as the app detection rule.
- A standard File or Folder path detection rule is configured.
- A Registry key or value detection rule is configured.
- An MSI ProductCode GUID detection rule is configured.
What specific output or exit state does the custom PowerShell detection script return when executed manually?
- Script executes with exit code 0, but outputs nothing to STDOUT (e.g., no Write-Output string).
- Script fails due to 32-bit (SysWOW64) PowerShell execution context redirection or execution policy restrictions.
- Script checks a user-specific path (HKCU / %APPDATA%) while running in System Context (NT AUTHORITY\SYSTEM).
- Script completes after installer exits, but the installer ran asynchronously without waiting for background child processes.
Correcting Custom PowerShell Script Output Streams and Exit Codes
Solution:
Root Cause: Missing Standard Output (STDOUT) Stream Data
Microsoft Intune Management Extension (IME) evaluates custom PowerShell detection rules using a strict binary contract: to signal a successful app detection, the script
MUST exit with return code
0 AND write a non-empty string to standard output (
STDOUT). If a script terminates with
exit 0 but generates no console text output (for example, returning
$true as a boolean without
Write-Output), Intune interprets the result as 'Not Detected'. Because the installer binary returned code
0 (Success), Intune flags the deployment state as error
0x87D13B9A (*Application was not detected after installation completed successfully*).
# Diagnostic Verification:
Open the Intune Management Extension log located at: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
Search for the App GUID or [Win32App] string. Look for log lines stating: Detection script output: [] or
Script output is empty followed by
Detection result: False.
# Step-by-Step Fix:
Update PowerShell Detection Script Code:Ensure your script explicitly writes a string to STDOUT upon successful detection: powershell
$AppPath = "C:\Program Files\ExampleApp\app.exe"
if (Test-Path -Path $AppPath) {
Write-Output "Installed"
exit 0
} else {
exit 1
}
Test Script locally under SYSTEM Context:Download PsExec from Microsoft Sysinternals and run PowerShell as SYSTEM: psexec.exe -i -s powershell.exe
Execute the script and verify that STDOUT displays Installed and $LASTEXITCODE is 0.Update App Package in Intune Admin Center:Navigate to Microsoft Intune Admin Center > Apps > Windows > select your Win32 App > Properties > Detection rules.Re-upload the revised .ps1 script file and click Save.# Prevention & Long-Term Monitoring:
Always enforce Write-Output "Detected" alongside exit 0 in all enterprise Intune custom detection scripts.
Bypassing 32-bit (SysWOW64) Script Redirection and Execution Policies
Solution:
Root Cause: 32-bit Architecture Redirection and PowerShell Script Execution Block
By default, the Intune Management Extension (IME) agent operates as a 32-bit process (
IntuneManagementExtension.exe) on 64-bit Windows operating systems. When executing a custom PowerShell detection script without enabling the 64-bit option, Windows automatically redirects file system queries from
C:\Program Files to
C:\Program Files (x86) and registry queries to
HKLM\SOFTWARE\WOW6432Node. If the app installs natively as a 64-bit application, the detection script queries the redirected 32-bit location, fails to find the files, and returns undetectable state
0x87D13B9A.
# Diagnostic Verification:
Check IntuneManagementExtension.log for execution flags: Running detection script with 32-bit PowerShell
Inspect file system logs; the script searches C:\Program Files (x86)\Vendor\App.exe instead of C:\Program Files\Vendor\App.exe.# Step-by-Step Fix:
Enable 64-bit Script Execution in Intune:Open Intune Admin Center > Apps > Windows > select target Win32 App > Properties > Detection rules.Edit the Detection script settings.Toggle Run script as 32-bit process on 64-bit clients to No.Add Explicit Execution Policy Bypass inside Script Header (Optional Guardrail):Add the following header to force native 64-bit execution if spawned externally: powershell
if ($env:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
& "$env:WINDIR\SysNative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -File $MyInvocation.MyCommand.Path
exit $LASTEXITCODE
}
Save configuration and sync device in Intune.# Prevention & Long-Term Monitoring:
Default to Run script as 32-bit process = No for all modern 64-bit enterprise software packages.
Resolving SYSTEM Context Evaluation Conflicts in HKCU / User Profile Paths
Solution:
Root Cause: User Profile Context Mismatch (NT AUTHORITY\SYSTEM vs User Hive)
When a Win32 app's install context is set to
System, Intune executes the detection script under the
NT AUTHORITY\SYSTEM account. If the detection script checks user-specific locations—such as
%APPDATA%,
%LOCALAPPDATA%, or
HKCU\Software\Vendor—the script evaluates the
SYSTEM profile hive (
C:\Windows\System32\config\systemprofile\AppData\Local) rather than the logged-in user's profile. Consequently, the detection fails post-install, raising error
0x87D13B9A.
# Diagnostic Verification:
Inspect the detection script logic; it references $env:USERPROFILE or HKCU: while the Intune app install context is set to System.# Step-by-Step Fix:
Align Install Context with Detection Target:If the app installs per-user into %LOCALAPPDATA%, change the Intune App Install Context to User.Query All Active User Hives for System-Wide Apps:If the app must run as System but writes per-user shortcuts, modify the detection script to enumerate logged-in user hives in HKU:: powershell
$UserProfiles = Get-ChildItem -Path "Registry::HKEY_USERS" | Where-Object { $_.Name -notlike "*Classes" -and $_.Name -like "S-1-5-21*" }
foreach ($Profile in $UserProfiles) {
$Path = "Registry::$($Profile.Name)\Software\Vendor\AppName"
if (Test-Path -Path $Path) {
Write-Output "Detected in $($Profile.Name)"
exit 0
}
}
exit 1
Save detection rule and re-trigger sync.# Prevention & Long-Term Monitoring:
Never query HKCU or $env:APPDATA directly in detection scripts assigned to System install context.
Handling Asynchronous Child Installers with PowerShell Process Wait Handles
Solution:
Root Cause: Early Installer Process Exit (Asynchronous Execution)
Many legacy EXE wrappers (e.g., InstallShield, Inno Setup, or custom bootstrap orchestrators) spawn a secondary child installer process and terminate the primary process immediately with exit code
0. Intune sees the main installer exit and triggers post-install detection instantly—while the child process is still actively writing files or registry keys. Detection fails because the files are not yet present, triggering error
0x87D13B9A.
# Diagnostic Verification:
Inspect IntuneManagementExtension.log. The time difference between installer completion and detection evaluation is less than 2 seconds, but manual inspection 30 seconds later reveals the app installed correctly.# Step-by-Step Fix:
Wrap Application Installation Command:Modify the Intune Install command to use PowerShell's Start-Process with -Wait parameter: powershell
powershell.exe -ExecutionPolicy Bypass -Command "Start-Process -FilePath '.\setup.exe' -ArgumentList '/S' -Wait"
Implement Retries inside Custom Detection Script:Add a retry loop inside the detection script to allow asynchronous child installers up to 30 seconds to finalize disk writes: powershell
$TargetFile = "C:\Program Files\Vendor\App\app.exe"
$Retries = 6
while (-not (Test-Path $TargetFile) -and $Retries -gt 0) {
Start-Sleep -Seconds 5
$Retries--
}
if (Test-Path $TargetFile) {
Write-Output "Found"
exit 0
} else {
exit 1
}
Update Intune app configuration.# Prevention & Long-Term Monitoring:
Always test EXE installer switches using Start-Process -Wait to ensure execution threads do not return prematurely.
What specific file or folder attribute mismatch is causing the detection rule to fail?
- File version detection rule operator (e.g., 'Greater than or equal to') fails against a lower binary build number.
- File path contains environment variable expansion errors or hardcoded architecture path mismatches.
- Date modified/created file rule fails due to installer timestamp preservation or timezone offsets.
- 64-bit application file path redirected under Program Files (x86) due to Associated 32-bit app setting.
Verifying Binary File Version Operators and String Comparison Rules
Solution:
Root Cause: Semantic File Version Mismatch
When using a File detection rule checking String comparison (file version), Intune compares the target binary's FileVersion resource metadata attribute. If the vendor updates the binary file (e.g., installer lays down build 1.2.3.104 while the detection rule requires 1.2.4.0 or expects ProductVersion instead of FileVersion), Intune reports that the file was not detected, causing error 0x87D13B9A.
# Diagnostic Verification:
Right-click the installed executable (.exe or .dll) > Properties > Details tab.Check the exact File version value versus the value specified in Intune Admin Center.Alternatively, run in PowerShell: (Get-Item "C:\Program Files\Vendor\App\app.exe").VersionInfo.FileVersion
# Step-by-Step Fix:
Update Intune Detection Rule Values:Go to Intune Admin Center > Apps > Windows > select app > Properties > Detection rules.Edit File rule.Ensure Operator is set to Greater than or equal to.Enter the exact minimum file version string verified from binary properties.Fall Back to 'File or folder exists' Rule:If vendor version strings are inconsistent across patches, change Detection method to File or folder exists.Save and re-sync device policy.# Prevention & Long-Term Monitoring:
Prefer 'File or folder exists' alongside version-specific installer packages to reduce detection string errors.
Correcting Environment Variable Expansion Paths in File Detection Rules
Solution:
Root Cause: Unresolved or Invalid Environment Variable Expansion
Intune file detection rules support specific environment variable tokens (e.g., %ProgramFiles%, %ProgramData%, %SystemDrive%). If a path uses custom or unexpanded system variables (such as %ProgramFiles(x86)% inside a rule marked as 64-bit, or custom user variables like %USERPROFILE% in a System context deployment), Intune fails to resolve the path string and returns detection error 0x87D13B9A.
# Diagnostic Verification:
Inspect IntuneManagementExtension.log for file rule resolution events: File detection checking path: C:\Windows\system32\config\systemprofile\%CUSTOM_VAR%\app.exe
# Step-by-Step Fix:
Standardize Path Variables in Intune Admin Center:Use standard built-in Intune path tokens:%ProgramFiles% (resolves to C:\Program Files or redirected based on app bitness)%ProgramData% (resolves to C:\ProgramData)%SystemRoot% (resolves to C:\Windows)Avoid Hardcoding Drive Letters:Replace C:\Program Files\ with %ProgramFiles%\ to accommodate non-standard system drive configurations.Save changes and force client check-in.# Prevention & Long-Term Monitoring:
Utilize native Intune environment token dropdown choices rather than entering raw custom environment strings.
Resolving Date Modified and Timezone Offset Detection Failures
Solution:
Root Cause: UTC vs Local Timezone Timestamp Mismatch
Configuring a file detection rule based on Date modified or Date created requires an exact timestamp match. Many software installers preserve the original compilation timestamp of embedded binaries during extraction rather than assigning the current system time. Furthermore, Intune evaluates date rules against UTC timestamps; local client timezone offsets cause valid files to fail comparison tests, resulting in error 0x87D13B9A.
# Diagnostic Verification:
Query target file creation and modification timestamps in PowerShell: Get-Item "C:\Program Files\Vendor\App\app.exe" | Select-Object CreationTimeUtc, LastWriteTimeUtc
Compare UTC output against the date specified in the Intune rule.# Step-by-Step Fix:
Remove Timestamp Detection Criteria:In Intune Admin Center, edit the File detection rule.Switch to File Bitness / Version / Size Check:Change Property selection from Date modified to File or folder exists or Size (in MB).Save rule updates.# Prevention & Long-Term Monitoring:
Avoid using date-based detection rules in enterprise application deployments due to timezone and extraction timestamp variability.
Configuring 'Associated with a 32-bit app on 64-bit clients' File Path Flags
Solution:
Root Cause: Incorrect 32-bit File Path Context Selection
In Intune File detection rules, the toggle Associated with a 32-bit app on 64-bit clients controls WOW64 path redirection. If set to Yes, Intune automatically translates %ProgramFiles% to C:\Program Files (x86). If a 64-bit app installs into C:\Program Files but this toggle was set to Yes, Intune checks the x86 directory, fails to locate the binary, and reports error 0x87D13B9A.
# Diagnostic Verification:
Target file exists in C:\Program Files\Vendor\App.exe.IntuneManagementExtension.log shows IME searching in C:\Program Files (x86)\Vendor\App.exe.# Step-by-Step Fix:
Update Detection Rule Bitness Flag:Open Intune Admin Center > Apps > Windows > select app > Properties > Detection rules.Edit File detection rule.For 64-bit applications installed in %ProgramFiles%, set Associated with a 32-bit app on 64-bit clients to No.For 32-bit applications installed in %ProgramFiles(x86)%, set Associated with a 32-bit app on 64-bit clients to Yes.Save changes and sync client.# Prevention & Long-Term Monitoring:
Verify destination file directory architecture during package QA before finalizing Intune detection settings.
What registry path, value name, or WOW6432Node redirection conflict is failing?
- Registry key path resides under HKLM\SOFTWARE\WOW6432Node but detection rule checks standard HKLM\SOFTWARE.
- Registry value data comparison rule fails due to DWORD vs String format or leading/trailing space mismatches.
- Registry key exists under HKCU while the application is deployed under System Install Context.
- Uninstall registry key ProductCode GUID missing after silent EXE wrapper execution.
Managing Registry WOW6432Node Redirection and Bitness Toggles
Solution:
Root Cause: Registry Hive WOW6432Node Architecture Redirection
When a 32-bit installer executes on a 64-bit Windows OS, the Windows registry reflector intercepts writes to HKLM\SOFTWARE and redirects them to HKLM\SOFTWARE\WOW6432Node. In Intune, registry detection rules feature the toggle Associated with a 32-bit app on 64-bit clients. If this toggle is misconfigured (e.g., set to No for a 32-bit app), Intune checks native 64-bit registry space, misses the key inside WOW6432Node, and throws error 0x87D13B9A.
# Diagnostic Verification:
Open regedit.exe and locate the application registry key.Verify whether the key is in HKLM\SOFTWARE\Vendor or HKLM\SOFTWARE\WOW6432Node\Vendor.# Step-by-Step Fix:
Adjust Registry Rule Bitness Toggle in Intune:Go to Intune Admin Center > Apps > Windows > select app > Properties > Detection rules.Edit Registry detection rule.If key is in WOW6432Node, set Associated with a 32-bit app on 64-bit clients to Yes.If key is in native HKLM\SOFTWARE, set Associated with a 32-bit app on 64-bit clients to No.Remove explicit WOW6432Node from Path String:Do NOT type WOW6432Node explicitly into the Key path field. Type SOFTWARE\Vendor\App and rely on the bitness toggle to handle reflection.Save and re-sync client.# Prevention & Long-Term Monitoring:
Never include literal WOW6432Node strings in Intune registry path fields; control redirection via the bitness switch.
Matching Registry Value Data Types (DWORD vs String) and Version Formats
Solution:
Root Cause: Registry Value Type Mismatch or Unstripped Whitespace
Registry detection rules can evaluate Value comparison against specific data types (String, DWORD, Version, Integer). If the installer creates a REG_SZ (String) containing 1.0.0 but Intune is configured to check a REG_DWORD, or if the string value contains invisible trailing whitespace, data type validation fails. Intune concludes the app is absent, triggering error 0x87D13B9A.
# Diagnostic Verification:
In regedit.exe, check the target value name and look at the Type column (REG_SZ, REG_DWORD, REG_EXPAND_SZ).Run in PowerShell: (Get-ItemProperty -Path "HKLM:\SOFTWARE\Vendor\App").DisplayVersion.GetType().Name
# Step-by-Step Fix:
Configure Exact Value Type in Intune:Edit Intune Registry detection rule.Ensure Detection method matches the physical registry type:For REG_SZ version numbers, set Property to Version comparison or String comparison.For REG_DWORD flags, set Property to Integer comparison.Fall Back to 'Key exists' Detection:If registry value data changes dynamically, set Detection method to Key exists or Value exists without data validation.Save rule updates.# Prevention & Long-Term Monitoring:
Use 'Key exists' detection for registry checks unless version enforcement is mandatory.
Redirecting HKCU Registry Checks to HKLM for System-Context Deployments
Solution:
Root Cause: SYSTEM Context Inability to Access HKEY_CURRENT_USER
If an Intune Win32 app is deployed under System install context, the Intune agent evaluates registry detection rules against the system profile hive (HKEY_USERS\.DEFAULT or HKEY_USERS\S-1-5-18). A detection rule targeting HKEY_CURRENT_USER\Software\Vendor will fail because the logged-in user's HKCU hive is unmapped in the SYSTEM context during post-install inspection, producing error 0x87D13B9A.
# Diagnostic Verification:
Detection rule targets HKEY_CURRENT_USER\Software\... while Intune App Install Context is set to System.# Step-by-Step Fix:
Change Registry Rule Target to HKLM:Update the application installer parameters so it writes a system-wide flag to HKLM\SOFTWARE\Vendor\App upon completion.Point the Intune registry detection rule to KEY_LOCAL_MACHINE\SOFTWARE\Vendor\App.Switch App Install Context to User (If App is Per-User):If the app installs strictly inside user profiles, edit App Properties > Program > set Install context to User.Save and re-deploy.# Prevention & Long-Term Monitoring:
Never pair HKEY_CURRENT_USER registry detection rules with System install context configurations.
Extracting and Validating Custom EXE Uninstall Registry Strings
Solution:
Root Cause: Missing or Non-Standard Uninstall Key Generation
Many custom software installers wrapped inside silent EXE packages do not register standard Windows Installer GUIDs or create entries under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. If an administrator configures a Registry detection rule targeting a predicted Uninstall key that the installer fails to create, post-install detection returns false, causing error
0x87D13B9A.
# Diagnostic Verification:
Open regedit.exe and check both uninstall paths: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Search for the application display name. If no subkey exists, the installer did not create an uninstall registration.# Step-by-Step Fix:
Switch to File/Folder or Custom Script Detection:Change the Intune detection method to check for the primary installed executable path (%ProgramFiles%\Vendor\App\app.exe) instead of the uninstall registry key.Inject Custom Registry Key via Wrapper Script:If registry detection is required by enterprise policy, update your installation script (e.g., PSAppDeployToolkit) to write a custom registry marker upon exit: powershell
New-Item -Path "HKLM:\SOFTWARE\EnterpriseApps\AppName" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\EnterpriseApps\AppName" -Name "Installed" -Value 1 -PropertyType DWORD -Force
Target Intune detection to HKLM\SOFTWARE\EnterpriseApps\AppName.Save updates in Intune.# Prevention & Long-Term Monitoring:
Use PSAppDeployToolkit (PSADT) to standardize registry entry creation for non-MSI EXE installers.
What MSI ProductCode GUID or Windows Installer service error is blocking detection?
- MSI ProductCode GUID changed between major application patch versions.
- MSI Product version check operator fails due to small build/revision number differences.
- Windows Installer database (MSI) locked or rollback state prevented ProductCode registration.
- Intune Management Extension Global Requirement State (GRS) cache stuck on previous failure.
Updating MSI ProductCode GUIDs for Application Major Upgrades
Solution:
Root Cause: MSI ProductCode GUID Mutation
In the Windows Installer framework, major application upgrades frequently change the
{GUID} assigned to the
ProductCode property while keeping the
UpgradeCode constant. If an Intune Win32 package is updated with a new
.msi or
.intunewin payload but the detection rule still points to the old ProductCode
{GUID}, the installer succeeds but post-install detection checks for the legacy GUID. Intune reports error
0x87D13B9A.
# Diagnostic Verification:
Query active MSI ProductCodes on client machine using PowerShell: Get-CimInstance -ClassName Win32_Product | Where-Object { $_.Name -like "*AppName*" } | Select-Object Name, IdentifyingNumber, Version
*(Or inspect
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall)*.
Compare IdentifyingNumber against the ProductCode in Intune.# Step-by-Step Fix:
Extract Current MSI ProductCode:Open PowerShell and query the target .msi file directly: powershell
$com = New-Object -ComObject WindowsInstaller.Installer
$database = $com.GetType().InvokeMember("OpenDatabase", "InvokeMethod", $null, $com, @("C:\Path\To\installer.msi", 0))
$view = $database.GetType().InvokeMember("OpenView", "InvokeMethod", $null, $database, @("SELECT Value FROM Property WHERE Property='ProductCode'"))
$view.GetType().InvokeMember("Execute", "InvokeMethod", $null, $view, $null)
$record = $view.GetType().InvokeMember("Fetch", "InvokeMethod", $null, $view, $null)
$record.GetType().InvokeMember("StringData", "GetProperty", $null, $record, @(1))
Update Intune MSI Detection Rule:Edit Intune Win32 App > Detection rules.Replace the ProductCode string with the freshly extracted {GUID}.Save and force client policy sync.# Prevention & Long-Term Monitoring:
Re-verify ProductCode GUIDs every time a vendor releases a updated MSI build.
Configuring MSI Product Version Operators in Intune Detection Rules
Solution:
Root Cause: Strict MSI Product Version Comparison Rejection
When using an MSI detection rule in Intune, administrators can optionally check MSI product version check. If configured to Equals instead of Greater than or equal to, any minor patch laid down by a cumulative update or vendor hotfix will cause the version check to fail. The MSI ProductCode exists, but version mismatch triggers error 0x87D13B9A.
# Diagnostic Verification:
IntuneManagementExtension.log records: MSI ProductCode {GUID} found, but version X.X.X.X does not satisfy rule condition.
# Step-by-Step Fix:
Edit MSI Detection Rule in Intune:Go to Intune Admin Center > Apps > Windows > select app > Properties > Detection rules.Modify Version Operator:Set MSI product version check to Yes.Set Operator to Greater than or equal to.Enter the baseline minimum version number.*(Alternatively, set MSI product version check to No to rely solely on ProductCode GUID presence).* Save rule updates.# Prevention & Long-Term Monitoring:
Use Greater than or equal to for all MSI version check rules to prevent minor patch failures.
Repairing Windows Installer Database Locks and Rollback Failures
Solution:
Root Cause: Windows Installer (msiexec) Silent Rollback or Mutex Lock
If another installation process holds the Global\_MSIExecute mutex lock, or if an MSI installation encounters a non-fatal custom action error that triggers a silent rollback, msiexec.exe may exit with return code 0 or 3010 (Reboot Required) while rolling back system changes. Because files and ProductCode registry entries were removed during rollback, Intune's post-install detection fails with 0x87D13B9A.
# Diagnostic Verification:
Inspect Windows MSI installer logging in Event Viewer > Windows Logs > Application (Source: MsiInstaller).Look for Event ID 1033 (Removal/Rollback) or Event ID 1603 immediately following installation events.# Step-by-Step Fix:
Enable Verbose MSI Logging in Intune Install Command:Update Intune Install command to generate verbose logs: msiexec.exe /i "app.msi" /qn /L*V "%ProgramData%\Microsoft\IntuneManagementExtension\Logs\app_install.log"
Inspect app_install.log for Rollback Triggers:Search for Return value 3 to identify the failing custom action.Clear Pending Install Locks and Restart Windows Installer Service:Open PowerShell as Administrator: Stop-Service -Name "msiserver" -Force
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations" -ErrorAction SilentlyContinue
Start-Service -Name "msiserver"
Re-evaluate deployment in Intune.# Prevention & Long-Term Monitoring:
Always include verbose logging switches (/L*V) in enterprise MSI deployment commands.
Clearing Intune Management Extension Global Requirement State (GRS) Cache
Solution:
Root Cause: Intune GRS (Global Requirement State) Retry Back-Off Cache
When a Win32 app installation or detection fails initially, the Intune Management Extension (IME) writes a Global Requirement State (GRS) cache entry into the local registry. By default, Intune enforces a 24-hour back-off period before re-evaluating the same app on the client machine. Even if an administrator fixes the detection rule in the cloud, the local client reads the cached GRS failure state, skips detection evaluation, and continues reporting error
0x87D13B9A.
# Diagnostic Verification:
IntuneManagementExtension.log records: Grs cache present for app [AppGUID]. Enforcement evaluated to False. Skipping detection.
# Step-by-Step Fix:
Restart Intune Management Extension Service:Open PowerShell as Administrator and run: Restart-Service -Name "IntuneManagementExtension"
Purge Local GRS Registry Cache Keys:Run the following PowerShell commands to delete cached app evaluation results and force immediate re-detection: powershell oppose
$GRSKeys = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps"
Get-ChildItem -Path $GRSKeys | ForEach-Object {
Remove-Item -Path "$($_.PSPath)\GRS" -Recurse -Force -ErrorAction SilentlyContinue
}
Trigger Manual Sync from Client:Go to Settings > Accounts > Access work or school > select account > Info > click Sync.# Prevention & Long-Term Monitoring:
For detailed endpoint guidance, consult the Microsoft Official Support Guide.Purge GRS registry cache during testing to bypass 24-hour evaluation back-off timers.