Unexpected User Account Control (UAC) prompts during MSI repair operations recently caught many IT teams off guard. Standard (non-administrator) users who previously could launch certain applications without elevation suddenly began seeing permission prompts triggered by Windows Installer self-repair behavior.
Timeline and Technical Background
In August 2025, Windows security updates (notably KB5063875 and related builds on Windows 10 and 11) introduced a security improvement to address CVE-2025-50173, a privilege escalation vulnerability. This change strengthened MSI behavior by enforcing administrator elevation during certain repair and configuration actions. Microsoft later acknowledged the resulting UAC prompt behavior as a resolved issue in Windows 11 version 23H2 on the Windows Release Health dashboard.
As a result, non-admin users who previously could launch apps that trigger MSI self-repair without elevation began seeing UAC prompts unexpectedly.
Scenarios included:
- Running msiexec /fu or similar repair commands
- Launching apps that perform initial self-configuration
- Windows Installer invoked via Active Setup
- Deployments with user-specific “advertised” configurations via ConfigMgr
- Per-user components requiring MSI repair
(Examples include Autodesk AutoCAD and older Office installers.)
Technical Impact on MSI-Based Applications
This behavior has several implications for patch and deployment teams:
MSI Repackaging Risks
Advertised components and per-user logic in MSIs are typically used to support self-repair, shortcuts, or user customization. When Windows Installer detects missing key paths under user profile locations, it triggers a repair.
The stricter UAC requirements mean:
- Expected silent maintenance now prompts for elevation
- Standard users can no longer complete background MSI repair
- Silent installs might appear “broken” at first launch
- Legacy installers that rely on self-repair can surface errors like MSI Error 1730
This affects repackaged applications and transforms that end up introducing user-specific key paths or advertised features within per-user contexts.
PSADT and Per-User Resources
Even with modern scripting frameworks like PSAppDeployToolkit (PSADT), if MSI packages track per-user files or registry entries, Windows Installer may attempt a repair. Left unchecked, this can trigger UAC prompts with no admin credentials available to accept them.
Workarounds & Best Practices
Until environments receive updates that refine this behavior, the following approaches are recommended for patch management and application deployment:
Avoid MSI Self-Repair Triggers
- Remove advertised shortcuts from MSIs; create them via script instead
- Ensure user-profile files and HKCU registry entries are not key paths in MSI components
Use PSADT for User-Context Tasks
Instead of baking per-user resources into the MSI:
- Deploy machine-wide resources via MSI
- In PSADT routines run as user, copy files to per-user folders like %APPDATA% / %LOCALAPPDATA%
- Create shortcuts and user registry settings using PSADT functions
Example dynamic PSADT logic (in your Invoke-AppDeployToolkit.ps1):
PSADT v4 includes helper functions to work directly with user profiles.
Copy-ADTFileToUserProfiles -Path "$($adtSession.DirSupportFiles)\config.txt" -Destination "AppData\Roaming\MyApp"This copies a single file into existing user profiles without MSI tracking them as repair-critical components.
Repackage to Minimize Elevated Actions
- Convert fragile MSI custom actions into post-install script logic
- Avoid elevated custom actions unless absolutely necessary
- Test on standard user accounts to validate absence of repair triggers
Longer-Term Recommendations
As Windows updates refine MSI UAC behavior, the underlying issue is largely resolved. Nonetheless, modern deployment models benefit from:
- Separation of machine install and user customization
- Script-based per-user provisioning (PSADT, Intune Win32 post-install steps)
- Avoiding reliance on Windows Installer self-repair wherever possible
Operational recommendations
- Ensure latest Windows cumulative updates are installed
This specific UAC repair issue is now resolved according to Microsoft, but only on patched systems. - Test repackaged apps after Patch Tuesday
Especially apps that rely on first-launch configuration or Active Setup–style logic. - Avoid relying on MSI self-repair for user configuration
Use PSADT or post-install scripts instead. - Design for Intune and locked-down endpoints
Where users will never have admin rights and UAC prompts equal application failure.
Final Notes
While Microsoft has resolved the unexpected UAC behavior in current Windows builds, the incident highlights a long-standing risk in enterprise packaging: MSI self-repair and per-user components are fragile in locked-down environments.
By shifting user customization into PSADT and keeping MSIs focused on machine-level installation, organizations reduce:
- breakage after Windows updates,
- support overhead,
- and migration pain when moving from SCCM to Intune.
Even when the OS is fixed, good packaging design remains the best long-term mitigation. This approach guides day-to-day packaging work at Apptimized.
If you’d like your application management to stay stable and predictable as platforms evolve, feel free to get in touch or book a demo. We’ll be happy to discuss your scenario.
