Updating an MSIX application via SCCM

Copper Contributor



My test scenario:


I have packaged two versions of Mozilla Firefox - and - they both have the same name so when I manually install first and then double click the .msix file for version 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 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 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, 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 but it is not, it remains as 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 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 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.


15 Replies



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.



@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?

@michalkala123 My recollection is that the update should succeed even if the app is in use, and closing all use of the app should result in the new version being seen.  But honestly, I haven't tested that scenario in a long time.

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

@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)





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:

  • Every time the application starts. In this case, the update will be automatically downloaded and installed when the application is closed.
  • At a specific frequency (for example, every 6 hours). In this case, the update will be automatically downloaded and installed if the application is not running; otherwise, it will be installed as soon as the application is closed.



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


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

@michalkala123 Well you could always package and deploy using App-V.

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



@John Vintzel  great, I am looking forward to this!


Shall I report this to ConfigMgr team or do you mean that they are aware already?

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



@michalkala123 Feel free to request this with the ConfigMgr team as well.





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. 

@Troy Wilch  true, that is an option. But in the end I think end-users will appreciate the most if they get no notifications and application updates in the background or after they stop working with the software we are updating.