r/Intune

I've been blinding myself late at night for years and was too lazy to check if the Admin Centers supported dark mode. Sounds like it's been available at least a few years now. Oh well.. consider this your PSA 😅

I deployed a couple of SecureBoot Cert monitoring scripts (no remediation file selected) yesterday. One was the one from MS and another was a homegrown with logging. Deployed to my test group to run hourly. Neither is showing any results in the Intune console after almost 24 hours and I can see in the log file I created that the script has run numerous times since yesterday. Not sure where to look next on this.

Hi all,

We suddenly started seeing a large number of Android Enterprise devices becoming non-compliant in Intune on password-related settings.

Environment:

• Microsoft Intune
• Samsung devices only
• Android Enterprise
• Mix of Fully Managed and Corporate-Owned with Work Profile (COPE)
• Android versions ranging from Android 12 up to Android 16

The issue appeared suddenly without major policy changes.

In the Device Configuration Profiles, Fully Managed devices are showing errors on:

• Device password: Number of sign-in failures before wiping device
• Device password: Required password type
• Device password: Number of passwords required before user can reuse a password
• Device password: Minimum password length
• Device password: Number of days until password expires

In the Device Configuration Profiles, COPE devices are showing errors on:

• Device password: Number of sign-in failures before wiping device
• Device password: Required password type
• Device password: Number of passwords required before user can reuse a password
• Device password: Minimum password length
• Device password: Number of days until password expires

And additionally on:

• Work Profile password: Number of days until password expires
• Work Profile password: Minimum password length
• Work Profile password: Number of passwords required before user can reuse a password
• Work Profile password: Required password type
• Work Profile password: Number of sign-in failures before wiping device

As a result, both device types are becoming non-compliant on these compliance requirements:

• Required password type
• Number of passwords required before user can reuse a password
• Number of days until password expires
• Minimum password length

The most interesting part:

• After the user manually changes their PIN/password, the device becomes compliant again.
• However, users are NOT getting any prompts or notifications from Android/Intune that a password change is required.
• So the remediation is currently completely manual.

All other configuration settings deploy successfully. Only password-related settings are failing.

Has anyone else seen this recently? Any known fixes or recommended changes for this?

Hi everyone,

about 2–3 days ago I modified one of my device configuration profiles in Intune and changed "Allow Telemetry" from "Security" to "Full".

Since then, I noticed that in the report “Device counts by Secure Boot certificate status”, suddenly more than 200 devices are shown as “up to date” (we have around 400 devices in total).

My questions:

• Could this telemetry change have caused this behavior?
• Or is it more likely just a coincidence?

In addition, I now see many devices with the status:
"Under Observation – More Data Needed"

Portal description:

>

I’d appreciate some clarification on this:

• What does this status technically mean?
• Is it a temporary state after changes (e.g. telemetry adjustments)?
• Are there recommended actions to resolve or speed up this status?

Thanks!

Hey everyone, been stuck on this for a while and need fresh eyes.

Environment:

• Windows 11 Multi-session (Build 10.0.26200) — Azure Virtual Desktop
• Hybrid Entra ID join setup
• On-prem AD synced via Entra Connect

The issue: New AVD session hosts in a newly created OU refuse to complete Hybrid Entra ID join. The device always attempts DeviceRenew instead of DeviceRegister even after full domain unjoin → AD object deletion → fresh rejoin.

AzureAdJoined        : NO
Kerberos Ticket Test : FAIL [0x80090311]
Server ErrorSubCode  : error_missing_device
Server Operation     : DeviceRenew  ← should be DeviceRegister

What's weird: Kerberos tickets are valid under SYSTEM (klist -li 0x3e7 shows 3 tickets) but dsregcmd still reports Kerberos FAIL. All other diagnostic tests pass (AD, DRS, connectivity).

Already tried:

