Microsoft Intune-felsökning för enhetsenrollment — komplett guide för IT-helpdesk 2026

Om du jobbar på en helpdesk 2026 har du förmodligen redan fått ett par Intune enrollment-ärenden i veckan — och om inte, så kommer du. Microsoft Intune är numera default-MDM för i stort sett alla organisationer som lämnat den klassiska on-prem-världen för Microsoft Entra ID. Det betyder också att när enrollment går snett, så landar bollen direkt hos oss. Och felkoderna? Tja, "0x801C03ED" är inte direkt självförklarande första gången du ser det.

Den här guiden samlar den felsökningsmetodik som faktiskt fungerar i fält (uppdaterad april 2026), med fokus på de fel som genererar flest tickets på Windows, iOS/iPadOS, Android Enterprise och macOS. Inga teoretiska resonemang — bara grejer som löser ärenden.

Förutsättningar innan du dyker ner i felkoderna

Ärligt talat: ungefär 60 % av alla "misslyckade enrollment"-ärenden vi tittar på beror på att någon av punkterna nedan är fel eller saknas. Innan du börjar gräva i loggar — gå igenom listan. Det sparar tid.

• MDM Authority är satt till Microsoft Intune i tenant-inställningarna.
• Licens som inkluderar Intune är tilldelad användaren (Intune Plan 1, EMS E3/E5, Microsoft 365 Business Premium, M365 E3/E5).
• Microsoft Entra ID har "Users may join devices" satt till All eller en specifik grupp där användaren ingår.
• Enrollment restrictions tillåter den aktuella plattformen (Windows, iOS, Android, macOS) och versionen.
• Device limit per användare är inte överskriden (standard är 5, vilket går snabbt om man har en testpark).
• UPN i Active Directory matchar UPN i Entra ID — en klassisk fallgrop i hybridmiljöer.
• Tid och datum på enheten är synkroniserade. Avvikelser över ±5 minuter bryter token-validering, och det är förvånansvärt vanligt på enheter som legat på lagret en månad.

Diagnostiska verktyg och loggar

Event Viewer på Windows

Det här är där du kommer att tillbringa det mesta av din tid. De viktigaste loggarna finns under:

Applications and Services Logs
  └── Microsoft
      └── Windows
          ├── DeviceManagement-Enterprise-Diagnostics-Provider
          │   └── Admin
          ├── ModernDeployment-Diagnostics-Provider
          │   └── AutoPilot
          ├── Provisioning-Diagnostics-Provider
          │   └── AutoPilot
          └── User Device Registration
              └── Admin

Börja alltid i DeviceManagement-Enterprise-Diagnostics-Provider/Admin. Det är där MDM-klienten loggar HRESULT-koder från enrollment, och 9 gånger av 10 hittar du svaret där.

Registret — verifiera enrollment-status

När en Windows-enhet är korrekt enrollad finns ett GUID under följande nyckel:

HKLM\SOFTWARE\Microsoft\Enrollments\{GUID}

Värdet EnrollmentState ska vara 1 (enrolled) och ProviderID ska vara MS DM Server. Är det något annat så är enrollment inte komplett — oavsett vad Settings säger.

MDM Diagnostics Tool

Inbyggt i Windows 10 1809+ och samtliga versioner av Windows 11. Kör som administratör:

MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -cab C:\Temp\MDMDiag.cab

CAB-filen innehåller event logs, registerexport och konfigurationsdata. Bifoga den i ärenden till Microsoft support — det är bokstavligen det första de frågar efter.

PowerShell — snabb statuskontroll

$enrollments = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments\" |
    Where-Object { $_.Property -contains "UPN" }

foreach ($e in $enrollments) {
    [PSCustomObject]@{
        EnrollmentID    = $e.PSChildName
        UPN             = (Get-ItemProperty $e.PSPath).UPN
        ProviderID      = (Get-ItemProperty $e.PSPath).ProviderID
        EnrollmentState = (Get-ItemProperty $e.PSPath).EnrollmentState
    }
}

dsregcmd — Entra ID join-status

dsregcmd /status

Granska sektionerna Device State, SSO State och Tenant Details. AzureAdJoined: YES och MdmUrl ska vara satta för en korrekt enrollad enhet. Saknas MdmUrl men AzureAdJoined är YES? Då har du Entra-join utan auto-enrollment, och det är en helt egen härva (oftast en MDM scope-grupp som inte täcker användaren).

Vanliga felkoder på Windows och hur du löser dem

0x8007064c — "The machine is already enrolled"

Orsak: Datorn har tidigare varit enrollad och har kvar gamla certifikat eller registry-poster. Vanligast på enheter som klonats från en image utan korrekt sysprep — något jag personligen har sett orsaka flera dagars huvudvärk när en hel batch laptops kom ut till användarna.

