TL;DR: Managing .appx packages is tricky because they’re installed per user instead of machine-wide, which can make discovery and removal inconsistent across Windows profiles. PowerShell helps admins identify installed packages with Get-AppxPackage, search across all profiles with -AllUsers, scan devices through PDQ Inventory, create allowlists to protect required apps, and remove unwanted packages with Remove-AppxPackage, as long as scripts are tested carefully before production use.
You can manage .appx packages with PowerShell by using Get-AppxPackage to identify installed Microsoft Store apps and Remove-AppxPackage to uninstall them. Because .appx packages are installed per user, admins often need the -AllUsers parameter to find and remove packages across Windows profiles.
Why are .appx packages hard to manage?
APPX packages, otherwise known as Microsoft Store apps, Universal Windows Platform (UWP) apps, and MSIX apps, aren’t built like traditional machine-wide installers. Unlike most traditional MSI and EXE installers, .appx packages are per-user installs, which means that many of the installation files and registry entries are tied to the user profile that installed the application.
Per-user installs make it harder for admins to see every application installed on a Windows device.
When installation files and registries are tied to a specific user profile, knowing what software is installed on a device becomes more challenging. For example, the Start menu likely won’t list .appx packages installed under another user’s profile, which makes it difficult for administrators to identify all the software installed on a device. This can also pose a security risk, especially if there is unauthorized software installed on a user’s profile.
How to identify .appx packages with PowerShell
The easiest way to identify installed .appx packages is with the PowerShell cmdlet Get-AppxPackage. Run the following command to list .appx packages installed for the current Windows user profile:
Get-AppxPackageKeep in mind that if you don’t include any additional filters or parameters, this command returns a lot of results but does not include .appx packages installed on other users’ profiles.
Run PowerShell scripts on remote devices
Execute PowerShell scripts on managed devices from anywhere with PDQ Connect.
For example, I have a Windows 11 machine with the Roblox .appx package installed on it. If I run Get-AppxPackage -Name “*Roblox*” while logged into my administrator account, Roblox is not returned as a result.

But, if I log into the profile that installed Roblox and run the same command, I now get the result I’m looking for.

How to identify .appx packages for all users
To look for .appx packages installed under all user profiles, use the -AllUsers parameter with the Get-AppxPackage cmdlet. The -AllUsers parameter searches for .appx packages installed under all user profiles. Make sure to launch PowerShell as an administrator any time you intend to use the -AllUsers parameter or the command will fail.
To show the -AllUsers parameter in action, I’ll search for the same Roblox package as before using the account that doesn’t have it installed. However, because I’m using the -AllUsers parameter, the package information should be returned.

Another benefit of using the -AllUsers parameter is that that the command returns which profile the .appx package is installed under.
How to scan for .appx packages with a PDQ PowerShell Scanner
You can scan for .appx packages across managed devices by creating a PowerShell Scanner in PDQ. This scanner uses Get-AppxPackage -AllUsers and filters for packages where NonRemovable is set to $false.
How to create an .appx PowerShell Scanner in PDQ Connect
1. In PDQ Connect, click Scanners > Create scanner.

2. Name the scanner, and select PowerShell from the Type drop-down menu.
3. Under Input script, add this:
$apps = Get-AppxPackage -AllUsers | Where-Object { $_.NonRemovable -eq $false }
ForEach ($app in $apps){
[PSCustomObject]@{
Name = $app.Name
Location = $app.InstallLocation
}
}
4. Select a test device and run the script to validate it, then click Save. In the Scanners tab, ensure your new scanner is enabled.
Now you're ready to run the script against other devices in your fleet.
1. Go to Devices, and select the devices or groups you want to scan. Then, go to the Actions drop-down menu and select Scan.

2. Once the scan is complete, you can access the data by going to Devices and selecting a device.
3. Under Additional data, scroll down to PowerShell, and select the scanner name.

4. Enjoy the sweet, sweet insights.

How to create an .appx PowerShell Scanner in PDQ Inventory
In PDQ Inventory, click Scan Profiles.
In the Scan Profiles window, click New.
Name the scan profile, then click Add, then click PowerShell.

Add a scanner name, then select the Script radial button.
Add this PowerShell script to the script pane:
$apps = Get-AppxPackage -AllUsers | Where-Object { $_.NonRemovable -eq $false } ForEach ($app in $apps){ [PSCustomObject]@{ Name = $app.Name Location = $app.InstallLocation } }Click OK to save the scanner, then click OK to save the scan profile.

With the scan profile created, you’re ready to run it against your devices and view the results. Here’s how.
Right-click All Computers, then click Scan Collection > (Your scanner name).

