Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

IntuneWin32ComboLogo

Microsoft made it finally happen and provides an integrated way to deploy Win32 Apps via the Intune Management Extension. This is by far the biggest step forward in the Modern Management field. Until now the community came up with lots of ways to utilize PowerShell scripts to finally install some Win32 Apps. By doing this you need to take care of the content location, availability, distribution, the app install, and verification logic. All this is now available in the enhanced Intune Management Extension. As a short refresh regarding Intune Management Extension, I recommend to read my blog articles about it, where you find a lot of information regarding the architecture, the inner workings, and troubleshooting advises:

Part 1 Deep dive Microsoft Intune Management Extension – PowerShell Scripts
Part 2 Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Both articles are very relevant to this new feature as they all describe the architecture and technical details regarding the Intune Management Extension itself. Exactly this Intune Management Extension is used now for deploying Win32 apps packaged as .intunewin file format. It’s even better, the new functionality can be used to basically transport everything in a package and trigger a certain command line for execution. This is not a end to end walk-through how to use the feature in regards of the Intune portal or on the client itself. For this check out other great articles found in my last section End to end usage walk-throughs?. This is an article all about the inner workings of this new capability, a deep dive into the new technology itself.

Table of content for easy navigation

How do we get packaged apps now?

To get a Win32 apps deployed via the Intune Management Extension we first need to package the content we want to distribute. Microsoft decided to use the same approach like they did for the macOS world, where they provide a small tool to create the packages – Microsoft Intune App Wrapping Tool for macOS. A similar tool to create these packages is available for the Windows world now. This tool is called:

Microsoft Intune Win32 App Packaging Tool

For all of you with ConfigMgr experience, the new feature to deploy Win32 apps with Intune can be compared a little bit with the Packages and Programs functionality within ConfigMgr, but with some additions.

The usage of the Microsoft Intune Win32 App Packaging Tool (IntuneWinAppUtil.exe) is quite simple. We specify a folder and the executable and create then an yourappname.intunewin file. This is our packaged app which we then can upload to the Intune service. The command line of the tool is this:

IntuneWinAppUtil -c  -s  -o  <-q>

To dig a little deeper we inspect the resulting package in detail now. After successful execution it will generate the .intunewin file from the specified source folder and setup file. For MSI setup files, this tool will retrieve required information for later usage in the Intune portal. To explore this a little bit I captured the output and highlighted some important facts there, to gain understanding how the tool is working.

IntuneWin32AppToolOutput

As seen the tool is executed with the necessary parameters to create a package for Google Chrome Enterprise Edition Browser, which is provided as a .msi file. A sub folder called Chrome is in the same folder as the IntuneWinAppUtil. The command line then is:

IntuneWinAppUtil.exe -c .\Chrome -s GoogleChromeStandaloneEnterprise64.msi -o .\ -q

If we look at the green highlighted output now we find some very important information appearing which is exactly describing the workflow:

  1. Compressing the source folder and its files to a sub folder ‘content’ with the new extension .intunewin
  2. Encrypting the compressed file
  3. Computing SHA265 hash
  4. Generating a detection.xml file in a sub folder ‘metadata’
  5. Compressing complete working folder and create again an .intunewin file

As we can see a normal zip compression is used and therefore it is easy to verify all this by opening the generated package with our favorite archive application:

IntuneWinContentRoot

We can see the content folder and metadata folder. Where the content folder stores the encrypted .intunewin file:

IntuneWinContentSubContent

and the metadata folder contains the detection.xml file:

IntuneWinContentSubMetadata

If we now have a look at the detection.xml file we can see the information gathered about the package and msi file:

<ApplicationInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ToolVersion="1.0.0.0">
<Name>Google Chrome</Name>
<UnencryptedContentSize>52284458</UnencryptedContentSize>
<FileName>GoogleChromeStandaloneEnterprise64.intunewin</FileName>
<SetupFile>GoogleChromeStandaloneEnterprise64.msi</SetupFile>
<EncryptionInfo>
<EncryptionKey>Rj9EtHeHGYMv5HYBpyobrmp0rVg0pzIy0TwO9PnSRg8=</EncryptionKey>
<MacKey>5kxZeuk6xfeMak+r/9hzbwS0vBUW1jBMhgN10Jy7XBQ=</MacKey>
<InitializationVector>2AK05qM3tm/5ijDnlFPISA==</InitializationVector>
<Mac>zI8vragiGb1VtbVRiKo3lPkJldZGZB4juX50MCNrmDw=</Mac>
<ProfileIdentifier>ProfileVersion1</ProfileIdentifier>
<FileDigest>Nzl3O6e70W1P0kJDJiWh3eU6gCVOhODNNy7mspfplQA=</FileDigest>
<FileDigestAlgorithm>SHA256</FileDigestAlgorithm>
</EncryptionInfo>
<MsiInfo>
<MsiProductCode>{A4BC9C54-4589-3A4C-8217-9FA00262F471}</MsiProductCode>
<MsiProductVersion>67.92.84</MsiProductVersion>
<MsiUpgradeCode>{C1DFDF69-5945-32F2-A35E-EE94C99C7CF4}</MsiUpgradeCode>
<MsiExecutionContext>System</MsiExecutionContext>
<MsiRequiresLogon>false</MsiRequiresLogon>
<MsiRequiresReboot>false</MsiRequiresReboot>
<MsiIsMachineInstall>true</MsiIsMachineInstall>
<MsiIsUserInstall>false</MsiIsUserInstall>
<MsiIncludesServices>false</MsiIncludesServices>
<MsiIncludesODBCDataSource>false</MsiIncludesODBCDataSource>
<MsiContainsSystemRegistryKeys>true</MsiContainsSystemRegistryKeys>
<MsiContainsSystemFolders>false</MsiContainsSystemFolders>
</MsiInfo>
</ApplicationInfo>

A detailed review shows us the file and encryption information and in addition the MSI file information. This information is used by the Intune portal to pre-populate some Intune app definitions for us.

The MSI information is only available when a msi file is packaged. If we package a setup.exe for example you will not see the entire section in the detection.xml file.

How can we decode Intune Win32 app packages?

I wrote a small utility to convert a .intunewin package back to it’s original sources. You can read more about it on my separate blog post here: How to decode Intune Win32 App Packages

Why is the .intunewin packaged like this?

This is pretty simple to explain. The portal and the Intune service gets all necessary information to deal with the app (in this case Google Chrome). The msi information listed in the detection.xml is used to simplify the setup within the Intune UI by pre-filling the app form during creation. For example by adding the install and uninstall commands for the msi automatically:

IntuneWin32AppsMSIInstallCommand

The EncryptionInfo is used to store it with your Intune tenant to gain access to the uploaded .intunewin package. The encrtypted .intunewin (located in the content folder) can be distributed safely to the Intune back-end services responsible for content distribution without getting exposed to others, only the tenant who uploaded the file has the EncryptionInfo and can decrypt the file.

Where can I find details of the Win32 App deployment?

The Intune Management Extension tracks some details of the Win32 apps in the registry at: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Apps\

IntuneWin32AppDetailsRegistry

The yellow highlighted names provide us the execution commands for install and uninstall and the attempts and results of it.

If we look at the green highlighted GUID at HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\73d664e4-0886-4a… we can see it matches my Azure AD user object ID. To compare it I got the details via Azure AD PowerShell:

GetAzureADUser

The red highlighted GUID (b0f62b79-e464-4f95-afe2-ed99eb612fe5) is the application GUID which is assigned by the Intune service back-end. This can be easily traced by looking at the graph data with the Graph Explorer from Microsoft:

In my example I used this to retrieve the details of my uploaded app:

https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/b0f62b79-e464-4f95-afe2-ed99eb612fe5

This is the detailed information about the uploaded Win32 .intunewin app:

