Option to use SYSTEM context for detection method for a user-based application deployment
The application detection method only runs in the user context if it is deployed to a user collection. This would be reasonable if the Deployment Type user experience were set to "Install for User" (User context), however the detection method runs in the user context when this is set to "Install for system" installation behavior (SYSTEM context).
Dan Sonnenburg
shared this idea
10 comments
-
Eddie Bumpus
commented
I've just discovered this problem with using Get-WindowsCapability for detecting RSAT installs. It doesn't work properly as I would have expected.
-
Pete Caforio
commented
Please fix this!
-
Andrew Bloom
commented
I have definitely had some strange results with this. A checkbox to allow the developer to control under which credentials the detection method is run would seem to be an easy fix!
-
Anonymous
commented
Further to this, if the apps are part of a dependency it gives some very counterintuitive results.
If App B has a dependency on App A, and App A has a powershell detection criteria that must be run with privilege (e.g. Get-WindowsOptionalFeature which can't be done as a user) then:
If you deploy app A to a user collection, it will fail with "software not applicable to this device"
if you deploy app A to a machine collection, it will work
If you deploy app B with the dependency of app A to a user collection, it will evaluate app A detection as the user and fail with "software not applicable to this device". This is true even if app A is already on the machine and correctly detected via a machine deployment.In this situation, you must also deploy app B to a machine collection.
-
Phil Brandvold
commented
This definitely needs to get fixed. I was extremely exited to use powershell scripting detection method, but I need to run Get-AppxPackage, which requires elevated permissions. The feature was *this close* to solving many problems for me (we use the Software Center to deploy quite a few Windows features and other settings with powershell scripts, and right now I'm having to create registry keys every time to mark that an installation has been made).
-
Matt
commented
This is still a very confusing limitation, as there's no indication of this behavior other than unexpected detection issues. It makes little sense to tie detection to the deployment target, rather than the "User experience" section in the application. If something installs per user, it should be detected per user regardless of how it's deployed. Same for something that is installed for system.
-
Anonymous
commented
Agreed on this. Perhaps someone in dev can explain why it's designed this way. Are we missing something or is this an underlying design flaw?
Our users roam. We have about 100 apps present in Software Centre. Our deployment method is "deploy to system" but we target user collections. Ideally, our users login to a machine they haven't been at before, go into software center and view a list of installed applications to determine if there are any missing. Currently, they have to select "install" for any they want to work with which is a waste of time if it's already installed.
-
Qasim Mashwani
commented
This was "NOTED" two years ago. Any updates? Is User Voice as popularity contest or is it about improving the product to address fundamental design and usage issues for customers? Is MSFT adopting a new "pet view" development strategy?
-
Martin commented
+1! A checkbox for this in the deployment type would be great.
-
Chris
commented
I had this problem too. Was unable to run the power shell cmdlet Get-AppxProvisionedPackage in the detection method because it did not have elevated permission. Really, the detection method should run as system regardless of if the application installs as user or system.