But that first part mainly answered one question: what is IC3 doing in the IME? This second part answers the next one: What happens to the old Intune flow once IC3 starts taking over?

The Current Intune Flow

The deeper I looked into Intune timing, the clearer one thing became. Windows management never really behaved like one single communication model.

One part of the platform lived in the MDM world. Policies, remote device actions, and similar actions relied on a push notification that had to wake the device and to get the MDM stack running.

Another part lived in the IME world. Win32 apps, PowerShell scripts, remediations. Those IME/Sidecar workloads followed their own evaluation cycles, timers, and internal logic. That meant the device was already split into two different timing models. One side waited for a push notification to arrive. The other side waited on polling or timers. That is one of the real reasons Intune’s timing has always felt inconsistent.

IC3 Starts Replacing What WNS Used to Handle

That is where the story starts to change. For a long time, WNS was the path Intune relied on when something needed to happen quickly on the device. A policy changed, a remote action was triggered, Intune sent the nudge, and WNS was supposed to get that signal to Windows.

If that worked, the device woke up and checked in. If it did not, the device waited. That older design always had two weak spots. The first was WNS itself. Once the signal left Intune and entered that path, it disappeared into a black box.

The second was that this only helped part of Windows management. The IME side still lives on Internal timers, polling, and workload-specific logic.

IC3 totally changes that direction. It does not look like a small improvement to the old design. It looks like the beginning of a replacement for it.

What IC3 Starts to Look Like

If you put the old flow and the new direction side by side, the shift becomes much easier to see.

Instead of one side depending on WNS while the other waits for its next cycle, both the MDM world (policies) and the IME World (Win32Apps/Scripts) begin pointing toward the same notification channel….IC3. With it, WNS starts fading into the older path. Timers start fading with it. And IC3 is starting to look like the place where the IME and MDM worlds finally meet.

IC3 and Future Device Actions

The first blog already showed the most important technical clue: when an IC3 message arrives, it is decoded and pushed straight into the IME’s internal device action callback. Following that path lands you in EmsAgentService.DeviceActionCallbackAsync inside the Intune Windows Agent.

If IC3 already lands in the same callback pipeline, then this is no longer only about IME specific actions. It also opens the door for remote actions that live in the MDM words, like Sync, Wipe, Retire, SetDeviceName, and RotateBitlockerKeys, to move away from the opaque MDM WNS path and into the same stateful channel.

What That Means for Win32 Apps and Scripts

Our previous blog already pointed out the most obvious example: Win32AppWorkload.

That matters because required Win32apps have historically depended on the IME’s own evaluation timing (60 minutes), including the familiar pull cycle rather than an immediate push trigger.

If Win32AppWorkload moves over to IC3, Intune no longer has to wait for the IME’s next timer to come around. It can wake up the device, tell the IME to kick off the Win32 app workload, and start processing the app install right away.

That is the real change. Instead of sitting around waiting for the next scheduled IME cycle, the device can react when the IC3 push message arrives. And once that becomes possible for Win32 apps, it is hard not to look at PowerShell scripts, remediations, device inventory, EPM related actions, and other current Windows MMP-C push scenarios the same way.

Remote Help Already Points in That Direction

This is also why the Remote Help announcement in the “whats in development” matters.

Remote Help is one of the clearest signs that Microsoft is already moving time-sensitive IME device actions toward a more direct notification path (IC3). Once you see Remote Help show up in the same action model, it becomes much easier to understand where this is heading. The same communication layer that can handle Remote Help can just as easily become the place where other time sensitive actions land as well.

And that opens the door far beyond just apps. If IC3 becomes the shared path for real-time actions, then it is not hard to imagine more MMP-C style push notifications moving over to it. EPM-related actions, device inventory, policy-related triggers, and other Sidecar-style workloads all make more sense once the device no longer has to wait for a timer or rely on WNS to deliver the message.

Summary

The arrival of IC3 inside the Intune Management Extension marks a shift toward a more responsive Intune. A live IC3 connection gives the IME its own real-time channel, which means actions routed through it no longer have to wait for timers, polling, or the uncertainty of WNS delivery.

That matters for both sides of the story. On one side, older remote actions such as Sync, Wipe, Retire, SetDeviceName, and RotateBitlockerKeys can move away from the opaque WNS path and into a direct stateful channel that the agent maintains itself.

On the other side, Win32 app workloads, scripts, remediations, Remote Help, and other IME-driven actions no longer have to depend on their own isolated timing model before something finally happens. That is the biggest shift ever.

If IC3 becomes the channel for time-sensitive communication, then WNS can fall back to the broader background flow while the IME becomes the place where real-time actions actually land. That is why IC3 feels bigger than another protocol change.

The post IC3: From WNS to Real Time Device and IME Actions appeared first on Patch My PC.

Fixes

• Fix a bug causing products marked for ‘Exclude from auto-pubilshing rules‘ not be saved when the product treeview is filtered to enabled products only. 
• Fix a bug causing the user to be unable to add a new language to Manage Conflicting Processes global settings.
• Refresh the Intune authentication token before retrieving reports from Intune when performing auto-publishing during synchronization.
• Ensure the list of discovered devices with an application only includes unique device matches within the Intune scan wizard.

The post Patch My PC Publisher Preview Version 2.1.108.10 Released appeared first on Patch My PC.

Maintenance Window Introduction

Microsoft recently announced that the possibility to configure a Maintenance Window is now also coming to Intune for cloud-managed Windows devices….

With it, a new Settings Catalog entry will appear in Intune (In the near future).

Please Note: This is a mockup? AKA Not there yet...but it will look like this…

Which brings back some good memories, right?

That new Maintenance Window setting catalog gives us the option to define when update activity is allowed and adds controls for OS, driver, and firmware servicing. Before the Maintenance Window setting fully shows up in the Settings Catalog, we can already spot the underlying logic in Windows.

You can already spot it in the policy definitions, in the MOF behind the WMI bridge, in the Update Policy CSP, and inside the Unified Update Platform itself. So by the time Microsoft announced it, Windows already knew how to read the policy and act on it.

Why Windows needed something beyond active hours

Windows Update has had scheduling controls for years. You can configure active hours, deadlines, grace periods, and restart notifications. Those settings help, but they do not give you a true maintenance window.

That is the difference that matters. Active hours are mostly about avoiding disruption. They tell Windows when it should stay out of the user’s way. A Maintenance window does the opposite. It defines when update work is actually allowed to happen.

