-Problem overview
If you deploy the application under the following conditions, the running application will be killed immediately after the download phase.
The customer has set "Maintenance Windows", and the problem is that the application is killed at a timing outside the "Maintenance Windows" range.

This behavior is reproducible. (Confirmed with MECM 2002) I want to confirm whether this behavior is a by design or a known issue.

-Repro step
1. Set "Maintenance Windows" to the device collection. The next step is to set the installation deadline before entering "Maintenance Windows".

1. In the application's Deployment Type properties, on the Install Handling tab, specify the appropriate process.
   This time, notepad.exe is specified for reproducibility confirmation.




2. Deploy with the following settings.
   (repro-step3.jpg)




3. [Automatically close any running executables you specified on the install behavior tab of the deployment type properties dialog box]
   > Check this item.
   (repro-step4.jpg)




4. On the client side, run notepad.exe, run the evaluation cycle, and receive the new deployment.




5. notepad.exe is killed after the application content is downloaded to ccmcache.
   The application content itself has not been installed yet, so it has been killed immediately after the download is complete.

Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.
This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application, I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears based on the ‘Minimum duration before cached content can be removed’ client setting and there is no problem. However, there is one specific and prevalent use case where it is: stupidly large applications.
There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size on a day-to-day basis. Admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply should not be that for a system designed to deploy applications.
So, what to do? One option would be to simply not cache apps that exceed the limit and/or delete them immediately upon successfully detecting the app. Another option would be to do what Software Updates do: allow them to violate the cache limit. Maybe that becomes a deployment option: Allow deployment to violate cache limits. The only hard limit that should be allowed to break a deployment is the amount of free disk space to
TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

We have discovered an issue with the current grace period feature (and got this bug confirmed with a case) not enforcing the deployment after expiration (Software Updates & Application).

This results in multiple things:
- the selected duration of the grace period is irrelevant for the deployment enforcement
- as long as the client is only online during configured business hours an enforcement never occurs (so the documented "...reverts to normal behavior for overdue deployments." does not occur)

As a result an enforcement is not assured and renders this feature unusable if you have the requirement to enforce e.g. software update installation.

We would really love to see this feature working as expected (and documented) to "empower our users" without loosing control over security related updates.

Some of our customers work in the application model with available deployments. They would like to let the employees choose which application they want to install, but the update should be installed automatically if the user has already installed an application himself via the software center.

Let's assume that with the help of Supersedence we update Application with name "Av1.0" with a second Application named "Av1.1" via available deployment. Then the supersedence should recognize whether the product assigned with the help of the available deployments was installed on a client and if so, the update should take place automatically. if this is not the case, only the new version can be displayed in the software center (as the behavior is now)

Given a scenario of an application group which contains more than one application: if any application in that group requires a reboot the whole application group is terminated with an error (AppGroupHandler - InternalProcessAppRules failed with error 0x87d0032e) even though the application which demanded the reboot was installed correctly.

The expected behaviour is to perform the reboot and then continue with the next application in line in the application group after the reboot.

It would be beneficial if any reboot request in the application group process were internally remembered and only one reboot request would be sent to the user after the completetion of the whole application group.

It would be even better if any application in an application group could demand a reboot and the request would be sent to the user. After the user reboots the machine the application group should then continue with the next application in line.

When creating an applicaiton, we currently have the option to specify an uninstall ONLY when an install is already defined. It would be helpful to make an uninstall deployment without specifying any install content.

At the moment, yes this can be done by leaving uninstall blank and specifying the unintsall as the install. However this causes a LOT of confusion since the button in software center reads Install.
Alternativly, if we have the ability to just change what the text says for the install\uninstall buttons that would satisfy as well.

Currently when we need similar behavior we essentially have a blank command for the install which sometimes fails runing our reporting and complaince as this will not make the system level changes the detection method(s) are expecting

In other words. There is currently a check to make sure the installation program is populated. I am asking for some removal to allow an override to this check.

The expected behvaior for a client is to open software center and be able to click "Uninstall" and when that is done, the install becomes the greyed out, unselectable option.