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.

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.

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

It is not uncommon for us to use a SCCM application deployment to remove an application from our environment. The detection method can verify an executable is there but there is no reverse logic to detect it missing. If the uninstall is clean and there is nothing left over to detect we are forced to use a create a .log or .txt file with PowerShell for the detection method. While this provides basic functionality, it does not allow the deployment to detect when software is reinstalled so it can rerun and remove it again. If there was reverse logic to detect a missing executable or registry key this would reduce our need to reconfigure a version 2 and redeploy.

Instead of providing a GUI to specify the MSIEXEC command line for the MSI installer type, please provide a GUI that allows the desired check boxes, a path for a log (and drop down for log level), and a tab for PATCH to specify patches, and a PROPERTIES table to add properties to a list. It is misleading to even put "MSIEXEC" in the installer, if you remove it, it just breaks the install.

When importing a MSI file the default Deploment Type should include the /quiet /norestart switches on both the install/uninstall. It should also default the logs to /log c:\windows\ccm\logs\app"MSINAME"install.log and uninstall.log respectively. This helps provide a consistent logging practices.

I created a UV item for one component of this and supported others that involve some of these items but I think it makes sense to have one that encapsulates all items.

1. Be able to specify the number of Primary Devices that can be associated with users. Being allowed to have more than one device associated with a user makes the deployment of licensed apps more precarious.




2. Allow e-mails for Approval Requests and allow the flexibility for creating a workflow for multiple approvers.




3. Be allowed to do Approvals for the User and the Device. I'd love to be able to approve an Application for a User on a specific machine. Now if I approve it for a user, they can go to any machine and install the software. Again, this gets precarious with licensed applications.




4. If an Application has a requirement for the UDA relationship and the User has not specified a Primary Device, do not just have the Install fail instead give a message like "This application requires you to specify a Primary Device. To do so, please do the following."