For many environments, that is a much better model. Shared devices, kiosks, frontline endpoints, and cloud-managed devices often need a fixed servicing slot rather than a soft attempt to avoid reboots during the day. That is exactly where the Maintenance Window fits.

The first clue appeared in the Windows Update ADMX

The first sign of this new Maintenance feature showed up in WindowsUpdate.admx.

Inside the policy definitions, a new policy named Maintenance Window appeared with the backing value Maintenance Window Enabled. It was marked as supported for Windows 11 24H2 preview, which already showed that the operating system had a real policy surface for this feature before Intune exposed it.

It was also clear from the start that this was not just a cosmetic toggle. The policy definition included update actions, which meant the feature was designed to control actual update behavior, such as download, install, and restart. At that point, the policy definition told me Windows was aware about the maintenance window policy. What it did not yet show was how that policy was exposed to modern management.

That is where the MOF came in.

The MOF confirmed it was part of the WMI bridge

The next clue appeared in the MOF definitions that are related to the WMI bridge.

That matters because the MOF file tells you the setting is not just living in old administrative template land. Once it appears in the MOF file, you know it is part of the modern management surface as well. The Maintenance Window policy is being projected through the same bridge that exposes MDM-backed settings into WMI.

That was the point where the Maintenance Window feature stopped looking like an unfinished ADMX addition and started looking like a fully grown setting. The next step was obvious. If the feature already exists in the policy definitions and in the WMI bridge, then the actual implementation should be visible in the CSP that backs it.

And that is exactly what turned up.

Maintenance Window in the Update Policy CSP

Once the search moved into the Update Policy CSP, the picture became much clearer.

The Maintenance window policy family was already there. It included the settings to enable or disable the window, define the start date and start time, set the duration, choose the repeat schedule, and configure which update actions are governed by the window. Weekly and monthly scheduling options were already available.

Configure the Maintenance Window with a CSP

Because the Update Policy CSP already exposed the Maintenance Window settings, the only thing missing was the friendly Intune experience. The device itself did not need that interface. It only needed the policy values.

So the feature could already be configured manually through a custom policy. Once those CSP settings were pushed to a supported Insider Preview build, the device accepted them and treated them as a valid update policy.

As shown above and below, the device was accepting the maintenance window configuration.

With it, we can also spot those Maintenance Window settings showing up in the policies registry keys

From there, the next question was how Windows processes it internally once that Maintenance Window policy arrives on the device.

Windows Maintenance inside the MoUsoCoreWorker

The MoUsoCoreWorker executable is where the Maintenance Window policies are being processed and validated so Windows can actually use and apply them. This all happens inside the GetAndValidateMaintenanceWindowConfiguration function

The function starts by checking whether the underlying feature is enabled through Feature_Containment_UUS_Feature_MaintenanceWindow_59270588.  (because everything is behind known issue rollback/feature flighting)

After that, it reads enterprise policy ID 65 using Windows::GetEnterprisePolicy. From the flow, this value is clearly the main enablement switch. If it is not enabled, the function falls back to the existing configuration.

If the Maintenance Window policy is enabled, the function continues by calling Windows::Policy::GetMaintenanceWindowGovernedActions. That is the point where Windows determines which update actions are controlled by the maintenance window.

The function then reads the enterprise policy ID 70. Based on the switch statement in the code, that value controls the recurrence type. A value of 1 maps to no repeat, 2 maps to daily, 3 maps to weekly, and 4 maps to monthly.

That repeat type is then handed to one of four generator functions:

Windows::Policy::GenerateNoRepeatConfiguration
Windows::Policy::GenerateDailyConfiguration
Windows::Policy::GenerateWeeklyConfiguration
Windows::Policy::GenerateMonthlyConfiguration

This is the part that matters most. Windows takes the policy, reads the current time, resolves the recurrence pattern, and calculates the next actual start and end time for the upcoming window. The logging inside the function makes that clear:

That is the real shift. Windows is not storing a passive policy blob. It is building a runtime maintenance window configuration with governed actions, a real next start and end time, and the duration. At that point, the maintenance window is no longer just a policy. It is part of the update decision-making path.

How the Maintenance Window is checked

Once update activity begins, whether through a scheduled scan or a user pressing Check for updates, the execution path moves into the modern update stack. One of the components involved there is the famous MoUsoCoreWorker.exe.

That is where the maintenance window starts to matter in practice. By the time MoUsoCoreWorker.exe is running, the device already knows whether a maintenance window exists, which update actions it governs, and whether the current moment falls inside a valid scheduled window. The worker is operating within the context of that effective update-policy state rather than blindly continuing with update work. That is the important distinction. The maintenance window is not just something that sits in policy. It becomes relevant during execution.

This is not just active hours with a new name

It is easy to confuse this with active hours, but they solve different problems. Active hours are defensive. They try to reduce user disruption by avoiding restarts during expected working hours. A Maintenance Window is strict. It defines exactly when updates are allowed to run. That is why this feature reaches deeper into the update stack. It is not just a UX setting. It is a scheduling primitive for modern update orchestration.

Summary

The Maintenance Window settings catalog policy is pretty important because it will finally give control over when update activity happens, instead of relying on Windows to avoid disruption on its own. This makes update behavior more predictable, especially for shared devices, critical workloads, or environments where timing matters. Once configured, Windows calculates the next valid window and uses that schedule during update execution. When update work starts, MoUsoCoreWorker.exe checks if the current time falls within that window. If it does, updates proceed. If not, they wait until the next allowed moment.

The post Maintenance Window Settings for OS, Drivers, and Updates appeared first on Patch My PC.

Fixes

• SMTP Oauth Test permission button would only ever account for the first tenant configured.
• Ensure the nth-day-of-the-week option for a monthly sync schedule maps correctly to settings.xml.
• Resolve an issue that causes the Publisher to improperly parse the installation command line for WSUS in some cases. This could result in an update being published with an incorrectly formatted installation command.

The post Patch My PC Publisher Preview Version 2.1.103.1 Released appeared first on Patch My PC.

Adobe was founded in 1982 with PostScript, laying the foundation for digital document rendering and enterprise printing. Early adoption through the Apple LaserWriter brought Adobe technology into business environments.

With the introduction of PDF Reader in 1993, Adobe standardized digital document exchange across organizations. In the 2000s, Adobe expanded its portfolio with Creative Suite, and in 2013 shifted to a subscription‑based model with Creative Cloud. In the 2020s, Adobe further expanded its cloud‑based offerings, introducing more frequent releases across Creative Cloud and Document Cloud applications.

