{"id":367407,"date":"2018-08-10T15:13:04","date_gmt":"2018-08-10T22:13:04","guid":{"rendered":"http:\/\/moderneuc.com\/?p=116"},"modified":"2026-02-18T13:02:30","modified_gmt":"2026-02-18T20:02:30","slug":"windows-10-and-application-modernization-msix-format-2","status":"publish","type":"post","link":"https:\/\/jorgep.com\/blog\/windows-10-and-application-modernization-msix-format-2\/","title":{"rendered":"Windows 10 and Application Modernization: MSIX Format"},"content":{"rendered":"\n
\n
\n
\n
\n
\n
\n
\n
\n
\n

Lots of change in the EUC space these days! \u2014<\/p>\n

The reason for this blog is a specific question I received :<\/p>\n

Customer is looking for application modernization services.  They would like their .exe apps converted to be able to work in the Windows Store for Business as a part of their AutoPilot\/Intune project.<\/p>\n

Short answer to the question:  <\/strong><\/p>\n<\/wp-block>


Today, exe\u2019s installations cannot be easily deployed out of the Windows Store for Business.<\/p>\n

They can however be deployed out of Intune without many changes.  It is always best to package them to MSI.<\/p>\n

EXE and MSI do not go on Windows Store for Business  They need to go in Intune<\/p>\n

There is a Microsoft tool  called Desktop Bridge that allows the \u201cconversion\u201d and distribution of Win32 desktop app into Universal Platform (UWP) with some limitation.<\/p>\n

As an aside \u2013 Autopilot is only the registration of the device into the Autopilot Dashboard.  When the Windows OS does is first boot out of the factory, the first thing it does is to look up the device\u2019s unique \u201cserial number\u201d (hash) in the dashboard, and if it finds it, then it enrolls the device into the MDM systems (Intune)   and then starts to execute whatever you have defined in Intune as part of the process (aka Profile)   Intune is in control after that.<\/p>\n

 <\/p>\n

As organizations adopt new technologies and processes ( Windows 10 , Windows as a Service,  Modern Provisioning and such)  application delivery and management becomes a critical topic of conversation in order to fully move into the modern device management state.<\/p>\n

The traditional (aka old way) of managing applications  was to deploy them via .exe or .msi   targeted to devices.    The challenges with this approach included:<\/p>\n

    \n
  1. Each application was locally installed and required changes to the device\u2019s configuration, sometimes considerable ones.<\/li>\n
  2. Different applications may have conflicting requirements and therefore step over each other.<\/li>\n
  3. Over time, it becomes difficult to cleanly remove specific applications and keep track of versions across the enterprise.<\/li>\n
  4. Organizations needed a tool to deploy and manage updates.  This meant more infrastructure and specialized skills was need.<\/li>\n<\/ol>\n

    In the new world (moving forward)  there is a different mind-set where applications:<\/p>\n

      \n
    1. must be \u201cseparated\u201d from the baseline OS<\/li>\n
    2. should know where to get install-bits and updates from.<\/li>\n
    3. Applications are targeted to users with multiple devices rather than devices<\/li>\n<\/ol>\n

      In the Microsoft \/ Windows world  this needs a new packaging method\/technology that support \u201clegacy\u201d apps as well as new apps.<\/p>\n

      Microsoft introduced (preview was announced in May 2018) a new format called .MSIX  which is in the process of being rolling out.  It is a form of \u201cvirtualization\u201d  called containers.<\/p>\n

      MSIX is a containerized packaging format where the application is separated from the underlying Operating System. It will always be kept inside its container. The OS integrated client will manage deployment, configuration and execution. If needed, every container can be configured individually, and Windows will keep track of all the contents and integrations.<\/p>\n

      This leads to a nice feature set:<\/p>\n