Standardisation: The Foundation of a Modern Windows Estate
How to build a repeatable, auditable Windows estate using Intune, Autopilot, and GitOps — and why it matters more than ever.
The pressure on IT teams has never been greater. Copilot and AI workloads demand consistent, well-managed endpoints. Zero Trust architectures require every device to prove its health before accessing resources. Remote and hybrid work patterns have obliterated the traditional network perimeter. In this environment, a fragmented, inconsistent Windows estate isn't just inefficient—it's a liability.
Standardisation is the antidote. It's the practice of aligning your devices, configurations, and deployment processes to a defined, repeatable baseline. Done well, it transforms endpoint management from reactive firefighting into predictable, auditable operations. Done poorly—or not at all—you're left with configuration drift, security gaps, and an endless stream of "works on my machine" incidents.
This post focuses on Windows, but the principles apply equally to macOS, iOS, and Android. The tooling differs; the philosophy doesn't.
The Business Case for Standardisation
Standardisation delivers value across multiple dimensions, though the specific benefits depend on your starting point and organisational context.
Cost reduction comes from consolidation. Fewer hardware SKUs mean simpler procurement and spares management. Rationalised application portfolios reduce licensing spend and support overhead. Consistent configurations mean support engineers diagnose issues faster because they're not constantly context-switching between bespoke builds.
Security posture improves dramatically when every device receives the same hardened baseline. You can't enforce what you haven't defined, and you can't audit what isn't consistent. Standardisation is a prerequisite for meaningful compliance—whether that's Cyber Essentials, ISO 27001, or your cyber insurer's requirements.
Operational efficiency follows naturally. Automated deployments replace manual builds. Drift detection replaces periodic audits. Your team spends less time on repetitive tasks and more time on work that actually moves the organisation forward.
Business agility is perhaps the least obvious benefit, but arguably the most valuable. When you can provision a fully configured device in under an hour via Autopilot, onboarding new starters becomes trivial. When your application deployment pipeline is proven and repeatable, rolling out new tools to support a business initiative stops being a six-week project.
None of this is controversial. The challenge isn't understanding why standardisation matters—it's achieving and maintaining it in practice.
The Modern Standardisation Stack
If you're running a Windows estate in 2026 and not using Microsoft's cloud-native management stack, you're making life unnecessarily difficult. The tooling has matured significantly, and the integration between components creates compound benefits that third-party alternatives struggle to match.
Entra ID Join (formerly Azure AD Join) should be your default for new devices. Hybrid join still has its place for estates with heavy on-premises dependencies, but cloud-native identity simplifies conditional access, removes domain controller dependencies for remote workers, and aligns with Zero Trust principles. Every device authenticates independently; no VPN required to prove identity.
Windows Autopilot handles provisioning. Ship devices directly from your vendor to end users, and let Autopilot transform a factory image into your corporate build on first boot. No imaging infrastructure to maintain, no technician touch required. The device registers itself, pulls its configuration from Intune, installs applications, and lands on the user's desk ready to work. This isn't future-state thinking—it's table stakes for any organisation buying new hardware today.
Microsoft Intune is your control plane. Policies, compliance baselines, application deployments, update management—everything flows through Intune. The shift from Group Policy to Intune isn't just about cloud versus on-premises; it's about moving from imperative ("apply these 47 registry keys") to declarative ("this device should have BitLocker enabled with these recovery key escrow settings"). You define the desired state; Intune enforces it.
Windows Autopatch takes update management largely off your plate. Microsoft manages the deployment rings, monitors for issues, and pauses rollouts automatically if problems emerge. You're not abdicating responsibility—you still define which devices are in scope and can override when necessary—but you're leveraging Microsoft's telemetry from millions of devices rather than discovering issues in your own estate first.
For organisations that prefer more control over update rings, manual configuration via Windows Update for Business policies in Intune remains entirely valid. I typically recommend five rings at most: Horizon (IT pros and volunteer early adopters), Pilot1 (broader IT and key stakeholders), Pilot2 (representatives from all business functions), Broad (general population), and Critical (kiosk devices, automation endpoints, anything where unplanned reboots cause business impact). One firm rule: executives go in Broad, never earlier, regardless of how loudly they protest. They're not special, and putting them in early rings just means their issues get prioritised over everyone else's.
Executives go in Broad — never earlier.
Configuration as Code and GitOps
Here's where standardisation becomes genuinely powerful: treating your endpoint configuration the same way you'd treat infrastructure or application code.
Microsoft365DSC is the enabler. It's a PowerShell module that can export your entire Microsoft 365 and Intune configuration to structured files, compare environments, detect drift, and apply configurations declaratively. Think of it as Terraform for the Microsoft cloud management stack.
The workflow looks like this: export your current Intune configuration to DSC format, commit it to a Git repository, and establish that repository as your source of truth. Changes go through pull requests with peer review. A CI/CD pipeline validates syntax and compliance before merging. On merge, the pipeline applies the configuration to your tenant. Drift detection runs on a schedule and alerts—or auto-remediates—when reality diverges from the declared state.
This approach delivers several benefits that manual console-clicking never will:
Auditability: Every change is logged in Git with who, when, and why. No more archaeology through Intune audit logs trying to work out which policy change broke something.
Repeatability: Spinning up a test tenant with identical configuration becomes trivial. Disaster recovery for your management plane is a git clone and pipeline run away.
Collaboration: Your team can work on configuration changes in parallel without treading on each other's work. Conflicts are surfaced at merge time, not discovered in production.
Rollback: Something goes wrong? Revert the commit and re-run the pipeline. Configuration management becomes as reversible as code deployment.
This isn't theoretical—it's how mature organisations are operating today. If you're still making changes directly in the Intune console, you're accepting unnecessary risk and friction.
Application Deployment: Win32 and MSIX
Application packaging is often the bottleneck in standardisation projects. You can have perfect policies and pristine update rings, but if your applications are deployed inconsistently or rely on legacy installation methods, you'll never achieve true standardisation.
Intune supports two primary deployment mechanisms for Windows applications, and understanding when to use each is essential.
Win32 app deployment (via .intunewin packages) is pragmatic and flexible. Take your existing MSI or EXE installers, wrap them with the Intune Content Prep Tool, define detection rules, and deploy. For most organisations, this covers 80-90% of applications with minimal packaging effort. It works, it scales, and it doesn't require specialist packaging skills.
MSIX is the more sophisticated option, and it genuinely shines in specific scenarios. MSIX packages are containerised—applications run in an isolated environment with virtualised registry and filesystem access. This delivers cleaner installs, reliable uninstalls, and better security isolation. More importantly for modern estates, MSIX packages are portable: the same package deploys to physical devices, Windows 365 Cloud PCs, and Azure Virtual Desktop session hosts. If you're operating across multiple Windows platforms, MSIX eliminates the "build once, package three times" problem.
MSIX App Attach takes this further for AVD environments, allowing applications to be mounted dynamically to session hosts without local installation. This is transformative for non-persistent VDI—users get their applications on demand without bloating golden images.
The trade-off is packaging complexity. Converting legacy applications to MSIX requires effort, and not every application converts cleanly. My recommendation: start with Win32 deployment for pragmatic coverage, then progressively migrate high-value applications to MSIX—particularly anything deployed across physical and virtual estates, anything with troublesome installation footprints, or anything where security isolation is particularly valuable.
Don't let perfect be the enemy of good. A standardised estate with Win32 packages is vastly better than a fragmented estate waiting for a complete MSIX repackaging project that never finishes.
The Challenges Are Real
Standardisation projects fail for predictable reasons, and acknowledging them upfront improves your chances of success.
Resistance to change is human nature. People are attached to their workflows, their preferred applications, their local admin rights. Some resistance is legitimate—a developer's workflow genuinely differs from a finance analyst's—but much of it is simply inertia. Clear communication about the why, genuine engagement with edge cases, and executive sponsorship that doesn't waver at the first complaint are essential.
Technical debt accumulates over years. You'll discover applications that nobody owns, dependencies that nobody documented, and configurations that exist for reasons lost to time. Budget time for archaeology and accept that some mysteries will never be solved—you'll need to make pragmatic decisions with incomplete information.
The long tail of applications can consume disproportionate effort. Twenty applications might cover 95% of users, but the remaining 200 niche tools—each with three users who insist they're critical—will dominate your packaging queue if you let them. Prioritise ruthlessly. Some applications don't justify the effort and can remain exceptions, documented and risk-accepted.
Skill gaps are common. Many IT teams grew up with on-premises tools—SCCM, Group Policy, manual imaging. The cloud-native stack requires different skills: Graph API, PowerShell DSC, declarative policy thinking, CI/CD pipelines. Invest in training early, or accept that velocity will be slower than planned while the team learns.
Where to Start
If this feels overwhelming, start small and iterate.
First, establish your baseline. Document what "standard" means for your organisation: hardware specifications, OS version, core applications, security configurations. This doesn't need to be perfect—it needs to be written down and agreed.
Second, pick a beachhead. New devices are easier than migrations. Get Autopilot working for your next hardware refresh, even if existing devices remain on legacy management temporarily.
Third, implement one policy properly. Take a single Intune configuration profile, export it via Microsoft365DSC, commit it to Git, and set up a basic pipeline. You'll learn more from doing this once than from reading documentation for months.
Fourth, measure and iterate. Use Intune reporting and Endpoint Analytics to understand your current state, track progress toward standardisation, and identify the next area to tackle.
Standardisation isn't a project with an end date—it's an operating model. The goal is continuous alignment between your defined standard and reality, with automation doing the heavy lifting and humans handling the exceptions.
If you've been through a standardisation journey—successful or otherwise—I'd be interested to hear what worked and what didn't. The theory is straightforward; the war stories are where the real learning happens.