If you want to jump straight to the conclusion, please click on this link.

Adobe Product Overview

Adobe has different products and services

• Acrobat Reader
  Free PDF viewing, printing, commenting, form fill, and basic signing.
• Acrobat Standard
  Paid version with PDF creation, editing, conversion, basic redaction, and OCR.
• Acrobat Pro
  Full feature set including advanced OCR, full redaction, PDF comparison, preflight, and certificates.
• Adobe Acrobat Classic
  Paid perpetual license for Acrobat Pro 2024. Desktop only. No cloud or AI features. Limited updates.
• Creative Cloud Acrobat Pro
  Same functionality as Acrobat Pro, delivered via Creative Cloud subscription.

Adobe classic

Adobe’s Classic track refers to the perpetual (non‑subscription) releases of Acrobat, distributed via MSI base installs and MSP updates. Over time, Adobe retired the “Classic” name, but not the concept.

• Acrobat Classic 2015 – End of life
• Acrobat Classic 2017 – End of life
• Acrobat Classic 2020 – End of life on November 30, 2025 (still supported until then). But Adobe is still updating it in 2026, so we will not remove it for now in our app catalog.
• Acrobat Pro 2024 – Current Classic‑track release, now without the “Classic” label

Despite the rebranding, Acrobat Pro 2024 continues the same model: a perpetual license with controlled updates, familiar to IT teams managing MSI deployments and MSP patching.
Only the name changed. The lifecycle behavior did not.

You can find this version in PMPC Cloud, although it is incorrectly named. It should be listed as Acrobat Pro 2024.

Acrobat products by Audience

Individuals
Adobe offers both Acrobat Standard and Acrobat Pro for individual users, depending on feature requirements.

Business
Organizations can choose between Acrobat Standard and Acrobat Pro for commercial use, available through individual or team licensing.

Students and Education
Education licensing is centered on Acrobat Pro, either as a standalone education plan or included with Creative Cloud for Students and Teachers, which bundles Acrobat Pro with additional Adobe applications.

Adobe Reader Naming History

Adobe’s free PDF viewer has existed for decades, but its name has changed several times as Adobe adjusted its product and branding strategy.

In the 1990s and 2000s, the application was simply known as Adobe Reader. This name became widely recognized and synonymous with viewing PDF files.

During the 2010s, Adobe renamed the product to Adobe Acrobat Reader, aligning it more closely with the Acrobat product family.

From 2015 through 2023, the application was branded as Adobe Acrobat Reader DC. The “DC” designation reflected Adobe’s broader Document Cloud branding during this period.

Starting in 2023, Adobe removed the “DC” label and reverted to the name Adobe Acrobat Reader. Functionally, the product remained the same free PDF reader, but the branding was simplified.

Adobe Reader Installation Options

Adobe Reader is available through multiple installer types including Patch My PC Cloud.

• Creative Cloud Desktop Application
  Reader can be installed via the Adobe Creative Cloud Desktop Application. This method requires an Adobe account sign‑in.

• Standalone EXE Installer
  Adobe provides a standalone executable installer, commonly distributed as Reader_en_install.exe. This allows installation without Creative Cloud and is a webinstaller.

• Exe (offline) and MSP Installers
  EXE and MSP packages are available for managed deployments. These formats are used for enterprise installation and updates and are available through Patch My PC Cloud.

The .exe installer type can do a clean installation and update Adobe Acrobat Reader. The .msp installer type can deploy an update-only package.

Note: You don’t need to deploy the .msp installer type if you deploy the .exe with a required assignment.

Updating Adobe Reader: Product Class vs Unified Installer

Per Product Class Updates (Not Recommended)

Updating Reader per product class means treating each installer, version, or track as its own lifecycle. In theory, this gives control. In practice, it creates fragmentation.

• Multiple installers to manage
• Separate detection and update logic per version
• Higher risk of missed patches
• Inconsistent versions across the estate

This approach does not age well. Every new release adds complexity, and over time, the environment drifts. Security posture depends on perfect execution, which rarely happens at scale.

Result: more effort, more exceptions, less certainty.

A quick guide on how to update per product class with Patch My PC cloud

Update Adobe Acrobat Reader.

Recommended if you just deploy this as a Required assignment.

If you want to deploy an available and update only. You will need to work with a combination of the .exe and the .msp (update).

Same concept for Adobe Pro (Adobe Acrobat).

Or Adobe Reader Classic

Unified Installer (Recommended)

The unified installer flips the model. Instead of managing versions, you manage the whole product.

• One install source
• One update path
• Predictable patching behavior
• Consistent versioning across devices

Updates become incremental and continuous rather than event‑driven. From an operational and security perspective, this is the only model that reliably holds up over time.

Result: fewer moving parts, fewer mistakes, improved compliance, and reduced operational overhead from managing fewer applications.

On the Adobe webpage, we can see this table that shows how flexible this Unified installer is.

Source: Unified installer for Windows 64-bit — Deployment Planning and Configuration

Deploying Unified Adobe Acrobat

Before we begin, it’s important to clarify a key point that is often misunderstood: The Adobe Acrobat installer is the same for all editions. There is no separate installer for:

• Reader
• Adobe Acrobat Standard
• Adobe Acrobat Pro

In other words: Adobe Acrobat (Unified) = Acrobat Pro = Acrobat Standard. The installer is identical. What changes is how the application behaves at runtime, based on licensing and policy configuration.

We can make the Adobe Acrobat run in a Unified state if we add the following regkeys (Official Adobe documentation). A post‑install script must be added here using PMPC Cloud.

Example code

# Writes Adobe policy keys under HKLM (machine-wide). Must run elevated / as SYSTEM.
# Purpose: reduce in-product messaging and upsell prompts in Adobe Acrobat/Reader DC.
$base = 'HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown'

# Ensure the policy base key exists
New-Item -Path $base -Force | Out-Null

# Enforce "SCR reduced mode" (limits certain Share/Send-for-Review style experiences)

# This can reduce some cloud/share related prompts depending on feature usage.
New-ItemProperty -Path $base -Name 'bIsSCReducedModeEnforcedEx' -PropertyType DWord -Value 1 -Force | Out-Null

# cIPM is commonly used for in-product messaging controls (prompts/toasts/info banners)

$ipm = Join-Path $base 'cIPM'
New-Item -Path $ipm -Force | Out-Null

# Suppress messages while viewing documents
# 0 = allow messages
# 1 = don't show messages (reduces popups while reading PDFs)

