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

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?

I worked with Radia for many years. Two things from Radia we miss are the ability to set priority and holding reboots until the end of all deployments. For priority, we could set a value of 1 to 99 on an application. Anytime there were multiple deployments to a device they would be performed in low to high number priority order for install and reverse for uninstall. Uninstalls would occur first. We could also set reboot=reallysuppress in any msiexec command line and set a flag on the application to reboot on install, uninstall, update, etc. Radia would then wait until all deployments were complete and trigger the reboot at the end of the processing. That way multiple reboots were avoided as much as possible.

The docs say that SMSTSWaitForSecondReboot variable does not apply to custom task sequences. That is true, unfortunately.
A few customers use custom tasksequences to update application bundles and the variable could help here.
The problem: Software Updates (Cumulative W10 etc) have been installed during the day, reboot is pending until next maintenance window. Maintenance window opens at night and starts task sequence for application updates. Task sequence has a reboot step or app install forces a cm hard reboot by exit code 1641. Now when the system reboots, the task sequence may fail on startup because of a second reboot caused by update installation.
We actually see that problem with January updates causing four reboots on startup, two with about five minutes inbetween.
Current workarounds are
a) to either schedule a reboot (scheduled task) before the large maintenance window starts to finish update installation, or
b) split the maintenance window in a small one that fits for reboot and a larger that can run the TS.
I'd believe the variable could be more fail safe.

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