Currently, when creating a Deployment Type for an Application, the "Installation program" field on the "Content" tab of the wizard is mandatory. However, there are scenarios when an installation program isn't needed. For example:

* An Application used for the sole purpose of uninstalling an application from endpoints. In this case, only the "Uninstall program" and detection method are needed
* An Application used for the sole purpose of detecting an existing application, to be used as a Supersedence condition when an application being deployed as Available should upgrade an application on an endpoint. In this case, only the detection method needs to be specified.

There is a workaround which works well enough, which is to specify a bogus command line in the "Installation program" field. However, this is inelegant. Moreover, if it were allowed to be blank, the CM console could block an admin from attempting to deploy the Application for installation.

Might seem like a silly thing, but a column added to Applications and Packages that will show the number of DPs that have the application or package on it.
Often times a high overview of how many DP's have the package can help determine if we need to distribute it to other DPs.

Case in point: When we build test applications, we tend to want to deploy the application to our local DP before we deploy it to the other DP's so we can ensure things work before distributing it.
Sometimes we need to browse through each application to see how many DP's have the application... if there was a column that we could set to show us a number, it would be a quick look.

Yes this is also a process issue, but can make a world of difference when scrolling through a long list of applications or packages.

When you are in the references tab of an application and you select 'Applications that depend on this application', it lists the applications and the referring deployment types. There are hyperlinks to take you to the applications and deployment types.

I expected to be able to click on these links and be able to modify the applications/deployment type. Instead the links open the objects in read-only mode.

I expected to be able to copy this table data to put it into excel. This functionality isn't here.

This makes the work flow more busy for replacing say a VC++ 2017 redistributable dependency with a VC++ 2019 redistributable dependency. I have to take multiple screen shots of the tab, since I have more items to modify than can fit in the visible window, close the properties, then find each application in the console, and open the deployment type and modify the dependency.

Adjustments to this workflow would be appreciated.

The ability to replace an application in all task sequences at one time.

(Scenario: I have many task sequences for multiple regions, and have the same application in all of them. Then an updated version of the application is released, and I'd like to update all of the task sequences with the updated version instead of doing it individually in each task sequence. I'm not ready to remove the old app from SCCM yet in case some of our techs need it. I usually keep the outdated app for 3 months before removing from SCCM.

****Plus a bonus would be to have the ability to "checkbox" multi-select which task sequences I'd like to perform the application swap.

**NOTE: I'm new(ish) to SCCM. So if the below request is something already offered and I'm overlooking it, please let me know.**

Think Microsoft needs to supply an Application Package that encompasses most; if not all, Microsoft owned products for easy integration into SCCM. For example, instead of me having to download PowerBI Desktop and creating a package in SCCM to deploy it to users computers and servers. The SCCM team should already have that application available in SCCM and I can either authorize it for deployment to certain collections based off a generic package/template you all create, or I get the option to modify the package to fit our organizational policies. I use PowerBI as an example, but this should encompass almost all your products.

Imagine already having application templates for your products already available in the SCCM Management console. An administrator could just easily make changes to packages for Visual Studio Code, or SQL Management Studio, etc...and within a few minutes, have it made available for installation on their respective collections.

A good reference for something like this is PDQ Inventory and PDQ Deploy.