New-ItemProperty -Path $ipm -Name 'bDontShowMsgWhenViewingDoc' -PropertyType DWord -Value 1 -Force | Out-Null

# Suppress upsell / promotional prompts (reduces "try Pro", banners, upgrade nudges)
New-ItemProperty -Path $base -Name 'bAcroSuppressUpsell' -PropertyType DWord -Value 1 -Force | Out-Null

Expected behavior

• Adobe Acrobat installs once and runs for Reader, Standard, and Pro users
• Users without a Pro license can still open and use PDFs without the application closing
• Pro features remain license‑controlled and unlock automatically for licensed users
• Reduced in‑product messaging and fewer upsell prompts (depending on policy settings)
• A single install base can be patched and updated consistently

Note: You still need to deploy the .msp if you want to utilize the update only option

Please vote on this Idea to support a single Adobe Acrobat (Unified) application that can perform both a full install and update‑only actions. The .exe installer should also be supported as an update mechanism, not limited to the .msp installer.

Summary:

This blog explains how Adobe’s Acrobat products, naming, and licensing evolved, and why patching has become unnecessarily complex for IT. It shows that Reader, Standard, and Pro all use the same unified installer, with behavior controlled by licensing and policy, not separate packages. Managing updates per product class increases fragmentation and risk, while the unified installer model provides consistent patching and simpler operations. With the correct registry configuration, a single Acrobat deployment can safely cover all scenarios with fewer apps, fewer errors, and better compliance.

The post Adobe Acrobat Patching: A Practical Guide appeared first on Patch My PC.

Intune Timing

If you manage devices with Intune, you have probably seen behavior that initially feels inconsistent. A configuration policy appears on the device not long after deployment. At the same time, you assign a PowerShell script, and nothing happens for hours. You press Sync in the Intune portal, expecting everything to refresh immediately… and still nothing happens.

At that point, people usually start looking for some hidden Intune refresh timer that everything must be waiting on. That is also the moment when someone inevitably jokes that the S in Intune must stand for Speed, as if every workload were sitting behind the same timer. But that is not what is happening.

The Mistake We All Make First

The easiest assumption is that Intune has a single universal sync engine.

Please Note: This Image above is absolutely NOT the reality!!!!!

If we deploy “something” from the Intune portal to the device, it is natural to expect that policies, Win32 apps, LOB apps, PowerShell scripts, and remote actions all travel through the same channel and follow the same timing. But Windows and Intune do NOT work that way.

As shown above, there are different engines/traffic lanes involved, each handling a different type of workload. The built-in MDM stack (OMA-DM) handles the policy state. The Intune Management Extension handles task-based workloads such as Win32 apps, scripts, and remediations. On top of that, push notifications can wake some of those paths (Device Query/ Remote Help), but not all of them. That is exactly why two assignments (Win32App and a Policy) created at the same time can still reach the device in very different ways. That split is the key to the whole story.

The Policy Side: Fast, Push-Driven, and State-Based

Let us start with the most famous one…Policies. Configuration policies rely on the Windows MDM engine built into the operating system. This is the OMA DM side of the Intune world.

When “something” changes in Intune, Intune does NOT open a direct management session to the device and push the policy down. Instead, it asks WNS (Windows Notification Service) to send a push notification. Windows receives that nudge, and then the device starts an OMA-DM SyncML session to pull the latest instructions (policies).

As shown below, the push notification wakes the engine. It does NOT contain the policy itself.  

Once that OMA-DM session starts, Windows retrieves the configuration and routes it to the right CSP.

How the policy is applied

From there, the operating system applies the desired state (get-set-get). That is why policy delivery is best understood as state enforcement. Windows is not being told to “run a task.” It is being told what state should exist, and the CSP layer enforces it.

This is also where the famous “The device will only sync every eight hours myth” starts to fall apart. Policy delivery is NOT waiting on a single 8-hour maintenance timer. During enrollment, Windows checks in every 3 minutes for the first 15 minutes, then every 15 minutes for the next 2 hours, and only after that does it drift toward the longer maintenance cycle.

AFTER enrollment is complete, the policy path is largely wake-up-driven through WNS, with the longer cadence serving more as a safety net than as the main delivery mechanism. It is also good to know that this WNS push mechanism ALSO has its own timers and throttling in place.

That is why configuration changes often feel random. Not because Intune is treating policies more kindly, but because the policy engine follows a different wake up and timer model.

When an App Is Not Really an App

This is where things are starting to get even more confusing. Some things that appear as applications in the Intune portal are still managed on the policy side (OMA-DM Client). Microsoft 365 Apps is a well-known example. As shown below, the Microsoft 365 Apps is nothing more than a policy (CSP) being sent to the device.

MSI’s line of business apps delivered through Enterprise Desktop App Management is another.

From the operating system’s point of view, those are NOT the responsibility of the Intune Management Extension (IME). They are CSP-backed instructions that belong to the policy pipeline.

That is why they can show up faster than Win32 apps or scripts. They are not faster because they are more important. They are faster because they are not going through the Intune Management Extension at all… With it, they don’t rely on the internal IME Win32App workload Timer.

The IME Side: Separate Workloads, Separate Intune Timing

Now let us move to the side that causes even more confusion.Win32 apps, PowerShell scripts, remediations, and other task based workloads are handled by the Intune Management Extension (IME).

This is NOT the same engine as OMA DM, and it does not behave like OMA DM. It does NOT speak SyncML.

The IME does not enforce the state through CSPs. Instead, it retrieves its workloads and processes them through the local SideCar agent. This is the moment where timing starts to feel inconsistent if we do not realize what is happening behind the scenes. The IME/Sidecar Agent has its own workload timers, and they are all different…..

That means the question is not simply, “Why didn’t my device received the change” The real question is, “Did the correct workload engine evaluate it yet?” Once we ask that question instead, a lot of weird behavior suddenly becomes much easier to explain.

Why PowerShell Scripts Intune Timing feels So Different

PowerShell scripts are one of the best examples. From our point of view, everything looks ready. The script is assigned. The device is online. The IME service is installed and healthy. So it feels logical to expect the script to run immediately. But that expectation is based on the wrong timing model.

The PowerShell workload is not waiting on the OMA DM path. It is waiting on the IME’s own workload engine. Our PowerShell script delay article shows this very clearly. When a user logs on, that event can trigger the same timer-driven workload engine that handles scheduled script evaluation