Once the scan finishes, double-click on a device to open the device details window.
In the left menu, click PowerShell.
Select your PowerShell Scanner from the PowerShell Scanner drop-down menu.

With your computers scanned, you can easily see what .appx packages are installed on your devices. When you’re ready, you can take that information and create dynamic collections and reports based on the scanner results.
How to create an .appx allowlist in PowerShell
Often, the reason you are trying to find installed Microsoft Store apps (.appx packages) is so you can uninstall them. And I am completely on board with this train of thought. However, as Microsoft transitions more necessary applications to .appx packages, it’s important not to accidentally uninstall something important. That’s where an allowlist comes in.
To create an allowlist in PowerShell, make an array listing all the .appx package names you want to keep. Keep in mind that this list is only an example and not an exhaustive list. Please verify your installed packages and which you want added to your allowlist.
$AllowList = @(
'*WindowsCalculator*',
'*Office.OneNote*',
'*Microsoft.net*',
'*MicrosoftEdge*',
'*WindowsStore*',
'*WindowsTerminal*',
'*WindowsNotepad*',
'*Paint*'
)Now that we have our allowlist, we can create a script that removes unwanted .appx packages.
How to remove .appx packages with PowerShell
Removing .appx packages can be tricky because they are tied to user profiles and may include apps Windows depends on. Run PowerShell as an administrator, verify your allowlist first, and use Remove-AppxPackage with the -AllUsers parameter to remove most unwanted .appx packages.
Here’s an example PowerShell command to uninstall an .appx package for all users.
Get-AppxPackage -AllUsers -Name “*Roblox*” | Remove-AppxPackage -AllUsers
In the image above, you can see that I ran the command to uninstall Roblox (sorry kids). After the command finished, I used Get-AppxPackage to search for the Roblox package and no results were returned, meaning the uninstall was successful.
If we want to take this a step further and remove most .appx package installations, we can use a combination of the allowlist we created earlier and the Remove-AppxPackage cmdlet. Again, this is an example and should be used with caution after thoroughly identifying apps you need to include in your allowlist.
#Get appx Packages
$Packages = Get-AppxPackage
#Create Your allowlist
$AllowList = @(
'*WindowsCalculator*',
'*Office.OneNote*',
'*Microsoft.net*',
'*MicrosoftEdge*',
'*WindowsStore*',
'*WindowsTerminal*',
'*WindowsNotepad*',
'*Paint*'
)
#Get All Dependencies
ForEach($Dependency in $AllowList){
(Get-AppxPackage -Name “$Dependency”).dependencies | ForEach-Object{
$NewAdd = "*" + $_.Name + "*"
if($_.name -ne $null -and $AllowList -notcontains $NewAdd){
$AllowList += $NewAdd
}
}
}
#View all applications not in your allowlist
ForEach($App in $Packages){
$Matched = $false
Foreach($Item in $AllowList){
If($App -like $Item){
$Matched = $true
break
}
}
#Nonremovable attribute does not exist before 1809, so if you are running this on an earlier build, remove “-and $app.NonRemovable -eq $false” rt; it attempts to remove everything
if($matched -eq $false -and $app.NonRemovable -eq $false){
Get-AppxPackage -AllUsers -Name $App.Name -PackageTypeFilter Bundle | Remove-AppxPackage -AllUsers
}
}
This script essentially iterates through all the returned .appx packages on a system, then compares the results to the applications in the allowlist. It skips the matched items in the allowlist and any .appx packages with the NonRemovable attribute set to true, then removes all other .appx packages.
Again, thoroughly test this script before running it against production machines.
FAQ about managing .appx packages
Why does Get-AppxPackage not show an installed app?
Get-AppxPackage only shows packages installed for the current user unless you include the -AllUsers parameter. If an app was installed under another Windows profile, run PowerShell as an administrator and use Get-AppxPackage -AllUsers.
How do I find .appx packages installed for another user?
Use Get-AppxPackage -AllUsers in an elevated PowerShell session. The command searches across user profiles and can return package user information that shows which profile has the app installed.
Can PDQ Connect scan for .appx packages?
Yes. PDQ Connect can scan for .appx packages with a PowerShell Scanner that runs Get-AppxPackage -AllUsers and returns structured results, such as package name and install location.
Should I remove all .appx packages from Windows devices?
No. Some .appx packages are required by Windows or other Microsoft apps. Build and test an allowlist before removing packages, and avoid uninstalling packages marked as nonremovable.
A closing .appx rant
The best way to manage .appx packages is to inventory them regularly, use an allowlist to protect required apps, and test removal scripts before deploying them broadly. Are .appx packages still more annoying than traditional installers? Absolutely. But at least PowerShell gives us a fighting chance.








