Deploy Win32 and Store Apps in Intune with Detection Rules

Two kinds of app, and the one idea that makes both work

Intune can put software on a Windows PC in two main ways. A Microsoft Store app (the portal calls it Microsoft Store app (new)) is chosen from a searchable catalogue inside Intune. Microsoft's side supplies the package, the install method and the update mechanism, so you write no commands and no detection logic. A Win32 app is everything else: an MSI, an EXE, a script-driven setup, a vendor tool that has never heard of the Store. You supply the installer and tell Intune how to install it, remove it and recognise it.

That last part is the detection rule, and it is the bit people skip past on the way to the Assignments page. Intune needs a yes-or-no answer to one question: is this app on this device? It asks before installing, so it does not reinstall something that is already there, and it asks again afterwards, so it knows whether to report success. If the installer exits happily but the detection rule still says no, Intune reports a failure. In practice the detection rule outranks the installer's own opinion.

Win32 apps are delivered by the Intune Management Extension (IME), a small agent that Intune installs automatically on an enrolled device the first time a Win32 app, Store app or PowerShell script is assigned to it. Intune does not support interactive installers. If the setup wants someone to click Next, it cannot be deployed as it stands, because nobody is there to click it.

By the end of this article you will have deployed one safe Store app and one deliberately boring Win32 package to a single lab device, confirmed both from Intune and from the device, and removed them again with an Uninstall assignment.

Before you begin

This is the fifth instalment in our Intune series and it continues with the fictional lab from the earlier chapters: a small test group and one enrolled Windows 11 virtual machine. If you are starting here, you only need the list below.

One honest caveat first. This article is built from Microsoft's current documentation and public references. We have not run these exact steps on a live device or tenant for this piece, so treat the scripts as lab material. Run them in a disposable VM first and expect small differences in portal wording.

• A test device that is enrolled in Intune and Microsoft Entra joined or registered (hybrid joined also works). The IME does not support Windows Home or Windows in S mode, so use Pro, Enterprise or Education.
• A test group holding that device. Every assignment in this article targets that group and nothing else. Do not use All devices or All users while learning.
• An admin account that can create and assign apps. Microsoft's built-in Application Manager role covers mobile apps and managed apps (create, assign, update, delete); an Intune Administrator will also do.
• An Intune licence for the people and devices involved. Win32 and Store app deployment are core Intune features and the Microsoft pages we read name no add-on for them, but Microsoft 365 Business Basic and Standard do not carry full Intune Plan 1, so check your entitlement rather than assuming. Microsoft 365 Business Premium includes it.
• A Windows PC for packaging, with Windows PowerShell 5.1 (the standard blue console). Your lab VM is fine for this. You will also need to run a few commands in an elevated window, which means Run as administrator.
• Network access from the test device to the Microsoft Store and the Intune service endpoints. A device behind a restrictive proxy is the usual reason a Store app never turns up.

Deploy a Microsoft Store app

Start here because it is the shortest route and it shows the assignment mechanics without any packaging. Pick a free app you are happy to see on a lab machine. When you search, the Type column shows UWP or Win32. Choose a UWP entry: Store-hosted Win32 apps are still labelled preview by Microsoft, and not every Win32 app is searchable. Paid apps cannot be deployed this way, and Microsoft notes that apps with an ARM64 installer are not supported.

Intune sets the install behaviour as System or User. For this lab choose System. It is also the required choice if your test device is Microsoft Entra registered rather than joined.

1. In the Microsoft Intune admin center, go to Apps > All apps > Create.
2. In the Select app type pane, choose Microsoft Store app (new) under the Store app heading, then select Select.
3. On the App information page, select Search the Microsoft Store app, type the name of your chosen app, pick the result with Type UWP and select Select. Intune fills in the name, description and publisher. Check them and edit if you like.
4. Set Install behavior to System. If the option is greyed out, the app supports only one context and you can leave it. Select Next.
5. On the Assignments page, under Required, select Add group and choose your lab device group. Select Next, review, then select Create.
6. Make the device check in. On the device open Company Portal and go to Settings > Sync, or in Intune go to Devices, open the device and use Sync. Give it a few minutes; Store apps arrive without any dialogue boxes, so look in the Start menu rather than waiting for a prompt.
7. In Intune, open the app from Apps > All apps and look at the device status graph on the Overview page. Installed is what you want to see. If you prefer to confirm from the device, the command in this step lists the package. Run it in an elevated Windows PowerShell window and replace YOUR_APP_NAME with part of the app's name.
   powershellCopy

   Get-AppxPackage -AllUsers -Name '*YOUR_APP_NAME*' | Select-Object Name, Version, PackageFullName