This means that the PowerShell check can happen immediately. Without that trigger, the script may simply wait for the next timer interval of 28800000 milliseconds, which is 8 hours.

That is the real reason PowerShell script timing feels so different from policy timing. A PowerShell script can be assigned right away, but until the PowerShell IME workload wakes up, NOTHING will happen on the device. If we are not aware of that behavior, it just looks like Intune is being slow for no reason.

Why Required Apps Sometimes Wait Exactly One Hour

The required Win32 app story is another perfect example, especially during Autopilot. This one often feels even stranger because the delay is so exact. Once the required Win32 apps are assigned, and the user reaches the desktop, nothing happens. About an hour later, the apps suddenly start installing.

Exactly that kind of behavior looks random until we look at the logs and code. The IME does not jump straight into the required app workload. It first runs through the available app workload. That order matters. If the available app pass exists early because no valid user is ready yet, the session is still too early, or the ESP state is not in the right place, the IME does not immediately continue to the required apps. Instead, it schedules the next attempt for 3600000 milliseconds later. That is one hour.

The delay often looks very exact for a reason. This is not some mysterious pause, nor is it the policy engine being slow. Nor is it really an Autopilot problem. What you are seeing is the Win32 app workload following its own scheduling logic. Autopilot simply makes that timing easier to notice because the first user session and the first IME application evaluation often collide.

That distinction matters a lot. Required apps are still workload-based in general. Autopilot is just the place where that behavior becomes easiest to see.

What the Sync Button Really Does

The magical Sync button is another of the biggest sources of misunderstanding in Intune.  Let me explain. Because when we press Sync in the portal, it is tempting to think we just told the whole device to do everything now. But again….that is not what happens.

The remote Sync action wakes the MDM path. Intune asks WNS to deliver a push. Windows records that state change internally, the PushLaunch task reacts to it, deviceenroller.exe gets involved, and only then does the device decide whether to start the OMA DM session immediately or queue it before omadmclient finally syncs policies. In other words, pressing Sync mainly wakes the policy side. It does NOT directly force every IME workload to run.

That is why pressing Sync can make policies appear quickly while PowerShell scripts and Win32 apps are still waiting on the IME timer to expire. The sync button did something. It just did not wake the engine we were expecting.

Why the Split Exists in the First Place

Hopefully, at this point, the inconsistency starts to look a lot less inconsistent. Policies are state. Scripts, apps, and remediations are tasks. Those are NOT the same thing, and Windows does not treat them as the same thing.

The old OMA DM model works, but it is chatty. This MMP C article explains that the classic enforcement flow follows a Get, Set, Get loop. Multiply that across many CSPs, and every setting becomes another chain of cloud round-trips. If one part of that chain fails, the device can end up waiting until the next scheduled sync.  That is exactly why Microsoft started building the next model.

With WinDC and MMP C, Intune can send down a single declarative document that describes the intended state. The device stores it locally, applies it through WinDC, and then a scheduled refresh task checks for drift and reapplies as needed. Even offline, drift correction can continue because the device already has the desired state locally. The old model becomes much closer to “get once, set, and self heal.” That tells us something important. The split between policy and task execution is not accidental. It exists because different workloads need different execution models.

Where This Is Heading Next with Intune Timing

That brings us to the interesting part. If the policy side is moving toward MMP-C and declared configuration, what happens to the IME side? This is where IC3 (I SEE 3) becomes interesting.

Our IC3 article shows that the Intune Management Extension is learning a very different communication model from the older WNS pattern. Instead of waiting on built-in IME timers, the IME could keep a socket open to Microsoft’s IC3 backbone. That means real-time awareness, connection state, retry logic, and a more direct delivery path for device actions and other IME-owned work.

The same post describes that IC3 is direct, while WNS was the middleman for policy delivery. That naturally raises the question we should be asking. What if IC3 becomes the real-time communication channel for IME workloads /MMP-C and current MDM device actions?

If that happens, Win32 apps, scripts, remediations, and other IME-owned tasks may no longer need to rely so heavily on waiting for the next timer-based evaluation. Instead of polling and hoping the next workload cycle arrives soon, the IC3 service could notify the IME directly when new work is ready.

The policy side would continue evolving through MMP-C and declared configuration. The IME side could evolve into a more direct real time task channel through IC3. In other words, the future may not be one engine doing everything. It may be two different engines becoming better at their own job.

Why Intune Timing could feel Inconsistent

Once we can see the different engines, the timing story changes completely. Policies travel through the Windows MDM stack and are mostly wake-up driven through WNS. Some things that look like apps still ride that same path because they are really CSP-backed policy. Win32 apps, scripts, and remediations belong to IME, which means they follow their own workload logic and their own timers. Some remote actions can wake more direct paths, while future IME workloads may move toward IC3 instead of relying so heavily on timer-based evaluation.

So the next time timing feels inconsistent, the better question is not, “Why is Intune slow?” The better question is, “Which engine owns this workload?” That is usually where the answer starts.

The post Intune Timing Demystified: What Actually Happens Behind the Scenes appeared first on Patch My PC.

Improvements

• When selecting the Use Existing App Registration option for SMTP oAuth, you are now given a choice of Intune tenants to choose from.​
• Ensure the Publisher gracefully handles the case where the Publisher connection is deleted from the cloud.

Fixes

• Clicking Browse in the Manage Pre/Post Scripts window would sometimes cause the Publisher to force close.​
• The product export feature in the Advanced tab no longer exports duplicate rows for Intune applications and updates.​
• Large Intune reports would fail to write to disk, causing an Out Of Memory exception.​
• Intune tenant names were not correctly shown in the webhook list under the Alerts tab.​
• Fixed a bug where some applications would not be found in the local content cache.​
• Ensure the OS requirements are set appropriately for ConfigMgr and Intune Publishing.

The post Patch My PC Publisher Preview Version 2.1.100.380 Released appeared first on Patch My PC.

Introduction

For a long time, Intel Threat Detection Technology (Intel TDT) was one of those interesting features sitting quietly in the background of Microsoft Defender. It promised hardware-assisted threat detection using CPU telemetry, something that sounded both powerful and slightly mysterious.

In practice, it mostly stayed invisible unless you went looking for it. Recently, that changed…. Just a bit…While investigating Defender configuration behavior, something unexpected surfaced: the Intune Policy used to control Intel TDT suddenly stopped working after the latest Windows Defender KB2267602 Update.

At first glance, it looked like a normal Intune policy failure. After digging deeper, it became clear that something more fundamental had changed inside the Defender agent.  Before looking at the 0x86000002 failure, it helps to understand what Intel TDT actually is.

