Completely overhaul the application model to be a sequence of actions set within system or user context, rather than a single command.
I'll be upfront: being completely new to SCCM, the reason I propose this is I've been using Zenworks Configuration Management for the last 10 years. I'm not here to complain but rather to propose ideas that would improve the SCCM experience for system administrators and end-users alike.
For starters, right now what I am discovering is that Applications in SCCM only support one command for installation, and one for uninstallation. I suppose that if you are deploying a MSI and you can easily implement any customisation and user settings in the form of a MST file you are good to go. However, simple things such as adding a MSP file to your sequence is not allowed within this model. Furthermore, the truth is that not all products are MSI based and are that easy to configure, especially Setup.exe that you cannot edit.
What I am discovering is that most SCCM packagers will create a custom script that is either VBS, powershell or Auto-IT based and this is what is called within the "Installation" line in the Application. Then either a different script is called to unstall, or a parameter is handled to the same script to perform a different action.
What's worse is that since this script is usually run under the System context (lockdown users), you have to either implement Active Setup or have a special section in your script to find the user registry hive, load it, apply changes, then save and unload.
In order to simplify packaging and add more flexibility, I believe the application model should be split into different tabs (sections) as follow:
Once you have these 4 separate processes, that basically add these 4 actions to end-users through Software Center, the other important part is that we should not be limited to a single command for each of these.
Instead under each section we should be allowed to perform a sequence of action such as Install MSI, install MPS, copy files, run script, change registry keys, launch executable, kill process, delay, etc... Furthermore, for EACH of these action we should be allowed to run either as System, or as the Logged user.
Also there should be an option to have each application "Always install", "Install once per user" or "Install once per device".
Now if that is not enough, the cherry on top would be to add a requirement on each of these actions, kind of what we are able to do within a OSD task sequence (which by the way is FANTASTIC). But I'm not asking that much yet ;)
Then, truly, you could have 100% control over what happens and this would make SCCM a robust and modern platform for application deployement, control and launch.
Roth, Chase commented
I like all of what has been mentioned here. Additional functionality would definitely be appreciated.
C. Lessard commented
Commenting my own idea to throw an alternative. If it is too complex to choose system or user context for each action, then maybe we could at least separate the installation in 2 different sections as follow:
-Install (System) > each action in this section is performed under System context
-Install (User) > each action in this section is performed under User context
This allows for a bonus feature: to be able to install an application as part of a OSD task sequence by running only the System section. The User section would run only when the user first uses the application under his account (or would force-install if it's a mandatory installation).