Lösning:

1. Öppna certlm.msc (lokala datorns certifikatlager).
2. Navigera till Personal > Certificates.
3. Sök efter certifikat utfärdade av Sc_Online_Issuing eller Microsoft Intune MDM Device CA.
4. Radera dem.
5. Ta bort registernyckeln HKLM\SOFTWARE\Microsoft\Enrollments\{GUID} där GUID inte är 00000000-0000-0000-0000-000000000000.
6. Schemalagda uppgifter under \Microsoft\Windows\EnterpriseMgmt\ bör också raderas.
7. Starta om och försök enrolla på nytt.

0x8018002A — "No MFA token" (Conditional Access blockerar enrollment)

Orsak: En Conditional Access-policy kräver MFA för "Microsoft Intune Enrollment"-appen, men enheten kan inte tillhandahålla MFA-token under den tysta enrollment-fasen. Det här är, utan tvekan, det jag oftast ser missas av nya tenants.

Lösning: Exkludera molnappen Microsoft Intune Enrollment (App ID d4ebce55-015a-49b5-a083-c84d1797ae8c) från CA-policyn som kräver MFA. Behåll MFA-kravet på själva Microsoft Intune-appen, så att MFA fortfarande triggas vid den interaktiva inloggningen. Du tappar alltså ingen säkerhet.

# Lista CA-policyer som påverkar Intune-enrollment via Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.Conditions.Applications.IncludeApplications -contains "d4ebce55-015a-49b5-a083-c84d1797ae8c" } |
    Select-Object DisplayName, State, Id

0x80180014 — Personal devices blocked

Orsak: Användaren försöker enrolla en personlig (BYOD) enhet, men Enrollment Device Platform Restrictions är konfigurerade att blockera personliga Windows-enheter.

Lösning: Gå till Intune Admin Center > Devices > Enrollment > Enrollment device platform restrictions > Windows restrictions. Sätt Personally owned till Allow, eller (om policy är policy) informera användaren om att enheten måste vara företagsägd och importerad i Autopilot.

8018000a — "The device is already enrolled by another user"

Orsak: En annan användare har tidigare enrollat enheten eller anslutit den till Entra ID, och spår finns kvar i Work or School Account-listan.

Lösning:

1. Logga ut och logga in med originalkontot om möjligt.
2. Gå till Settings > Accounts > Access work or school.
3. Välj kontot och klicka Disconnect.
4. I Intune Admin Center, radera enheten från Devices > All devices.
5. I Entra ID admin center, radera enhetsobjektet under Devices > All devices.
6. Starta om och kör dsregcmd /leave som SYSTEM via PsExec om kontot inte kan logga in.

0x801C03ED — Invalid Token (Autopilot)

Det här är, ärligt talat, en av de mest envisa felkoderna i 2026 års supportstatistik. Den dyker nästan uteslutande upp under Autopilot pre-provisioning eller AADEnroll-fasen — och just därför är det en mardröm att felsöka eftersom enheten redan är delvis konfigurerad när det smäller.

Orsaker:

• Entra ID-enhetsobjektet som skapades vid Autopilot-import har raderats manuellt.
• "Users may join devices to Azure AD" är satt till None eller en grupp där användaren saknas.
• Pre-provisioning slutfördes utan att enheten unjoinades från Entra ID innan reseal.
• MFA krävs men enheten kan inte interaktivt slutföra det.

Lösning:

1. Verifiera Entra ID device settings: Microsoft Entra admin center > Devices > Device settings > sätt "Users may join devices to Microsoft Entra" till All (eller lägg till användaren i den tillåtna gruppen).
2. I Intune > Devices > Windows > Windows enrollment > Devices, hitta enheten via serienummer, radera den, och importera hardware hash på nytt från en CSV.
3. Vänta minst 8 timmar innan du försöker igen — det säkerställer att backend-replikering hinner klart. Jag vet, det känns som en evighet, men det fungerar.
4. Kör Autopilot mot ett kabelbundet nätverk. Wi-Fi-drivrutiner som laddas sent i OOBE orsakar oftare token-fel än man tror.
5. Granska ModernDeployment-Diagnostics-Provider/AutoPilot för exakt HRESULT.

0x80180018 — License-related enrollment failure

Orsak: Användaren saknar Intune-licens, eller licensen har precis tilldelats men inte propagerats till Entra ID.

Lösning: Kontrollera tilldelade licenser med:

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
$user = Get-MgUser -UserId "[email protected]" -Property AssignedLicenses,UsageLocation
$user.AssignedLicenses
$user.UsageLocation  # Måste vara satt (t.ex. "SE"), annars kan licensen inte appliceras