Create a demonstration Win32 package

For the Win32 half we deliberately avoid third-party software. The fictional package, LabNote, copies one text file into a folder under C:\ProgramData and removes it again. It is trivial, harmless and easy to detect, which makes it ideal for seeing how install, uninstall and detection fit together. The commands below only create and delete files under C:\IntuneLab and C:\ProgramData\RismorLab, so they are safe to run on the lab VM.

Two details in the scripts are worth knowing. The install script uses a try/catch so that any failure leaves a non-zero exit code, which Intune reads as failed. The detection script also checks the file contents, not just that the file exists, because a detection rule that cannot tell version 1.0.0 from version 1.1.0 will cheerfully treat an old install as current.

Save the detection script with UTF-8 encoding. Microsoft recommends UTF-8 with BOM, and Set-Content with -Encoding UTF8 in Windows PowerShell 5.1 writes one. PowerShell 7 does not, so use the 5.1 console for this step.

1. Create three working folders. Source holds only what goes into the package, Output receives the .intunewin file and Tools holds Microsoft's packaging utility. Keeping the utility out of the source folder matters because it compresses everything in the source folder.
   powershellCopy

   New-Item -ItemType Directory -Path 'C:\IntuneLab\Source\LabNote', 'C:\IntuneLab\Output', 'C:\IntuneLab\Tools' -Force | Out-Null

2. Create the payload file and the install script inside the Source folder. The install script copies the payload into C:\ProgramData\RismorLab\LabNote.
   powershellCopy

   Set-Content -Path 'C:\IntuneLab\Source\LabNote\LabNote.txt' -Value 'LabNote version 1.0.0 - fictional lab package' -Encoding ASCII
   
   @'
   try {
       $target = Join-Path $env:ProgramData 'RismorLab\LabNote'
       New-Item -ItemType Directory -Path $target -Force | Out-Null
       Copy-Item -LiteralPath (Join-Path $PSScriptRoot 'LabNote.txt') -Destination $target -Force
       exit 0
   }
   catch {
       exit 1
   }
   '@ | Set-Content -Path 'C:\IntuneLab\Source\LabNote\Install-LabNote.ps1' -Encoding UTF8

3. Create the uninstall script in the same folder. It removes only the LabNote folder and nothing wider.
   powershellCopy

   @'
   try {
       $target = Join-Path $env:ProgramData 'RismorLab\LabNote'
       if (Test-Path -LiteralPath $target) {
           Remove-Item -LiteralPath $target -Recurse -Force
       }
       exit 0
   }
   catch {
       exit 1
   }
   '@ | Set-Content -Path 'C:\IntuneLab\Source\LabNote\Uninstall-LabNote.ps1' -Encoding UTF8

4. Create the detection script one level up, outside the Source folder, so it is not packaged. It writes a line to STDOUT and exits 0 only when the file exists and contains the expected version text. Otherwise it exits 1 with no output.
   powershellCopy

   @'
   $file = Join-Path $env:ProgramData 'RismorLab\LabNote\LabNote.txt'
   $expected = 'LabNote version 1.0.0'
   if ((Test-Path -LiteralPath $file -PathType Leaf) -and (Select-String -LiteralPath $file -SimpleMatch -Pattern $expected -Quiet)) {
       Write-Output 'LabNote 1.0.0 detected'
       exit 0
   }
   exit 1
   '@ | Set-Content -Path 'C:\IntuneLab\Detect-LabNote.ps1' -Encoding UTF8

5. Test detection before installing anything. In an elevated Windows PowerShell window, run the command below. The expected result is 1, meaning not detected.
   powershellCopy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\IntuneLab\Detect-LabNote.ps1
   $LASTEXITCODE

6. Run the install script locally, then run detection again. You should see the line LabNote 1.0.0 detected followed by 0. This runs as you, not as SYSTEM as Intune will, so it proves the logic rather than the final context.
   powershellCopy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\IntuneLab\Source\LabNote\Install-LabNote.ps1
   powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\IntuneLab\Detect-LabNote.ps1
   $LASTEXITCODE