What Intel Threat Detection (Intel TDT) Technology Does

Intel TDT is a hardware-assisted detection capability built into certain Intel CPUs. Instead of relying purely on software signals, Defender can use CPU performance telemetry to detect suspicious behavior patterns. Typical examples include cryptomining workloads or encryption patterns associated with ransomware.

The idea is simple: malicious activity often produces very specific CPU instruction patterns. Intel exposes those patterns through hardware telemetry, and Defender can analyze them with machine learning models. When supported hardware is present, Defender can use this signal alongside its normal protection layers, such as behavioral monitoring, cloud intelligence, and attack surface reduction. In most environments, this feature does not require manual configuration. When supported hardware is present and Defender is running, the Intel TDT integration activates automatically.

However, Windows also exposed a configuration switch that allows administrators to explicitly enable or disable the feature.

The Intune Policy That Used to Control Intel TDT

Administrators had two main ways to control the feature. The first was a local PowerShell configuration through Defender preferences: Set-MpPreference -IntelTDTEnabled 1

The second was through the Defender MDM configuration CSP  (Settings Catalog) used by Intune: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled

When configured through Intune, the policy was successfully applied via SyncML through the Defender CSP provider.

The node mapped to the Defender preference model behind the scenes and enabled the hardware telemetry integration.

Which we could also spot in the registry as well

For a long time, this Defender Intel TDT policy worked exactly as expected.

The Policy Works… Until….(0x86000002)

On freshly installed Windows devices, the defender configuration behaves normally. The policy applies successfully, and Defender accepts the Intel TDT configuration. Besides the Intune policy, the PowerShell command also still works as expected. After updating the latest Windows Defender Signatures (Engine Update) twice, something changed.

As shown above, the same PowerShell command that previously enabled Intel TDT now reports that the Intel TDT setting has been deprecated.

At the same time, Intune deployments will start failing with the well-known error 65000.

In other scenarios, that same error could be associated with licensing issues (or any other error that Microsoft didn’t map to a proper error code). In this case, it is not. The real error becomes visible when examining the DeviceManagement event logs.

The Actual 0x86000002 Error Behind Intune’s 65000

Inside the DeviceManagement-Enterprise-Diagnostics-Provider log, the event shows the real failure.

Command failure status:
CSP Name: Defender: Command Type: Add
CSP URI: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled
Result: Unknown Win32 Error code: 0x86000002

This code originates from the Windows MDM stack and indicates that the requested node doesn’t exist and is no longer supported. In other words, Windows is rejecting the request before it ever reaches the Defender engine.

Testing the CSP Directly

To remove Intune from the equation, the next step was to query the CSP directly through SyncML. Using the local SyncML testing tool, we queried the configuration CSP defender node to find out if the IntelTDT was indeed gone

As shown above, the IntelTDTEnabled node no longer exists in the Defender CSP. When performing the same steps on device that did NOT had the latest Defender Updates installed, the Intel TDT node was still there:

At this point, it was clear that Intune was not the problem. The Intel TDT node itself was being rejected by the Windows MDM stack.

Recreating the Node Manually also got 0x8600002

Just to be certain, the next attempt was to manually add the IntelTDT node and apply the configuration again per the Defender CSP policy.

The result was identical to that of Intune. The request failed immediately with the same 0x86000002 error code. If the issue had been caused by missing configuration data or corrupted policy state, recreating the node should have restored the functionality. Instead, the result remained unchanged. Even when manually creating the node, Windows still rejects the request. The node simply no longer exists as a valid configuration endpoint.

Missing Documentation and No Warning in Intune

One thing that makes this change particularly confusing is that there is currently no documentation describing this behavior. (Please Note: I reached out to MSFT: They are aware of the issue.)

The Microsoft Defender CSP documentation still lists the following configuration node: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled. Nothing in the documentation indicates that the setting has been deprecated or removed. From the documentation alone, administrators would assume the policy is still valid and supported.

However, systems updated with the latest Defender Updates reject the Intel TDT CSP node completely. Any attempt to configure it through Intune results in the well-known 65000 error. Looking at the device logs reveals the real failure: 0x86000002. This error originates from the Windows MDM stack and means the node is no longer supported by the operating system. At the same time, the Intune portal itself also provides no indication that the feature has been deprecated. So, Microsoft, maybe adding this to start with?

Because the policy can still be configured and assigned. The only visible symptom is the device’s deployment failure. From an administrator’s perspective, this creates an awkward situation:

Without checking the device logs or testing the CSP directly, it is easy to assume something is wrong with the configuration or the device. In reality, the configuration endpoint itself appears to have been removed or deprecated, while the documentation and management tools have not yet been updated to reflect that change.

Is Intel TDT Deprecated or Just the IntelTDTEnabled Policy?

One interesting detail is that the default value for IntelTDTEnabled now appears to be False.

Attempts to enable it through PowerShell return a deprecation warning while the Defender CSP fails with error 0x86000002. At first glance, that could suggest the Intel TDT integration itself has been removed. However, there is currently no public documentation from Microsoft or Intel confirming that Intel Threat Detection Technology has been deprecated.

The evidence shows that the administrator-controlled setting for Intel TDT is no longer functional. In other words, the configuration interface seems to be deprecated, while the underlying hardware capability may still exist and could be managed internally by Microsoft Defender rather than through an exposed policy setting.

Looking at the Defender engine itself also supports that theory. The mpengine.dll still contains a full TDT agent implementation that initializes the Intel TDT runtime, retrieves CPU information, loads configuration, and prepares telemetry handling. That suggests the Intel TDT component is still present inside Defender. What appears to have changed is the administrator-facing control surface. The IntelTDTEnabled policy can no longer be configured, while the underlying detection capability may still be used internally by the Defender engine.

0x86000002 Summary

After the latest Defender Engine Update, the Defender CSP node IntelTDTEnabled stops working. Intune deployments start failing with error 65000, while the device logs reveal the real cause: 0x86000002, indicating the node is no longer supported. The setting also shows as deprecated when using Set-MpPreference.

The confusing part is that the Defender documentation still lists the node as supported, and Intune still allows the policy to be configured. The result is a policy that appears valid but can no longer be applied because the CSP node has quietly disappeared from Windows.

The post Intel TDT Deprecated: Defender CSP Error 0x86000002 appeared first on Patch My PC.

