Without access to a time stamp server solution, we’ve needed to re-sign a selection of MSIX packages deployed to windows 10 devices with a new code signing certificate previously. That time has come around again and thinking ahead as we prepare for windows 11, we know the list of packages will increase as we convert more AppV packages, a review of the MSIX toolkit has been started.

A couple of observations, I’ll also place on the github issues list, perhaps somecan provide feedback and sights in to. @jvintzel

Firstly the packages get updates with the new certificate and publisher information as checked using the get-appxpackage cmdlet; however the publisherid is not substituted in the msix package name as per the MPT default naming standard when saving msix packages, so these have needed to be renamed with another powershell script afterwards.

Secondly, we have seen some unexpected results when deploying the resigned packages via MECM targeting the previously signed application with supersedence rules to swap the packages around without an application version update.

Scenarios where with the uninstall tick box selected the previous package is removed but MECM doesn’t proceed to attempt to install the new replacement package.

Or the uninstall selection is not made an the update results in the new package passing for detection but leaving only the previous package actually installed.

Whilst I know some of this could be added to a MECM community thread, any shared experiences with using the toolkit would be welcome.

​Without access to a time stamp server solution, we’ve needed to re-sign a selection of MSIX packages deployed to windows 10 devices with a new code signing certificate previously. That time has come around again and thinking ahead as we prepare for windows 11, we know the list of packages will increase as we convert more AppV packages, a review of the MSIX toolkit has been started. A couple of observations, I’ll also place on the github issues list, perhaps somecan provide feedback and sights in to. @jvintzel Firstly the packages get updates with the new certificate and publisher information as checked using the get-appxpackage cmdlet; however the publisherid is not substituted in the msix package name as per the MPT default naming standard when saving msix packages, so these have needed to be renamed with another powershell script afterwards.Secondly, we have seen some unexpected results when deploying the resigned packages via MECM targeting the previously signed application with supersedence rules to swap the packages around without an application version update.Scenarios where with the uninstall tick box selected the previous package is removed but MECM doesn’t proceed to attempt to install the new replacement package.Or the uninstall selection is not made an the update results in the new package passing for detection but leaving only the previous package actually installed. Whilst I know some of this could be added to a MECM community thread, any shared experiences with using the toolkit would be welcome.  Read More

​