{
"@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceAppManagement/mobileApps/$entity",
"@odata.type": "#microsoft.graph.win32LobApp",
"id": "b0f62b79-e464-4f95-afe2-ed99eb612fe5",
"displayName": "Google Chrome (new)",
"description": "Google Browser",
"publisher": "Google",
"largeIcon": null,
"createdDateTime": "2018-09-21T09:38:11.4343585Z",
"lastModifiedDateTime": "2018-09-21T09:39:16.2037636Z",
"isFeatured": true,
"privacyInformationUrl": null,
"informationUrl": null,
"owner": "",
"developer": "",
"notes": "",
"uploadState": 1,
"publishingState": "published",
"committedContentVersion": "1",
"fileName": null,
"size": 52284512,
"installCommandLine": "msiexec /i \"GoogleChromeStandaloneEnterprise64.msi\" /q",
"uninstallCommandLine": "msiexec /x {A4BC9C54-4589-3A4C-8217-9FA00262F471} /q",
"applicableArchitectures": "x64",
"minimumFreeDiskSpaceInMB": null,
"minimumMemoryInMB": null,
"minimumNumberOfProcessors": null,
"minimumCpuSpeedInMHz": null,
"msiInformation": null,
"setupFilePath": null,
"minimumSupportedOperatingSystem": {
"v8_0": false,
"v8_1": false,
"v10_0": false,
"v10_1607": true,
"v10_1703": false,
"v10_1709": false,
"v10_1803": false
},
"detectionRules": [
{
"@odata.type": "#microsoft.graph.win32LobAppProductCodeDetection",
"productCode": "{A4BC9C54-4589-3A4C-8217-9FA00262F471}",
"productVersionOperator": "notConfigured",
"productVersion": null
}
],
"installExperience": {
"runAsAccount": "system"
},
"returnCodes": [
{
"returnCode": 0,
"type": "success"
},
{
"returnCode": 1707,
"type": "success"
},
{
"returnCode": 3010,
"type": "softReboot"
},
{
"returnCode": 1641,
"type": "hardReboot"
},
{
"returnCode": 1618,
"type": "retry"
}
]
}

Intune Management Extension Agent working folders?

If we have a look at the file system at:

C:\Program Files (x86)\Microsoft Intune Management Extension\Content

we can find some interesting folders where the agent is downloading the content and detection scripts and stores the actual MSI log files:

ItnuneWin32AppsFolders

Agent execution context when processing .intunewin files?

The agent is bound to the same restrictions during execution like we know them for PowerShell scripts, meaning the calling process (the Intune Management Extension agent) is a 32-bit process. This can result in some unexpected behavior. For example when trying to package a simple .ps1 file within a .intunewin and trying to execute cmdlets in this scripts which are only available in a 64-bit environment. We then have to use a technique to restart the PowerShell script as a 64-bit process. This is described in my previous articles and I have built a Intune PowerShell script template to simplify the start for this, which can be found on my GitHub here https://github.com/okieselbach/Intune/blob/master/ManagementExtension-Samples/IntunePSTemplate.ps1. This can also affect installers packaged as .intunewin when they assume a 64-bit environment!

If no restart technique is used keep in mind that environment variables must be handled with care from 32-bit processes. For example if you like to target the %windir%\System32 environment from a 32-bit process you have to use %windir%\Sysnative otherwise you will land in %windir%\SysWOW64. Visit the linkt to read more about the file system redirector: https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector


What are the retry and execution intervals?

The agent has default values for retry and execution:

  • max. of 3 retries
  • interval between the retries is 5 min.
  • max. execution run time is 60 min.

these limits are not adjustable at the moment.


Current Limitations (as per date Oct-2018)?

End to end usage walk-throughs?

Good walk-throughs on how to use the feature with the Intune portal and the end user experience can be found here:

Deploy Win32 Applications with Microsoft Intune
http://www.scconfigmgr.com/2018/09/24/deploy-win32-applications-with-microsoft-intune/

Deploy customized Win32 apps via Microsoft Intune
https://www.petervanderwoude.nl/post/deploy-customized-win32-apps-via-microsoft-intune/

Intune – sidecar for Win32 apps revealed
http://gerryhampsoncm.blogspot.com/2018/09/intune-sidecar-for-win32-apps-revealed.html

Intune Win32 App deployment – A gamechanger
https://ccmexec.com/2018/10/intune-win32-app-deployment-a-gamechanger/

Official documentation can be seen here

Intune Standalone – Win32 app management
https://docs.microsoft.com/en-us/intune/apps-win32-app-management

Remember to check back frequently as Intune progresses and the feature will be enhanced in short cycles. I will update the article accordingly.

Happy packaging, deploying and troubleshooting Win32 apps with Intune!

