Allow customer icons in software center for Package/Programs
Split this item from a bigger umbrella item.
This is to specify an icon per legacy package/program in the Software Center.
Jason Gibson commented
Just one example: We have a troubleshooting script i wrote that needs the ability to run as often as the user (tech or help desk) needs, so it won't work with an application model unless we make it "fail" every time. That doesn't look very professional either. Would much prefer to just be able to assign an icon to a package the way we do to an application.
Zeb Smith commented
I agree with the other comments. Applications aren't going to work in 100% of use cases. They're obviously the best for software installs and upgrades, but there is always going to be value in the ability to simply run some command lines on a client on a schedule (or on demand by the user) without the need to process a detection rule.
As Martin mentioned, Applications are also limited in regards to content distribution compared to Packages.
Paul Wetter commented
A great example would be something from Software Center to allow end users to run to fix common issues on their PC. The "Easy button" as most would call it. Maybe you can do this now with an application with a "Repair" but, a on demand run anytime Package/Program fits the bill better. Or a Task Sequence. But, I can't give either of these an "Easy" button icon/image in Software Center.
David, I think the biggest reason people still use programs is for scripts that are difficult to provide a detection method for. Maybe this could be solved by allowing an application to optionally not use a detection method? Like a checkbox in the detection method tab that says "Use detection method for this application".
Brian Grinstead commented
Same issue for us, not everything works as an application and end user experience
Martin Lindberg commented
1. Sometimes I want the clients to run installation files directly from a network share, without having to download content to local cache. Application model doesn't support that.
2. I often use "PS App Deployment Toolkit" in conjunction with SCCM, that gives me a lot of benefits and a better experience for end users. Let's say I'm deploying a big sized CAD-program. I then use PSADT to force the user to shut down necessary programs, but I also give them opportunity to defer and postpone the installation, for example 3 times. Thanks to deploying the script as a package, I can schedule to run the deployment recurring every day at 8 am, and "rerun if failed previous attempt". With Application model I can not make a custom recurring schedule. With Application model, if a user defers the installation once, it will ask again the next time Software Deployment evaluation cycle is run. I know I can customize that value in client settings, but I want to do it on a per application basis.
These are some examples why I often need Packages.
Michael Morris commented
#2) Task Sequences
In some cases packages are needed. Of coarse I prefer applications, but that is not always possible or efficient. For example (big) content cannot be shared between deployment types, but can be shared between applications in a package. Programs in Software Center listed between applications with fancy icons looks very stupid to the end user.
Andrew Martin commented
Unfortunately, not all software lends itself to be installed as an application. Also, some user scripts we have don't actually get installed so setting a detection rule is impossible.
Martin / Chris - help me understand more what the gaps are between App Model, and Prog/Pkg model?
Martin Lindberg commented
I still need package model and it’s not a nice user experience when half of the software in SC has proper icons, and half om them doesn’t. End users don’t care for packages or applications, for them it’s just software.
Chris Martin commented
Not everything that is deployed fits application model.