Intune still can't bare-metal image a device, and other things nobody told IT

The mandate came from leadership, not from IT

Almost every admin managing a hybrid environment right now has heard the same question: "Why haven't we fully migrated to Intune yet?" It usually comes with an unspoken assumption that the holdup is inertia, or an IT team that's comfortable with an old tool and reluctant to learn a new one.

That's not what's happening. Admins who've spent months testing Intune as a full replacement for Group Policy keep arriving at the same conclusion: Intune isn't there yet. It has real strengths, but as a like-for-like replacement for Group Policy, it’s just not there yet.

What Intune still doesn't do

No bare metal imaging.

Group Policy paired with task sequencing let admins wipe a device and reload a clean OS from scratch, including complex, multistage installs that require reboots in between. Autopilot doesn't replace this. It provisions a device that already has an OS on it. Admins report shipping "clean" machines to end users still loaded with manufacturer bloatware, because there's no equivalent of a task sequence to strip it out first.

Servers were never in scope, and that's fine.

Intune manages client devices.  It was never built to manage Windows Server, so conditional access policies and compliance enforcement stop at the workstation by design, not by accident. That's not a hole in the roadmap; it's a boundary that was drawn on purpose.

The reason this rarely trips anyone up in practice is that hybrid environments already have server management covered elsewhere. SCCM still handles on-prem Windows Server patching and bare metal builds. Azure Arc extends policy and compliance enforcement to servers wherever they live, on-prem or in another cloud. VMware vSphere handles provisioning and imaging through templates and cloning. Ansible (or AWX Tower) picks up the ongoing configuration enforcement that Group Policy used to own. Nothing here is missing, it's just split across a handful of tools most infrastructure teams already run.

Less hierarchy, more workarounds.

Active Directory's OU structure let admins mirror how a business is organized, by department, location, or device tier, nesting exceptions cleanly and delegating admin rights at every level. Entra ID groups can be nested too, but Microsoft's own guidance steers admins away from it: nesting a large group inside one Intune already targets forces Intune to resync every group and membership underneath it, turning a small exception into a performance problem instead of a clean inheritance model.

Assignment filters and scope tags pick up some of what OU-based delegation used to do, scoping visibility and targeting without full nesting. Neither recreates true inheritance, but delegation-style control is closer than it looks at first glance.

Dynamic grouping still exists in Intune, just narrower than what Group Policy admins are used to. Entra ID dynamic device groups can filter on attributes like manufacturer and model, and Intune assignment filters add device properties like OS version and CPU architecture on top of that. What's missing is dynamic grouping or filtering based on installed software, a routine query in Group Policy environments that has no native equivalent in Intune today.

Coverage that's closer, but not complete.

Group Policy supports roughly 4,000 ADMX settings.  Intune's Settings Catalog now covers 18,000+ settings across all platforms, and Administrative Templates alone, the direct carryover from GPO, account for roughly 2,500 of those. The raw numbers aren't the real story anymore. What's left is a set of specific GPO behaviors that still don't have a clean Intune equivalent: Group Policy Preferences, certain legacy scripting-based configurations, and settings that depend on capabilities Intune's CSP-based model doesn't expose yet. That gap gets filled with scripts and manual configuration profiles, rebuilding by hand what used to be a checkbox.

Group Policy Preferences have no home.

Mapped drives, printer connections, and the dozens of small preference settings GPP handled automatically now require scripting or third-party tools to replicate.

Slow, unpredictable policy application.

Where Group Policy applies changes in seconds, Intune relies on Windows Notification Service to relay policy to devices, and that pipeline is effectively a black box. Admins have documented sync times ranging from instant to 72 hours for the identical policy, with no reliable way to force it through when a deadline is real.

Troubleshooting is catching up, not there yet.

Group Policy has RSoP and gpupdate, tools built specifically to answer "why isn't this applying" in minutes. Intune now has rough equivalents: Sync forces an on-demand policy check-in, and per-setting policy status shows which policies applied to a device and why. Copilot in Intune adds an error code analyzer and side-by-side device comparison on top of that, and as of mid-2026 this comes bundled into Microsoft 365 E5, no separate license required.

