DEV Community: AdminPackStudio

Build a small M365 + Intune home lab to practise admin skills (without touching production or your wallet)

AdminPackStudio — Wed, 07 Oct 2026 14:15:34 +0000

Build a small M365 + Intune home lab to practise admin skills

You can read about Intune all week, but things only really make sense once you've enrolled a device yourself, watched a policy not apply, and worked out why. Practising on your employer's tenant is a bad idea, and so is practising on your daily laptop. You need a small lab you're allowed to break.

This is the setup I'd suggest to anyone who wants hands-on M365 and Intune admin practice. It fits on one decent laptop or desktop, costs little or nothing beyond the hardware you already own, and stays well away from production.

Quick version (TL;DR):

Get a tenant you control. That might be a developer sandbox (if you're eligible), a product trial, or a small paid subscription. Check current Microsoft terms first. Don't assume anything is free.
Run two or three VMs on Hyper-V or VirtualBox: one or two Windows 11 clients and an optional Windows Server for AD practice.
Create fake users and groups with an obvious naming scheme, plus one break-glass admin.
Practise the basics first: users, groups, licences, enrolment, one compliance policy, one config profile, one app.
Keep lab and production apart: separate browser profile, separate accounts, separate passwords, no real data.
Put cost reminders on your calendar for every trial end date.

1. Getting a tenant: options, and why you should check eligibility first

The biggest misconception in home lab threads is "just grab a free E5 developer tenant." That used to be easy. Today, the Microsoft 365 Developer Program sandbox is only available to members who meet specific qualification paths (for example, certain Visual Studio subscriptions or partner programs), and the rules have changed several times. Read the current Developer Program FAQ and eligibility pages yourself before you plan around it.

Your realistic options, roughly:

Option	Good for	Watch out for
Microsoft 365 Developer Program sandbox	Full E5-style feature set, if you qualify	Eligibility is restricted and changes. Check current terms. Windows licences aren't included
Product trials (for example Microsoft 365 Business Premium, Intune, or Entra ID P1/P2 trials)	Time-boxed practice on a specific feature set	Limited length. Some trials ask for a payment method and can convert to paid unless you cancel. Read the terms on the signup page
Small paid subscription (one or two user licences)	A lab that lasts past 30 days	It's a real monthly cost. Pick the cheapest SKU that includes what you want to practise (Intune + Entra ID P1 covers most of this article)
Your employer's test tenant	Realistic config	Only with written permission, and only if it's genuinely a test tenant

Whichever you pick:

Sign up with a new identity (a fresh *.onmicrosoft.com admin), not your work account.
Write the trial end date down the day you start, and set a reminder a few days before it.
Don't add your real custom domain to the lab. The default onmicrosoft.com domain is fine for practice.

Licensing matters for what you can practise. Dynamic groups and Conditional Access need Entra ID P1 (or a bundle that includes it), and devices only enrol into Intune when the user has an Intune licence. If a feature is missing, check licensing before you assume you've misconfigured something.

2. Hypervisor and VM layout

Hypervisor:

Hyper-V is built into Windows 10/11 Pro, Enterprise, and Education (not Home). It supports Gen 2 VMs with Secure Boot and a virtual TPM, which Windows 11 expects.
VirtualBox works on Windows Home, macOS (Intel), and Linux. Recent versions support virtual TPM 2.0 and Secure Boot for Windows 11 guests. Check the docs for your version.

RAM is usually the limit. 16 GB on the host is a comfortable minimum for a client and a server running at the same time. With 8 GB, run one VM at a time.

A layout that works:

VM	OS	vCPU / RAM / disk	Purpose
`lab-w11-01`	Windows 11 Enterprise or Pro	2 / 4 GB / 64 GB+ (dynamic)	Main Intune client: Entra join + enrol
`lab-w11-02` (optional)	Windows 11	2 / 4 GB / 64 GB+	A second client so you can compare "pilot" vs "everyone" groups
`lab-dc01` (optional)	Windows Server (evaluation)	2 / 2–4 GB / 60 GB	On-prem AD, DNS, GPO practice, and later hybrid identity if you want it

Notes:

Use legal media. The Microsoft Evaluation Center offers time-limited evaluation editions of Windows Server and Windows Enterprise. Evaluation periods end, so plan to rebuild (good practice anyway).
Windows Home can't enrol into Intune as a managed corporate device. Use Pro, Enterprise, or Education in your client VMs.
Network: use NAT or a host-only/internal switch for VM-to-VM traffic, plus outbound internet so the clients can reach Microsoft 365. Don't port-forward RDP to the internet "for convenience".
Naming: prefix everything with lab- (VMs, users, groups, policies). When you're looking at a screenshot later, you'll know immediately it's the lab.

Checkpoints / snapshots: use them, but know the catch

Take a checkpoint before enrolling a client (20261006-clean-w11-pre-enrol). Reverting a VM to a point before it enrolled is clean.

Reverting an already-enrolled VM to an older checkpoint is messier. The cloud still remembers the newer state, so you'll often see duplicate or stale device records in the admin center. That isn't broken, it's just what happens. Clean up stale records in your lab tenant and re-enrol. It's a good lesson in why device naming and record hygiene matter.

3. Test users and groups

Create a small, fictional org. Five to ten users is enough:

Account	Role in the lab
`lab-admin-breakglass@<tenant>.onmicrosoft.com`	Emergency Global Admin. Long random password in your password manager. Exclude it from any Conditional Access you test
`lab-admin-daily@…`	Your day-to-day admin. Practise using a lower role (for example Intune Administrator) instead of Global Admin
`lab-helpdesk1@…`	Practise scoped/limited admin roles
`lab-user-pilot1`, `lab-user-pilot2`	Pilot group members
`lab-user-std1` … `lab-user-std4`	"Everyone else"

Groups to start with:

lab-sg-pilot-users (assigned): your first ring for every new policy
lab-sg-all-users (assigned, or dynamic if you have P1)
lab-sg-devices-pilot (device group): practise the user-vs-device assignment difference
lab-sg-lic-intune (if your tenant supports group-based licensing): assign licences by group, not by hand

Rule: every user in the lab is fake. Don't import real names, real phone numbers, or a CSV from work.

4. What to practise first (in this order)

Resist the urge to start with the scariest feature. Build up:

Users, groups, licences. Create users, assign licences through a group, and check a user actually received Intune. Most "my device won't enrol" problems in a lab are licensing.
Enrol one Windows 11 VM. Entra-join it during OOBE or from Settings → Accounts → Access work or school. Find it in the Intune admin center. Note how long it takes to appear.
One compliance policy, assigned to the pilot group. Keep it simple (for example require a minimum OS version). Watch the device go from "Not evaluated" to a real state.
One configuration profile from the settings catalog. Pick something visible, like a desktop or lock-screen setting or a Start menu tweak, so you can confirm it applied without a log viewer.
One app. Deploy a Microsoft Store app to the pilot group as Available, then Required. See the difference from the user's side.
Read the logs. Entra sign-in logs, audit logs, and the device's Intune status pages. Learning to read "why didn't this apply?" is the actual job.
Roles. Sign in as lab-helpdesk1 and see what they can and can't do. Practise least privilege on purpose.

Once those feel boring, move on to harder topics (Conditional Access in report-only, update rings, Win32 apps, Autopilot). There are plenty of write-ups on each of those, so I won't repeat them here.

Journal everything. A two-line note per session ("Goal / what broke / what fixed it") becomes your interview story bank later:

## 2026-10-06
Goal: enrol lab-w11-01, apply first compliance policy
Broke: device enrolled but stayed "Not evaluated" for 40 min
Fix/lesson: policy was assigned to a user group, I was checking a device group. Read the assignment tab first.

5. Keeping lab and production completely separate

This is the part people skip, and it's the one that actually causes incidents.

Separate browser profile (or a separate browser) for the lab tenant. Never have lab and work admin portals open in the same profile. It's very easy to click "Assign" in the wrong tenant.
Different names and colours. Give the lab browser profile a loud theme and name it LAB. Check the tenant name in the top-right of the portal before every change.
Separate accounts and passwords. Don't reuse your work password or MFA method name. Lab admin passwords go in your password manager under a LAB folder.
Don't enrol your daily driver or your work laptop into the lab tenant. Lab policies belong on lab VMs.
Don't connect the lab to production. No syncing your work AD, no trust relationships, no guest-inviting your work account into the lab "just to test."
No real data. No exported user lists, no real mailboxes, no screenshots of production pasted into lab notes.
Employer tenant = written permission, every time, even if it's called "test."

6. Cost awareness

Trials: put the end date in your calendar the day you sign up. If the trial asked for a payment method, check whether it auto-converts and cancel in time if you don't want to pay.
Paid licences: one or two licences is enough. Remove spare licences you added "just to try."
Cloud VMs (if you use Azure instead of local VMs): set a budget alert, enable auto-shutdown, and delete resource groups you're done with. Unattached disks and public IPs still cost money after you stop a VM.
Local costs: disk space for checkpoints adds up quickly. Keep three or four per VM and delete old ones monthly.
Evaluation media: time-limited. Rebuilding is free; extending past the terms isn't something to rely on.

7. A one-month plan

Week 1: hypervisor + network, first Windows 11 VM, tenant signup, fake users and groups, journal started.
Week 2: enrolment, compliance policy, settings catalog profile, one app. Break each one on purpose and fix it.
Week 3: roles and least privilege, sign-in and audit logs, optional lab-dc01 with a few OUs and GPOs.
Week 4: tear down and rebuild one VM from scratch in an evening. Write up three incidents from your journal as interview stories.

8. Want the lab plan in a ready-made pack?

The Home Lab Starter Pack for Aspiring Admins from Admin Pack Studio ($19) is the planning and practice side of this post in a set of Markdown playbooks: a lab map with budget tiers and network isolation, a domain controller + member build order with an OU sketch, snapshot naming and a lab journal template, practice ticket drills (seven AD/Windows drills plus four cloud-optional ones for a practice tenant) with a simple self-scoring table, and a 30-day study path geared towards interviews. It also includes a small read-only PowerShell script that records your host's RAM, free disk, and Hyper-V status to a CSV so you can size the lab. It doesn't include ISOs or licences, and it's mostly focused on the VM/AD side, with the cloud practice kept optional.

👉 https://cashflow4375.gumroad.com/l/ivqwrn

Moving on to the Intune side? The Intune & M365 Admin Starter Pack ($19 launch price, normally $29) has enrolment/compliance checklists and read-only snapshot scripts you can run against your lab tenant: https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Microsoft 365, Intune, Entra ID, Hyper-V, and Windows are Microsoft products. Program eligibility, trial terms, licensing, and portal menus change, so check current Microsoft documentation before you sign up for anything. Use only tenants and devices you're authorised to manage. Examples use placeholder names.

Helpdesk Tier-1 triage cards: how to build a small ticket card library (with 4 copy-ready cards)

AdminPackStudio — Wed, 07 Oct 2026 14:09:20 +0000

Helpdesk Tier-1 triage cards: how to build a small ticket card library

Most Tier-1 queues don't have a knowledge problem. They have a consistency problem. The same ticket ("VPN says connected but I can't reach anything") gets handled four different ways by four techs. One flushes DNS, one reinstalls the client, one escalates right away, and one asks the user to "try again tomorrow."

A triage card library fixes that without a 400-page wiki. Each card is one page for one common ticket: what the user sees, what to check in order, what Tier-1 is allowed to fix, and the exact point where you stop and escalate. Ten to fifteen cards cover most of a Tier-1 day.

This post covers:

The card format, and why it beats long KB articles for Tier-1
How to organize a small card library (naming, IDs, ownership)
An intake card that every other card depends on
Four copy-ready cards: MFA prompt loop, VPN with no internal access, "PC is slow," and OneDrive stuck syncing
An escalation matrix and handoff note
A monthly upkeep routine so the library doesn't rot

If you only want one card to start with, the earlier post on the "Outlook keeps asking for my password" card walks through a single card in depth. This one is about building the set.

Scope: Windows 10/11, Microsoft 365, Entra ID (Azure AD) accounts. Menu names and commands move around, so check every card against your own build, tools, and policies before you publish it to your team. Only work tickets for users and devices you're authorized to support.

1. Why cards beat long KB articles for Tier-1

Long knowledge base articles are written for the person who already understands the problem. Tier-1 techs need something different. They're on a call, the user is waiting, and they need to know the next check in the order that matters.

A good card is:

Short. One screen, or one printed page.
Ordered. The checks run cheapest and most decisive first, and each one says what a result means.
Bounded. It names what Tier-1 may fix and, just as important, what Tier-1 must not do.
Escalation-aware. It says exactly when to stop, who gets the ticket, and what to attach.

The format used throughout this post:

CARD <ID>: <the user's words, not the technical cause>

SYMPTOMS     what the user sees / reports
CHECKS       ordered, read-only first, each with "if X -> Y"
TIER-1 FIXES only what your playbook allows
DO NOT       the common mistakes that make things worse
ESCALATE     specific triggers -> specific queue
ATTACH       what Tier-2 needs so they don't call the user back

Name cards with the user's words ("PC is slow," "VPN connected but nothing works"), not the root cause ("DNS suffix misconfiguration"). The tech searches for what the user said, because the cause isn't known yet.

2. Organizing a small card library

You don't need a fancy tool. A folder of Markdown files, a OneNote section, a Confluence space, or a set of ticket macros all work. What matters is structure.

Group cards into four shelves:

Shelf	Example cards
0. Intake & rules	Intake script, priority rubric, escalation matrix, note template
1. Identity & sign-in	Password doesn't work, MFA prompt loop, repeated Office password prompt, VPN no internal access
2. Endpoint basics	PC is slow, disk full, Wi-Fi with no internet, printer, dock/monitor
3. M365 apps	Outlook can't send, Outlook search, Teams audio, OneDrive stuck, "I lost a file"

Give every card a short ID (ID-02, EP-01, M365-04). Then a ticket note can say "Ran EP-01 checks 1–4," and the next tech knows exactly what was done.

Put a header on every card:

ID: EP-01   Owner: <team/lead>   Last reviewed: <date>   Applies to: Win 10/11

An owner and a review date are what keep a card library alive. Cards without them quietly go stale.

Start small. Pull your last 30 days of tickets, sort by category, and write cards for the top 8–10. That usually covers most of the volume. Add a card only when the same ticket shows up three times without one.

3. The intake card (every other card depends on it)

Most bad escalations aren't caused by bad troubleshooting. They're caused by missing basics. An intake card makes sure every ticket starts with the same facts.

CARD IN-00: Intake (use on every ticket)

ASK
1. Who: name + email/UPN. Verify identity per YOUR org's procedure.
2. Device: name or asset tag (if it's an endpoint issue).
3. Goal: what are you trying to do?
4. Error: exact text or a screenshot. "It doesn't work" isn't an error.
5. Since when? What changed? (password, new laptop, travel, VPN, update)
6. Where: office / home / hotel, wired / Wi-Fi, on VPN or not.
7. Impact: just you, your team, or customers?

DECIDE
- Many users, same symptom -> stop. Tell your lead / check service health.
- Security smell (unexpected MFA prompts, odd inbox rules, "I clicked a link")
  -> follow the security procedure. Don't troubleshoot it as a normal ticket.
- Otherwise -> pick the matching card.

NEVER
- Ask for a password in chat, email, or on the phone.
- Bypass MFA or Conditional Access "as a favor."

DONE WHEN
Another tech could pick up this ticket without calling the user back for basics.

That last line is the whole test for good intake.

4. Four copy-ready Tier-1 cards

These are written to be pasted into your KB and edited. Replace the tool names, queues, and allowed actions with your own.

Card ID-03: MFA prompt loop / "it keeps asking me to approve"

CARD ID-03: MFA prompt loop / endless "approve sign-in"

SYMPTOMS
- Authenticator push arrives, user approves, and sign-in asks again
- "Try another way" goes nowhere
- Often after: new phone, restored phone backup, reinstalled Authenticator

CHECKS (in order)
1. Did the user START this sign-in? If they're getting pushes they didn't
   trigger -> STOP. Treat as possible account compromise. Security procedure.
2. Right account in Authenticator? (work account, not a personal one)
3. Number matching shown? Is the user entering the number from the screen,
   or only tapping "Approve"?
4. Phone time set automatically? (codes fail when the clock drifts)
5. New phone recently? The old phone may still be the registered method.
6. Can they sign in using a code (OTP) instead of a push?

TIER-1 FIXES (only if your role and playbook allow)
- Have the user use the code option instead of push.
- Walk them through re-adding the work account in Authenticator ONLY via
  your org's supported registration flow, after identity is verified.

DO NOT
- Remove or reset MFA methods without verified identity and the right role
- Approve or relay prompts on the user's behalf
- Reset the password to "fix" an MFA loop (it rarely helps)

ESCALATE WHEN
- Unrequested prompts / suspected MFA fatigue        -> Security, now
- Method reset needed and Tier-1 isn't allowed       -> Identity admin
- "Blocked by policy" / Conditional Access wording   -> Identity / CA owner

ATTACH
- Time of last attempt, app/browser used, exact error or screenshot,
  phone change details, whether the user started each prompt

The most important line is check 1. An MFA loop the user didn't start isn't a helpdesk ticket. It's a security event.

Card ID-04: VPN connected but no internal resources

CARD ID-04: VPN says "connected" but file shares / intranet don't work

SYMPTOMS
- VPN client shows connected
- Internal sites, mapped drives, or apps time out
- Internet browsing may still work (split tunnel) or may not

CHECKS (in order)
1. Scope: one user or many? Many -> lead / network team. Stop.
2. One resource or all internal resources?
   One -> could be that app/server, or the user's access to it.
3. Name vs address: run  nslookup <internal-name>
   Fails -> likely DNS over the VPN. Try the full name (server.corp.example).
4. Read-only network info:  ipconfig /all
   Does the VPN adapter have an IP and the expected DNS servers?
5. Another VPN, a "privacy" VPN, or a security tool also running?
6. Right VPN profile / gateway for this user's group or region?
7. Did VPN MFA actually complete, or is the client stuck half-connected?

TIER-1 FIXES
- Disconnect fully, close the client, reconnect.
- Turn off any other VPN or proxy and retest.
- ipconfig /flushdns, then retest by full name (FQDN).
- Reboot once.
- Reinstall the VPN client ONLY from your approved source, and only after
  confirming the profile is correct.

DO NOT
- Edit hosts files or hard-code DNS on the user's laptop
- Install a different VPN client from the internet
- Add the user to network/VPN groups yourself unless that's your role

ESCALATE WHEN
- Multiple users, same resource                   -> Network team
- Adapter has no DNS servers / wrong subnet       -> Network team
- User lacks access to the resource itself        -> App owner / access request
- Works on hotspot, fails on home network         -> Tier-2 (likely IP conflict
                                                     or router issue; document)

ATTACH
- ipconfig /all output, nslookup result, resource(s) affected,
  network type (home/hotel/office), VPN client version, time of test

Check 3 settles most of these. If the name won't resolve but the full name or IP works, it's DNS, not "the VPN is broken."

Card EP-01: "My PC is slow"

CARD EP-01: "My computer is slow"

SYMPTOMS
- Apps hang, long boot, fan loud, "Not responding"

CHECKS (in order)
1. Slow at everything, or one app? One app -> that app's card / vendor.
2. Task Manager > Processes: sort by CPU, Memory, Disk. Note the top 3.
3. Free space on C:. Under ~10% free is a red flag.
4. Last reboot (Task Manager > Performance > CPU > Up time).
   Days or weeks? Pending updates?
5. Anything new: an install, update, or browser extension?
6. Anything suspicious: pop-ups, unknown processes, security alerts?
   -> STOP. Security procedure. Don't "clean it up" yourself.

TIER-1 FIXES
- Reboot (a real restart, not just closing the lid).
- Close runaway apps; trim browser tabs and extensions.
- Free disk space: Storage Sense / Disk Cleanup, Recycle Bin, Downloads.
- Install pending updates if policy allows.
- On managed devices: sync from Company Portal / Settings rather than
  disabling management components.

DO NOT
- Install "PC optimizer" or registry-cleaner tools
- Disable antivirus / Defender to "speed it up"
- Delete files you can't identify, or user data without consent

ESCALATE WHEN
- Disk health warnings, or drive always near full on a standard image -> Tier-2 / hardware
- Malware suspicion                                                  -> Security
- Repeated high CPU from a managed/security agent                    -> Endpoint team
- Hardware age/spec clearly below standard                           -> Lead (refresh)

ATTACH
- Top processes (CPU/Mem/Disk), free space, uptime, recent changes,
  what you already tried

Card M365-04: OneDrive stuck on "processing changes"

CARD M365-04: OneDrive stuck syncing / "processing changes" forever

SYMPTOMS
- Sync icon keeps spinning; files show pending or have a red X
- "Processing changes" or "Looking for changes" for hours

CHECKS (in order)
1. Click the OneDrive cloud icon. Is there a specific error or file listed?
   Screenshot it.
2. Free disk space on the device.
3. Problem file names/paths: very long paths, unusual characters,
   or files open/locked in another app.
4. A huge folder just added or moved? (it may just be slow, not stuck)
5. Can the user open the same files at office.com / in the browser?
   Yes -> the cloud copy is fine; the problem is the local client.
6. Shared library: does the user still have permission to that site?

TIER-1 FIXES
- Pause sync, wait a minute, resume.
- Fully quit OneDrive (cloud icon > Settings > Pause/Quit), reopen.
- Close apps holding the problem file; rename it if the name/path is the issue.
- Free up disk space.
- Make sure the OneDrive client is up to date.

DO NOT
- Unlink the account or delete the local OneDrive folder as a first step
- "Fix" a conflict by deleting one copy before confirming which one is current
- Move the user's data around without telling them

ESCALATE WHEN
- Files exist locally but not in the cloud, and the user needs them  -> Tier-2 (data risk)
- Permission errors on a SharePoint library                          -> Site owner / Tier-2
- Storage quota warnings                                             -> M365 admin
- Unlink/reset is the next step and your playbook reserves it        -> Tier-2

ATTACH
- Error text/screenshot, affected paths, free disk space,
  browser test result, client version, what you already tried

Check 5 is the OneDrive version of the Outlook web test. If the files look right in the browser, the data is safe, and you're only fixing the sync client.

5. The escalation matrix

Cards tell a tech when to escalate. A single matrix tells them where. Keep it on its own page and link every card to it.

ESCALATION MATRIX (edit queue names to match yours)

Trigger                                              -> Queue
-----------------------------------------------------------------------------
Many users, same symptom                             -> Lead + service health
Suspected compromise / unrequested MFA / phishing    -> Security (immediately)
Sign-in blocked: "policy", "compliant", "managed"    -> Identity / CA owner, or
                                                        Endpoint / Intune admin
Device missing from management / enrollment broken   -> Endpoint / Intune admin
Network: DNS, VPN gateway, Wi-Fi floor-wide          -> Network team
App-specific access or data                          -> App owner
Possible data loss (sync, deleted files)             -> Tier-2, flagged as data risk
Hardware failure                                     -> Tier-2 / hardware / RMA
Card's fixes done, problem back within a day         -> Tier-2

Handoff note (paste into the escalation):

Escalating to: <queue>        Card used: <ID>, checks 1–<n>
User / UPN:                   Device:
Business impact:
Ruled out:
Tried (and result):
Key errors + timestamps:
Attachments: (screenshots, ipconfig/dsregcmd output, etc.)
User available: <window>

"Card used: ID-04, checks 1–7" tells Tier-2 more in one line than a paragraph of "tried everything."

6. Keeping the library alive (monthly, ~30 minutes)

Card libraries die quietly. Here's a routine that keeps one useful:

Pull the top 10 ticket categories for the month. Any without a card? Draft one.
Check reopened and bounced tickets. If a card's fixes keep failing, the order or the escalation trigger is wrong. Fix the card, not the tech.
Ask Tier-2 one question: "Which escalations arrived missing something?" Add that item to the card's ATTACH list.
Update menu names after major Windows or Microsoft 365 changes.
Bump the "Last reviewed" date on every card you touched, and archive cards for tickets that no longer happen.

A useful signal to watch: escalations that bounce back to Tier-1 for missing information. When that number drops, the cards are working.

FAQ

What's the difference between a triage card and a KB article?
A KB article explains a topic. A triage card drives a live ticket: ordered checks, allowed fixes, and a hard stop for escalation. Many teams keep both and link the card to the deeper article.

How many cards does a Tier-1 team need?
Start with 8–10 that match your top ticket categories. Most small teams level off around 15–25. If a card hasn't been used in six months, archive it.

Should Tier-1 be allowed to reset passwords and MFA?
That's your org's decision, and it should be written down. If it is allowed, it should always come after identity verification. The cards above keep it behind "only if your role and playbook allow."

Can I automate data collection for cards?
Yes, carefully. A read-only script that gathers local info (OS, uptime, disk space, network config, join state) and saves it to a file saves a lot of back-and-forth. Keep collection scripts read-only so Tier-1 can run them without risk.

Want a ready-made card library?

The cards above are samples of the format used in the IT Helpdesk Tier-1 Break/Fix Runbook Pack ($24) from Admin Pack Studio. It's a ready-made version of the library described in this post:

Intake and escalation rules: an intake script, a priority rubric, escalation triggers, and verification steps before any password reset
Identity and sign-in cards: password problems, MFA loops, work-account sync errors, VPN with no internal access, guest access to SharePoint links
Endpoint cards: slow PC, disk full, Wi-Fi with no internet, printers, docks and monitors
Microsoft 365 cards: Outlook send/receive and search, Teams audio/video, OneDrive sync, "I lost a file"
Notes and handoff templates plus a weekly queue hygiene routine
One read-only PowerShell local snapshot script for Windows triage. It only reads: no password changes, no device actions, no Graph writes.

All of it is plain Markdown, so you can paste it into whatever KB or ticket tool you use.

👉 https://cashflow4375.gumroad.com/l/tezla

If a lot of your escalations end up at Intune enrollment or device compliance, the Intune & M365 Admin Starter Pack covers that side for admins ($19 during launch week, normally $29): https://cashflow4375.gumroad.com/l/joonf

You don't need either one. The intake card, the four cards, and the matrix above are enough to start a library this week.

Admin Pack Studio. Not affiliated with or endorsed by Microsoft. For IT staff authorized to support their organization's users and devices. Follow your own policies, and check current Microsoft documentation for menu names and behavior.

Windows Autopilot ESP Stuck? The Complete Runway Guide: Hash, Profile Assignment, Blocking Apps, Network/TLS, and CA Deadlocks

AdminPackStudio — Wed, 07 Oct 2026 14:08:29 +0000

Windows Autopilot ESP Stuck? The Complete Runway Guide

Short version: when Windows Autopilot stalls on the Enrollment Status Page (ESP), the cause almost always sits on one of five layers: registration (hash), profile assignment, ESP blocking design, network/TLS, or Conditional Access. Work through them in that order and collect evidence with read-only tools before anyone resets the device.

This is the long version of an earlier, shorter triage checklist. That one is a single page for the moment a laptop is stuck. This one is the runway: what each layer does, how it fails, what you'll see, how to prove it, and how to stop it coming back on the next dock day.

No Microsoft affiliation. Operational guidance for admins who are authorized to manage their tenant and devices. Check current Microsoft Learn docs for your OS build and cloud, because endpoints and ESP behavior change over time.

How Autopilot and ESP actually fit together
Before you touch anything: capture the state
Layer 1: Hardware hash and Autopilot registration
Layer 2: Deployment profile assignment
Layer 3: ESP blocking apps, policies, and timeouts
Layer 4: Network, proxy, and TLS inspection
Layer 5: The Conditional Access enrollment deadlock
Hybrid join sidebar: when ESP takes the blame for AD
Read-only diagnostics toolkit
Symptom to layer lookup table
Escalation note template
Making dock day boring: prevention habits
FAQ

How Autopilot and ESP actually fit together

People say "Autopilot is stuck" for problems in very different places, so it helps to split the flow into stages:

Stage	What happens	What has to be true
OOBE network	Device gets online	Reachable internet, no captive portal, sane clock
Profile download	Device asks the Autopilot service "who am I?"	Hash registered and a deployment profile assigned to this device
Identity / join	User signs in (user-driven) or device authenticates (self-deploying / pre-provisioning)	Join type matches profile; TPM attestation works where required
MDM enrollment	Device enrolls into Intune	License, MDM user scope, CA doesn't block enrollment
ESP device phase	Device-targeted policies, certificates, and blocking apps install	Assignments reach the device; content downloads; apps detect correctly
ESP account phase	User-targeted policies and apps	Assignments reach the user; CA allows token issuance for the session
Desktop	User can work	ESP released

Two things to keep in mind for the rest of this guide:

ESP only waits for what it's told to wait for. If a blocking app or policy never succeeds, or never targets the device, ESP keeps waiting until it times out.
A failure in an early stage often shows up later. A profile assignment gap can look like an ESP hang, and a CA policy can look like a broken app. The layered order exists so you don't fix the wrong thing.

Before you touch anything: capture the state

The most expensive mistake in Autopilot troubleshooting is resetting a device before you know why it failed. A reset removes local evidence, and if the cause is assignment, network, or CA, the next attempt fails the same way.

Capture these first:

[ ] Serial number and model
[ ] Exact ESP text and phase: "Device preparation", "Device setup", or "Account setup", plus the item it's stuck on
[ ] Elapsed time and the timeout configured in the ESP profile
[ ] Network type: corporate wired, corporate Wi-Fi, home, hotel/guest, branch
[ ] Error code if the ESP shows one (photo is fine)
[ ] Did a sister device succeed on the same network with the same profile today?

During OOBE, Shift+F10 usually opens a command prompt (unless you've disabled it by policy). That's enough to run the read-only checks in the diagnostics section.

Layer 1: Hardware hash and Autopilot registration

What it does

Autopilot identifies the device from its hardware hash. No registered hash means no profile, which means a generic, consumer-style OOBE however good your Intune configuration is.

How it fails

Failure	What you see
OEM / partner never uploaded this order	Generic OOBE on brand-new hardware
Hash captured but CSV import failed or was never done	Device absent from Autopilot devices list
Motherboard replaced after registration	Device behaves as unregistered or mismatched
Duplicate / stale objects from a prior life	Wrong profile, wrong Group Tag, confusing assignment
Group Tag typo (`CORP-STD` vs `CORP_STD`)	Registered but never lands in the dynamic group

How to prove it

Look the serial up in the Autopilot devices list. Is it there, and is there exactly one entry?
Check Group Tag / Order ID against the dynamic group rule character for character.
Check the device's profile status. "Not assigned" after a sync points to Layer 2, not Layer 1.

How to fix it

Register the hash (OEM/partner, or capture and import in your normal process), wait for the service to sync, then confirm a profile is assigned before restarting OOBE. Resetting an unregistered device won't make a profile appear.

Prevention: one source of truth that maps purchase order, asset tag, serial, and hash, plus a pre-ship check that every device appears with the correct tag.

Layer 2: Deployment profile assignment

What it does

The deployment profile tells the device which mode to use (user-driven, self-deploying, pre-provisioning), which join type (Entra or hybrid), and how OOBE should behave. The profile has to reach the device before the user signs in.

The device-group vs user-group trap

This causes more "Autopilot is haunted" tickets than anything else:

Deployment profiles should target device groups that contain Autopilot device objects, often through a dynamic rule on Group Tag or ZTDId.
Assigning a deployment profile to a user group doesn't work the way people expect, because during OOBE there's no user yet. The device has to be in scope on its own.
Overlapping assignments (the device is in two groups with two profiles) give unpredictable results. Aim for one device, one winning profile.

Dynamic group lag

Dynamic membership is not instant. Right after registration a device may not be in the group yet, and then the profile isn't assigned yet. Testing too early causes plenty of false failures. Check membership and profile status first, then start OOBE.

Checklist

[ ] Device is a member of the targeted device group (check the group, not just the rule)
[ ] Profile status for the device shows assigned, and it's the profile you expected
[ ] Mode and join type match the scenario (self-deploying needs TPM 2.0 and no user affinity; hybrid needs directory prerequisites)
[ ] ESP profile targets the same population as the deployment profile
[ ] Profile names carry intent and version, e.g. AP-UserDriven-Entra-Std-v3

Tip: if the device showed the right branding and sign-in page, Layer 2 probably worked. If it showed a generic OOBE or the wrong join behavior, stay here.

Layer 3: ESP blocking apps, policies, and timeouts

What it does

ESP holds the desktop until selected apps and policies finish. Done well, users get a ready-to-work PC. Done badly, it turns every flaky installer into a dock-day outage.

Common ESP blockers

Blocker	Why it stalls ESP
Too many blocking apps	Every extra app adds download time and another chance to fail
Win32 detection rule that never matches	App installs fine, Intune thinks it didn't, ESP waits
Requirement rules (OS build, architecture, disk) excluding the device	App never applies, so "blocking" means waiting forever
Dependencies / supersedence chains	One failure deep in the chain stops everything
Installer needs user context or a reboot nobody planned	Exit codes misread; hard reboot mid-ESP
Mixed app types colliding	Different install channels fighting during provisioning
Timeout shorter than real-world p95	Fine in the lab on gigabit, fails on branch Wi-Fi

Design rules that keep ESP sane

Block only what's needed before the desktop. Usually security agent, Company Portal, and the bare minimum of line-of-business apps. A starter cap of around five proven apps is a reasonable first production ring.
New apps are never ESP-blocking on day one. Deploy as required/available outside ESP until installs are reliable, then promote.
Detection must reflect what the installer actually leaves behind. Validate on a clean device, not your packaging VM.
Run a timing study. Ten pilot devices across office, home, and branch networks. Record minutes to ESP complete. If your p95 goes past the timeout, shrink the blocking set or fix the app before you raise the timeout.
Device ESP vs account ESP. Know which phase each blocking item lands in. User-targeted items stall the account phase, device-targeted items stall the device phase.

When ESP names a specific app

Don't raise the timeout first. Check:

Install status for that app on that device
The install command, return codes, and the detection rule against what's actually on disk or in the registry
Requirements and dependencies
The Intune Management Extension logs (see diagnostics)

Fix the package, test it outside ESP, and only then put it back in the blocking list.

Layer 4: Network, proxy, and TLS inspection

Why network problems look like ESP problems

ESP downloads policy, certificates, and Win32 content from cloud endpoints. If the network quietly interferes, ESP sees "not installed yet", not "network broken". The classic sign is: works on the lab bench, fails at the branch or on home Wi-Fi.

Network failure modes

Problem	Signal
Captive portal / guest Wi-Fi	Online for the first sign-in, then content stops after the session expires
Proxy requiring user authentication	OOBE and system-context downloads can't do interactive proxy auth
TLS / SSL inspection	Certificate mismatch on endpoints that expect the real Microsoft chain; enrollment or content download fails without a clear message
Firewall category blocks	Some endpoints allowed, CDN / content endpoints blocked
DNS filtering	Name resolution fails for content or attestation hosts
Clock skew	Token and certificate validation fails in ways that look random
TPM attestation blocked (self-deploying / pre-provisioning)	Device can't reach the TPM manufacturer certificate endpoints and attestation fails early
Low bandwidth + large blocking payload	Not "broken", just slower than the ESP timeout

What to do

[ ] Compare with a known-good network (wired corporate or a phone hotspot). If the same device succeeds, the problem is the path, not the profile.
[ ] Use the current Microsoft network endpoint guidance for Autopilot, Entra, Intune, and Win32 content delivery in your cloud, and allowlist through your normal change process.
[ ] Exclude enrollment and content endpoints from TLS inspection where your security process allows. Inspection appliances break more provisioning than almost anything else.
[ ] Keep provisioning on a network segment without captive portals or per-user proxy auth.
[ ] Check the device clock / time sync before you chase token errors.
[ ] Include at least one branch device in every ESP timing study.

If several devices enroll fine but then fail the same Win32 installs, fix delivery before you rewrite detection rules again.

Layer 5: The Conditional Access enrollment deadlock

The chicken-and-egg

A device has to enroll before it can be compliant. Compliance evaluation also needs time after enrollment. A broad CA policy such as "All cloud apps → require compliant device" can block the sign-ins and token requests the device needs during enrollment and the ESP account phase. You get a loop: can't finish enrollment → can't become compliant → CA blocks → can't finish enrollment.

What it looks like

ESP reaches the account setup phase, then fails or prompts for sign-in again
Errors mention the device not being compliant, managed, or registered
Sign-in logs show CA failures for the user during the provisioning window
It started right after someone enforced a CA policy that worked fine in report-only

How to prove it

Pull the user's sign-in logs for the provisioning window. Which policy applied, and which grant control failed?
Use What If with the user, the app, and the device platform to see which policies would apply.
Check whether the policy is report-only or on. If report-only shows it would have failed, you've found the likely future deadlock before it happens.

How to break the loop safely

[ ] Follow current Microsoft guidance on how enrollment-related apps should be handled in "require compliant device" policies. Don't invent broad exclusions under pressure.
[ ] Keep new device-compliance CA policies in report-only until Autopilot success rates are stable.
[ ] Watch MFA and registration requirements (for example, "register or join devices" user actions) so they don't fight the OOBE sign-in.
[ ] Keep break-glass accounts excluded and monitored, as with every CA rollout.
[ ] Document every exclusion with an owner and a review date.

Rule: keep CA enforcement one step behind your Autopilot success rate. Tighten after provisioning is boring, not before.

Hybrid join sidebar: when ESP takes the blame for AD

Hybrid Autopilot adds failure domains: the on-prem directory, sync, and a line of sight to domain controllers. Plenty of "ESP hangs" are really hybrid prerequisites failing quietly.

Check before blaming ESP:

[ ] Directory sync healthy
[ ] Service connection point (SCP) configured correctly
[ ] Provisioning network can reach domain controllers when the domain-join step runs
[ ] Offline domain join connector / components healthy, with rights to create computer objects in the target OU
[ ] Naming template respects AD / NetBIOS limits

If your apps don't strictly need hybrid join on day one, it's worth reviewing whether Entra join could be the default with hybrid as a documented exception. That's an architecture decision for your org, not a quick fix in the middle of an incident.

Read-only diagnostics toolkit

Everything in this section reads state or collects logs. None of it enrolls, resets, wipes, or changes policy. Only run it on devices you're authorized to support.

1. Join and MDM state: `dsregcmd /status`

# Read-only: summarize join + MDM signals
$raw = dsregcmd /status | Out-String
$pick = 'AzureAdJoined','DomainJoined','TenantName','DeviceId','MDMUrl','AzureAdPrt'
foreach ($k in $pick) {
    if ($raw -match "(?m)^\s*$k\s*:\s*(.*)$") {
        '{0,-14} {1}' -f $k, $Matches[1].Trim()
    }
}

How to read it:

AzureAdJoined : NO after the user signed in → join stage failed (Layer 2 / identity)
MDMUrl empty → not enrolled into MDM (license, MDM user scope, or CA)
AzureAdPrt : NO during the account phase → token problems; look at CA and network

2. Autopilot and MDM event logs

# Read-only: recent Autopilot + MDM enrollment events
$logs = @(
  'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot',
  'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
)
foreach ($l in $logs) {
  Get-WinEvent -LogName $l -MaxEvents 30 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName,
      @{n='Msg';e={ ($_.Message -split "`n")[0] }}
}

Look for profile download results, enrollment errors, and repeated failures around the time the ESP stalled.

3. Win32 app logs (Intune Management Extension)

Win32 installs and detection results are logged under:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

IntuneManagementExtension.log (and related logs in that folder) shows download progress, exit codes, and detection results. A "detection rule not satisfied" after a successful install exit code is the classic Layer 3 detection bug.

4. Built-in diagnostic bundle

Windows includes an MDM diagnostics tool that collects logs into an archive for offline review:

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -cab C:\Temp\ap-diag.cab

It writes a log bundle and doesn't change device configuration. Attach the bundle to the escalation instead of resetting first.

5. Local snapshot to CSV

For dock days with many devices, a small read-only script that writes join state, tenant, MDM URL, and OS version to CSV makes it easy to compare a failing device with a working one. The Autopilot pack below includes one (Get-LocalAutopilotEspSnapshot.ps1). It only reads local signals and writes an optional CSV.

Symptom to layer lookup table

Symptom	Most likely layer	First check
Generic OOBE, no org branding	1 Registration / 2 Assignment	Serial in Autopilot devices; profile status
Wrong join type or mode	2 Assignment	Overlapping profiles; device group membership
Stuck in "Device preparation"	4 Network / TPM	Known-good network test; attestation reachability
Stuck in "Device setup" on an app	3 ESP blocker	IME log; detection rule; requirements
Stuck in "Device setup" on policies/certs	3 ESP / 4 Network	Assignment of the blocking items; content reachability
Fails in "Account setup" with sign-in loop	5 CA deadlock	Sign-in logs; What If; report-only results
Works on HQ wired, fails on branch/home	4 Network	Proxy, TLS inspection, captive portal, bandwidth
Hybrid device fails at domain join	Hybrid sidebar	Directory sync, SCP, DC line of sight
Pre-provisioning (technician phase) red screen	3 / 4	Apps in technician phase; network; TPM

Escalation note template

Paste this into the ticket so the next person doesn't start from zero:

AUTOPILOT / ESP ESCALATION
Serial / model:
Autopilot registered (Y/N), Group Tag:
Device group member (Y/N), deployment profile assigned:
Mode / join type:
ESP phase + item stuck on:
Elapsed time vs ESP timeout:
Network type (and known-good network test result):
dsregcmd: AzureAdJoined / MDMUrl / AzureAdPrt:
CA sign-in log result (policy + grant failed):
Logs attached (IME / diag cab):
Sister device on same profile+network succeeded? (Y/N)
Actions taken so far (no reset yet? Y/N):

Making dock day boring: prevention habits

Pre-ship registration check: every device present, one object, correct tag.
One primary profile covering most of the fleet; exceptions get a second profile, not seven.
ESP blocking cap with a promotion rule: only apps that have installed reliably outside ESP.
Timing study on every major change (new blocking app, new site, new OS build).
Provisioning network standard: no captive portal, no user-auth proxy, TLS inspection exclusions approved.
CA changes go through report-only and are checked against Autopilot sign-ins before enforcement.
Written reset criteria: a reset/retry happens only after the layers above are checked and evidence is collected, and always under your org's change and device policy.

FAQ

Why is my Autopilot device stuck on "Setting up your device for work"?
Usually an ESP blocking app or policy that never succeeds or never targets the device. Check which phase it's in, which item is pending, and the Intune Management Extension log for that app.

Why does Autopilot show a normal OOBE instead of my company's?
The device either isn't registered (no hash) or has no deployment profile assigned yet. Check the serial in Autopilot devices, device group membership, and profile status.

Should the deployment profile be assigned to users or devices?
Devices. The profile has to reach the device before anyone signs in, so target a device group containing the Autopilot device objects.

Can Conditional Access break Autopilot?
Yes. A "require compliant device" policy that also applies to the sign-ins needed during enrollment can create a loop. Validate with sign-in logs and What If, and keep new compliance policies in report-only until Autopilot is stable.

Can TLS inspection cause ESP failures?
Yes. Inspection can break certificate validation for enrollment and content endpoints. Exclude them according to current Microsoft guidance and your security process.

Should I just increase the ESP timeout?
Only after you've fixed failing apps and confirmed content delivery. A longer timeout on a broken app just makes users wait longer for the same failure.

When is resetting the device the right call?
When registration, assignment, ESP design, network, and CA all check out, the evidence is collected, and the device is in a bad local state. Do it under your org's policy and confirm hash and profile are still correct before the next OOBE.

Want the full Autopilot runbooks?

This guide gives you the triage order. If you'd like the rest written down, the Windows Autopilot & ESP Ops Pack ($29) from Admin Pack Studio has five markdown modules:

Registration hygiene (OEM/hash paths, Group Tag strategy, duplicate cleanup, hand-off template)
Deployment profiles that stick (decision matrix, assignment rules, hybrid gates, change-control snippet)
ESP design and timing (blocking-set rules, configuration checklist, timing study template)
Cloud vs hybrid join ops (decision prompts, migration path, exec one-pager)
Seven break/fix cards (generic OOBE, ESP hangs, failing Win32, hybrid join, branch-only failures, CA deadlock, pre-provisioning)

It also includes the read-only local snapshot script mentioned above. The script reads local signals and writes an optional CSV. It does not enroll, reset, wipe, or change policy.

👉 https://cashflow4375.gumroad.com/l/hlanei

If your problem is more about enrollment and compliance than Autopilot itself, the Intune & M365 Admin Starter Pack covers enrollment hygiene, baseline compliance with report-only CA phasing, and break/fix cards. It's $19 during launch week (normally $29): https://cashflow4375.gumroad.com/l/joonf

The checklist above works fine without either pack. Questions and war stories welcome in the comments.

— Admin Pack Studio

Not affiliated with or endorsed by Microsoft. Windows, Intune, Autopilot, and Entra are trademarks of their respective owners. Operational guidance for admins authorized to manage their tenant and devices. Test in a pilot first; provided AS-IS, no warranty.

Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass and rollout waves

AdminPackStudio — Wed, 07 Oct 2026 14:02:13 +0000

Conditional Access baseline for Entra ID: from report-only to enforce, step by step

Conditional Access (CA) is the most powerful switch in a Microsoft 365 tenant, and the easiest one to get wrong. One policy scoped to All users and All cloud apps, set to On on a Friday afternoon, and Monday starts with a helpdesk queue full of people who can't open Outlook. Sometimes that includes the admins.

The policies themselves are rarely the issue. The trouble usually comes from the rollout: no naming standard, no pilot group, report-only skipped or never actually reviewed, no emergency access, and a big-bang switch to "everyone."

This guide is the long version of a baseline that avoids that. It covers:

What a CA baseline is (and isn't)
Prerequisites: licenses, roles, inventory
A naming convention you'll still like in a year
Pilot groups that actually tell you something
Report-only mode, done properly
What If and Insights and reporting
Break-glass (emergency access) accounts
The starter policy set
Expanding in waves
Troubleshooting table
Ongoing operating rhythm

If you only want the five-minute version, the short post is here: Conditional Access without the Monday lockout: report-only → enforce.

What a Conditional Access baseline is (and isn't)

A CA baseline is a small set of policies that every tenant should have, plus the process you use to change them safely. The policies are the easy part. The process is what keeps you from locking people out.

What CA does: it evaluates a sign-in to a cloud app (who, what app, what device, where from, how risky) and decides allow, require something (MFA, a compliant device, an authentication strength), block, or limit the session.

What CA does not do:

It doesn't configure devices. Intune does that. CA only reads the device's compliance state as a signal.
It doesn't fix a broken MFA registration process. It will expose one, loudly.
It doesn't apply to things that never touch Entra sign-in (an on-prem file share over SMB, for example).

That last distinction matters for planning. If you plan to require a compliant device, your Intune compliance has to be green first. Otherwise CA just turns every compliance gap into an access outage.

Prerequisites: licenses, roles, and an inventory

Before you design anything, check these three things.

Licenses

Conditional Access needs Microsoft Entra ID P1 for every user the policies cover. P1 is included in Microsoft 365 Business Premium and E3/E5 suites. Risk-based conditions (sign-in risk, user risk) need P2. Build the baseline on P1 and treat risk policies as a later upgrade. Don't hold the baseline back waiting for them.

If your tenant runs on security defaults, know that you'll have to turn them off to use CA. Plan your replacement MFA policy before you do, so there's no gap where nothing enforces MFA.

Roles

Day-to-day CA work doesn't need Global Administrator:

Task	Role
Create and edit policies	Conditional Access Administrator
Read policies, logs, exports	Security Reader or Global Reader
Emergency recovery	Global Administrator (break-glass only)

Inventory what already exists

Many tenants already have a few CA policies from a previous admin, a consultant, or Microsoft-managed policies. Before you add anything, write down every existing policy: its state (On / Report-only / Off), who it targets, and what it grants. Export it to CSV so you have a "before" picture for change control. Any On policy that nobody can explain should get reviewed before you add new ones on top of it.

A Conditional Access naming convention that scales

At 3 a.m. during an incident, you'll be scanning a list of 25 policies to find the one blocking finance. Names like MFA, Test, and New policy (2) are no help then.

Use a structured name that reads like a change ticket:

CA - <Who> - <Control> - <Apps/Scope> - <Phase> - v<n>

Example	Reads as
`CA - AllUsers - Require MFA - O365 - ReportOnly - v1`	Broad MFA design, still observing
`CA - Admins - Require MFA - AllApps - Enforce - v2`	Admin hardening, live, second revision
`CA - AllUsers - Block Legacy Auth - AllApps - Enforce - v1`	Legacy protocols blocked
`CA - Guests - Require MFA - AllApps - Pilot - v1`	Guest policy in pilot
`CA - Windows - Require Compliant - O365 - Wave2 - v1`	Device gate, second rollout wave

A few rules that make the convention stick:

Same field order every time. Alphabetical sorting then groups policies by audience automatically.
Pick one source of truth for phase. Either put the phase in the name and rename at each step, or keep names stable and rely on the portal's state column plus your export. Don't mix the two habits.
Use the Description field for owner, ticket number, last review date and a warning: Owner: SecOps | Ticket: CHG-1042 | Reviewed: 2026-10-06 | Do not widen scope without pilot sign-off.
Bump the version whenever the grant or the scope changes. That makes before-and-after exports easy to diff.

Name your groups the same way: CA-Pilot-Wave0, CA-Wave2-Finance, CA-Excl-LegacyApp-Exp2026-11-30. An exclusion group with its expiry date in the name is much harder to forget.

Pilot groups: who goes first and why

A pilot only helps if it's realistic. If the pilot is three IT admins on brand-new laptops, every policy will look fine until it reaches the warehouse.

A good pilot group (CA-Pilot-Wave0) has:

5–15 people across roles: IT, someone in finance, someone who travels or works in the field, an executive assistant (they act on behalf of others and hit edge cases early).
A mix of devices: managed Windows, a Mac if you have them, a phone using Outlook mobile, and if possible one device you know is noncompliant, so you can see what failure looks like.
People who know they're in a pilot. Send a short note: what's changing, when, and who to call.

Scope rules for the pilot:

Include the pilot group only. Never start with "All users" on a Block or a hard device requirement.
Exclude break-glass accounts from day one, even in pilot (see below).
For harsh grants (compliant device, block), start with a specific app such as Office 365 instead of "All cloud apps." Widen the app scope later, as a separate change.

Report-only mode: how to use it properly

Report-only is the most useful CA feature and the most often wasted. Admins turn it on, never look at the results, and then flip to On a week later. All that tells you is that a week went by.

What report-only does: the policy is evaluated on every matching sign-in and the result is logged, but nothing is enforced. Each sign-in shows outcomes like Report-only: Success, Report-only: Failure, or Report-only: User action required (for example, the user would have been asked for MFA).

How to run a report-only window:

Create the policy with Enable policy = Report-only. Don't create it as On "just to test."
Leave it running for at least 3–5 business days. You want a Monday in there, plus month-end if the policy touches finance apps.
Review the results daily (next section shows where).
Classify every report-only failure as either:
- Expected: this person genuinely isn't ready (no MFA method, noncompliant device). That's a remediation ticket, not a reason to weaken the policy.
- Bug: the policy hits something it shouldn't (a service account, a guest, an app you didn't mean to include, an Intune enrollment flow). That's an assignment fix.
Set an exit bar before you start. For example: "≥95% of pilot users have a registered MFA method, and zero unexplained report-only failures for 3 consecutive days."

A word of caution: a policy that requires a compliant device can trigger device-related prompts during report-only on some platforms. Read the current Microsoft documentation for any device-based policy before you put it in report-only, and test it on a pilot device first.

What If and Insights and reporting: reading the results

Two tools cover most of the investigation work. Use both.

What If (before and after every change)

Entra admin center → Protection → Conditional Access → Policies → What If.

Run these scenarios on every new or changed policy:

Scenario	Expected result
Pilot user + Office 365 + normal location	Your policy applies
Break-glass account + any app	Your policy does not apply
Non-pilot user	Your policy does not apply (while still pilot-scoped)
Guest user (if guests are in scope)	Matches your guest design

If What If surprises you, fix the assignment before you go any further.

Sign-in logs (single-user truth)

Entra → Monitoring & health → Sign-in logs. Open a sign-in and look at the Conditional Access and Report-only tabs. You'll see every policy that was evaluated, whether it applied, and which grant control passed or failed. This is where you confirm a specific user's story ("I got blocked at 8:05").

Insights and reporting (the aggregate view)

Entra → Protection → Conditional Access → Insights and reporting shows the combined effect of one or more policies across all sign-ins over a time range, broken down by user, app, and result.

Practical notes:

The workbook reads sign-in logs from a Log Analytics workspace. If you haven't set up diagnostic settings to send sign-in logs there, set that up first, or the view will be empty.
Filter to one policy at a time during a report-only window.
Sort by Failure and User action required, then open 3–5 sample sign-ins for each pattern. Don't try to read every row.
Screenshot or export the summary for your change ticket. "Report-only reviewed, 2 false failures fixed, 0 outstanding" is the evidence your CAB wants.

If Insights shows a pile of "would block" results for normal, expected work, you aren't ready to enforce, no matter how long the policy has been in report-only.

Break-glass accounts: before you enforce anything

A break-glass (emergency access) account is how you get back in when CA, MFA, or a bad change locks out every admin. Without one, your rollback plan depends on another Global Admin being reachable and not locked out too.

Baseline setup:

At least two cloud-only accounts on the *.onmicrosoft.com domain (not synced from on-prem AD, so an AD or sync problem can't take them out).
Global Administrator, permanently assigned. Not PIM-eligible, because activation may depend on the same systems that are broken.
Excluded from your CA policies, ideally through one CA-Excl-BreakGlass group that you add to every policy's exclusions.
A strong, phishing-resistant sign-in method. Microsoft now requires MFA to sign in to its admin portals, and that applies to emergency accounts as well, so plan for something like a FIDO2 security key stored with the sealed credentials. Check current Microsoft guidance on emergency access accounts when you set this up.
Credentials kept offline in a sealed, documented process, so that two people can retrieve them without depending on the tenant being up.
Monitored. Every break-glass sign-in should raise an alert and be treated as an incident until explained.
Tested quarterly: sign in, open the CA policy list, sign out, write down that the test happened.

The emergency disable procedure (print it and keep it with the credentials):

Sign in as break-glass from a known clean device.
Go to Conditional Access → Policies → the offending policy.
Set it to Report-only (keeps logging for root cause) or Off.
Post in the incident channel: what changed, when, who.
After recovery: root cause, rotate the break-glass credential, and reintroduce the fix through the normal report-only path.

Exclusion hygiene: break-glass is the only permanent exclusion that's acceptable. Every other exclusion (a legacy app, a user stuck mid-migration) should be a group with an owner, a ticket and an expiry date in its description. Exclusions that never get removed are how a CA baseline slowly stops protecting anything.

The starter baseline policy set

Don't enable everything on day one. Most tenants get the most value from these, introduced one at a time, each going through pilot → report-only → enforce:

#	Policy	Why	Watch for
1	Require MFA for admin roles	Highest-value accounts first; small blast radius	Target directory roles, exclude break-glass
2	Block legacy authentication	Legacy protocols can't do MFA, so they bypass it	Old Outlook clients, IMAP/POP, scan-to-email devices
3	Require MFA for all users	The core control	MFA registration gaps; use Temporary Access Pass for stragglers
4	Require MFA for guests	B2B accounts are often forgotten	Separate policy, separate pilot
5	Require compliant device (Windows first)	Only managed, healthy devices reach data	Intune compliance must be green first

Policy 5 is the one most likely to cause a Monday lockout, because it depends on a whole separate system (Intune) being in good shape. Two things to settle before it goes beyond pilot:

Compliance has to be reliably green. Devices that are still encrypting, haven't checked in, or are inside a compliance grace period are common causes of false "not compliant" blocks. I covered one of the most common in BitLocker still encrypting: why Intune marks you noncompliant (and how grace periods save Monday).
Don't create a circular dependency with enrollment. If a "require compliant device" policy covers the apps a device needs in order to enroll (Microsoft Intune / Microsoft Intune Enrollment), new devices can't get compliant because they can't finish enrolling. Check Microsoft's current guidance on which enrollment apps to exclude.

(If your enrollment and compliance side needs work first, there's a separate Intune & M365 Admin Starter Pack for that, linked at the end.)

Rolling out in waves instead of a big bang

Once a policy has been enforced on the pilot for a couple of days without drama, expand it in waves. Use nested groups: add wave groups into the policy's include list instead of switching to "All users" and adding exclusions.

Wave	Who	Enter when	Hold for
0	Pilot (`CA-Pilot-Wave0`)	Report-only clean, What If verified	48 hours enforced
1	IT + Security	Wave 0 had no emergency rollback	3 business days
2	One department (pick a cooperative one)	Helpdesk ticket rate normal	1 week
3	Remaining staff	Remediation backlog cleared	Monitor 2 weeks
4	Guests / vendors	Separate guest policy validated	Ongoing

Rules for each wave:

Tell people before the wave, not after. One paragraph: what changes, what they'll see, what to do if they're blocked.
Watch the helpdesk queue and Insights for 48 hours after each wave.
Have a pre-agreed rollback trigger, for example "more than 5 lockout tickets in an hour from the new wave → remove that wave group, investigate." Removing one wave group is a much smaller, safer change than turning the whole policy off.
Don't expand on Fridays or right before holidays or month-end close.

When the final wave is in, you can switch the include list to "All users" (still excluding break-glass) and retire the wave groups, or keep the waves for the next policy. Either works, as long as it's written down.

Conditional Access troubleshooting table

These are the tickets you'll see during and after rollout. Rule zero: don't disable CA org-wide as a first response. Scope the fix to the affected user or wave and time-box it.

Triage in five minutes: get the error screenshot with the Correlation ID / Request ID → open that user's sign-in log → Conditional Access tab → find which policy shows Failure → reproduce in What If → then fix.

Symptom	Likely cause	First check	Safe fix
"More information required" / MFA registration loop	No usable MFA method, or registration blocked by policy	User's authentication methods; auth methods policy	Issue a Temporary Access Pass; finish registration on a trusted network
"You can't get there from here" / device not compliant	Device not enrolled, not synced, or compliance not yet evaluated	Intune device record: compliance state + last check-in	Sync the device, fix the failing setting; time-boxed exclusion group (≤48h) with ticket if business-critical
Compliant in Intune but CA still blocks	Device identity mismatch (hybrid join vs Entra join), or browser not passing device info	Device ID in sign-in log vs Intune; browser used	Use a supported browser / sign-in method that passes device identity; fix join state
Old Outlook / IMAP / POP / SMTP app fails, new Outlook works	Legacy authentication blocked	Sign-in log Client app column	Move to a modern-auth client; temporary exception group with expiry for true business blockers
Scan-to-email printer or app stops sending	Device uses basic SMTP auth	Sign-in log for the service account	Use a supported relay/connector method; don't permanently exclude the account
Guest can't open Teams / SharePoint	Guest policy requires MFA they haven't set up, or cross-tenant settings	Guest's sign-in log; cross-tenant access settings	Guest completes MFA registration; adjust cross-tenant trust deliberately
New devices stuck during Autopilot / enrollment	Compliant-device policy covers enrollment apps (circular dependency)	Which policy fails on Microsoft Intune Enrollment sign-ins	Exclude enrollment apps from the device policy per Microsoft guidance
Traveling user blocked or prompted unexpectedly	Named location / country rule; VPN egress IP changed	Sign-in log location + IP; named location definitions	Update named locations; time-boxed traveler exception
Named admin locked out of portal	Admin policy too strict, MFA method broken	Which policy failed; admin's auth methods	Second admin sets policy to Report-only or adds timed exclusion; break-glass only if no other admin can act
Report-only shows failures nobody can explain	Policy scope wider than intended (apps, users, platforms)	What If with a sample user	Fix assignment before enforcing; that's what report-only is for

Severity guide:

Severity	Example	Response
SEV1	All admins locked out	Break-glass → offending policy to Report-only → incident bridge
SEV2	A whole department can't reach email	Remove that wave group or scope a ≤4h exclusion; fix the root cause
SEV3	One user, one app	Standard ticket; no tenant-wide changes
SEV4	Report-only noise	Tune during business hours

Keeping the baseline healthy

A baseline isn't a one-time project. A light routine keeps it from drifting:

Cadence	Action
Weekly	Skim CA failures in Insights; check for new report-only failures on anything in flight
Monthly	Export all policies to CSV and diff against last month; review exclusion groups for expired entries
Quarterly	Test a break-glass sign-in; run a tabletop of the emergency disable procedure
After any big Intune or identity change	Put affected device-based policies back through a short report-only check

Checklist before any policy goes to On:

[ ] Name and Description follow the convention (owner, ticket, review date)
[ ] Include = pilot or wave group, not All users
[ ] Exclude = break-glass group (+ documented, expiring exceptions only)
[ ] App scope isn't accidentally "All cloud apps" with a Block grant
[ ] Report-only ran ≥3 business days and Insights was reviewed
[ ] What If verified for pilot user, break-glass and non-pilot user
[ ] Remediation tickets for false failures are closed
[ ] Rollback trigger and owner written in the change ticket

Excel & CSV ops for IT admins: cleaning Intune device exports without breaking your UPNs (Power Query basics + 9 pitfalls)

AdminPackStudio — Wed, 07 Oct 2026 14:01:27 +0000

Excel & CSV ops for IT admins: cleaning Intune device exports without breaking your UPNs

Someone asks: "How many active laptops do we actually have, and who's on them?" You export the device list from the Intune admin center, open it in Excel, and immediately run into problems: serial numbers in scientific notation, the same laptop listed three times, and a user who shows up as Jane.Doe@contoso.com in one sheet and jane.doe@contoso.com (trailing space) in the other.

None of this is hard. It just needs a repeatable routine. Here's the one I'd hand to any admin who lives in CSV exports.

Quick version (TL;DR):

Don't double-click the CSV. Import it with Data → From Text/CSV.
Normalize your join key: trim, clean, lowercase UPNs before you match anything.
Dedupe on the right column (serial or device ID, not device name). Keep the latest check-in, not whichever row comes first.
Put it in Power Query once, then press Refresh every week.
Keep raw data, cleaned data, and reports on separate sheets.

1. Import, don't open

Double-clicking a .csv lets Excel guess every column's type. That's how you lose data:

Long numbers (IMEIs, some serials) turn into 3.52E+14, and the original digits are gone once you save.
Leading zeros get dropped (00123 → 123).
Dates get read in your PC's locale, so 03/04/2026 might become April 3rd or March 4th.

Do this instead: Data → From Text/CSV → pick the file → Transform Data. That opens Power Query, where you set column types on purpose.

Also worth checking: recent Microsoft 365 builds of Excel have File → Options → Data → Automatic data conversion settings. You can turn off "remove leading zeros" and "convert to scientific notation" there. Option names move around, so check your build.

Rule zero: work on a copy of the export. Keep the original file untouched in case you need it for an audit or ticket.

2. Normalize UPNs before you join anything

The UPN (user principal name) is usually your best join key between a device export and a user or license export. It's also where the sneakiest problems hide.

Pitfall	What it looks like	Fix
Trailing / leading spaces	`jane.doe@contoso.com` doesn't match	`TRIM()` / `Text.Trim`
Non-breaking spaces (char 160)	Looks trimmed, still doesn't match	`SUBSTITUTE(A2,CHAR(160)," ")` before `TRIM`
Case differences	Power Query merges miss rows	Lowercase both sides
UPN ≠ email address	`jdoe@contoso.onmicrosoft.com` vs `jane.doe@contoso.com`	Join on UPN to UPN, never UPN to mail
Renamed users	Old UPN in last month's export	For long-lived tracking, also keep the object ID if your export has it
Blank primary user	Shared, kiosk, or userless devices	Label them `(no primary user)`. They usually aren't errors.

A worksheet helper column if you're not using Power Query yet:

=LOWER(TRIM(SUBSTITUTE([@[Primary user UPN]],CHAR(160)," ")))

Why case matters: Excel's XLOOKUP and COUNTIF don't care about case. Power Query's Merge and Remove Duplicates do. So the same data can give you different answers depending on which tool you used. Lowercase the key, and the tools will agree.

3. Duplicates: dedupe on the right key, keep the right row

Duplicates in device exports are usually real records, not export bugs. A laptop that was reset and re-enrolled can show up more than once, and so can a device that got re-imaged and renamed.

Pick the key on purpose:

Device name. Bad key. Names get reused (LAPTOP-001 after a re-image) and changed.
Serial number. Good key for counting physical hardware. Watch for blanks and placeholder values that some VMs and white-box devices report. Filter those out and look at them separately.
Device ID. Good key for counting Intune records. It changes on re-enrollment, so it's the right key for "records", not for "laptops".

Keep the latest row, not the first one. Excel's grid Data → Remove Duplicates keeps whichever row comes first. Sort by last check-in, newest first, then remove duplicates. In Power Query there's one more step to remember (see the Table.Buffer note below).

Before you delete anything, count it:

=COUNTIFS(tblDevices[Serial number],[@[Serial number]])

Filter where that's > 1. Those rows are your stale-record cleanup list, which is useful on its own and not just noise to get rid of.

4. Power Query basics: a refreshable device list

This is the habit that saves the most time. You build the cleanup once, and next week you drop in the new export and press Refresh.

In Power Query: Home → Advanced Editor, and adapt this. Column names are examples, so rename them to match your export headers.

let
    Source   = Csv.Document(
                 File.Contents("C:\Exports\Intune\devices.csv"),
                 [Delimiter = ",", Encoding = 65001, QuoteStyle = QuoteStyle.Csv]),
    Headers  = Table.PromoteHeaders(Source, [PromoteAllScalars = true]),

    // Keep serials as TEXT so nothing turns into scientific notation
    Typed    = Table.TransformColumnTypes(Headers, {
                 {"Serial number", type text},
                 {"Primary user UPN", type text},
                 {"Last check-in", type datetime}}, "en-US"),

    // Normalize the join key: replace non-breaking spaces, trim, clean, lowercase
    CleanUpn = Table.TransformColumns(Typed, {{"Primary user UPN",
                 each if _ = null then null
                      else Text.Lower(Text.Clean(Text.Trim(
                           Text.Replace(_, Character.FromNumber(160), " ")))),
                 type text}}),

    // Newest check-in first, then BUFFER so the sort order sticks
    Sorted   = Table.Buffer(Table.Sort(CleanUpn, {{"Last check-in", Order.Descending}})),

    // One row per physical device (latest record wins)
    Deduped  = Table.Distinct(Sorted, {"Serial number"})
in
    Deduped

Notes:

"en-US" on the type step tells Power Query how to read the date text. Set it to whatever locale your export actually uses. Timestamps in admin exports are often UTC, so label the column so nobody reads it as local time.
Table.Buffer after the sort is the classic gotcha. Without it, Power Query can reorder rows during optimization and Table.Distinct might keep an older row. Buffering pins the sorted order.
Point the path at a fixed filename (for example devices.csv) and overwrite it each week, or use From Folder to combine several exports.
Close & Load To… → Table on a sheet named clean_devices.

Then join licenses or users with Merge Queries on the lowercased UPN (Left Outer: keep all devices, bring in the matches).

5. Stale devices: one column that answers the real question

Add a custom column in Power Query (Add Column → Custom Column):

Duration.Days(DateTime.LocalNow() - [Last check-in])

Name it DaysSinceCheckIn. Then use buckets (0–7, 8–30, 31–90, 90+) in a Pivot. That gives you "active vs stale" in one view. It's an easy number for a manager to read, and it's your cleanup queue.

Be careful about the conclusion: "hasn't checked in for 90 days" means investigate. It doesn't mean delete. That laptop might be on someone's parental leave shelf. Clean up through your normal change process, not straight from the spreadsheet.

6. Workbook layout that survives next month

raw_* sheets: the untouched import (or just keep it in Power Query)
clean_* sheets: Power Query output tables (tblDevices, tblLicenses)
viz_* sheets: Pivots and charts built from Tables, never from hard-coded ranges
A README sheet: where each export comes from, who ran it, and when

More pitfalls, quick fire:

Distinct counts in Pivots: check "Add this data to the Data Model" when creating the Pivot, then choose Distinct Count. A regular Count counts rows, not users.
Hidden header changes: if an admin portal renames a column, your query breaks on refresh. That's a good thing, because it fails loudly. Fix the column name in one step instead of hunting through formulas.
Personal data: device and user exports are personal data. Store them where your org says to, and don't email them around as attachments.

7. Want the full set of patterns?

This post covers the cleanup part. The Excel & Power Automate Ops Pack for IT Admins from Admin Pack Studio ($29) goes further: Excel ops patterns for messy admin CSVs (Tables, XLOOKUP, Pivots), an admin workbook starter layout (Licenses / Devices / Tickets sheets), Power Automate cloud flow starters for IT approvals and notifications, guardrails and run-after error handling, and two read-only PowerShell helpers that generate practice CSVs so you can learn without touching production data. It teaches you a layout to build in your own tenant. It doesn't ship a macro-laden .xlsx that breaks the first time you open it.

👉 https://cashflow4375.gumroad.com/l/vougj

Need the Intune exports and enrollment hygiene side? The Intune & M365 Admin Starter Pack ($19 launch price, normally $29) has enrollment/compliance checklists and read-only snapshot scripts whose output drops straight into this workbook: https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Excel, Power Query, and Intune are Microsoft products; menu names and export columns change over time, so check current Microsoft documentation. Examples use placeholder data (contoso.com).

The sysadmin interview question you'll get anyway — "Tell me about a change that locked users out" (STAR drill + worked outline)

AdminPackStudio — Wed, 07 Oct 2026 13:54:07 +0000

"Tell me about a change that locked users out": a STAR drill for sysadmin and M365 interviews

If you're interviewing for a sysadmin, M365, or endpoint role, expect some version of this question:

"Tell me about a time a change you made (or your team made) caused an outage. What happened, and what did you do?"

It's not a trick. The interviewer wants to know three things: do you check before you fix, do you communicate while it's broken, and do you change something so it doesn't happen again? Most weak answers skip straight to "I rolled it back" and stop there.

Here's one drill you can run in about 10 minutes, built around a very common M365 story: a Conditional Access policy flips to On and users get blocked on Monday morning.

1. The drill (do it out loud, timed)

Set a timer for 3 minutes. Answer the question above out loud using your own real story. If you don't have a CA story, use any change that broke sign-in, mail, VPN, printing, or a line-of-business app.
Stop at 3 minutes, even if you're mid-sentence. Interview answers that run past 3 minutes lose people.
Score yourself with the table in section 5.
Answer the follow-ups in section 4 without notes. That's where most candidates lose points.
Run it again tomorrow. The second run is always tighter.

No real story yet? Use the scenario version in section 3 instead. It's fine to say "I haven't had this exact incident. Here's how I'd handle it." Don't invent one. Interviewers dig into details, and made-up stories fall apart on the second follow-up.

2. Worked STAR outline (illustrative composite)

This is an example structure, not a script. Swap in your own facts, numbers, and tools. Keep it small and true rather than big and vague.

S — Situation (about 20 seconds)

~150-seat org on M365. We were rolling out a Conditional Access policy requiring a compliant device for Exchange Online and SharePoint.
The policy had run in report-only for a week, and it was switched to On late Friday.

T — Task (about 10 seconds)

Monday 8:05am the help desk queue filled with "can't open Outlook" tickets. I was the on-call admin, so I owned getting people working again and figuring out why.

A — Action (about 90 seconds, the heart of the answer)

Scoped it first. Was it everyone, or one group? Sign-in logs showed failures only from a group of contractor laptops that had never enrolled in Intune. Employees were fine.
Ruled out the obvious. Checked the Microsoft 365 service health page: no incident. The only recent change was our policy.
Confirmed the cause. The sign-in log entries showed the new CA policy as the one that failed, with "device not compliant" / not managed as the reason.
Contained with the smallest safe change. Rather than turn the whole policy off, we temporarily excluded the contractor group (with a ticket, a named owner, and a removal date). Employees stayed protected.
Communicated on a cadence. A short message to affected users and their managers at 8:20 ("we know, here's the workaround, next update at 9:00"), then an all-clear at 8:50.
Didn't break-glass for convenience. Emergency access accounts stayed untouched. This wasn't that kind of outage.

R — Result (about 20 seconds)

Contractors were back in ~45 minutes. No security policy was disabled for everyone.
Prevention: we added a pre-enforce check (review report-only results by group, not just overall) and stopped enforcing on Friday afternoons. Contractors got a documented path: enroll, or use web-only access.
What I'd do differently: I'd have asked "who would fail this policy?" before turning it on, not after.

That last line matters. Owning a miss calmly is often the strongest part of the answer.

3. Scenario version (if you don't have the story)

The interviewer says: "It's Monday, 8am. Fifty people can't get into Outlook. A Conditional Access change went in Friday. Walk me through it."

Talk through it in this order:

Clarify scope: who, how many, which apps, which sites? Desktop and mobile both?
Rule out the service: check Microsoft 365 service health before blaming your own change.
Find evidence: look up one affected user in the Entra sign-in logs. Which policy applied, and what was the failure reason?
Contain narrowly: a scoped, time-boxed exclusion or putting that one policy back to report-only. Not "turn off all CA."
Communicate: first update within ~15 minutes, then a stated cadence.
Prevent: a group-level review of report-only results, change windows, and a rollback note written before the change.

Say out loud that you'd follow the change process and get approval for an emergency exclusion. Interviewers listen for that.

4. The follow-ups they'll actually ask

Practice these without notes:

"Why not just turn the policy off?" (Answer: that removes protection for everyone to fix a problem for a few. Contain narrowly.)
"How did you know it was CA and not an M365 outage?" (Service health + sign-in log evidence.)
"Who did you tell, and when?"
"What's a break-glass account, and would you have used it here?"
"What changed in your process afterward?"
"What would you do differently?"

If a follow-up stumps you, say so: "I'm not sure. Here's how I'd find out." That beats guessing.

5. Score yourself (1–4)

Score	What it sounded like
1	Jumped straight to the fix. No scoping, no evidence.
2	Some structure, but missed blast radius or communication.
3	Clear: verify → contain → communicate → result.
4	All of 3, plus prevention, a "what I'd do differently," and judgment about not overreacting.

Aim for a 3 on the first try and a 4 by the second or third run.

Common ways to lose points:

Blaming a coworker or "Microsoft."
Running past 3 minutes on the Situation.
No numbers at all. Even rough ones help ("about 30 users," "back in under an hour").
Claiming a bigger role than you had. "I was on the team that…" is fine.

6. Want more drills like this?

This is one of the scenario drills in the Sysadmin Interview & Career Cheatsheet Kit from Admin Pack Studio ($19). It includes a role map and a STAR story bank worksheet, core Windows/AD/networking/M365 Q&A, timed scenario drills (morning outage, new-hire day-one failure, Patch Tuesday fallout, "can you just make me admin?", phishing mailbox rules), offer and first-90-days prep, and a weekly scorecard with a 30-day study plan. It's practice material, not a brain dump, and no one can promise you a job. The practice is what does the work.

👉 https://cashflow4375.gumroad.com/l/nojrvg

On the job and want to avoid the Monday lockout in the first place? The Entra ID Conditional Access Starter Pack ($29) covers report-only → enforce with pilot groups, break-glass hygiene, and sign-in troubleshooting cards, with read-only export scripts: https://cashflow4375.gumroad.com/l/nhuyrc

Admin Pack Studio. Not affiliated with Microsoft. The worked example is an illustrative composite. Use your own true experience in interviews. Check current Microsoft documentation for portal names and features, which change over time.

A Tier-1 helpdesk card for "Outlook keeps asking for my password": symptoms, checks, and when to escalate

AdminPackStudio — Wed, 07 Oct 2026 13:51:34 +0000

A Tier-1 helpdesk card for "Outlook keeps asking for my password"

It's one of the most common tickets in any Microsoft 365 shop: "Outlook keeps popping up a password box. I type it, it goes away, and it comes back." Sometimes Teams and OneDrive do it too.

Most Tier-1 techs handle it from memory, and that's how you get a mix of results. One tech resets the password, which rarely fixes it and sometimes makes it worse. Another removes the work account from Windows and breaks single sign-on for the whole device.

A ticket card fixes that. It's one page: what the user sees, what to check in order, what Tier-1 is allowed to fix, and the exact point where you stop and escalate. Here's one you can copy into your knowledge base.

Scope: Windows 10/11 with Microsoft 365 Apps, Entra ID (Azure AD) accounts. Menu names move around, so check them against your build and your own policies.

The card

CARD: Outlook / M365 apps keep prompting for password (Windows)

SYMPTOMS
- Repeated password prompt in Outlook (sometimes Teams/OneDrive too)
- "Need password" banner in Outlook or OneDrive
- Password is accepted, then the prompt comes back minutes/hours later
- Often follows: password change, new laptop, VPN change, recent reboot

CHECKS (in order — stop when you find the cause)
1. Scope: one user or many? One app or all M365 apps?
   Many users at once -> check service health / tell your lead. Don't touch devices yet.
2. Web test: can the user sign in at outlook.office.com in a private window?
   - Fails -> account problem (password, lockout, MFA). Go to the password/MFA card.
   - Works -> account is fine. Problem is on the device/app. Continue.
3. Recent password change? Other devices (phone, old laptop) may still be
   using the old password and causing lockouts.
4. Device time: Settings > Time & language. Set automatically = On, correct time zone.
5. Network: on VPN, hotel/guest Wi-Fi, or a proxy? Test once off VPN / on another network.
6. Device state (read-only): run  dsregcmd /status  and note:
   AzureAdJoined / DomainJoined / WorkplaceJoined, AzureAdPrt (YES/NO)
   Paste the output into the ticket.
7. Error text: any message like "Your sign-in was successful but doesn't
   meet the criteria..." or "device must be managed/compliant"? Screenshot it.
   That is NOT a password problem. Go straight to ESCALATE.

TIER-1 FIXES (only what your playbook allows)
- Fully close Outlook/Teams (check the system tray), then reopen.
- In Outlook/Office: File > Office Account > Sign out, reboot, sign back in.
- Clear cached Office creds: Credential Manager > Windows Credentials >
  remove entries for MicrosoftOffice / the user's M365 address. Reboot.
- Make sure Office is up to date (File > Office Account > Update Options).
- Retest with a fresh Outlook profile only if the mailbox is cloud-only
  and your playbook allows it.

DO NOT (at Tier-1)
- Reset the password "just to see" if the web test worked
- Disconnect the work/school account from Windows Settings > Accounts
- Remove MFA methods without verified identity and the right role
- Unenroll, reset, or reimage the device

ESCALATE WHEN
- Web sign-in fails after password/lockout checks          -> Identity / Tier-2
- AzureAdPrt = NO on a device that should be Entra joined -> Tier-2 / endpoint
- Any "device must be compliant/managed" or CA error     -> Endpoint / Intune admin
- Same symptom across many users                          -> Lead + service health
- Fixes above done and prompt returns within a day        -> Tier-2

ATTACH TO THE ESCALATION
- User, device name, time of last prompt, app(s) affected
- Web test result, dsregcmd /status output, screenshot of any error
- What you already tried (so Tier-2 doesn't repeat it)

Why the order matters

The web test (check 2) does most of the work. If the user can sign in to Outlook on the web in a private window, the password and the account are fine. Resetting the password at that point only adds a new problem: every other device now has a stale password and starts locking the account.

Device state comes before "fixes." If dsregcmd /status shows AzureAdPrt : NO on a laptop that should be Entra joined, the device has no valid primary refresh token, so apps keep falling back to asking for a password. Tier-1 can capture that. Fixing it usually needs Tier-2.

Compliance errors look like password problems. When Conditional Access requires a compliant device and the laptop isn't compliant (it isn't enrolled, it's missing an update, BitLocker isn't reporting, and so on), the user sees a sign-in failure right after typing a correct password. Tier-1 can't fix compliance from the user's desk. The best move is a clean escalation with the screenshot and the dsregcmd output attached.

A note template that saves Tier-2 time

[Tier-1] Outlook repeated password prompt — <user> / <device>
Scope: single user, Outlook + Teams
Web sign-in (private window): WORKS
Time sync: OK | VPN: tested off VPN, same result
dsregcmd: AzureAdJoined YES, AzureAdPrt NO
Tried: Office sign-out/in + reboot, cleared Office creds in Credential Manager
Result: prompt returns within ~1 hour
Escalating to: endpoint team (PRT missing)

Two minutes of notes like this keep the ticket from bouncing back to the user with "can you try restarting?"

Want the rest of the cards?

This card is a sample of the format in the IT Helpdesk Tier-1 Break/Fix Runbook Pack ($24). The pack uses the same Symptoms → Verify → Fix → Prevent/Escalate layout for the tickets that fill Tier-1's day: password and MFA loops, VPN with no internal access, slow PCs, full disks, Wi-Fi, printers, Outlook search and send, Teams audio, and OneDrive sync. It also includes intake and escalation rules, note and handoff templates, and one read-only PowerShell local snapshot script. The script only reads. It makes no password changes, takes no device actions, and makes no Graph writes.

👉 https://cashflow4375.gumroad.com/l/tezla

If your escalations keep landing on Intune enrollment or compliance, the Intune & M365 Admin Starter Pack covers that side for admins ($19 during launch week, normally $29): https://cashflow4375.gumroad.com/l/joonf

Neither is required. The card above works fine on its own.

Admin Pack Studio. Not affiliated with Microsoft. For IT staff authorized to support their organization's users and devices. Follow your own policies, and check current Microsoft documentation for menu names and behavior.

An offboarding checklist for M365 + Intune admins — disable vs delete, license reclaim, and the device decision

AdminPackStudio — Wed, 07 Oct 2026 13:47:47 +0000

Offboarding in M365 + Intune: a leaver checklist that doesn't lose data or leave doors open

Offboarding usually goes wrong in one of two ways:

Too slow. The account stays usable for days, an old phone still syncs mail, or a SaaS admin login nobody tracked keeps working.
Too fast. Someone deletes the user or pulls the license on day one, and the manager loses the mailbox and OneDrive files they needed.

This is the short version of a leaver process for Microsoft 365 + Entra ID + Intune, for admins authorized to manage their tenant. Follow your HR, legal, and retention policies first. Retention periods and admin-center labels change over time, so check the current Microsoft docs before you rely on any number here.

1. Disable first, delete much later

	Disable (block sign-in)	Delete the user
What it does	Stops new sign-ins. Data, groups, and licenses stay put until you change them	Soft-deletes the account; it can be restored for a limited window (30 days by default), then it's gone for good
Reversible?	Yes, right away	Only during the soft-delete window
Mailbox / OneDrive	Still there	Start their own retention clocks; data is lost when those run out unless a hold or retention policy keeps it
When	Last day, at the agreed time	After handoff is done and retention/legal requirements are met (often 30+ days)

Default rule: disable on the last day, delete only after the handoff is finished. A disabled account costs you almost nothing for a few weeks. An early delete can lose data you can't get back.

Hybrid tenants: if the account syncs from on-prem AD, disable it in AD. If you only block it in the cloud, the next sync can turn it back on. (It's one of the most common "leaver still signing in" causes.)

2. The last-day sequence

Order matters. Use this as a starter, then adjust to your policy:

Before last day:  Confirm date/time with HR. Flag privileged or VIP accounts.
                  Agree who receives mailbox + OneDrive + Teams/SharePoint ownership.
                  Check for legal hold / litigation requirements.
Last day (agreed time):
  1. Block sign-in (on-prem AD first if hybrid).
  2. Revoke sessions / refresh tokens (Entra admin center → user → Revoke sessions).
  3. Remove privileged roles and PIM eligibility.
  4. Reset the password if your policy requires it.
  5. Review MFA methods; remove ones tied to shared or company phones per policy.
  6. Remove from groups, except license groups until mailbox handoff is done.
  7. Mailbox: convert / delegate / auto-reply per HR (section 3).
Day +1..7:        Check sign-in logs for failed attempts or other surprises. Make the device decision (section 4).
                  Disable non-SSO SaaS accounts. Rotate shared secrets the user knew.
Day +30 / policy: Reclaim the license if it isn't already gone, delete the account, close the ticket with evidence.

Two things to know:

Revoking sessions isn't instant everywhere. Some apps hold access tokens until they expire (often up to about an hour), and apps using continuous access evaluation react faster. Block sign-in and revoke sessions, then check the sign-in logs the next day.
Rotate secrets as work items. If the leaver knew a shared admin password, a Wi-Fi key, or an API key, track the rotation in your ticket system. Never paste the secret into the ticket.

3. Mailbox and OneDrive handoff (high level)

Mailbox: common options are:

Convert to a shared mailbox and give the manager or team access. Convert before you remove the license. Shared mailboxes have size limits without a license (check current docs), and hold or archive features may still need one.
Delegate access (Full Access / Send As) for a fixed period with an end date.
Auto-reply pointing senders to the right contact. Avoid forwarding to external addresses; many orgs block it on purpose.

OneDrive:

Set the manager (or named delegate) to receive access. In many tenants, deleting the user gives the manager access automatically for the OneDrive retention period. Confirm your tenant's retention setting so nobody gets surprised.
Tell the receiver what to move and the deadline. Files that matter to the team belong in a SharePoint/Teams site, not in a former user's OneDrive.

Teams / SharePoint: if the leaver was the only owner of a Team, group, or site, add a new owner first. Ownerless groups turn into cleanup work later.

4. The device decision: retire vs wipe (it's a judgment call)

Intune gives you device actions in the admin center. Pick one based on who owns the device and what policy and legal holds require:

Situation	Usual direction	Notes
Personal (BYOD) phone or PC	Retire	Removes company data, managed apps, and profiles. Leaves personal data alone
Corporate device, returned to IT	Reset for reuse, per your reimage process	Check legal hold first. Keep the Autopilot record if the hardware stays in the fleet
Corporate device, not returned	Escalate per policy; a remote wipe may be appropriate	Get documented approval. Lost/stolen handling differs from "employee kept the laptop"
Device under legal hold / investigation	Don't touch it until counsel clears it	Wiping evidence is a serious problem
Hardware leaving the org for good	Remove it from Autopilot / Intune after the reset	Otherwise the next owner hits your enrollment

Treat retire and wipe as deliberate, approved actions done by an authorized admin in the Intune admin center, with the ticket ID recorded. Don't fire them off from a quick script at 5pm on a Friday. Confirm ownership (corporate vs personal) in the device record before you click.

5. License reclaim without breaking things

Pulling licenses too early is the most common way offboarding causes data loss.

Order: convert the mailbox / finish handoff → then remove the license. Removing an Exchange license starts a countdown on the mailbox data unless a hold or a shared-mailbox conversion protects it.
Group-based licensing: if licenses come from groups like LIC-M365-E3, removing the user from the group removes the license. Keep that membership until handoff is finished, then remove it on purpose.
Weekly orphan check: look for accounts that are disabled but still licensed. That's money spent on nobody. A read-only Graph query is enough:

Connect-MgGraph -Scopes 'User.Read.All'

Get-MgUser -All -Filter 'accountEnabled eq false' -Property 'displayName','userPrincipalName','assignedLicenses','accountEnabled' |
  Where-Object { $_.AssignedLicenses.Count -gt 0 } |
  Select-Object DisplayName, UserPrincipalName, @{n='LicenseCount';e={$_.AssignedLicenses.Count}}

It only reads. Review the list with whoever owns licensing before you change anything. Some disabled accounts are kept licensed on purpose, for holds or shared mailboxes over the size limit.

Conditional Access and break-glass awareness

CA exclusion groups: if the leaver was in a Conditional Access exclusion group (travel exceptions, legacy-app exceptions, "temporary" bypasses), remove them. Exclusions outlive the people they were made for.
Break-glass accounts: don't disable or delete your emergency-access accounts as part of someone's offboarding. If the leaver knew or held break-glass credentials (password, FIDO key, safe combination), rotate them and record that you did, using your normal break-glass procedure.
Admins leaving: check what they owned: app registrations, service principals with their own credentials, automation accounts, scheduled flows running as them. Reassign ownership before those quietly break or stay unowned.

If your CA exclusions and break-glass setup have drifted, the Entra ID Conditional Access Starter Pack ($29) covers exclusion hygiene and emergency-access patterns: https://cashflow4375.gumroad.com/l/nhuyrc

6. Evidence: close the ticket like an auditor will read it

A few lines per leaver saves a painful audit later:

Leaver ticket / Last day / Sign-in blocked (time) / Sessions revoked (time) /
Roles removed / Groups removed / Mailbox action / OneDrive delegate /
Device action + approver / License removed (date) / Account deleted (date) /
Performed by (role) / Verified by (role)

Record roles, not personal names, if the evidence gets shared widely.

Common mistakes

Mistake	What happens	Fix
Delete on day one	Manager loses mail/files; restore window runs out	Disable first; delete after handoff + retention
License removed before mailbox conversion	Mailbox data starts expiring	Convert/delegate first, then reclaim
Cloud-only block on a synced account	Account comes back after the next sync	Disable in on-prem AD
Leaver was sole Team/site owner	Ownerless groups, nobody can manage access	Add new owners before the last day
Wiping a device under legal hold	Evidence destroyed	Check holds; get approval for any wipe
Forgetting CA exclusions / break-glass knowledge	Old exceptions and known secrets linger	Remove exclusions; rotate what they knew
Non-SSO SaaS logins ignored	Access continues outside Entra	Keep a SaaS inventory in the checklist

Want the full joiner / mover / leaver checklists?

The Entra ID Joiner-Mover-Leaver Ops Pack ($29) from Admin Pack Studio turns this into repeatable checklists: joiner day-1 definition of done, a mover access-diff worksheet, leaver timeline lanes and a revoke checklist, group-based licensing and orphan hunts, plus audit evidence and JML break/fix cards. The one bonus script writes a blank local checklist CSV. It makes no tenant calls and takes no account or device actions.

👉 https://cashflow4375.gumroad.com/l/vljmze

Managing the device side too? The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) covers enrollment hygiene, compliance baselines, inventory snapshots, and break/fix cards, with read-only PowerShell scripts: https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant and devices. Follow your HR, legal hold, and retention policies, and check current Microsoft documentation for retention periods and admin-center steps.

Intune Win32 app shows "Failed" after a successful install? It's usually the detection rule

AdminPackStudio — Wed, 07 Oct 2026 13:45:15 +0000

Intune Win32 app shows "Failed" after a successful install? It's usually the detection rule

Here's a ticket most Intune admins have seen. The installer ran and the app opens fine on the device, but Intune reports Failed. Or the app installs again every few hours. Or a Required app stays "Install pending" forever.

In most cases the installer is fine. The detection rule is wrong. This post covers why that happens, how detection differs from requirement rules, the mistakes that come up most, and where to look in the logs. Everything here is read-only troubleshooting. You don't need any special tooling.

Intune UI labels and log names change over time, so check them against current Microsoft docs.

1. How Intune decides "installed"

For a Win32 app, the Intune Management Extension (IME) on the device runs roughly this sequence:

Requirement rules. Is this device allowed to get the app (OS version, architecture, disk space, custom checks)? If not, the app shows Not applicable and nothing else happens.
Detection (before install). Is the app already there? If yes, the install is skipped and the app reports as installed.
Install. Runs your install command and reads the exit code against your return-code mapping.
Detection (after install). Runs the detection rule again. This step decides the final status.

That last step is the part people forget. A clean exit code 0 followed by a detection rule that comes back false means Intune reports the app as not detected after installation, and the status goes to Failed. A Required assignment then retries on its normal schedule, so you get the install loop.

Rule of thumb: exit code success + Failed status = look at detection first.

2. Detection rules vs requirement rules

These two get mixed up a lot:

	Requirement rule	Detection rule
Question it answers	"Should this device get the app?"	"Is the app on this device right now?"
When false	Not applicable (no install attempt)	Install attempted (before) or Failed (after)
Typical checks	OS build, x64, free disk, a prerequisite present	MSI product code, file + version, registry value, script
Common mistake	Using it to check "already installed"	Checking something the installer doesn't actually write

If a device shows Not applicable and you expected an install, check the requirement rules. If it shows Failed or keeps retrying, check the detection rule.

3. The detection mistakes that cause most loops

MSI product code

The product code changes between versions. You upgrade the package, keep the old detection rule, and either the new version never detects or the old version detects as "good enough."
The MSI is wrapped in an EXE bootstrapper that installs several MSIs, and you picked the wrong product code.
Fix: read the product code from the exact MSI you're shipping, and update it whenever you change versions.

File or folder

x86 vs x64 paths. A 32-bit app installs to C:\Program Files (x86)\... and your rule checks C:\Program Files\..., or the other way round. Check the "Associated with a 32-bit app on 64-bit clients" setting. It changes which path and registry view the IME checks.
User-profile installs. The app writes to %LOCALAPPDATA% but the app is set to install in system context, so detection looks in the wrong profile.
"File exists" with no version. It passes for an old version and leaves you thinking the upgrade worked. Use a version comparison (greater than or equal to the version you ship) where you can.
Files that stay behind after uninstall. Logs, configs, or an updater folder. Detection stays true and uninstall looks like it failed.

Registry

WOW6432Node. 32-bit installers write under HKLM\SOFTWARE\WOW6432Node\.... If the 32-bit setting doesn't match, the IME looks in the wrong view.
HKCU vs HKLM. The IME runs system-context detection, so a value written per user under HKCU isn't where it looks.
Value type and comparison. Comparing a version stored as a string with an integer or version operator gives results you didn't expect. Check the type in Registry Editor first.
Uninstall GUID keys that change per version. Same problem as MSI product codes.

Custom detection script

Detected means exit code 0 and output written to STDOUT. A script that exits 0 and prints nothing counts as not detected. A script that writes errors to STDERR also counts as not detected.
Slow scripts (network calls, big searches) can time out.
32-bit vs 64-bit PowerShell. The script may run in a 32-bit host unless you set it to run as 64-bit, which changes what the registry and file system show it.
Keep detection scripts read-only and fast. They should check state, never change it.

4. Test detection before you assign Required

Do this on a lab VM before you upload. It takes about ten minutes:

Step	Expected
Run your exact silent install command manually	Exit code is what you mapped as success
Check the detection target (file/registry/MSI)	Present, correct version
Run your exact uninstall command	Exit code success
Check the detection target again	Gone

If detection still matches after uninstall, or doesn't match after install, fix the rule before any Required assignment. Pilot the app as Available or on a small Required group of lab devices first.

5. Reading the IME logs (high level)

On the device, with authorization, the logs are in:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

Useful files (names vary by IME version):

AppWorkload.log: newer builds put most Win32 app download, install, and detection activity here.
IntuneManagementExtension.log: the main IME log. Older builds put Win32 app activity here too.
AgentExecutor.log: what happened when PowerShell scripts ran, including custom detection and requirement scripts.

How to read them without getting lost:

Open the log in a log viewer that handles CMTrace-format logs (or just a text editor) and search for the app name or its app ID (the GUID from the Intune portal URL).
Find the requirement result. If it's "not applicable," stop here and fix requirements.
Find the install step and note the exit code. Compare it with your return-code mapping.
Find the detection after install result. If it's false following a successful exit code, your detection rule doesn't match what the installer wrote. Go back to section 3.
Check the vendor's own install log too (add a /log or /l*v switch to your install command). It tells you what was actually written, and where.

You can also gather these logs remotely with the Collect diagnostics device action in Intune where your tenant supports it. That's read-only. It doesn't change the device.

6. Quick triage table

Symptom	Most likely cause	First check
Failed, but the app works	Detection doesn't match the install	Detection target vs what the installer wrote
Reinstalls every few hours	Detection false after a successful install	Same, plus 32-bit setting and HKCU vs HKLM
Not applicable	Requirement rule	OS/arch/disk/custom requirement
Install pending forever	Device not checking in, or IME not getting the assignment	Device sync, assignment group
Uninstall "fails"	Detection still true after uninstall	Files or registry keys left behind
Upgrade never happens	Old version still satisfies detection	Add version comparison; update the MSI code

Want the full packaging workflow?

Detection is one piece. The Intune Win32 App Packaging Starter Pack from Admin Pack Studio ($39) covers the whole workflow: packaging basics and silent-switch research, detection truth tables for MSI/file/registry/script rules, install and uninstall commands with return codes and logging, six failure triage cards, and pilot-to-production gates including supersedence. It includes one read-only local evidence helper script that checks whether a file or registry path exists and records the file version, so you can design detection rules from real evidence. It doesn't install, uninstall, or change anything.

👉 https://cashflow4375.gumroad.com/l/cgnpzt

If your apps are fine and the real problem is enrollment or compliance, our Intune & M365 Admin Starter Pack covers that ($19 launch week, normally $29): https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant and devices. Pilot first, and check current Microsoft documentation for setting names and log locations.

Windows Update rings for Intune pilots — pilot vs broad, deferrals, and why "minimum OS" compliance fails first

AdminPackStudio — Wed, 07 Oct 2026 13:41:52 +0000

Windows Update rings for Intune pilots: a starter layout that won't page you

If every device takes this month's quality update the day it ships, one bad driver or a broken line-of-business app hits the whole company at once. Update rings exist to buy you detection time. A small group gets updates first, you watch for problems, and the rest of the fleet follows a few days later.

This is the short, practical version for admins using Intune → Devices → Windows → Update rings for Windows 10 and later. It covers Windows only. Exact setting names and limits move over time, so check them against current Microsoft docs before you copy any numbers.

1. A starter ring layout

Three rings covers most small and mid-size tenants:

Ring	Who	Size (starter idea)	Quality deferral (starter idea)
Ring 0 — IT	IT staff + a few willing champions	~1–3%	0 days
Ring 1 — Pilot	A mix across departments (not only IT)	~10–15%	A few days (e.g. 3–5)
Ring 2 — Broad	Everyone else	The rest	About a week or more, inside your patch SLA

A few rules that save pain later:

Assign rings to device groups, not just user groups. Patching is a device problem, and shared or multi-user devices make user targeting messy.
One ring per device. If a device lands in two update ring policies with different values, you'll get conflicts and confusing reports. Use clear names like WU-Ring0-IT, WU-Ring1-Pilot, WU-Ring2-Broad, and make the broad group exclude the earlier rings.
Pilot ≠ IT only. Your pilot ring needs Finance's and Ops' real apps on it. That's where the breakage shows up.
Execs usually follow Broad, not first. If someone senior insists on being early, write down that they agreed to it.

2. Quality vs feature updates (they're not the same dial)

	Quality updates	Feature updates
What	Monthly cumulative security + fixes (Patch Tuesday)	New Windows version (e.g. a new 24H2-style release)
Risk	Usually lower, but a bad one still hurts	Higher. Apps, drivers, and hardware eligibility all matter
Ring setting	Quality update deferral (days)	Feature update deferral (days), or a separate Feature updates policy
Typical pace	Days	Weeks to months, pilot first

Two practical points:

If you control the Windows version with a Feature updates policy (pin a target version), Microsoft's guidance is to leave the feature deferral in the update ring at 0 so the two settings don't fight. Check current docs for your setup.
Deferral and deadline are different things. Deferral controls when the update is offered. Deadline settings (plus grace period and restart behavior) control how long the user can put off installing and rebooting after it's offered. A pilot ring with 0-day deferral and a long deadline can still be weeks behind in practice.

3. Why "minimum OS version" compliance fails first

This is the most common way rings and compliance end up fighting each other.

You set a compliance policy with Minimum OS version = this month's build (e.g. 10.0.22631.xxxx) right after Patch Tuesday. Then:

Ring 0 gets the update, but some of it is still waiting on a reboot.
Rings 1 and 2 haven't been offered the build yet, because you deferred them on purpose.
Compliance evaluates them anyway. Every device below that build shows noncompliant.
If Conditional Access requires a compliant device, those users are now blocked from email and Teams because of a schedule you chose.

The device didn't do anything wrong. The compliance rule got ahead of the ring.

Safer habits:

Set minimum OS to a build that your broad ring has actually received: usually last month's cumulative, or the org standard (N-1). Raise it only after Ring 2's deadline has passed and your reports show the fleet caught up.
Use the compliance grace period / actions for noncompliance so a device gets time (and a notification) before it's marked noncompliant, instead of being blocked right away.
Look at the gap before you raise the bar. A read-only Graph pull of OS versions tells you how many devices you'd break:

Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All'

Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" -Property 'deviceName','osVersion','lastSyncDateTime' |
  Group-Object OsVersion | Sort-Object Count -Descending |
  Select-Object Count, Name

If a big chunk of the fleet sits below the build you were about to require, wait.

Treat feature-version minimums (e.g. "must be on 23H2 or later") as a separate, slower project with its own pilot. Don't bundle it into a monthly change.

4. A simple monthly rhythm

Patch Tuesday:     Ring 0 offered (0-day deferral). Read known-issues notes.
Wed–Thu:           Validate Ring 0: install success, reboots done, smoke tests.
Following days:    Ring 1 offered (deferral expires). Watch helpdesk volume.
~1 week+ later:    Ring 2 offered if Ring 1 is clean.
After Ring 2 deadline + reports caught up:  consider raising min OS in compliance.

Smoke tests worth five minutes on Ring 0/1: Outlook send/receive, a Teams call, VPN connect, your top 3–5 line-of-business apps, printing, browser sign-in to your identity provider, and a check that BitLocker still reports healthy.

When something breaks: pause the affected rings (quality and feature pauses are separate, and pauses expire on their own, so note when). Write down who approved it, the reopen criteria, and a reopen date. A pause with no end date turns into unpatched devices.

5. Common mistakes

Mistake	What happens	Fix
Min OS compliance raised on Patch Tuesday	Deferred rings go noncompliant, CA blocks users	Raise only after the broad ring has the build
Device in two ring policies	Conflicts, reports nobody trusts	One ring per device, exclusions on the broad group
Pilot ring is only IT laptops	LOB app breakage found in Broad	Add real users from each department
Treating "deferral 0" as "patched today"	Long deadlines and pending reboots mean it isn't installed	Watch install/reboot status, not just policy assignment
Feature deferral in the ring + a Feature updates policy	Confusing or blocked version offers	Pick one control. With a Feature updates policy, ring feature deferral = 0
Pausing with no reopen date	Security debt piles up quietly	Time-box every pause with an owner
Exec devices excluded "temporarily"	Forgotten, unpatched for months	Every exclusion gets an owner and a review date
Ignoring the reports	Problems found by users first	Check Intune's Windows update reports for errors weekly

6. When it's not actually an update-ring problem

Not every "it broke after Tuesday" ticket is about Windows Update:

Device isn't getting the ring at all: check enrollment, sync, and group membership before you touch ring settings.
Compliance flapping right after patching: usually the min-OS timing from section 3, or BitLocker/health attestation re-evaluating after a reboot.
An app failed to install or update: that's app deployment, not update rings.

Side note: app installs are a different problem. Update rings only control Windows quality and feature updates. They don't install or update your Win32 apps. If your real headache is Win32 apps failing to install, reinstalling in a loop, or showing "not detected" after a successful install, that's packaging and detection rules. We cover it separately in a Win32 app packaging pack ($39): https://cashflow4375.gumroad.com/l/cgnpzt

Want the compliance side done properly?

Most ring pain shows up as compliance pain. The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) covers enrollment hygiene, a baseline Windows compliance bar (including minimum OS set to builds you actually patch to), inventory snapshots, M365 admin hygiene, and break/fix cards. It also includes three read-only PowerShell scripts: a local enrollment snapshot, a Graph managed-device snapshot, and a compliance policy summary. The scripts only read. They take no device actions and make no policy changes.

👉 https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Pilot first, and check current Microsoft documentation for setting names and limits.

"Company Portal can't connect" / device not syncing — a 10-minute triage order for Intune admins

AdminPackStudio — Wed, 07 Oct 2026 04:09:52 +0000

"Company Portal can't connect": a 10-minute triage order

The ticket says "Company Portal can't connect" or "my laptop isn't getting the new policy." The tempting move is to start re-enrolling. Usually you don't need to. Most of these tickets come down to the same handful of causes, and you can check all of them without changing anything on the device or in the tenant.

Here's the order we work through, cheapest checks first. It's Windows-focused; mobile platforms have their own quirks.

1. Is the user actually in scope? (license + MDM scope)

You'd be surprised how many "Intune is broken" tickets end right here.

Check	Where	What you want
Intune-eligible license	Microsoft 365 admin center → user → Licenses	e.g. Business Premium, E3/E5 with Intune, or Intune Plan 1
MDM user scope	Entra admin center → Mobility (MDM and MAM) → Microsoft Intune	User is in the scoped group (or scope is All) — not left on a pilot group they're not in
Enrollment restrictions	Intune admin center → Devices → Enrollment → restrictions	Platform/personal-device restrictions and device limit aren't blocking this user
Right account	Ask the user	Signed in with their work account, not a personal Microsoft account or a second tenant

If the license was just assigned, give it a little time to propagate before you decide it didn't work.

2. What does the device think it is? (`dsregcmd /status`)

Run this in a normal command prompt on the device:

dsregcmd /status

Look at:

Field	What it tells you
`AzureAdJoined` / `DomainJoined`	Matches the join type you expect (Entra joined vs hybrid)
`WorkplaceJoined`	`YES` on a corporate device often means a user added a work account to a personal-style setup — check it's the path you intended
`AzureAdPrt`	`NO` points at a sign-in/token problem, not an Intune policy problem
`MdmUrl` (Tenant details)	Empty usually means the device never completed MDM enrollment — go back to section 1
`TenantName`	It's your tenant

Also check Settings → Accounts → Access work or school. A healthy enrolled device shows the work account with an Info button. No Info button = MDM enrollment isn't there.

3. Trigger a sync — and look at the result, not just the spinner

Three places to kick a check-in:

Company Portal → Settings → Sync
Settings → Accounts → Access work or school → account → Info → Sync
Intune admin center → Devices → the device → Sync (this only asks the device to check in; it doesn't force a result)

Then look at the outcome:

Info page shows the last attempted and last successful sync times.
Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin. Errors here are much more useful than "can't connect" in the UI.
In the Intune admin center, compare the device's Last check-in with what the user is telling you.

If the sync time moves but the policy still doesn't show up, it's an assignment problem (wrong group, filter, user vs device targeting), not a connectivity problem.

4. Network, proxy, and TLS inspection

When the device is in scope and enrolled but still can't reach the service, it's usually the network path:

Date/time and time zone. A clock that's off breaks TLS and token checks. Check this first, it's free.
Proxy. Company Portal and the MDM client need to reach Microsoft's Intune and Entra endpoints. An authenticated proxy that the system context can't satisfy will block check-ins even when the browser works fine.
SSL/TLS inspection. Breaking and re-signing traffic to Intune/Entra endpoints is a classic cause of "can't connect." Use Microsoft's published Intune network endpoints list and exclude them from inspection per your security team's process.
Different network test. If it works on a phone hotspot and fails on the office LAN, stop debugging the laptop and talk to whoever owns the firewall.
VPN split tunnel. Some full-tunnel VPN configs route management traffic somewhere it can't get out.

5. Common false alarms

These look like failures but often aren't:

What you see	What's often really going on
Device shows stale "last check-in"	Laptop was asleep, off, or in a bag over the weekend. Check whether it's actually been online.
New policy "not applied" 10 minutes after assignment	Regular check-ins run on a schedule (hours, not minutes). Trigger a sync and give it time before escalating.
Compliance shows "Not evaluated" / "In grace period"	Evaluation hasn't completed or grace hasn't expired yet — not the same as noncompliant
Company Portal says "can't connect", but `MdmUrl` is set and sync times are moving	Often the Company Portal app itself (sign-in cache, outdated app version). Device management may be fine.
Two device records for one laptop	Stale record from a previous enrollment. Look at enrolled date + last check-in before assuming the "broken" one is the live one.
Company Portal missing entirely	Microsoft Store access blocked or the app isn't assigned/available to the user

6. A read-only check from the admin side

If you want to confirm what Intune sees without touching the device, a delegated Graph read with a read-only scope is enough:

Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All'

Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'LAPTOP-123'" -Property `
  'deviceName','userPrincipalName','complianceState','lastSyncDateTime','enrolledDateTime','managementAgent','id' |
  Select-Object DeviceName, UserPrincipalName, ComplianceState, LastSyncDateTime, EnrolledDateTime, ManagementAgent, Id

Intune Reader (or an equivalent read role) is enough for this. You don't need Global Admin to look. Keep the output off public forums, since it includes UPNs and device IDs.

7. When to stop and escalate

Section 1 fails: licensing / Entra admin. Not an Intune bug.
Section 4 fails: network / security team, with your evidence (works on hotspot, fails on LAN, event log errors).
Device enrolled, syncing, still wrong policy: assignment review (groups, filters, user vs device targeting).
Hybrid joined but no MDM: check the automatic MDM enrollment GPO and that hybrid join itself is healthy before anything else.

Side note — new device stuck during setup? If the "can't connect" is really a brand-new device hanging on the Enrollment Status Page during Autopilot, that's a different triage order (hash → profile assignment → ESP blockers → network). We packaged that one separately as an Autopilot ESP pack ($29): https://cashflow4375.gumroad.com/l/hlanei

Write the ticket up with the dsregcmd output (redacted), the sync timestamps, and which section failed. Next time, helpdesk can get through sections 1–3 before it reaches you.

Want the full runbook?

This post is the short version. The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) includes enrollment hygiene (with a triage map for exactly these symptoms), baseline compliance, inventory snapshots, M365 admin hygiene, and break/fix cards. It also comes with three read-only PowerShell scripts: a local enrollment snapshot (no Graph needed, handy for "is MdmUrl empty?"), a Graph managed-device snapshot, and a compliance policy summary. The scripts only read. They take no device actions and make no policy changes.

👉 https://cashflow4375.gumroad.com/l/joonf

Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Pilot first.

The 30-minute Monday habit — weekly read-only Intune device + compliance CSV snapshots

AdminPackStudio — Wed, 07 Oct 2026 04:05:38 +0000

The 30-minute Monday habit: weekly read-only Intune snapshots

"Are we healthier than last month?" is a hard question to answer from the Intune portal. Portal views show now. They don't version-control, they don't diff, and nobody remembers what the noncompliant count was three Mondays ago.

The fix is boring: export device and compliance state to a dated CSV once a week, read-only, and compare. Here's the pattern we use.

1. Read-only, least privilege, on purpose

A snapshot job should never be able to change anything. Set it up so it can't.

Choice	Starter setting
Entra role for the person running it	Intune Reader or Global Reader if that's sufficient in your tenant — not Global Admin for a weekly export
Graph scope — devices	`DeviceManagementManagedDevices.Read.All`
Graph scope — compliance policies	`DeviceManagementConfiguration.Read.All`
Where it runs	A dedicated admin workstation or hardened jump box — not a shared PC
Auth	Interactive delegated sign-in to start; automate later with app permissions + certificate only once you've thought it through

If Connect-MgGraph fails with insufficient privileges, stop and get consent the proper way. Don't "fix" it by borrowing a more powerful session.

2. The export (one-time setup, then copy-paste)

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Install-Module Microsoft.Graph.DeviceManagement -Scope CurrentUser

(If your org blocks PSGallery, use your internal module distribution.)

Each Monday:

$week = Get-Date -Format 'yyyy-MM-dd'
$out  = ".\snapshots\$week"
New-Item -ItemType Directory -Path $out -Force | Out-Null

Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All','DeviceManagementConfiguration.Read.All'

# Managed devices: a small, useful property set
Get-MgDeviceManagementManagedDevice -All -Property `
    'deviceName','operatingSystem','osVersion','complianceState','lastSyncDateTime',`
    'enrolledDateTime','userPrincipalName','isEncrypted','azureADDeviceId','id' |
  Select-Object DeviceName, OperatingSystem, OsVersion, ComplianceState,
                LastSyncDateTime, EnrolledDateTime, UserPrincipalName,
                IsEncrypted, AzureADDeviceId, Id |
  Export-Csv "$out\intune-devices.csv" -NoTypeInformation -Encoding UTF8

Then export your compliance policy list (names, platform, last modified) into the same folder. That second file is what tells you "someone edited a live policy on Thursday" — the device CSV alone won't.

Testing on a big tenant? Use -Top 50 instead of -All for a pilot-sized sample first.

You end up with:

snapshots/
  2026-09-28/intune-devices.csv
  2026-09-28/compliance-policies.csv
  2026-10-05/intune-devices.csv
  2026-10-05/compliance-policies.csv

3. What to track week over week

Don't build a dashboard. Track five numbers in a ticket or wiki table:

Metric	Why it matters
Total managed devices	Sudden drops = enrollment or licensing problem; sudden jumps = someone enrolled personal devices
Noncompliant count (and %)	The headline trend. Should fall as pilots mature
Stale sync (`LastSyncDateTime` > ~7 days)	Usually powered-off laptops or broken enrollment — not compliance logic
`IsEncrypted` false on Windows rows	Cross-check vs a BitLocker requirement; treat odd/null values on non-Windows rows carefully
Compliance policy count / last-modified changes	Unannounced policy edits are the #1 cause of "nothing changed but everything broke"

A quick comparison of two weeks:

$prev = Import-Csv .\snapshots\2026-09-28\intune-devices.csv
$curr = Import-Csv .\snapshots\2026-10-05\intune-devices.csv

'Last week:'; $prev | Group-Object ComplianceState | Select-Object Name, Count
'This week:'; $curr | Group-Object ComplianceState | Select-Object Name, Count

# Devices that went from compliant to anything else
$prevState = @{}; $prev | ForEach-Object { $prevState[$_.Id] = $_.ComplianceState }
$curr | Where-Object { $prevState[$_.Id] -eq 'compliant' -and $_.ComplianceState -ne 'compliant' } |
  Select-Object DeviceName, ComplianceState, LastSyncDateTime | Format-Table -AutoSize

# Stale sync this week
$cutoff = (Get-Date).AddDays(-7)
$curr | Where-Object { $_.LastSyncDateTime -and [datetime]$_.LastSyncDateTime -lt $cutoff } |
  Measure-Object | Select-Object Count

The "went from compliant to noncompliant" list is the one worth 5 minutes of human attention. Everything else is trend.

4. The ritual (≤30 minutes)

Run the device export → save under yyyy-mm-dd/
Run the compliance policy export
Write down the five numbers next to last week's
Spot-check 1–2 weird devices on the endpoint itself (dsregcmd /status, encryption status)
Open a ticket only if the trend worsens — or if Conditional Access report-only "would block" numbers spike

That's it. After a month you have real evidence for "ready to move CA from report-only to enforce?" instead of a gut feeling.

5. Where NOT to put these CSVs

These files contain device names, user principal names, and tenant-linked IDs. Treat them like internal data:

❌ Public Teams/Slack channels with guests, Discord servers, community forums
❌ Pasted into public AI chat tools or GitHub issues
❌ Attached to vendor tickets without trimming to the rows they need
❌ Product reviews or blog screenshots (redact names/UPNs/IDs first)
✅ An access-controlled share or repo your org approves, with a retention rule (e.g. keep 12 weeks)

If you need help from a forum, share the counts or a redacted row — never the file.

6. Common snags

Symptom	Likely cause
`Missing module Microsoft.Graph.*`	Installed under a different PowerShell edition/host than the one running the script
Consent prompt loop	Admin consent required once per tenant
Empty device list	Wrong tenant — check `Get-MgContext` — or scope too weak
Graph 403	Role doesn't cover Intune read; assign Intune Reader or an appropriate role
Execution policy blocks `.ps1`	Use process-scoped bypass or signed scripts per IT policy — don't weaken machine policy casually

Want this ready-made?

This post is the short version. The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) includes the full inventory-snapshot module plus enrollment hygiene, baseline compliance, M365 admin hygiene, and break/fix cards — and three read-only PowerShell scripts: a local enrollment snapshot (no Graph), a Graph managed-device snapshot, and a compliance policy summary. The scripts only read; they take no device actions and make no policy changes.

👉 https://cashflow4375.gumroad.com/l/joonf

Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Pilot first.

DEV Community: AdminPackStudio

Build a small M365 + Intune home lab to practise admin skills (without touching production or your wallet)

Build a small M365 + Intune home lab to practise admin skills

1. Getting a tenant: options, and why you should check eligibility first

2. Hypervisor and VM layout

Checkpoints / snapshots: use them, but know the catch

3. Test users and groups

4. What to practise first (in this order)

5. Keeping lab and production completely separate

6. Cost awareness

7. A one-month plan

8. Want the lab plan in a ready-made pack?

Helpdesk Tier-1 triage cards: how to build a small ticket card library (with 4 copy-ready cards)

Helpdesk Tier-1 triage cards: how to build a small ticket card library

1. Why cards beat long KB articles for Tier-1

2. Organizing a small card library

3. The intake card (every other card depends on it)

4. Four copy-ready Tier-1 cards

Card ID-03: MFA prompt loop / "it keeps asking me to approve"

Card ID-04: VPN connected but no internal resources

Card EP-01: "My PC is slow"

Card M365-04: OneDrive stuck on "processing changes"

5. The escalation matrix

6. Keeping the library alive (monthly, ~30 minutes)

FAQ

Want a ready-made card library?

Windows Autopilot ESP Stuck? The Complete Runway Guide: Hash, Profile Assignment, Blocking Apps, Network/TLS, and CA Deadlocks

Windows Autopilot ESP Stuck? The Complete Runway Guide

Table of contents

How Autopilot and ESP actually fit together

Before you touch anything: capture the state

Layer 1: Hardware hash and Autopilot registration

What it does

How it fails

How to prove it

How to fix it

Layer 2: Deployment profile assignment

What it does

The device-group vs user-group trap

Dynamic group lag

Checklist

Layer 3: ESP blocking apps, policies, and timeouts

What it does

Common ESP blockers

Design rules that keep ESP sane

When ESP names a specific app

Layer 4: Network, proxy, and TLS inspection

Why network problems look like ESP problems

Network failure modes

What to do

Layer 5: The Conditional Access enrollment deadlock

The chicken-and-egg

What it looks like

How to prove it

How to break the loop safely

Hybrid join sidebar: when ESP takes the blame for AD

Read-only diagnostics toolkit

1. Join and MDM state: dsregcmd /status

2. Autopilot and MDM event logs

3. Win32 app logs (Intune Management Extension)

4. Built-in diagnostic bundle

5. Local snapshot to CSV

Symptom to layer lookup table

Escalation note template

Making dock day boring: prevention habits

FAQ

Want the full Autopilot runbooks?

Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass and rollout waves

Conditional Access baseline for Entra ID: from report-only to enforce, step by step

What a Conditional Access baseline is (and isn't)

Prerequisites: licenses, roles, and an inventory

Licenses

Roles

Inventory what already exists

A Conditional Access naming convention that scales

Pilot groups: who goes first and why

Report-only mode: how to use it properly

What If and Insights and reporting: reading the results

What If (before and after every change)

Sign-in logs (single-user truth)

1. Join and MDM state: `dsregcmd /status`

2. What does the device think it is? (`dsregcmd /status`)