Jul 04 2019 01:11 AM
Jul 04 2019 01:11 AM
My test scenario:
I have packaged two versions of Mozilla Firefox - 22.214.171.124 and 126.96.36.199 - they both have the same name so when I manually install 188.8.131.52 first and then double click the .msix file for version 184.108.40.206 it will update the current installation of Firefox into new version. That works correct.
Now I put these two packages into my SCCM lab 1902 and I set them as two individual applications. to keep is simple I named them Firefox1 and 2, see picture:
I deployed these two as Available into my test client's Software Center. Test client is a clean machine, so no previous versions of Firefox.
Scenario A: I install firefox1 from SW center - it gets installed successfully and I can run firefox from start menu and see that it is version 220.127.116.11 in help-about
Scenario B: I uninstall firefox1 and install firefox2 from SW center - it gets installed successfully and I can run firefox from start menu and see that it is version 18.104.22.168 in help-about
Up to this point everything works as I expect.
Scenario C: I install firefox1 from SW center to a clean machine, I run firefox and verify the version is 22.214.171.124, then I close it and install firefox2 from SW center. Here I thought what would happen is that when I run firefox it will be version 126.96.36.199 but it is not, it remains as 188.8.131.52. Even after machine reboot and reopening firefox.
Am I wrong to expect that firefox would be updated?
Scenario D: I skip SCCM and instead create .appinstaller file that points to firefox1. I install firefox by double clicking this appinstaller file and firefox installs and version is 184.108.40.206. Then after a while I edit appinstaller file and point it to firefox2. After I reboot the machine, wait a minute and run firefox from start menu, it runs and version is 220.127.116.11. Here happened exactly what I wanted from Scenario 3.
Am I doing something wrong with SCCM or why doesn't scenario C work? My hope is that I update firefox via SCCM and users will not lose their settings (which means I don't want to uninstall older and install newer, but just apply an update)
Thanks a lot for every reply.
Jul 04 2019 02:34 AM
In SCCM, I would use a different approach to the upgrade. I would add the new version as a new Deployment Type of the original application, and reorder them such that the new version is a higher priority (lower priority number). If everyone gets the upgrade, you can remove the old DT, although I'd tend to want to wait a while before the removal.
Jul 04 2019 05:03 AM
@Tim Mangan You are correct Tim, it worked with your approach, thanks!
I tested two scenarios here, first is that Firefox is not running when update is being deployed - then it worked fine and Firefox is updated.
Second scenario I tried is that Firefox is running during the update deployment - in that case deployment is successful, but Firefox is still displayed as older version when I re-open it (or reboot machine). Shouldn't it update the blocks in the background even when the app is running?
Jul 04 2019 06:12 AM
@michalkala123 And by the way, to your original issue. I think you can deploy the upgrade as a separate application, but you need to remember to also assign the original application to an uninstall job. While MSIX knows that packages are related, SCCM doesn't and likely wants to reinstall the original. But the DT method I think is easier and more straightforward.
Jul 04 2019 07:15 AM
@Tim Mangan "While MSIX knows that packages are related, SCCM doesn't"
Yes this is true. All I had to do is specifying a supersedence relationship between my two firefox packages (without forcing uninstall) and now when I deploy the second one, SCCM is aware that is it meant as upgrade and it works as I wanted. It also preserves user settings like homepage, which I am not sure it would do if I set the older application to uninstall.
I like the method of adding new deployment type, but I want to be able to first shoot out new package to couple testers on customer side for verification. If I would do it with the new DT method, SCCM would start distributing to all where it is deployed.
Regarding updating while the app is in use - I tried again (now with supersedence) and maybe I am just expecting it to be really quick, but I still see only the old version. I will do more extensive testing next week, because I also think it should work (it works when deploying via .appinstaller file solution)
Jul 11 2019 12:20 AM
I've done multiple new tests but I am not able to update MSIX application via SCCM deployment while the application itself is running on the client. If it is not running then everything works well. If it is running I never see new version applied (even when SCCM says it is success)
Does anyone know if this is possible to achieve with SCCM? I am looking for similar update behavior like with App Installer solution as described here: https://techcommunity.microsoft.com/t5/Windows-Dev-AppConsult/Handling-application-updates-with-App-...
Updates checks can be configured in two ways:
Jul 12 2019 03:54 AM - edited Jul 12 2019 04:45 AM
@michalkala123 In my testing, I found the following:
Locally installing, if I install the original version and leave it running, and then install the update version (with matching FamilyName), the update install will close the running app (without notice) and then install the update version.
Using SCCM and deploying as msix packages and using the higher-priority deployment type method, if the app is running the SCCM agent downloads the installer to the SCCM cache but holds off the installation. The next time the evaluation cycle runs and the app is not in use it will be installed. This is likely to be "by design" and would be consistent with other SCCM deployment types (except for App-V which is built to handle it).
I also tested deploying the update by adding into SCCM as a New Application that is marked to Supersede the old one. The new application may have a different name using this method, and you must not only add supersedence but mark the old deployment type to be uninstalled in the new application supersedence definition. In this scenario, if the old app is running, it is killed and the new install happens right away. This is probably not the behavior your users want.
Jul 12 2019 04:43 AM
@TIMOTHY MANGAN closing the application without warning is of course not wanted and yes when I test local install and update I get the same result as you. I was hoping that I could deploy the update via SCCM without forcing users to close the app and it would prepare the update in the background and when user closes it, it will apply.
Jul 12 2019 09:35 AM
@michalkala123 Its a discussion item for ConfigMgr to stage the package and not register it during a deployment. We are looking to improve the overall download experience for MSIX in ConfigMgr in an upcoming release (TBD). We are also adding functionality to the an upcoming version of Windows to stage the package and defer the installation if the app until the next launch if the app is in use to help with these scenarios.
Jul 15 2019 08:16 AM
@John Vintzel ConfigMan has a checkbox for that, it just didn't seem to do anything (yet).
Good to hear about upcoming deferral. If app is in a partially deployed state, please also add a pending state to the PowerShell so we can detect this.
Sep 09 2019 09:49 PM
2 months old but will add for future searches. In ConfigMgr 1702 and later, open your MSIX Deployment Type, click on the Install Behavior tab and add the file and display name you need to kill before your installation starts. If deployed as available, user will be notified to self close, if deployed required, it'll close automatically.