In this blog, we go deeper and examine what changed inside the OMA-DM client, why the delay started to appear, and how the February 2026 update (24h2/25h2 only) removed the five-minute delay, effectively making Intune remote actions instant (aka fast) again.

Introduction to Intune Device Actions

A long time ago, executing Remote Intune Device Actions (Sync/Wipe/EPM Support Approved) behaved in a very direct and predictable way. When an admin pressed the Sync button or changed a policy assignment, the device received the push notification. From there on, the OMA-DM client woke up, and the management session started immediately.

The push notification itself contains no instructions and does not describe what has changed. It is simply a wake-up signal that tells the device something might have changed and that it should contact the service to retrieve the latest policies and settings. Even though the push carried no explicit intent, the OMA-DM client consistently treated it as a critical message. Why? Because it was classified that way, the session bypassed any deferred-execution logic and was executed immediately.

That behavior made Device Actions feel fast, responsive, and pretty reliable in the past (a couple of years back). The device did not wait, nothing was placed into a queue, and the OMA-DM session was launched as soon as the push notification arrived. Pressing the Device Action: Sync effectively meant “run now,” and for years that model stayed intact.

At some point, however, that instant behavior changed. The same push notification still arrived, and the device still received the signal, but the session no longer started immediately. Instead of launching right away, the request was deferred and scheduled to run the real check-in later (5 minutes).

A 5 minute Delay Appeared After performing a Device Action from Intune

With it, a 5-minute delay window appeared, and devices suddenly seemed idle even though the push notification had clearly been delivered.

From the outside, the behavior looked unreliable or inconsistent. From the inside, it was the result of an architectural change in how the push message was classified and executed. The rest of this story follows that transition:

How the original behavior worked. What changed inside the OMA-DM code path, how that unexpectedly affected Intune scenarios such as EPM Support Approved, and how Microsoft now introduced a dedicated bypass to restore instant execution for remote push-initiated sessions. Even though that bypass still remains gated behind a servicing feature flag today. (AKA you need the 2026-02 update)

Phase One: When the Device Action Message Was Always Critical

When reviewing the older OMA-DM code, push-initiated sessions (Remote Intune Device Actions) were always treated as critical operations. The classification within IsCriticalMsg ensured that a push notification from Intune was immediately triggered rather than queued or delayed.

When the push notification arrived, the client woke up, OmaDmInitiateSession_Internal was invoked, and the OMADM session began right away.

No queueing, no scheduling logic, and with it, no waiting period. The sync execution was pretty instant. This critical classification mattered because the client had no insight into the meaning of the push notification itself. The push did not reveal whether it was related to a configuration change, a policy update, or a device action. The only safe thing the client could assume was that it needed to wake up and start working. With it running, the sync started instantly.

That approach worked, and it aligned well with how administrators expected Remote Sync Device Action to behave. Sync meant “call the service now,” and because every push-driven session was treated as critical, the platform always honoured that expectation. Which was great…

Phase Two: When Push Stopped Being Critical

Some time later, a new execution logic was introduced into the OMA-DM client. The platform gained the ability to defer the Intune Sync, rather than always executing it immediately. To support that, the session initiation state could be deferred and queued. As a result, the session was classified as non-critical and routed to a queued execution model rather than being launched immediately.

This queued path was handled through ScheduleQueuedTask, which created the infamous scheduled task under the EnterpriseMgmtNonCritical task folder.

That queued scheduled task was tied to several triggers, including WNF network-state events. It operated within a fixed execution window of five minutes. Any sync session that entered this path no longer ran instantly; instead, it waited inside that time window and was retried when conditions allowed.

The key change was not the introduction of the queue itself, it was the shift in classification logic inside IsCriticalMsg. Push-initiated OMADM sessions were no longer automatically treated as critical. Once the push notification was stopped from qualifying as critical, it no longer bypassed the queue. Instead, it followed the same deferred execution path as other non-critical workloads. From that moment onward, the five-minute delay effectively became part of the Remote Device Action, such as a remote Wipe, Sync, or approval of an EPM elevation request.

Slower After 8 Hours

This was also when the behaviour identified in our earlier research began to manifest in real-world environments. In that previous analysis, remote actions felt fast shortly after enrollment but noticeably slower the next day. What appeared to be timing drift turned out to be the moment the client stopped treating push notifications as critical and began routing those same sessions into the queued execution pipeline.

From a reliability perspective, the change made sense for background workloads. Queuing reduced retry storms, prevented sessions from running on unstable networks, and allowed work to be batched more safely. But the same push notification is reused for almost everything Intune triggers: policy refresh, EPM Approval Requests, and even urgent device actions such as a Device wipe. That meant the change had a much broader impact than intended. The OMADM client still had no idea what the push actually represented. It only knew that a push had arrived. Instead of running immediately, it is now assumed that waiting is acceptable, even when administrators expect the device to respond straight away.

Phase Three: Defining the Push As Critical

Over time, it became clear that NOT every push initiated an OMA-DM session should be delayed.
Some scenarios required immediate execution (EPM) instead of moving through the deferred pipeline.
Microsoft introduced a selective bypass in the updated IsCriticalMsg logic.

This change allowed some push messages to be marked as critical again.
That restored the immediate execution path in cases where the delay caused problems.
When a push is marked critical, the OMA-DM session skips ShouldMsgBeQueued.
It does not enter the scheduled task and is launched directly, like in the original behavior.

To control how and when this bypass is applied, the mechanism was placed behind a servicing feature flag: Feature_Servicing_DMPushMessageSetCritical

This indicates that Microsoft did not want to flip the behaviour globally in a single step, but instead intended to roll it out gradually (Controlled Feature Rollout). From there on, they could observe the impact and selectively enable the critical lane where appropriate. Conceptually, the model shifts to a more balanced state: the queue becomes the safe default for most scenarios, while the critical path is reintroduced only when delay is known to be harmful or disruptive.

So that leaves us with 1 big question:  When will this gradual Rollout Happen? Well… that’s something I will keep a secret until I will notice the Control Feature Rollout kicking in.

Summary

Remote Device Actions, such as wipe, sync, or EPM elevation requests, originally ran instantly because push messages were treated as critical. The OMA-DM client launched sessions immediately instead of queueing them. After the IsCriticalMsg change (a couple of years ago), push sessions were deferred to a queued path with a 5-minute delay. This also affected policy refresh and urgent actions such as wipe and EPM. In February 2026, Microsoft added a bypass(DmPushMessageSetCritical) that restores instant execution for all remote Intune Device Actions on Windows 24h2/25h2 (Not 23h2 ).