7. Reset the machine by running the uninstall script, then confirm detection is back to 1. Do not skip this: if the file is already present, Intune will detect the app as installed and quietly skip the install you are trying to test.
   powershellCopy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\IntuneLab\Source\LabNote\Uninstall-LabNote.ps1
   powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\IntuneLab\Detect-LabNote.ps1
   $LASTEXITCODE

Convert the package to a .intunewin file

Intune does not accept a loose folder of installer files. The Microsoft Win32 Content Prep Tool compresses and encrypts the folder into a single .intunewin file that Intune can store and deliver. The portal warns you if the file was made with an out-of-date copy of the tool, so download a fresh one rather than reusing something from an old share.

1. Download the Microsoft Win32 Content Prep Tool from Microsoft's GitHub repository (microsoft/Microsoft-Win32-Content-Prep-Tool) and extract IntuneWinAppUtil.exe into C:\IntuneLab\Tools. When we checked in November 2026 the newest release was v1.8.7, published on 13 August 2025. Use whichever release is newest when you read this.
2. Check that the tool runs and see its options. The ones you need are -c for the source folder, -s for the setup file, -o for the output folder and -q for quiet mode.
   powershellCopy

   C:\IntuneLab\Tools\IntuneWinAppUtil.exe -h

3. Create the package. The tool reads everything in the source folder, so your detection script and the tool itself must not be inside it. If the output folder does not exist the tool creates it, and an existing .intunewin file of the same name is overwritten.
   powershellCopy

   C:\IntuneLab\Tools\IntuneWinAppUtil.exe -c C:\IntuneLab\Source\LabNote -s C:\IntuneLab\Source\LabNote\Install-LabNote.ps1 -o C:\IntuneLab\Output -q

4. List the output folder. You should see a .intunewin file named after the setup file; we expect Install-LabNote.intunewin. Keep note of the exact name because you will browse to it in the portal.
   powershellCopy

   Get-ChildItem C:\IntuneLab\Output

Add the Win32 app in Intune and set its detection rule

The portal walks you through a series of pages. Most of them can be left alone for this lab; the ones that matter are Program, Requirements and Detection rules.

Hold on to one fact about the install and uninstall commands: Intune runs them from the folder where it unpacks your package, so a relative path to your script works. Calling powershell.exe from these fields starts the 32-bit PowerShell. That is harmless here because ProgramData is not redirected for 32-bit processes. If you later package something that touches the 64-bit registry or Program Files, Microsoft documents a Sysnative path that forces 64-bit PowerShell instead.

Setting -ExecutionPolicy Bypass applies to that single PowerShell process only and does not change the device's policy.

1. Go to Apps > All apps > Create. In the Select app type pane choose the Windows platform, then Windows app (Win32), then Select.
2. On the App information page, select Select app package file, browse to your .intunewin file and select OK. Give the app a unique name such as LabNote 1.0.0 (lab) and a publisher such as Rismor Lab (fictional). Select Next.
3. On the Program page, set Installer type to Command line if your portal offers the choice. Enter the install command and the uninstall command shown below, one in each field. Set Installation time required to 10 minutes (the default is 60; our script takes seconds, so a short limit makes a stuck install fail sooner), Allow available uninstall to Yes and Install behavior to System. Leave Device restart behavior and the pre-filled return codes as they are. Select Next.
   cmdCopy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Install-LabNote.ps1

   cmdCopy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Uninstall-LabNote.ps1

4. On the Requirements page, select the operating system architecture and minimum operating system that match your lab VM. The architecture setting also decides which devices see the app as applicable, so a mismatch shows up later as Not Applicable rather than as an error. Select Next.
5. On the Detection rules page, set Rules format to Use a custom detection script and upload Detect-LabNote.ps1. Leave Run script as 32-bit process on 64-bit clients and Enforce script signature check on No. Select Next.
6. Select Next through Dependencies and Supersedence, as neither applies to a first package, and through Scope tags unless your tenant uses them.
7. On the Assignments page, under Required, select Add group and choose your lab device group. Leave the availability and installation deadline at As soon as possible. Select Next, check the summary and select Create.

Required, Available, Uninstall and what happens when an install fails