What's still missing is the maturity, not the concept. These tools are newer, and admins report inconsistent results on anything beyond the basics. The 20-year head start Group Policy has on "why isn't this applying" hasn't fully closed, but the gap is narrower than it looks.

No native bandwidth controls.

Group Policy environments running SCCM can schedule deployments with BranchCache or PeerCache so a single site doesn't hammer a slow WAN link downloading the same content over and over. Intune pulls from the internet per device, with no peer-to-peer caching to spread that load across a site. For bandwidth-constrained locations, that means slower rollouts and, in some cases, outright failures with no native fix.

Application controls that require raw SIDs and third-party tools.

Fine-grained application allowlisting, the kind Group Policy environments handle with AppLocker, is a heavier lift in Intune. Referencing security principals often means specifying raw SIDs instead of friendly names, and third-party patching for anything outside Windows updates requires a separate tool entirely.

Intune is fine if you are cloud-first

None of this means Intune is a bad product. It's a genuinely strong fit for straightforward, cloud-first environments. Microsoft's infrastructure for delivering monthly OS updates is excellent. The problem is narrower and more specific: as a full, drop-in replacement for everything Group Policy did, Intune isn't there yet, and pretending otherwise just moves the pain from a roadmap slide to a help desk queue.

That's exactly why so many organizations describe their Intune rollout as "hybrid for a couple more years" rather than "done." It isn't a people problem. It's a tooling gap that Netwrix PolicyPak was built to close.

How PolicyPak extends what Group Policy already does well

PolicyPak doesn't ask teams to rip out Group Policy and start over. It sits on top of the infrastructure already in place and extends the same policy logic to every endpoint, whether it's domain-joined, remote, or already enrolled in Intune.

• Full ADMX depth, not a subset: The Admin Templates Manager is ADMX-backed, so the thousands of granular settings Group Policy supports stay available instead of getting rebuilt by hand as scripts.
• Group Policy Preferences, still automated: The GPP Manager keeps handling mapped drives, printers, and the other preference settings that quietly kept desktops consistent, with no scripting required.
• Real hierarchy and consolidation: Sprawling GPOs get consolidated to reduce bloat and improve performance, while keeping the OU-based targeting model admins already understand.
• Compliance reporting that proves enforcement: Group Policy Compliance Reporting gives teams a way to show what's enforced across the environment, not just what's configured, which matters as much for an audit as it does for a Tuesday afternoon troubleshooting session.
• Coverage that follows the endpoint, not the domain: For devices that never touch a domain controller, PolicyPak Cloud and its GPO Export Manager carry the same policies to endpoints managed through Intune or other MDM and UEM platforms. A remote laptop enrolled in Intune gets the same least-privilege rules and desktop configuration as a machine sitting in a domain-joined office.
• Security controls built for the endpoint: Local admin rights come off the table, while standard users still get safe, specific elevation paths. File-owner-based allowlisting blocks untrusted applications and scripts with a single policy, and DLL hijack protection addresses a class of vulnerability common in older desktop software. Application, browser, Java, and removable device controls round out the coverage, all managed from one console.
• Simplified deployment and patching: Software deployment, automatic patching, and removal run across Windows, WinGet, and web-based sources, filling the third-party patching hole that Intune leaves for Windows updates alone.
• Least privilege that isn't Windows-only: The Least Privilege Manager extends admin-approval and folder-permission controls to Mac, not just Windows, so hybrid endpoint environments get least-privilege management from one console instead of a Windows tool plus a separate Mac process.

What PolicyPak doesn't try to be

To be direct about the boundary: PolicyPak doesn't do bare metal imaging or task sequencing, and it isn't a replacement for whatever tool is currently handling OSD. What it does is make sure that once a device exists, whether it was imaged, Autopiloted, or enrolled through Intune, it's configured, locked down, and reportable using the same policy engine and the same level of depth teams already trust.

Teams don't have to choose between Group Policy's maturity and Intune's reach. PolicyPak keeps the hierarchy, granularity, and reporting depth that took 20 years to build, and extends it to every endpoint Intune now manages. See how it fits into your current environment.