Om UsageLocation är tomt kommer Intune-licensen helt enkelt inte att fungera. Sätt det till SE (eller motsvarande land enligt ISO 3166-1 alpha-2) — det är en av de där detaljerna som ingen tänker på förrän det är för sent.

"MDM Authority Not Defined"

Sällsynt 2026, men kan dyka upp i nyligen migrerade tenants. Kontrollera i Intune Admin Center under Tenant administration > Tenant details att MDM authority är Microsoft Intune. Om det står None, klicka för att aktivera.

Felsökning på iOS och iPadOS

"NoEnrollmentPolicy" — APNs-certifikat saknas eller är ogiltigt

Apple Push Notification service-certifikatet (APNs) är obligatoriskt för all iOS/iPadOS-hantering. Det måste förnyas årligen — och det förfaller utan varning om kalenderpåminnelser saknas. (Ja, det har hänt mig. Två gånger.)

Kontroll: Intune Admin Center > Devices > Enrollment > Apple > Apple MDM Push certificate. Verifiera Expiration date.

Viktigt: Förnya alltid med samma Apple ID som ursprungligen skapade certifikatet. Om du tappat tillgång till det Apple ID:t måste du återskapa certifikatet — och då måste alla hanterade iOS-enheter enrollas på nytt. Du vill inte vara den person som tappade lösenordet till det Apple ID:t.

"Profile Installation Failed" under Setup Assistant (ADE/DEP)

Felen på Apple Business Manager / ADE-enrollade enheter beror oftast på en av följande:

• VPP-token har förfallit (giltig i 1 år).
• ADE-token har förfallit eller är inte länkad till MDM-server "Microsoft Intune".
• Enrollment profile är inte tilldelad serienumret i Intune.
• Tid på enheten är felaktig — vanligt på enheter som varit avstängda länge.

Felsökning på Android Enterprise

Existerande work profile blockerar enrollment

Android Enterprise tillåter endast en aktiv work profile per enhet. Om en användare tidigare lämnat ett företag utan att ta bort profilen kommer ny enrollment att misslyckas — och felmeddelandet är ofta hopplöst kryptiskt.

Kontroll på enheten: Settings > Passwords & accounts > Work eller Settings > Accounts beroende på Android-version.

Lösning: Ta bort den befintliga profilen. På äldre Android-versioner — fabriksåterställ enheten.

Google Play-tjänster och OEM-restriktioner

Vissa OEM-leverantörer (särskilt budgetenheter med modifierat Android) blockerar work profiles trots att enheten kör Android 8.0+. Konsultera Android Enterprise Recommended-listan för verifierade enheter innan du köper in en hel batch — det är en lärdom från min egen ryggsäck.

Felsökning på macOS

Enrollment misslyckas på Apple Silicon med systemtilläggsmeddelande

När macOS 14 (Sonoma) och senare introducerade striktare hantering av kernelextensions kräver Microsoft Intune Company Portal explicit godkännande av System Extensions och Privacy Preferences Policy Control (PPPC). Hoppa över det här steget och du har en användare som klickar "Tillåt" i tio dialoger — i bästa fall.

Lösning: Skapa en Configuration Profile i Intune som pre-godkänner Microsofts identifierare:

Team Identifier: UBF8T346G9
Bundle ID: com.microsoft.CompanyPortalMac

Distribuera profilen via Apple Business Manager innan enrollment, annars måste användaren manuellt godkänna varje extension.

FileVault-recovery key skickas inte upp

Symptom: enheten är enrollad, men FileVault-nyckeln saknas i Intune. Kontrollera att Endpoint security > Disk encryption > FileVault policy är tilldelad och att enheten har checkat in efter att policyn applicerades. macOS skickar nyckeln endast vid nästa policy refresh cycle, som körs var 8:e timme. Så ja — vänta lite, eller forcera en check-in via Company Portal.

Conditional Access och Intune — vanliga konfigurationsfel

Conditional Access och Intune-enrollment har en känslig (och ibland direkt fientlig) relation. Vanliga misstag i 2026 års tenants:

• Compliance-policy som kräver "marked as compliant" gäller även enrollment-flödet — vilket leder till en klassisk chicken-and-egg-situation där enheten inte kan bli compliant utan att vara enrollad. Lös det genom att exkludera Microsoft Intune Enrollment-appen från policyn.
• Block legacy authentication påverkar Android Device Administrator-enrollment (deprecated) men inte Android Enterprise.
• "Require approved client app"-grant kontrollerar inte Company Portal — använd Require app protection policy istället där det är tillgängligt.
• Sign-in frequency satt till en låg siffra (t.ex. 1 timme) bryter token-refresh under långa enrollment-flöden som Autopilot. Sätt det rimligt.

Felsökningsschema — checklista i ordning