An assignment has an intent. Required means Intune installs the app on devices in the group without asking anyone. Available for enrolled devices lists the app in Company Portal and waits for the user to ask; for Win32 apps this works with either user groups or device groups, though Microsoft notes the app only appears for the primary user who enrolled the device. Uninstall removes the app from devices in the group, but only if Intune installed it in the first place. A single group cannot hold more than one intent for the same app. When a user and a device belong to groups with different intents, Intune resolves the conflict using a table Microsoft publishes, and Required generally wins. The simplest advice is not to create the conflict.

Retry logic is more modest than people expect. Intune's own retry applies to return codes you mark as Retry: the agent tries three times, five minutes apart. A code marked Failed is reported as failed and not retried on that cycle. Separately, if a Required app is not detected on a device, Intune offers it again after roughly 24 hours. An app installed through Available is not reinstalled if the user later removes it.

Timing is the other surprise. Microsoft's pages currently disagree about how often the IME checks in (one says hourly, another says every eight hours), so do not plan a pilot around either figure. During a lab, use Sync and be patient. The first Win32 assignment on a device also has to install the IME itself, so it can take noticeably longer than later ones.

Removing an app from Intune does not remove it from devices, and unenrolling a device does not remove Win32 apps that Intune installed. That is why the rollback below is an Uninstall assignment rather than a delete.

1. To roll back the Win32 app, open it from Apps > All apps, go to Properties, and select Edit next to Assignments.
2. Remove your lab group from Required, then select Add group under Uninstall and add the same group. Select Review + save and then Save.
3. Sync the device as before. The uninstall command runs and the C:\ProgramData\RismorLab\LabNote folder should disappear. The device then reports not installed on the next detection cycle.
4. Optional: to try Available, create a small user group that contains only the primary user of your lab device. Replace the Uninstall assignment with Available for enrolled devices for that group, open Company Portal as that user and install the app from there. Uninstall it from Company Portal too, and notice that Intune leaves it uninstalled.
5. Do the same for the Store app: edit its assignments, remove Required and add your lab group under Uninstall. Remember that Store apps assigned as Available do not report installation status back to Intune.

Check that it worked

Two views matter: what Intune says and what the device actually has. When they disagree, believe the device and then work out why Intune thinks differently.

Intune's view comes from the app's Overview page, which graphs Installed, Not Installed, Failed, Install Pending and Not Applicable, and from Monitor > Device install status, which lists each device with a status, status details and last check-in. Use these when you want proof that a specific device finished.

• Install proof on the device: the LabNote folder contains LabNote.txt.
• Detection proof: running the detection script returns 0 and prints its line.
• Intune proof: Device install status shows your device as Installed with a recent last check-in.

Test-Path 'C:\ProgramData\RismorLab\LabNote\LabNote.txt'
Get-Content 'C:\ProgramData\RismorLab\LabNote\LabNote.txt'

Select-String -Path 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload*.log' -Pattern 'LabNote' | Select-Object -Last 20

If it did not work

These are the usual blockers for this exact task. Both commands in the previous section only read data. The AppWorkload log, which records Win32 app activity on the device, lives in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs and may need an elevated window to read.

• Nothing arrives at all: check the device really is in the assigned group (dynamic groups can lag), that it has synced, that it is not Windows Home or in S mode, and that it is enrolled rather than merely signed in with a work account.
• The installer ran but Intune shows Failed: this is almost always detection. Run Detect-LabNote.ps1 by hand and confirm it exits 0 and prints something. Anything written to the error stream makes Intune treat the app as not installed even if STDOUT has text and the exit code is 0. Also check the 32-bit and 64-bit setting if you later switch to registry detection.
• Intune says Installed straight away and nothing runs: leftover files from your local test. Run the uninstall script and sync again.
• Install times out: the Installation time required value is shorter than the setup needs. Raise it. The maximum is 1440 minutes.
• An installer that needs a click, a licence agreement or a reboot prompt will sit and fail, because Intune cannot press Next for you. Find the vendor's silent switch, or use a PowerShell script installer.
• Available app missing in Company Portal: check that the signed-in user is the device's primary user and that the assignment targets a group that user or device belongs to.
• Store app missing from search: it may be a paid app, unavailable in the selected region or on an unsupported platform. Learn also notes that region selection is temporarily unavailable, so searches default to the United States catalogue.
• Uninstall did nothing: Uninstall only removes apps that Intune installed under the same deployment.