"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.

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:

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:

1. Company Portal → Settings → Sync
2. Settings → Accounts → Access work or school → account → Info → Sync
3. 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:

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.

Related reading

• BitLocker still encrypting? Why Intune marks you noncompliant (and how grace periods save Monday)
• The 30-minute Monday habit: weekly read-only Intune device compliance CSV snapshots (Graph)
• Conditional Access without the Monday lockout: report-only → enforce

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.