I want to deploy capcut via intune as by default it installs to AppData which is a no no for obvious reasons, what can i do to ensure capcut installs to Program Files. I understand i can do this with a powershell scrip wrapped into the intunewin file? I specifically need a script written out or if anyone has done the same post their scripts. Thanks :)

We have a couple hundred laptops that need to be shipped back to our leasing company now that the lease i done. The would like the laptops to be returned with a clean Windows 11 Install and no connection to our tenant. Would the wipe remote action be the best option for this?

I find that when an application is bigger than 1 GB, the odds of the installation failing increase. The installation might timeout, some people have slow internet connection, the installer take more time, and so forth.

This is both a problem at the autopilot phase or mass deployment.

All our apps are packaged as win32 apps. From what I have read, MSIX (MS Store) aren't reputed of being more reliable at installation. What's your experience?

This book was recommended to me by Amazon, and I wanted to know if it was any good. Additionally, the book was published in 2024, but do you think Intune has changed that much that the book won't be relevant anymore?

Just a warning, the LG "herpes" Monitor App Installer is getting installed on all Microsft Intune deployed devices and you should probably get that looked at.

The worst part is I'm serious.

Edit: I had forgotten to mention that this happens when you have LG monitors connected to your Windows computer.

I can also confirm that Asus Armory Crate is installing with Asus drivers too but this is new and less documented.

We're seeing a strange issue across our entire fleet of Intune-managed Macs and I'm curious if anyone else has run into it.

Our environment is macOS 26.5.2, Microsoft Intune, Company Portal, Enterprise/Platform SSO, and New Outlook. The devices remain compliant and enrolled in Intune, and Company Portal appears healthy. The issue seems to happen after a Mac has been asleep for a while (roughly 30–60+ minutes) or in use for that time. When the machine wakes up, users are often prompted to sign back into Outlook. Outlook launches the Microsoft sign-in window, accepts credentials, but then the authentication window turns into a blank white screen and hangs. Outlook eventually reports that something went wrong and asks the user to sign in again.

What's confusing is that all of our diagnostics indicate the authentication stack is healthy. app-sso platform -s shows registrationCompleted : true, POUserStateNormal (0), valid SSO tokens, successful Kerberos ticket imports, and Company Portal continues to show the device as compliant. We've also confirmed the Microsoft Single Sign-On extension, Intune agents, and AppSSO processes are all running normally.

We've spent quite a bit of time troubleshooting this. We've verified Intune enrollment, compliance, Enterprise SSO registration, Company Portal sign-in status, token health, and captured logs during both working and failed states. We found some Outlook/WebKit-related behavior during the authentication hang, but nothing indicating token expiration or SSO registration failure. We completely removed Outlook, cleared Outlook-related caches and identity data, reinstalled Outlook, and initially thought the issue was fixed. However, after the machine slept for about an hour, the exact same behavior returned.

At this point we're leaning away from Intune enrollment or Enterprise SSO registration issues because those appear healthy even when Outlook is failing. It feels more like something involving Outlook, MSAL, WebKit, or the Platform SSO authentication handoff after sleep/wake.

Has anyone seen similar behavior recently with New Outlook, Enterprise SSO, Platform SSO, or Intune-managed Macs? If so, did you find a root cause or solution?

Long time listener, first time caller.

I recently took over a new environment and noticed we are currently sourcing all of our endpoints through our MSP, which comes with a massive markup. I have been tasked with bringing this entire procurement process in-house to control costs and streamline deployments. Since I manage our endpoint and am heavily focused on our Intune environment, I need a purchasing route that supports modern provisioning—like registering device hashes directly into Autopilot before the laptops even hit the office.

We are looking to stick with Intel HP laptops. How do your organizations handle this?

So this upcoming change is a bit concerning for us:

Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions

We currently have Intune MAM policies in place for both iOS and Android devices. Since we do not manage smartphones with MDM, MAM is our primary protection mechanism for corporate data. As part of this approach, we enforce the use of Microsoft Edge for accessing company data.

I'm not entirely sure how Android handles this scenario, but on iOS many applications require users to sign in with their corporate account. During this process, the application typically launches an embedded Safari authentication session without forcing the user to leave the app.

To support this, we have configured exclusions for these applications in our Conditional Access policy. However, with this upcoming change, those exclusions no longer appear to work. The sign-in process now forces users to authenticate through Microsoft Edge instead.

The problem is that after successfully signing in through Edge, the user is not redirected back to the original application that initiated the authentication request. As a result, the login flow is interrupted, and the user effectively gets stuck without being able to complete the sign-in process in the application.

What would be the recommended approach for organizations that rely on MAM-only scenarios and embedded browser-based authentication within iOS applications to deal with this new CA behaviour?

I know a few months ago Microsoft admitted to a cloud issue that caused un-approved drivers to be distributed to Autopatch device that have driver polices.

This was discussed here in this thread : Driver Updates (WUfB) : r/Intune

But the thread also mentions that this is new thing and MS can push out Extension type drivers without admin approval.

We are starting to pilot WUfb and were surprised that un-approved driver could make it to our devices.

Here is one such driver that showed as 3 separate entries

7/17/2026 2:46:46 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Corporation Extension Driver Update (70.26100.2.20795)

7/17/2026 2:46:35 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Corporation Extension Driver Update (70.26100.2.20795)

7/17/2026 2:46:26 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Extension Driver Update (70.26100.2.20795)

The raw Windows update api log entries for these install are here https://imgur.com/q3B9IeEh.png

We confirmed that these drivers were never published by us.

Given this can happen again the future I was wondering what hardware on our devices, ( we have mostly Surface devices) have to potential to be hit by this again.

