Windows Fails to Remove a Provisioned Application Using PowerShell

Question

Windows Fails to Remove a Provisioned Application Using PowerShell

George Wilson 80

I am experiencing an issue where Windows fails to remove a provisioned application from the operating system image using PowerShell. Although the application appears in the list of provisioned packages, attempts to remove it using Remove-AppxProvisionedPackage are unsuccessful or return an error. The issue persists even when PowerShell is run with administrator privileges. It is unclear whether the failure is caused by package dependencies, application provisioning restrictions, corrupted system components, or inconsistencies within the Windows image. How can I systematically investigate this issue by examining the provisioned package configuration, reviewing DISM and AppX deployment logs, checking package dependencies and servicing errors, and determining whether the application can be safely removed without affecting existing user profiles, system stability or future Windows updates?

0 comments

2 answers

Your answer

Answer 1

Hi Wilson,

Welcome to Microsoft Q&A and thank you for providing the details of the issue.

I understand that you're unable to remove the provisioned application using Remove-AppxProvisionedPackage, even when running PowerShell with administrator privileges.

To identify the root cause, I recommend carrying out the following checks:

Verify the package configuration: Run Get-AppxProvisionedPackage -Online to confirm the exact package name and provisioning status.
Check existing user registrations: Use Get-AppxPackage -AllUsers to determine whether the application is registered to existing user profiles.
Review deployment and servicing logs: Examine the AppX Deployment logs in Event Viewer, along with C:\Windows\Logs\DISM\dism.log and C:\Windows\Logs\CBS\CBS.log, for relevant errors or HRESULT codes.
Check dependencies and system health: Verify whether the application is a dependency of other packages and assess Windows image integrity using DISM and SFC.
Validate the removal approach: Confirm that the package can be safely removed without affecting existing user profiles, system functionality or future servicing operations.

For additional guidance, please refer to the following Microsoft documentation:

If you find this information helpful, please click Accept Answer. This helps other

community members identify useful solutions to similar issues.

Thank you for choosing Microsoft Q&A.

Answer 2

Use this sequence to isolate whether the problem is provisioning-only, user-registration, or image state.

Confirm what is actually provisioned
- List provisioned packages:
```
     Get-AppxProvisionedPackage -Online | Format-Table DisplayName, PackageName
```
- If the package is present there, it is provisioned in the image.
- Remove-AppxProvisionedPackage removes the package from the Windows image so it is not installed for new user accounts. It does not remove the app from existing user accounts.
Check whether the app is already registered for users
- List installed packages for all users:
```
     Get-AppxPackage <Application Name> -AllUsers
```
- This matters because /Remove-ProvisionedAppxPackage only removes provisioning if the package is registered to any user profile. To fully remove it from the image, remove the app for each user where it is already registered.
- To remove the app for all existing users:
```
     Get-AppxPackage <Application Name> -AllUsers | Remove-AppxPackage -AllUsers
```
Retry removal of the provisioned package
- PowerShell:
```
     Remove-AppxProvisionedPackage -Online -PackageName <PackageName>
```
- DISM command-line equivalent:
```
     DISM.exe /Online /Remove-ProvisionedAppxPackage /PackageName:<PackageName>
```
- Expected result: the package no longer appears in Get-AppxProvisionedPackage -Online, and it will not be installed for new user accounts.
Distinguish online vs offline behavior
- Online removal affects provisioning for new users only. Existing users keep the app unless it is separately removed with Remove-AppxPackage.
- Offline removal against a mounted image uses:
```
     Remove-AppxProvisionedPackage -Path <MountedImagePath> -PackageName <PackageName>
```
- If working with an offline image, verify the package name against that mounted image before removal.
Check whether the package is safe to remove
- Some apps can be removed, but protected system components should not be forced off the device because that can destabilize Windows.
- If removal attempts return errors such as protected-component behavior, leave the app in place.
Investigate update and reprovisioning behavior
- On Windows 10 version 1703 or 1709, previously removed first-party provisioned apps can return after a feature update if the device was offline when the apps were deprovisioned.
- This issue is fixed in Windows 10 version 1803. For Windows 10 version 1709, applying the latest security update fixes the registry-key creation issue.
- This behavior applies to first-party apps that shipped with Windows 10, not third-party apps, Microsoft Store apps, or LOB apps.
- If the app was removed while Windows was online, the signed-in user can still retain the app even though new users do not receive it.
If the package still fails to remove, determine whether the issue is user-profile state
- A common failure condition is: package installed for a user but not provisioned for all users.
- In image-capture scenarios, the documented resolution is to remove the package for the current user:
```
     Remove-AppxPackage -Package <package name>
```
- If multiple user profiles contain older or lingering versions, identify them with:
```
     Get-AppxPackage <Application Name> -AllUsers
```
What can be concluded from the supported behavior
- If the package is provisioned, Remove-AppxProvisionedPackage only stops installation for new users.
- If the package is still installed for existing users, remove it separately with Remove-AppxPackage.
- If the package is protected, it should not be forcibly removed.
- If removed apps return after a feature update, check whether the device was offline during deprovisioning and whether the OS version is affected by the known Windows 10 1703/1709 issue.

The provided material does not include specific DISM log paths, AppX deployment log locations, or a dependency-analysis procedure beyond checking whether the package is provisioned and whether it is registered for users.