It is 3 in the afternoon. You push one Conditional Access policy. You assigned it to All Users because the pilot group felt like extra work, and the policy requires a compliant device. Except for a few items, nothing in this tenant is enrolled yet.

Ninety seconds later, the first ticket lands. Then eleven more. Then the owner calls.

Every admin I know has a version of this story, and the ones who say they do not are lying or new. That single afternoon is the reason I test Intune policies on a disposable Windows 11 machine before anything touches a client tenant. Not a spare laptop in a drawer. A virtual machine on my Mac that I can wipe in eight seconds and rebuild in twenty minutes. 

Here is exactly how they put that lab together, what it catches, and where it quietly lies to you.

One client, one VM, and no shared clipboard

Start with the part that has nothing to do with Intune.

I run one virtual machine per client. Client’s tools, credentials, exported reports, and half-finished scripts live in Client A's VM and nowhere else. My own Mac stays my own Mac.

Partly it's about being tidy, but it's also what I'd have to explain in an incident review if a client asked me how I separated their data from another client's. 

"It was all in my Downloads folder, but in different subfolders" is not an answer that survives that conversation.

Two settings do the heavy lifting in Parallels Desktop:

• Isolate Mac from Windows (VM configuration, Security tab). Kills shared clipboard, drag and drop, and shared folders between the guest and my Mac. Nothing walks out of that VM by accident.
• Encrypt the virtual machine. The VM bundle becomes an encrypted file. A stolen Mac is then a stolen laptop, not a stolen client environment.

If you only take one thing from this article, take this one. It costs two clicks per VM and it changes what you can honestly say to a client about data handling.

Building the lab machine

The base image is deliberately boring.

Windows 11 Pro, not Home. Home cannot join Entra ID, so it cannot enroll in Intune. That single detail wastes an hour for many people the first time.

Virtual TPM on. Parallels creates an encrypted file inside the VM bundle that acts as TPM storage, and Windows 11 treats it as a real TPM 2.0 chip. That gets you two things: Windows 11 installs at all, and BitLocker actually works, so you can test a disk encryption policy end to end instead of assuming it applies.

4 vCPU, 8 GB RAM. More is not better here. You want a machine that boots fast and reverts fast, and you want to leave your Mac enough headroom that a Teams call does not stutter while the VM syncs policy.

Enrol during OOBE. On the "How would you like to set up this device?" screen, pick "Set up for work or school" and sign in with a test account from the target tenant. If MDM auto-enrollment is switched on in Entra ID (Mobility (MDM and MAM), MDM user scope), the device Entra-joins and lands in Intune on its own. No provisioning package, no Autopilot, no Sysprep.

Twenty minutes, and you have a real managed endpoint that no human being depends on.

The three snapshots that make the whole thing work when you test Intune policies

Snapshots are what turn a VM into a test rig instead of just a second computer.  The workflow I use has three fixed points:

1. Clean. Windows installed, updates done, nothing joined to anything. This is your escape hatch when a tenant gets so tangled that starting over is cheaper than untangling it.
2. Enrolled. Entra-joined, Intune-enrolled, baseline policies applied, Company Portal signed in. This is the snapshot you live in. It represents a normal user's laptop on day one.
3. Pre-change. Taken right before every single test. Named after what you are about to try.

That third one is the discipline. Before I push anything, I take a snapshot named for the change: pre-CA-compliant-device, pre-bitlocker-silent, pre-lapse-script. If the test goes badly, I revert to it and the machine has no memory of what I did.

From the Parallels command line tools this is two commands, which means it can live at the top of a test script instead of in your good intentions:

prlctl snapshot "Win11-ClientA" -n "pre-CA-compliant-device"

prlctl snapshot-list "Win11-ClientA"

prlctl snapshot-switch "Win11-ClientA" -i {snapshot-id}

How I test Intune policies in practice, step by step

Say the client wants Conditional Access requiring a compliant device. The sequence:

1. Snapshot the VM. Name it after the policy.
2. Create the compliance policy in Intune, assigned to a pilot group containing exactly one account: the test user signed into the VM.
3. Create the Conditional Access policy in report-only mode first, scoped to the same pilot group.
4. In the VM, force a sync from Company Portal and watch the device flip to compliant. Or watch it stay non-compliant, which is the interesting outcome, because that is what would have happened to sixty real people.
5. Read the sign-in logs in Entra ID. Report-only tells you what the policy would have done.
6. Flip the policy on for the pilot group only. Sign out, sign in, open Outlook and SharePoint in the VM. Break it deliberately: turn BitLocker off, let the device go non-compliant, and confirm the block message is one a normal human can understand.
7. Revert the snapshot. The VM forgets. Your notes do not.