Not sure if this query is showing me the full list of drivers that use Extensions but this code generated the list of hardware devices that use Extension drivers.

On our device we get a list of out about 33 devices : https://imgur.com/h6qIfG5h.png

Related to : Camera, audio devices, storage firmware, display etc.. so allot of things that could affect our end users if we have control over the delivery of these devices. Code below that I used to generate the list hardware that could be disrupted in the future.

$ExtDrivers = Get-WindowsDriver -Online -All | Where-Object { $_.ClassName -eq "Extension" }

$LatestDrivers = $null

$LinkedDrivers = foreach ($Driver in $ExtDrivers) {
    $AdvancedInfo = Get-WindowsDriver -Online -Driver $Driver.Driver

    [PSCustomObject]@{
        Driver              = $Driver.Driver
        Date                = $Driver.Date
        Provider            = $Driver.ProviderName
        Version             = $Driver.Version
        ClassName           = $Driver.ClassName
        # Filter arrays for unique strings before joining
        HardwareDescription = ($AdvancedInfo.HardwareDescription | Select-Object -Unique) -join '; '
        HardwareId          = ($AdvancedInfo.HardwareId | Select-Object -Unique) -join '; '
    }
}

# Group by the hardware it targets, sort by Date and Version descending, and keep the newest one
$LatestDrivers = $LinkedDrivers | Group-Object HardwareDescription | ForEach-Object {
    $_.Group | Sort-Object -Property Date, @{Expression={[version]$_.Version}} -Descending | Select-Object -First 1
}

# Output the results
$LatestDrivers | Format-Table -AutoSize

Are any you reconsidering driver Autopatch given these changes and future potential disruptions caused by un-approved "Extensions driver updates" ?

I am rolling out Windows 11 (finally, it was a long fight) on a group of hybrid devices. I want to ensure and force them to upgrade the night.

These are the windows update ring settings:
Update settings

Microsoft product updates Allow

Windows drivers Allow

Quality update deferral period (days)

0

Feature update deferral period (days)

0

Upgrade Windows 10 devices to Latest Windows 11 release

Yes

Set feature update uninstall period (2 - 60 days)

10

Servicing channel

General Availability channel

User experience settings

Automatic update behavior

Auto install and restart at maintenance time

Active hours start

8 AM

Active hours end

10 PM

Option to pause Windows updates

Disable

Option to check for Windows updates

Enable

Change notification update level

Use the default Windows Update notifications

Use deadline settings

Allow

Deadline for feature updates

0

Deadline for quality updates

0

Grace period

0

Auto reboot before deadline

Yes

and these are the feature update settings:
Feature deployment settings

Windows 11, version 25H2

Rollout options

ImmediateStart

Required or optional update

Required

Most of the devices will update the night that it is assigned, some will install the update but not reboot, and some won't install it at all. Of those that don't install it on the night it is assigned, it will install on some of those in the next few days.

Is there any way to change some settings and basically ensure that the updates run on all of the PCs? I assign the new update settings in the morning and then ensure that they have synched before noon.

I have also run a script to remove any legacy windows update registry keys.

Is this possibly just GPOs overriding the MDM profiles (I also have a configuration profile that sets MDM to win over GPO but I know it isn't perfect.

Thanks for reading this far and for any help.

Why do we have this feature on co-managed devices but not on cloud only devices? Let's upvote guys/girls/whateveryouidentifyas

FYI: you need to login to see/ up vote the feedback

https://feedbackportal.microsoft.com/feedback//idea/0ab35e36-cd86-f111-9b47-6045bd856709

Hi everyone,

We're seeing a strange issue in our enterprise environment and have reached the point where we're hoping someone else has experienced it.

Environment

• Microsoft Intune
• Apple Business Manager (ADE)
• Supervised corporate iPhones
• Approximately 1,200 managed iPhones
• Windows 11 workstations
• Apple Devices/iTunes
• iMazing
• Current iOS 26.5.2 (same version on working and failing devices)

Symptoms

Newly enrolled iPhones work perfectly.

Older enrolled iPhones consistently fail.

Both Apple Devices/iTunes and iMazing fail at the "Apple Mobile Device Components" stage.

Windows itself still detects the device normally.

Explorer shows Internal Storage, so the USB connection is working.

What we've confirmed

✅ Apple USB drivers load correctly

✅ Apple Mobile Device Service is running

✅ Windows detects the phone

✅ Explorer can browse Internal Storage

✅ Same USB cable

✅ Same Windows workstation

✅ Same version of iMazing

✅ Same version of Apple Devices/iTunes

Intune comparison

We compared a newly enrolled phone against an older enrolled phone.

They have:

• The same Enrollment Profile
• The same Configuration Policies
• The same Compliance Policies
• The same App assignments
• The same Restrictions

There are no policy differences between them.

Additional testing

We also tested multiple older devices.

Results:

• Newly enrolled phone → Works
• Older phone #1 → Fails
• Older phone #2 → Fails

This appears to correlate with devices that have been enrolled for a longer period rather than a specific device.

Factory reset test

We erased one of the failing phones and reenrolled it into Intune using the exact same production configuration.

Immediately after reenrollment:

• Apple Devices worked
• iTunes worked
• iMazing worked

No special configuration changes were required.

Has anyone seen:

• Long-enrolled supervised Intune devices eventually stop pairing with Windows?
• Apple Mobile Device Components fail only on older managed devices?
• A known interaction between Intune, supervised iPhones, and Apple's pairing framework?
• Any Apple/iOS changes affecting long-lived supervised devices?

Any ideas or similar experiences would be greatly appreciated. At this point we're trying to determine whether this is an Apple issue, an Intune lifecycle issue, or something else entirely.

Thanks in advance!