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.
24 comments
-
Jon
commented
this would make things more professional
-
Denis.stpierre
commented
Either this OR:
-make Detection Method in SCCM Applications optional. (Preferred)
-create a second type of Deployment Type that does not require a Detection Method that just launches a program.This way, SCCM Packages and programs could be dropped from SCCM altogether and simplify things.
-
Juha Ahoniemi
commented
Please make this happen!
-
Denise Jacques
commented
Would be extremely useful, users identify applications by the icon.
-
Pär Wennergrund
commented
There must be an easy fix on this problem, Microsoft!
We must be able to have icons on all software which we distribute through SC. -
Jeph
commented
Experience dictates people look for the pretty picture before they read any text. When everything looks the same, they get lost.
-
chensheng
commented
Yes please.... Consistent look and feel for Applications, Packages and TaskSequence Icons.
-
Sven
commented
Yes please.... Consistent look and feel for Applications, Packages and TaskSequence Icons.
-
Jovo
commented
Icons on packages would give software center a much more professional look for the end user.
-
Michael
commented
Icons on packages would give software center a much more professional look for the end user.
-
Anonymous
commented
We need this too. 1 consistent look for the Software Center (Applications / TS / Packages, all with icons) would be very welkcome. It looks kind of strange now when you have a mix of applications and packages. Not very inviting for our users.
-
Luis Otávio De Oliveira LO commented
Pleaseeeeee, urgent Allow customer icons in software center for Package/Programs
-
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.
-
Chris
commented
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
#1) Packages
#2) Task Sequences -
Anonymous
commented
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.