We see this also... on the upside it makes you look good even when failing!
19 votesAnonymous shared this idea ·
I would be happen with a modern app (appx etc) or some other method to self update without admin rights.
I would like to add... Please show update download progress as well.
We have some users that get a new computer and immediately attempt to install software from the catalog. At times this can be very slow, even resulting in odd requirement type errors.
What we generally find is the device is downloading updates and the updates do not show in the software center until the download is complete and updates are then enumerated.
So showing the update downloads will at least show people something is happening (though allowing apps to take priority would be nice).
I would love this as well... Our techs do all sorts of odd things from multiple restarts to clicking each one 3 times simply because they do not know what is going on when to expect results etc.
I agree with the OP, there are a LOT of apps that don't use what most would consider a true dependency like c++, .Net etc.
Instead they have other 3rd party apps etc, it isn't uncommon these are all separate installs.
You can script installation of these multi-parts but you lose built-in error reporting, version control, reuse of the dependency etc. We have numerous apps with 10 deps like this.
SCCM already tracks multiple App, dependency so you can't uninstall an application that is a dependency of another. Eric below mentioned an example where an app can't uninstall because a dependency is set on itself.
Good news is the multiple dependency hurdle mentioned by Mike could already be taken care of. :)
I would think a check box next to "auto-install" to allow uninstallation would be a fairly easy way to control if a dep is uninstalled with the app or not (only if another app doesn't need it).
There are some custom reports out there to list dependencies and it is not a simple affair given they store that info in XML I believe (why, SQL???) and just the way Apps/Deployment Types work/organized.
I completely agree dependency management is a total pain to manage, very manual and automation complex (XML again).
1. App Relationships tab: AWESOME, but please give an option to exclude old revisions, retired apps etc A built in report?
2. App Relationships tab: Please allow to open objects and edit. I have to look at this list, then search and edit the apps separately because if I use the link in the tab its read only.
3. Ability to remove an app from all dependency groups.
4. Ability to ADD an app to all dependency groups of object it is superseding (auto install options etc).
Jason Sandys provides the first obvious solution below. We currently do this, we create "types" of deployment collections (available, required, etc) and then use include rules to populate with other collections, role, department, etc.
The annoyance with doing it like this is organizational data our customers request is more difficult to access.
With one deployment per one collection, you can look at a collection properties\deployment tab and know exactly what apps are deployed to it. This data is not there when you start nesting/including collections.
You can create custom reports/scripts to get around this, but imo I would think a lot of organizations would like to easily provide a list of apps that is deployed to any given department/group (like for Win10 app testing etc).
Someone mentioned PS to deploy the same app to multiple collections... That can work, then you have the opposite issue where you have individual group information but lack overall health of a deployment, you now have to collate multiple reports or go custom again.
Generally speaking for us, the need to have multiple deployments with unique settings is much less, compared to being able to deploy the SAME deployment settings to multiple groups.
PS I love the idea of being able to add app deployments to a collection from the collection object.
I really like this idea. Why package a server name into the application when you could use an easily editable CI to set the servername and change it at any time. This would also tie the 2 objects together making it easier to manage things on a per application basis. While its easy to retire an "application" you have to remember to check the CIs etc etc.