I’m trying to remotely delete all the unwanted apps from Win10 with Powershell, but for some reason the script cannot find the actual apps when it’s running though BigFix task. I’m using the Remove-AppxPackage cmdlet.
Running the ps1 script locally deletes everything as intended. I have tried the script with x86 and x64 powershells.
Remove-AppxPackage : Deployment failed with HRESULT: 0x80073CF1, Package was not found.
Windows cannot remove Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed.
NOTE: For additional information, look for [ActivityId] a6686281-aac1-0001-7178-68a6c1aad101 in the Event Log or use the command line Get-AppxLog -ActivityID a6686281-aac1-0001-7178-68a6c1aad101
I have checked with powershell that all the apps are indeed installed. For some reason the powershell does not detect them during script running. Any ideas?
Since it works locally but not via BigFix, the first thing I would suggest testing is if it works locally using the System account. I assume when you are running locally you are using some other admin account.
Can you run the script using the System account via psexec or something and see if that exhibits the same behavior?
Appx installs are often by user only so the system profile won’t know they exists
We do have a lot of inspectors for this type of stuff though as WinRT didn’t really survive as a name we might want to add an alias for this going forward.
Ok I tested the System account and several interesting things happened: First I did not see all the app tiles in the start menu. It looked exactly as the script had already been executed and the apps were already deleted. Then I started the script and it ran through smoothly. Powershell log showed no errors in app delete task. Then I logged in with the other account and the app tiles were still in the start menu (get-appxpackage still shows the apps installed on the account) so it seems that the system account cannot delete those apps.
Is there a workaround that lets me run bigfix task as other user? I assume it runs as a System account by default?
PowerShell has some built in credential stuff, but I haven’t really used it yet. When I have to run something in BigFix with certain credentials, I usually use psexec from the PsTools suite like so:
Depending on what your script does, you may also need to use the -h and -i arguments that psexec provides to get around Session 0 isolation. If you end up needing to specify the session id with the -i argument, you can get that by doing something like this:
parameter "SessionId" = "{minimum of session ids of (current users;logged on users) whose (not remote of it)}"
but it seems to always fail. I’m logged with domain admin on the target computer and that account has direct access to the folder in the network drive. I also tried to make a task with Bigfix wizard (directly imported the .ps1 to the task) but that also seems to fail no matter what I do (the script itself can be found in the __Download folder but cannot run).
Let’s stick with the first method you are using to run the script, since you have confirmed that at least that runs the script. I think the next thing I would do is verify the script is indeed running as the user you think it is running as. In your powershell script can you add something to check the user? Like
But if you are logged in as that domain admin and running the script with “runas=currentuser”, I would think that whoami should show the domain user instead of the System account. You put whoami in your PowerShell script, correct? Not in the BigFix actionscript.
Well the problem now is that the powershell script will fail if I add:
override wait
runas=currentuser
in the beginning of bigfix task. I managed to see from the cmd/powershell window that appear on the computer (if I’m not using the hidden -command) that the user in fact is domain user now, but every command seems to fail.
The problem with that approach is if no user is logged the action will fail.
Sometime ago I used AutoIt tool to create a program with embedded credentials, the problem is that we MUST have standard credentials on every endpoint. But if the machines are in active directory it could be easier.
Thanks for the help everyone. I realized it might be easier to run this with task sequence when the Windows image is installing. For some reason all the commands for current user stuff seems to behave funky in our environment.
I’m hoping to make it easier to create content to deal with the windows store apps to remove them from the current user and to remove them from the system so new users don’t get them.
There are 3 different locations to remove these modern windows apps. One is in staging that every new user that logs in gets. These can be removed from the SYSTEM account. The other is in the windows image with DISM, these can also be removed from the SYSTEM account. The other location is the current user’s currently installed apps. These cannot be removed using the SYSTEM account and must be removed as the current user unless it is possible to get around this using absolute paths or some other trickery that I have not been able to determine.
A policy action to remove it from current users will do so to all users eventually and clean up those that have the apps, but it is just as important to remove it from the other locations so new users don’t get them in the first place.
It definitely makes sense to remove these with an MDT task sequence but it certainly isn’t required. Anything that can be done with MDT should be possible with BigFix and vis versa. I prefer the flexibility that BigFix offers, but there are definite advantages to doing something before the first user logs on. (which BigFix can also do)