• dsregcmd /leave + /join multiple times
• Clearing msDS-KeyCredentialLink from AD
• Full domain rejoin with fresh computer object
• Clearing all CloudDomainJoin and Enrollment registry keys
• Entra Connect delta + full sync
• DeviceWriteback is disabled

Key clue: Older VDIs in a different OU enrolled perfectly fine with the same GPO. Only difference is the new OU.

My questions:

1. Why does dsregcmd fail Kerberos when tickets clearly exist under SYSTEM?
2. Why does it always attempt DeviceRenew instead of DeviceRegister after a completely fresh join?
3. Could Entra Connect OU sync scope be causing error_missing_device?

Any help appreciated! 🙏

THIS IS NOT A PRODUCT PROMOTION POST, IT IS A TEST POST.

I built a small SaaS that auto-tracks new versions of Win32/macOS apps and pushes packaged updates to Intune via Graph API. The interesting bit: it generates the .intunewin format entirely in Node.js — AES-128-CBC encryption, HMAC, Detection.xml, the whole thing — without invoking IntuneWinAppUtil.exe. That lets the whole pipeline run on a Linux Docker container with no Wine, no Windows VM.

I have no Intune sandbox of my own. Microsoft 365 Developer Program rejected my application, and I don't want to risk a real customer tenant. So I'm asking here: would anyone with a non-production Intune tenant (lab, test, personal dev tenant — not a live customer) be willing to spend ~15 minutes validating one end-to-end flow?

What you'd do:

1- Register an account at <frontendtest-verpacker-app-suite-production.up.railway.app> (test deployment, marked with a banner)

2- Connect your Intune tenant (Graph API app registration with standard permissions)

3- Add a Windows app (e.g. Firefox, 7-Zip — anything in winget)

4- Trigger sync → it packages and uploads to your Intune

5- Tell me if the app appears in your Intune portal as a Win32 app ready to assign

Full step-by-step procedure with success/failure criteria is in the repo:

Validation procedure: <https://github.com/emreersoy442/verpacker-app-suite/blob/main/docs/PHASE0\_VALIDATION.md>

What I specifically need to know:

Did the Graph API commit step succeed, or did it return an error?

If it failed: the raw Graph API error body in full — please don't summarize or paraphrase. Paste the entire JSON response from the failed request. That's exactly the diagnostic data I'm missing and can't generate without a real tenant.

Important warnings:

This is a hosted test environment. Data may be reset.

Do NOT connect a production customer tenant. Use a lab/dev/test tenant only.

The .intunewin format implementation is verified against the published spec (svrooij/ContentPrep, MSEndpointMgr/IntuneWin32App) but has never been validated against the real Graph API commit endpoint — that's literally what I'm asking you to help with.

I am really missing the remote tools that I had when managing AD joined computers. Remote access to event viewer, Remote WMI/CIM access, remote PowerShell sessions admin share, etc... I could do a lot of trouble shooting and not interrupt users work. With our current Intune remote support workflow the user has to be logged in and present at the device and we do a shared remote session. This is fine for tier 1 support but for escalations to tier 2 having these remote tools is very helpful. I've tried using the defender live response, it's incredibly limited what it can do at the command line. Anybody else have a remote shell solution (for devices with network line of site) that is secure and preferably doesn't require yet another agent to be installed on the device or a per device subscription?

We currently have our vendor upload Autopilot hardware hashes into Intune on our behalf, as we order a large volume of hardware.

Recently, they have been unable to complete the uploads due to a permissions issue.

For anyone in a similar situation, how are you handling vendor access for Autopilot hash uploads? What permissions or roles are you providing to your vendor?

Any guidance would be helpful as I work through the best approach.

Many of our detect and remediate scripts have a "request policy is null" when we attempt to review settings under manage\properties. Our secondary accounts are elevated in PIM as "Intune Admin."

Request policy is null. Provided id: redacted guid (Code: UnknownError)