18 thoughts on “Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps”

  1. Nice write up once again.
    The current limitations are not earth shocking or real blocking for deployments.
    PS. Maybe add screenshot what user will see/get notificationd when deploy is in progress?

  2. I have an application i need to install via a .bat file. in the past i compiled this set of files and its batch into an exe using iexpress and the cmd.exe /c batchfile.bat. Would I still perform this operation and then convert this into an .intunewin file?
    Thanks
    Lee

  3. Hi Oliver. I got some issues with an app deployed this way. It fails during unzipping due to long file path. Intune gives following error: Error unzipping downloaded content. (0x87D30067)

    <![LOG[Exception occurs when unzipping Win32App user session 1, the Exception is System.IO.PathTooLongException: Sökvägen eller filnamnet, eller båda två, innehåller för många tecken. Det fullständiga filnamnet måste innehålla färre än 260 tecken och katalognamnet färre än 248.

    How can I resolve this issue?

    1. Hi Gurstav,

      I think I would try to do a workaround. I would install the app via a custom install wrapper script. I would package the program files of my app into a 7zip or regular zip archive and my custom installer would then extract to e.g. C:\temp to avoid long path names and would call the win32 installer/setup from there, wait for exit and gather exit code to return the exit code to the Intune Win32 package.

      best,
      Oliver

      1. Oliver/Gustav,

        i also have the 0x87D30067 message on a new win32.intune package and this is the only page according to google related to that error icw Intune.

        Checked the folder depth with cmd /s in powershell to check -gt 170, not 1 file. So it must be under the 170chars.
        The folder (c:\progfilesx86\intunemgt etc\staged\app_id) is about 56 chars.
        So, imho its not above 248 or 260 :D.

        I will try to wrap it and deploy with PS. And check this page the coming weeks for any updates.

      2. A small update;
        After some check I see that my PS folder depth check was not showing the correct info. After checking it myself i have found the folder with the issues, it is only 2 MB data. Also tried to use TARGETDIR as msiexec paramater, but it keeps extracting the folder to the Staging folder.

  4. Using the Win32 App Packinging tool to create an intunewin file from an exe, I open the detection.xml file but I am not seeing the product code to use to the uninstall command. In the xml file I have encryption key, mac key, initialization vector, mac, profileidentifier, file digest and file digest algorithm. Which one of those do I use in the uninstall command when uploading the intunewin to Intune?

    Thanks

    1. Hi dj56,

      you don’t need to look up the MSI product code by your own. When you package a .msi file as .intunewin the tool will generate the MSI information in the detection.xml. The portal will pick this information and automatically fill out the form for you with the relevant information for install command and uninstall command. If there is no msi information in the detection.xml it’s either you didn’t package a .msi file, maybe you packaged a setup.exe for example. Only with .msi files the Packaging Tool will provide this additional information as a .msi file is a standardized way of packaging which can be read programmatically. Other installers are all different and therefor no programmatic reading is possible. A setup.exe can be a Nullsoft installer, InstallShield or whatever… a ton of possibilities. Only .msi are read for product code to make your life a bit easier when uploading.

      best,
      Oliver

      1. So FireFox for example or any software that only provides an exe to download, is using this tool the best way to create the intunewin file to upload into Intune?

    1. Hi LJ,
      Of course when you use the Win32 app support you can package whatever you want and then specify any command line for install and uninstall. So your example is absolutely possible, yes!

      Best,
      Oliver

  5. Hi,
    nice Infos, like always. Im wondering, how to uninstall a Programm from Company Portal?? We only have “reinstall”… If we uninstall the normal way, then the Software has still the status “installed” in Company Portal.

    1. Under Intune Troubleshoot –> my device –> Managed Apps (Preview) Chrome has Installation Status failed (The application was not detected after installation completed successfully)

      😀 Not very Usefull at the Moment…

      1. But wait 🙂 it says “The application was not detected after installation completed successfully”, then your detection rule is not correct. Have a look at the detection rule.

    2. Hi Martin,

      thanks :-). The installed status will change after some time to installed failed. You need to wait a bit longer. This is because the detection rule of the intunewin will run and find your app not installed anymore and will get this status and reports it. This status will then be reflected in the company portal. If your app is not targeted as an available deployment, a required deployment, then the agent will reinstall the app again. For company portal you have the available deployment and therefore it will only be reported as failed as it is not there anymore, your detection rule failed. You could hit reinstall as a user and the app gets installed again. If you like to uninstall the app you might target a dedicated uninstall assignment.

      best,
      Oliver

      1. Hi Oliver,

        yes i know about the uninstall per assignment, but i think if you have not only required but also optional software, the end user needs the possibilty to uninstall. Maybe this will be on the Roadmap.

        Thanks
        Martin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s