1. Verifiera licens — har användaren en Intune-licens och korrekt UsageLocation?
2. Kontrollera platform restrictions — är plattformen och versionen tillåten?
3. Kontrollera device limit — har användaren nått sitt max?
4. Granska Conditional Access — är "Microsoft Intune Enrollment"-appen exkluderad från MFA-krav?
5. Verifiera enrollment-objekt — finns enheten redan i Entra ID/Intune under en annan användare?
6. Synka tid och datum — använd w32tm /resync på Windows.
7. Samla loggar — kör MdmDiagnosticsTool.exe och granska Event Viewer.
8. Översätt HRESULT — använd err.exe från Microsoft Debugging Tools eller Microsoft Learn.
9. Eskalera — bifoga CAB-filen, dsregcmd-output och tidsstämpel till Microsoft support.

Best practices för att förebygga enrollment-tickets

• Dokumentera Conditional Access-undantag i en levande wiki. Varje undantag som glöms blir ett incident-ärende inom 12 månader. Räkna med det.
• Sätt en kalenderpåminnelse för APNs- och VPP-tokens (60 dagar innan utgång). Och en till på 30 dagar.
• Använd dynamic groups baserade på device.deviceOSType för att automatiskt tilldela rätt enrollment-profil.
• Kör Autopilot pre-provisioning över kabel i tekniker-fasen, inte över Wi-Fi.
• Loggcentralisera MDM diagnostics via Intune > Reports > Devices och Log Analytics-integration.
• Inför self-service unenrollment via Company Portal för BYOD — det minskar belastningen på helpdesk märkbart.

FAQ

Hur lång tid tar Intune-enrollment normalt?

Manuell enrollment på Windows tar 1–3 minuter. Autopilot user-driven scenario tar 15–45 minuter beroende på antal apppolicyer och nätverkshastighet. iOS/iPadOS via Apple Business Manager tar 5–10 minuter, Android Enterprise 3–8 minuter. Om enrollment tar längre än 60 minuter — avbryt och granska loggar. Processen kommer sannolikt inte att slutföras.

Kan jag enrolla samma enhet i flera tenants samtidigt?

Nej. En Windows-enhet kan endast vara enrollad i en MDM-tenant åt gången. Försök att enrolla i en andra tenant returnerar 0x8018000a. På iOS kan en användare ha både ett personligt Apple ID och ett Managed Apple ID, men endast en MDM-kontrollkanal per supervisering är tillåten.

Vad är skillnaden mellan Entra ID join och Intune enrollment?

Entra ID join (tidigare Azure AD join) är identitetsregistreringen — enheten får ett objekt i Entra ID och stöder Single Sign-On. Intune enrollment är hanteringskanalen — enheten får policyer, appar och kan rapporteras som compliant. På moderna Windows-enheter sker båda automatiskt vid auto-enrollment, men det är två separata processer som kan misslyckas oberoende av varandra. dsregcmd /status visar status för båda.

Hur tvingar jag en omedelbar policy-sync?

På Windows: öppna Settings > Accounts > Access work or school, välj kontot, klicka Info och sedan Sync. Via PowerShell:

Get-ScheduledTask -TaskName "PushLaunch" -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
    Start-ScheduledTask

På iOS/iPadOS: Company Portal > Devices > Check status. På Android: Company Portal > menyn > Sync. På macOS: Company Portal > Devices > Check Settings.

Varför misslyckas enrollment trots att användaren har rätt licens?

Vanligaste orsaken är fördröjd licenspropagering. Det kan ta upp till 24 timmar för en nyligen tilldelad licens att aktiveras i alla regionala datacenter. Andra orsaker: användaren saknar UsageLocation, gruppmedlemskap som styr enrollment-restrictions har inte synkats, eller en tidigare licens som krävde annan MDM-konfiguration ligger kvar i cache. Verifiera först med Get-MgUser -Property AssignedLicenses,UsageLocation innan du eskalerar.

Hur återställer jag en enhet som fastnat i ett halvenrollat tillstånd?

Kör följande på Windows som administratör — det rensar både Entra ID-anslutningen och MDM-spår:

# 1. Lämna Entra ID
dsregcmd /leave

# 2. Ta bort enrollment-spår i registret (säkerhetskopiera först)
$enrollKey = "HKLM:\SOFTWARE\Microsoft\Enrollments"
Get-ChildItem $enrollKey | Where-Object {
    $_.Property -contains "UPN"
} | Remove-Item -Recurse -Force

# 3. Ta bort schemalagda uppgifter
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
    Unregister-ScheduledTask -Confirm:$false

# 4. Starta om och enrolla på nytt
Restart-Computer

Och glöm inte: ta bort enheten både i Intune Admin Center och Entra ID innan ny enrollment. Annars hamnar du tillbaka på ruta ett.