Only then does the policy get widened, and even then in rings, never to All Users in one move. Keep a break-glass account excluded from every Conditional Access policy while you do it.

The same rig is where every PowerShell and Graph script gets its first run. A script that touches mailboxes, licences or device records should meet a throwaway machine and a test tenant before it meets a client. -WhatIf is a good habit, and it is not a safety system.

Where the lab quietly lies to you

This is the part most articles about home labs skip, so here it is plainly.

Your VM is ARM, most client hardware is not. On an Apple Silicon Mac you are running Windows 11 on ARM. Policy, compliance, Conditional Access, configuration profiles, Defender settings, and almost everything you configure through Intune behave the same. Anything architecture-specific may not: x64-only agents, kernel-level software, vendor drivers, legacy line-of-business apps. Parallels does ship an x86 emulator for Intel VMs on Apple silicon, and it is honest about what it is - single vCPU, 8 GB ceiling, no USB, no sound, boot times measured in minutes, and no Windows 11 creation. Useful for one specific compatibility check, useless as a daily lab.

Autopilot is not really testable here. Real Autopilot depends on a hardware hash from a real device. You can automate VM enrollment in other ways, and you can prove your profiles and apps work, but do not tell a client you tested their Autopilot deployment when you tested enrolment in a VM.

Cloning an enrolled VM makes a mess. Two VMs from the same host can present as the same device to Intune, and enrollment fails with error 8018000a. Clone from the Clean snapshot, then enrol each copy separately. Never clone a machine that is already enrolled.

Reverting a snapshot leaves ghosts in the tenant. The VM forgets, but Intune and Entra ID remember. After a few cycles, you will have stale device records, which will make compliance reporting look incorrect. Retire and delete them, and if you are testing in a client tenant, do that clean-up the same day, not "later".

Performance means nothing here. A VM tells you whether a Defender for Endpoint onboarding package applies. It tells you nothing useful about what that agent does to a five-year-old laptop with 8 GB of RAM.

Which tenant do you point it at

A lab machine still needs somewhere to enrol.

A separate test tenant is the clean answer. The Microsoft 365 Developer Program E5 sandbox is the classic route, but check eligibility before you plan around it - it now runs through Visual Studio Professional or Enterprise subscriptions, partner programme membership, or Premier and Unified Support, rather than being open to anyone with an email address.

The practical answer for most consultants is the client's own tenant with hard rules: a dedicated test account, a pilot group that contains only that account, report-only mode first, every policy documented before it is created, and stale device records cleaned up the same day. It works. It requires more discipline than a sandbox because there is no safety net underneath you.

If you want to build the same lab to test Intune policies

A fair question at this point: which version of Parallels Desktop do you actually need for this.

For the workflow above, Parallels Desktop Pro is the one that fits. Two reasons that matter here. The command-line tools (`prlctl`) ship with the Pro and Business editions, so the snapshot commands earlier in this article can sit at the top of a test script instead of relying on you remembering to click. And Pro lifts the per-VM ceiling well past what Standard allows, which is what lets you run a client VM and still have a Mac that behaves normally underneath it. The x86 emulator for that occasional Intel-only compatibility check is also a Pro and Business feature.

Parallels Desktop Standard is the right pick for a different reader: someone who needs one Windows app on a Mac and will never script anything. Perfectly good for that, and short of what this lab asks for.

Set against a single afternoon of an outage you caused yourself, either licence is cheap. That is the whole argument, and I would rather make it plainly than dress it up.

Bottom line

The lab is the boring part of this job, and also the part that keeps the impressive part from turning into an outage.

One VM per client, isolated and encrypted. A clean snapshot, an enrolled snapshot, and a snapshot before every change. Pilot groups instead of All Users. Report-only before enforce. A break-glass account you never touch.

Twenty minutes to build. Eight seconds to undo a mistake that would otherwise have cost you an afternoon, a client's morning, and some part of their trust.

And if you are about to inherit an environment you did not build, work through the Microsoft 365 tenant handover checklist before you change anything, then fix the Business Premium security settings that are switched off in most tenants. Test both in the VM first.

📧 I write weekly about M365 security for SMBs - join the newsletter on LinkedIn → https://www.linkedin.com/in/tomasz-szulczewski/