Before We Dive In: This blog will focus on what could be the culprit when your Win32apps get stuck at 100% installation when installing from the Company Portal. We’ll walk you through the unusual symptoms we encountered, how you can trace the root cause, and why something as simple as a misconfigured PowerShell Execution Policy can completely derail your app deployments and Windows Autopilot enrollments. If you’re dealing with apps hanging during installation, this guide will help you pinpoint the issue and get your deployments back on track.
Company Portal: Installing Win32Apps
It started with a simple observation: Win32 apps were getting stuck in the Company Portal. The apps would begin installing, show progress up to 100%, and then…just sit there and be stuck on installing for the rest of eternity.
Hours would pass, and nothing would change—no errors, logs, or hints of what was going wrong. It was like the apps were trapped in some sort of installation purgatory. And then, to make things even stranger, Autopilot enrollments also began breaking. Devices would go through the standard enrollment phases, but once they hit the “install required apps” step, the whole process would grind to a halt. With the process being stuck, you will run into the Windows Autopilot issue: 0x80070001 error.
We were dealing with two separate but equally perplexing symptoms: apps that wouldn’t start installing and Autopilot enrollments that couldn’t be completed. There were no obvious clues, no visible errors, just a series of stalled processes. It was time to dig in and figure out what was happening.
The Symptom: Win32Apps stuck Installing
The first sign of trouble showed up in the Company Portal. Win32 apps were assigned for installation, but they never seemed to start. The Company Portal would display the app at 100% or get stuck at the “Installing” stage indefinitely, even though nothing was actually being installed. Rebooting the device or restarting the Company Portal didn’t help. It was as if Intune was sending out the command, but something silently blocked the process from the beginning.
Around the same time, we noticed another peculiar behavior with Autopilot. Required apps, usually a mix of core software and configurations, would begin the initial preparation phase. But instead of completing and letting the device move to the next step, the enrollment would just hang. The device kept checking in with Intune as if it was waiting for something. But what?
The Investigation: Uncovering Silent Failures
We started digging into every possible log file, from Event Viewer entries to Intune Management Extension logs. We combed through the Windows Application logs, the DeviceManagement-Enterprise-Diagnostics logs, and Intune Management Extension log. But nothing pointed us in the right direction. No errors, no failures, just a lot of repetitive status messages indicating that the app was still in a ‘pending’ state.
To get a clearer picture of what was happening, we turned to the AppWorkload.log file. This relatively new log file provides deeper insight into the app installation process and how the Intune Management Extension handles the Win32 app deployments. We saw that the app installer command was being generated, but no installation actions were being performed afterward.
The service attempted to execute the PowerShell script, but there was no indication that it was starting or completing. As shown below, the Company Portal itself was constantly trying to fetch the status…
It was as if the script had never been executed. There were no logs, errors, or feedback at all. Could it be that the scripts were failing without even getting a chance to run?
If you want a more detailed look at what this log file reveals and how to interpret it, check out this Intune Management Extension Deep Dive Webinar and an excellent breakdown of the new AppWorkload log structure in this guide.
Diving Deeper: Was Constrained Language Mode in Play?
One of our initial hypotheses was that Constrained Language Mode might have been enforced. Constrained Language Mode is a feature that restricts certain PowerShell commands to mitigate security risks, but it can also interfere with custom detection scripts. To rule this out, we checked whether Constrained Language Mode was being applied to the system. If it had been, the PowerShell scripts used for detection could have been blocked or limited in functionality.
You can find more details on how Constrained Language Mode impacts detection scripts in this Patch My PC guide, which covers how to detect and disable the mode if necessary.
But after confirming that Constrained Language Mode wasn’t enabled, we knew we needed to look elsewhere. That’s when we took a closer look at the execution policies and realized that something subtle was breaking our scripts.
The Breakthrough: Signed Scripts and the PowerShell Execution Policy
After analyzing the PowerShell Execution Policy settings, we noticed that the policy was configured to allow script execution, but it had an additional requirement: scripts needed to be signed.
As shown above, the Powershell execution policy was set to “Allow only signed scripts”
We then took a closer look at the scripts themselves, especially those provided by Patch My PC, and confirmed that all of them were signed.
If you want to know how to sign a PowerShell script yourself, check out this blog from Patch My PC
How to generate a code signing certificate and sign PowerShell .ps1 script – Patch My PC
This confirmation should have meant that the scripts would execute successfully. However, even though the scripts were properly signed, the installation still wouldn’t proceed. Something was missing.
Our next step was to verify if the signing certificate was imported into the Trusted Publishers store on the device. This is a crucial requirement when the execution policy is set to allow only signed scripts. Without the certificate being trusted, PowerShell would block the script silently without giving any indication of failure. And that’s exactly what we found, the certificate wasn’t imported.
The Missing Signing Certificate
This explained everything: The installation process was being kicked off, but it would never execute. PowerShell was allowing the command to start, but when it came time to run the actual script, it failed silently. No errors, no warnings—just a process that seemed to hang without any sign of progress.
The Fix: Trust the Signing Certificates
The solution turned out to be relatively simple but easily overlooked. For any signed scripts to run correctly, the signing certificate needs to be imported into the Trusted Publishers store on every device.
This installation guide below, will show you the steps you need to take to make sure the Signing Certificate is imported by configuring a CSP.
Wrapping Up: A Journey to the Root Cause
Here’s the rewritten version with the keyphrase included:
What seemed like a straightforward issue with Win32apps stuck installing at 100% soon revealed itself as a more intricate problem, all triggered by a minor misconfiguration. When working with signed PowerShell scripts, it’s essential to ensure the signing certificates are trusted by the system. Failing to do so can lead to elusive errors and odd behaviors that won’t show up in your logs.
So, the next time you notice Company Portal Win32Apps stuck installing or Autopilot enrollments endlessly looping, don’t just stop at checking your PowerShell Execution Policy—make sure to review your certificate stores as well. It’s a small step, but it can make all the difference in ensuring smooth deployments