The post Intune Device Actions: Microsoft brings back instant Remote Actions appeared first on Patch My PC.

PowerShell Script Installer Support

Intune recently gained a powerful capability: support for PowerShell installer scripts in Win32 apps, as documented in our deep-dive on PowerShell Script Installer Support for Win32 Apps in Intune.

This new Win32App feature includes a user-visible switch to run the script in 32-bit or 64-bit PowerShell, giving administrators control over the execution architecture of their install logic.

However, in practice, that switch doesn’t behave the way people expect. Even when the Win32 app policy is configured with the 64-bit option enabled, the installer script still launches under 32-bit PowerShell inside the Intune Management Extension (IME). This is clearly visible when Procmon is running.

The main problem isn’t that the UI switch is invalid or that the installer script logic builds the wrong command line, the IME code resolves the registry paths correctly, and the command string references System32\WindowsPowerShell.

The missing piece is how the process is actually launched under the hood. This became clear when comparing the installer script path with how Microsoft already handles architecture in the PowerShell AgentExecutor, which does properly honor the 32-bit / 64-bit preference by managing Windows file system redirection at the right point.

What Really Happens Inside IME

The Intune Management Extension runs as a 32-bit process on 64-bit Windows.

Whenever a 32-bit process attempts to access C:\Windows\System32, Windows automatically redirects that request to C:\Windows\SysWOW64. This redirection happens transparently and is designed to preserve compatibility for 32-bit applications running on 64-bit systems. So even when IME constructs a command line that clearly points to the System32 version of PowerShell, Windows intercepts the request and reroutes it to the 32 bit binary under SysWOW64.

The IME process believes it is starting the correct executable, but the operating system quietly substitutes it. The important detail is that this substitution happens at process creation time, not at string construction time. Therefore, changing registry paths or modifying command line strings alone does not prevent redirection.

Why the 64 Bit Toggle Does Not Work for the Script Installer

When the Win32 app installer logic builds the PowerShell command line, it correctly queries the registry to determine the appropriate PowerShell path based on the RunAs32Bit flag. If the flag indicates 64-bit execution, it resolves the System32 path. On paper, that logic is correct.

The issue appears later in the flow when LaunchInstaller ultimately calls CreateProcess or CreateProcessAsUser.

At that moment, because IME itself is a 32-bit process, Windows applies WOW64 file system redirection unless it is explicitly disabled.

Since the Win32 installer implementation does not disable redirection before creating the process, the request to start the System32 PowerShell executable is silently redirected to SysWOW64. As a result, the script installer 64-bit toggle changes the resolved path but never alters the execution context. The system still launches 32-bit PowerShell because redirection remains active.

How Microsoft Solved This in the PowerShell Executor

Interestingly, Microsoft already addressed this exact scenario in the PowerShell execution component located in Microsoft.Management.Services.IntuneWindowsAgent.AgentExecutor.PowershellExecutor. In the Run2 method, before starting the PowerShell process, the code calls Wow64DisableWow64FsRedirection.

That API temporarily disables file system redirection for the current thread. With redirection disabled, a request to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe is honored exactly as written. After the process is created, the code restores the original state using Wow64RevertWow64FsRedirection.

This Wow64RevertWow64FsRedirection. makes sure a 32 bit host can temporarily stop Windows from redirecting System32 to SysWOW64, so the real 64 bit PowerShell actually starts. That is why normal Intune PowerShell scripts truly run in the 32-bit or 64-bit mode you selected.

What Was Missed in the New Installer Script Implementation

When PowerShell installer script support was added to the Win32 app plug-in, the implementation reused parts of the command line construction logic, but did NOT replicate the redirection handling from the PowerShell executor. The flow works as intended, and the command line reflects the desired architecture, yet the crucial step of disabling WOW64 redirection was omitted.

Because that API call is missing, the execution still occurs within the redirected environment of the 32 bit IME process. The switch appears functional from a configuration perspective, but the underlying process launch does not enforce the architecture choice at the operating system level.

Why This  Matters

Running a script under 32-bit PowerShell instead of 64-bit PowerShell is not a minor variation. Registry access behaves differently because 32 bit processes are redirected to WOW6432Node under HKLM\Software. File system paths may resolve differently, and certain modules or COM registrations might only exist in the 64-bit context.

This mismatch can lead to subtle installation failures or detection inconsistencies that are difficult to diagnose because the configuration seems correct. Administrators trust the 64-bit toggle, but the execution environment does not honor it.

How Microsoft Could Easily fix this

The correction mirrors what is already implemented in PowershellExecutor.Run2. Before invoking CreateProcess or CreateProcessAsUser inside LaunchInstaller, the code must check whether the operating system is 64-bit and whether the current process is 32-bit. If those conditions are met and the installer script is intended to run in 64-bit mode, it should call Wow64DisableWow64FsRedirection before creating the process.

After the process has been created, the code should restore the previous state using Wow64RevertWow64FsRedirection inside a finally block. This ensures that redirection is disabled only for that specific launch and immediately re enabled afterward.

With that change in place, the System32 path is no longer rewritten to SysWOW64 during process creation, and the installer script genuinely runs under the 64-bit PowerShell host as intended.

How We Could Fix It in the Meantime

With Microsoft still needing to fix this WOW64 issue, we need to fix it ourselves in the meantime. Fixing it, is pretty easy, just ensure you add this to the top of your PowerShell script to ensure PowerShell will be relaunched as 64-bits.

# Relaunch in 64 bit PowerShell when running under 32 bit host
if ($env:PROCESSOR_ARCHITECTURE -eq "x86" -and $env:PROCESSOR_ARCHITEW6432)
{
    $ps64 = Join-Path $env:WINDIR "SysNative\WindowsPowerShell\v1.0\powershell.exe"
    if (Test-Path $ps64)
    {
        & $ps64 -NoProfile -ExecutionPolicy Bypass -File $PSCommandPath
        exit $LASTEXITCODE
    }
}

The Core Problem

The registry lookup logic is correct. The command line construction is correct. The configuration toggle is exposed and stored correctly. The missing piece is the temporary suspension of WOW64 file system redirection at the moment the process is created.

The PowerShell executor includes that safeguard. The newer Win32 installer script implementation does not. The result is not a broken switch in the user interface but an incomplete implementation at the process creation layer, where Windows ultimately decides which binary is executed.

The post Intune Win32App PowerShell Script Installer 64 Bit Switch Not Working appeared first on Patch My PC.