Intune can finally tell Windows Update to ignore Group Policy. I am not talking about the stupid “MDM wins if there is a conflict,” but actually skipping the Windows Update Group Policy path. The IgnoreWindowsUpdateGroupPolicies setting changes the source selection itself. When enabled, Windows Update can bypass the live GP values and the cached GP fallback, then continue with the managed policy sources instead. That makes this a very interesting setting for anyone moving from WSUS or legacy Windows Update GPOs to Intune. I took a closer look at how it works on the device and what Windows actually checks before Group Policy gets skipped. #Intune #MSIntune #WindowsUpdate #Windows11 patchmypc.com/blog/ignore-wi…

Do you think Intune is slow? When you put all the changes Microsoft has made next to each other, it starts to look like something much bigger than a few performance improvements. Intune is slowly moving away from waiting for timers and scheduled polling, toward push, local events and near real time actions. Policy delivery: The old roughly 30-minute notification throttle is being replaced by the Fast Lane model. Changes can trigger a new device check-in within minutes instead of sitting behind the old notification window. Remote actions :That annoying 5-minute queued delay after the first hours of enrollment? Gone on supported Windows versions. Remote actions can start the device check in immediately again. Device Sync: Sync used to mainly wake the Windows MDM world. Now one Sync can wake Windows MDM AND the Intune Management Extension. The IME side is delivered through IC3 and Trouter. Sync Status :It is no longer just “press Sync and hope”. The portal can now follow the progress of Policies, Applications, and Scripts. Win32 apps: A newly assigned Required Win32 app no longer necessarily has to wait for the normal 60-minute app check. Intune can push intent 2 over IC3 and bring the normal app check forward within minutes. Autopilot apps: When enrollment finishes, it can now trigger a fresh app check. That closes the gap where the desktop appeared, but the remaining Required apps could sit there waiting for the next app timer. Client-driven compliance: This one is even more interesting. The device can watch local signals such as Firewall, Defender, BitLocker, Secure Boot, and TPM. When something changes, it can proactively request a new compliance evaluation instead of waiting for the normal cycle. App Inventory: This used to be based around a 4-hour collection cycle. The newer Device Inventory Agent can react to an application change, validate it, and upload the delta on the next scheduler pass. In my testing, that was about 5 minutes. So... Do you still think Intune is slow? I think that question is becoming a lot harder to answer with a simple “yes”. #Intune #MSIntune #WindowsAutopilot

Required Apps No Longer Need to Wait 60 Minutes after Autopilot Microsoft has announced faster Win32 app delivery in What’s new in Intune. The other required Win32 apps no longer have to wait for the next hourly check after Autopilot ESP completes. Learn how the IME detects the transition and starts app processing sooner. patchmypc.com/blog/autopilot… #Intune #MSIntune #WindowsAutopilot

Are you testing Windows Autopilot Device Association? I guess you have all seen the steps you need to take to associate the device, right? The manual export, moving the file to another device, importing it into Intune, selecting the Autopilot Device Preparation policy, and returning to the device are not. That is why I built Get-AutopilotDeviceAssociation. Think of it as Get-WindowsAutopilotInfo, but for Windows Autopilot Device Association. With one PowerShell script, you can create the association, register the device in Intune, validate whether the signed association is still present and valid, and remove it from both the device and Intune after testing. Read the full story and get the script: call4cloud.nl/autopilot-get-… #WindowsAutopilot #MSIntune #AutopilotDevicePreparation #PowerShell #Intune

One of the big things Microsoft Windows Autopilot v1 gave us was control over the OOBE. Skip the pages you did not want and ensure a device name is applied! With Device Preparation, that totally changed. The tenant only becomes known AFTER the user signs in, which is simply too late to influence those earlier OOBE pages. That is exactly where Device Association comes in. It gives Windows a way to know which organization the device belongs to BEFORE the user signs in, so it can retrieve those settings early enough to shape OOBE again. But how does that device association actually work? -What is inside the exported CSV? -Why is TPM attestation involved? -What happens when you click Associate? -And why does the final association end up in UEFI? That is what I investigated (and NOT reverse-engineered!!!) #Intune #MSIntune #windowsAutopilot @IntuneSuppTeam @MSIntune lnkd.in/eRKWnmVv