• Extension Microsoft_Intune_Enrollment
• Content UXAnalyticsScriptProperties
• Error code 404

Any ideas?

Finally, it's working after 24 hours of struggle with the latest version of Intune - 5.0.6983.0.

I understand that if the device has no internet connection, then my only option would be to wipe it. However, it has a Verizon cellular plan tied to its eSim. The plan includes unlimited data (showing 0.03GB used this month), and I can call the phone and talk to myself on it. I can also tap "Call" on the screen to call the number we entered when we put it in lost mode.

I've never seen this before as the device should be sync'ing fine. It was last sync'd 5/7 when it was powered off, put in a box, and shipped to me. I've had it for a week trying everything possible to pull it out of lost mode, but it will not receive any commands from Intune despite showing full bars of 5GUW.

I tried connecting it to my MacBook with Configurator, but lost mode disables the USB port and if I put it in recovery mode the only options are to wipe it.

Legal needs to pull data off the phone so wiping it isn't an option. The device is in Apple Business Manager and is supervised (hence the ability for lost mode). You'd think there'd be some type of failsafe to prevent this kind of behavior because it really makes lost mode useless.

Does anyone have any suggestions?

--------------------

Thanks u/ProfessionalWorkAcct for the solution. The user account was deleted in Entra so Primary User of the device showed None in Intune, but graph showed the UserId to be the GUID of the deleted Entra object. Restoring the object and giving it an E5 license fixed whatever was broken in Intune and it started receiving commands again.

I've been exploring the new OSDCloud PowerShell module and specifically the Deploy-OSDCloud cmdlet. I have been testing with the Start-OSDCloudGUI workflow where you can restrict and pre-set OS versions, editions, and activation types through a Start-OSDCloudGUI.json file placed on the USB at OSDCloud\Automate\ I was wondering if similar functionality exists for Deploy-OSDCloud. I'm just not entirely sure yet whether Start-OSDCloudGUI is the best practice, or whether we should switch to the newer Deploy-OSDCloud right away during the testing phase i'm in right now. It seems to me that Start-OSDCloudGUI handles all the configuration, whereas using Deploy-OSDCloud requires more manual work on your part, such as launching these functions via a custom .ps1 script using the -StartPSCommand parameter. (haven't got this to work yet)

Goal:
We want the USB stick to automatically start a Windows 11 24H2 Pro Volume deployment without any user interaction. Drivers and firmware should be automatically selected based on the hardware of the machine, which already works fine with the manual GUI setup.

We want a fully unattended deployment where a technician only needs to boot from the USB, no clicking, no selecting OS versions or editions, just plug in and go with the newer Deploy-OSDCloud.

Thanks!

I have the suspicion one of my employees is sharing one folder from his corporate laptop to his personal one using the local network. Is there any way I can check or track this?

Hi all,

I have recently set up a device profile for single app use tablets. In doing this, the Play Store app was disabled, as we wanted them to be as locked down as possible. The company now wants to add another app to these tablets, but I can't get the users to reenable the Play Store, as it requires admin privileges. Is there any way to reenable the app through Intune, or at least give rights so the user can? Or have I shot myself in the foot? 🫠

Anyone had any luck with Microsoft's mitigation for YellowKey (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585)?

It seems to work ok when run manually, but I've been getting mixed results when deploying as a PRS, including:

Completely broken WinRE afterwards
Failure to wipe devices after the fix, leading to them being unbootable

My thought at the moment is simply to disable WinRE via reagentc.exe until there's a better remedy. Yes, it'll stop device wipes from working but we don't to that many, and we can always give an instruction to re-enable it before one is sent (they're also MAA'd).

Thanks,

Iain

Hi. I not updating my laptop since February 2026. My current winver is 26200.7840 . So, I decided to update my laptop with latest Windows Update 26200.8457. The updates no issue to download and install. But when the laptop reboots, the winver still not changing. It still 26200.7840.

So, have anyone experienced this issue?