This problem impacts on supersedence, which we don't trust to work if the 'previous' application version is not detected in the first place.
My vote too. This looks like an omission (bug) from when user-targeted deployments were brought across from the Application Catalog to the new tiles interface in Software Center, but the guts are still missing so that the user still has to select the app and run it before an existing installation is detected.
I vote + 1 (have run out of votes)
With our organisation moving towards branchcache, the issue becomes not only about the installing PC's cache, but also about consuming space on adjacent PCs' caches (which already consume much of those small SSD's). But we also lose our DPs. Getting difficult.
I have really tried - have application run a helper package to get its location (saved in a file) and use the source from there to install huge Application - but it turns out that WMI that has the programs is not accessible to SYSTEM account - so script fails to find the helper package. Lot of work to find out that the guts are just missing in SCCM client infrastructure.
We don't want to have to expand the cache size on our clients' small SSDs just to allow one or two unreasonably large packages to download before they install - costly in many ways. We have to use the package/program model for these applications that would otherwise work fine in the application model.
We can't use a single common share because our network is so widely distributed - we rely on SCCM distribution points replication to get the software close to the clients that will install it, and not willing to stand up alternative replication infrastructure that would only compete with it over our WAN.
At least could you let us distribute content as a Package to DPs, and give us a simple, reliable way to dynamically find the correct _local_ distribution point package contents with a script run on each client (eg powershell and/or WMI api), until a full solution can be implemented?
Having Application model able to install from distribution point share - would hit the mark so much better.
To avoid needing to close and re-open the console, I can move the folder to another folder, then back again and it then shows the right order.
But it locks up the console for a minute or so each folder move, out then back in, while it re-organises its internal guts.
others reporting the same problem:
Yes please! (commenting here because I'm out of votes. 10 votes are REALLY not enough.
Dependencies - issue with revisions - when I remove a dependency, the references in the depended-on application still shows the dependent application, but the link is to the last-1 revision. Disconcerting and unhelpful.
Turning off Application Revisions would take this problem away.
Maybe this: if I create a sub-folder, I have to wait for the subfolder to appear in the GUI (takes 5-10 seconds, not inutitive), then select the folder before creating a new item. Now I understand, it's awkward. Needs a bit of work, for example, pre-selecting new folder so new items can be created in it without the extra step of manually selecting it.
This is a BUG - just wanted to say that. As the existing operation effectively freezes up the user interface.
Run out of votes, but the slow 'edit membership' is a real problem for us too because our update group space has many automatic deployment rules being created all the time.
These suggestions (Deppentöter and Newman) would save us a lot of wasted time.
Eg if we have an office patch, we need to get 'required' instances where it only applies to windows 7 and not to the windows 8, 10 PCs. We need to know which machine /OS types a particular patch is 'required' on so we don't deploy unneeded patches to machines of a particular OS.
We need to separate patches required for Window 7 and windows 10. We need to differentiate updates that are only needed for our windows 7 based computers and only needed for our Windows 10 based computers. We want to do this through the search/filters in the Softare Updates list. Our server team is starting to use SCCM, like Bill, and needs also to filter updates by target OS. We will create different Software Update groups for each and need to put only the right updates in each group.
My vote +3 this week, but I've run out of votes. I really needed this, last week when deploying a suite of security applications, that needed a restart between phases of the installation. If there are multiple restarts, this feature would need to re-evaluate after every restart. When I tested using Application deployment as it stands now, the uninstall worked, then just sat there. We cannot leave systems insecure - that is unacceptable. We require the process to keep going until it's done. Deploying via Task sequence will lose Application management support.
We always use the feature for Software Updates, and would often use it for Application deployments.
This is terse. From the comments, can we assume we mean right-click on a device or device collection and select updates to exclude, from a list of deployed updates?
How would you track your exceptions down later when you want to clean up - will you be able to do it from the software update item?
934 votesstarted · Admindjam (Product Director, or Executive, Microsoft Endpoint Configuration Manager) responded
Check out the new uninstall behavior in 1804 tp.
Ah the good old AD software installation days.
But in SCCM, when an application is pushed to a user but installs in SYSTEM context, does it belong to the user or to the machine? If a corporate machine has a shared user history, we don't want a different user logging on to uninstall the software. We just want authorised users to be able to _run_ the software. We deal with this better with AppLocker and with App-V. We don't want a situation where software is installed, uninstalled, installed, uninstalled, installed ... as different people use the machine. We do, however, want to be able to pull all installations of the software when it is retired or superseded - even on machines where users are no longer using it and it would otherwise not be superseded by a user-pushed supersedent application.
If the targeting was to a device and the device falls out of scope in AD / out of the query collection, then we would likely want the software pulled off the device. (provided it was not due to an error in collection hierarchy where the members were temporarily dropped and re-instated - does happen in operation but not often).