-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.

Current detection method for MSIX native Deployment Type only allows us to check version equals to 1.x.y.z.

If that application is set to auto install updates afterwards the software center application status turns to failed. I experienced this after deploying Microsoft Whiteboard application, when I deployed to my user base app deployment was successful for over 5000 machines and deployment success status was almost 99%. After 2 weeks users complained they see Failed status in Software Center next to Whiteboard application. After troubleshooting the issue I came to know whiteboard application was set to install automatic updates and the version now changed to a latest one than the one I deployed.

Usually to avoid this in my MSI deployment types I select version as 'Greater than or Equal to' instead of just 'Equal to'. If we could have similar dropdown option for MSIX native deployment types that would be great

Thanks

When a user clicks on an application in Software Center while it is available (or pre-deadline) then all dependent and superseded applications should ignore the user's maintenance window. The current behavior is that if a reboot is needed in the chain then the user has to click install again in Software Center. This could be handled by a deployment option so that the current default behavior isn't impacted.

Example:
User Clicks on App1
App1 has a dependency on App2
App2 requires reboot
When user clicks App1, App2 should install, then reboot, then App1 should complete installation and reboot if needed without another key press by the user or waiting for a maintenance window.

I use application dependencies a lot and in general this works well in my environment. Setting them up is currently a bit cumbersome because you need to create the dependency then add the applications/deployment types to the dependency. I find that there are some dependencies that I use very commonly (Visual C++ Redistributables, .NET) where I'm always setting up the same dependency for different apps.

Instead of manually having to do this for each application, it would be nice to save these dependencies somehow so they could easily be added from a saved list. Perhaps the console could remember recently created dependencies? Or maybe a new node could be created under Application Management (similar to Global Conditions) where pre-defined common dependencies could be created and easily selected from in the Deployment-type creation workflow?