Intune Autopilot Errors 2026: Οδηγός Αντιμετώπισης Σφαλμάτων Εγγραφής

Ενημερώθηκε: 2 Σεπτεμβρίου 2026

Τα σφάλματα εγγραφής του Windows Autopilot (τύπου 80180018, 80180014, 80180032 και 0x800705b4) διορθώνονται σχεδόν πάντα με τέσσερις ελέγχους: σωστή άδεια Intune/Entra ID στον χρήστη, MDM enrollment επιτρεπόμενο στα enrollment restrictions, καθαρό αντικείμενο συσκευής σε Intune/Entra/Autopilot, και ένα Enrollment Status Page (ESP) που δεν περιμένει εφαρμογή η οποία δεν πρόκειται ποτέ να εγκατασταθεί. Ειλικρινά, αυτό είναι το ακριβές runbook που ακολουθώ όταν μια συσκευή κολλάει στο OOBE, από τους κωδικούς σφάλματος μέχρι τη συλλογή logs με Get-AutopilotDiagnostics. Το έχω τρέξει σε παραπάνω από 40 tenants φέτος και δεν με έχει προδώσει ακόμα.

• Ο κωδικός 80180018 σημαίνει σχεδόν πάντα λάθος άδεια χρήστη ή υπέρβαση ορίου συσκευών ανά χρήστη. Έλεγξε πρώτα τη λίστα «Devices» στο myaccount.microsoft.com.
• Ο κωδικός 80180032 ενεργοποιείται από enrollment restrictions που μπλοκάρουν personal Windows devices, ενώ το corporate marker δεν έχει προλάβει να διαδοθεί.
• Το ESP κολλάει τις περισσότερες φορές επειδή αναμένει Win32 app που έχει εξάρτηση από LOB app· μην τα βάζεις μαζί στο ίδιο ESP profile.
• Το σφάλμα 0x800705b4 σε συσκευές με TPM 2.0 απαιτεί καθαρισμό των κλειδιών registry AutopilotSettings\devicepreparation και devicesetup πριν την επαν-εγγραφή.
• Το Autopilot Device Preparation (v2) δεν χρησιμοποιεί ESP και δεν χρειάζεται hardware hash. Αν είσαι Entra-joined only, ίσως να πρέπει να μεταβείς εκεί.
• Το Get-AutopilotDiagnostics κατεβάζει τα MDM logs σε ZIP και είναι το πρώτο εργαλείο που ζητά κάθε Microsoft support ticket.

Γιατί αποτυγχάνει η εγγραφή Autopilot;

Πριν κυνηγήσεις κωδικό σφάλματος, εντόπισε σε ποια φάση έσπασε η ροή. Το Autopilot έχει τέσσερα διακριτά στάδια και το κάθε ένα αποτυγχάνει διαφορετικά: (1) OOBE, όπου η συσκευή κατεβάζει το profile, (2) Microsoft Entra join, (3) εγγραφή στο Intune MDM, (4) Enrollment Status Page (Device setup, Account setup, User ESP). Ο εμπειρικός κανόνας που γράφω σε κάθε runbook μου: αν σκάει πριν φτάσεις σε οθόνη login, το πρόβλημα είναι στο profile assignment ή στη σύνδεση με το Autopilot service. Αν σκάει μετά το login, είναι licensing, enrollment restrictions ή ESP.

Η δεύτερη σημαντική διάκριση: το Autopilot, το Microsoft Entra, το Intune και οι εγγραφές deployment attempts δεν είναι εναλλάξιμα. Διαγραφή μόνο του ενός δεν επισκευάζει τα υπόλοιπα. Αντιθέτως, αφήνει ορφανά αντικείμενα που εμποδίζουν την επαν-εγγραφή. Όταν κάνεις cleanup, δούλεψε πάντα και στους τέσσερις χώρους: Intune > Devices, Entra > Devices, Intune > Windows Autopilot devices, και το ίδιο το τοπικό OOBE state της συσκευής.

Οι πιο συχνές αιτίες αποτυχίας που καταγράφω σε 2026 tickets είναι, με σειρά συχνότητας: λάθος ή μηδενική άδεια στον χρήστη, enrollment restrictions που μπλοκάρουν προσωπικές συσκευές, ESP timeout σε required app, TPM certificate που δεν έχει ανανεωθεί, και mixed LOB/Win32 apps στο ίδιο ESP profile. Οτιδήποτε πιο εξωτικό (network filtering, PKI issues, hybrid join τραβήγματα) έρχεται πολύ μετά.

Πίνακας κωδικών σφάλματος Autopilot 2026

Αυτή είναι η μικρή αναφορά που έχω κρεμασμένη δίπλα στο monitor όταν κάνω pilot. Κάθε γραμμή αντιστοιχεί σε ένα σφάλμα που έχω δει τουλάχιστον πέντε φορές μέσα στο 2026.

Κωδικός	Μήνυμα	Πιο πιθανή αιτία	Πρώτη κίνηση
80180018	There was an error with your license	Λάθος licensing ή >5 devices per user	Έλεγχος Intune license & device count
80180014	This feature is not supported	Windows MDM blocked στα enrollment restrictions	Ενεργοποίηση Windows (MDM) = Allow
80180032	Your device cannot be enrolled right now	Enrollment restriction σε personal devices	Επιβεβαίωση corporate marker στο Autopilot
8018000a	The device is already enrolled	Ορφανό record από προηγούμενο deployment	Cleanup σε Intune + Entra + Autopilot
0x800705b4	Device Setup timeout	TPM 2.0 attestation ή stale AutopilotSettings key	Καθαρισμός registry & TPM certificate update
0x80070774	The specified account does not exist	Time skew > 5 λεπτά με το Entra	Συγχρονισμός ρολογιού με w32tm /resync

Ένα σημείο που θέλει προσοχή: ο ίδιος κωδικός μπορεί να εμφανιστεί σε διαφορετικά σημεία του OOBE και να σημαίνει διαφορετικό πράγμα. Παράδειγμα: το 80180018 στην αρχική οθόνη «Setting up your device» δείχνει προς licensing, ενώ το ίδιο 80180018 στη μέση του ESP συχνά δείχνει προς εξαντλημένο όριο συσκευών του συγκεκριμένου χρήστη. Πάντα κοίτα σε ποιο στάδιο έσκασε πριν αποφασίσεις τι είδους fix θα εφαρμόσεις.

Πώς διορθώνω το σφάλμα 80180018;

Το 80180018 «There was an error with your license» είναι το πιο συχνό σφάλμα εγγραφής που θα δεις σε νέο tenant. Στο 90% των περιπτώσεων, η αιτία είναι ένα από τρία πράγματα και υπάρχει πολύ συγκεκριμένη σειρά ελέγχου. Το runbook που ακολουθώ είναι:

1. Επιβεβαίωση Intune license: άνοιξε το Microsoft 365 admin center, βρες τον χρήστη, και στο tab «Licenses & apps» βεβαιώσου ότι έχει τουλάχιστον Intune Plan 1, Microsoft Entra ID P1, και ένα Windows subscription (E3/E5/Business Premium). Χωρίς Entra ID P1, δεν μπορεί να γίνει auto-enrollment στο MDM.
2. Έλεγχος device limit: στο myaccount.microsoft.com/device-list ή μέσω PowerShell με Get-MgUserOwnedDevice -UserId [email protected], μέτρησε πόσες συσκευές έχει ήδη ο χρήστης. Το default όριο είναι 5. Αν έχει φτάσει το όριο, είτε αύξησε το «Maximum number of devices per user» στα device enrollment settings, είτε καθάρισε παλιές συσκευές.
3. Επιβεβαίωση MDM user scope: στο Entra admin center → Mobility (MDM) → Microsoft Intune, το «MDM user scope» πρέπει να είναι είτε All, είτε Some με group που περιέχει τον χρήστη. Πολύ συχνά σε νέα tenants είναι None από default.

Για γρήγορο audit ολόκληρου του tenant, τρέξε το παρακάτω PowerShell. Μου έχει σώσει ώρες όταν πρέπει να πάρω απόφαση αν έχω global licensing gap ή isolated user issue:

# Απαιτεί Microsoft.Graph module: Install-Module Microsoft.Graph
Connect-MgGraph -Scopes "User.Read.All","DeviceManagementManagedDevices.Read.All"

# Βρες όλους τους χρήστες χωρίς Intune license
$intuneSku = "SPB" # Business Premium, άλλαξε αν χρειάζεται
Get-MgUser -All -Property DisplayName,AssignedLicenses,UserPrincipalName |
  Where-Object { $_.AssignedLicenses.Count -gt 0 } |
  ForEach-Object {
    $hasIntune = $_.AssignedLicenses | Where-Object { $_.SkuId -match $intuneSku }
    if (-not $hasIntune) {
      [PSCustomObject]@{
        User      = $_.UserPrincipalName
        Display   = $_.DisplayName
        HasIntune = $false
      }
    }
  } | Format-Table -AutoSize

Αναμενόμενο output: πίνακας με UPNs χωρίς Intune. Αν εμφανιστεί ο χρήστης που έχει το πρόβλημα, βρήκες την αιτία. Αν δεν εμφανιστεί, το license υπάρχει και πρέπει να ελέγξεις device limit ή MDM scope. Για βαθύτερο licensing troubleshooting, δες τον οδηγό μας για τη διαχείριση Entra ID authentication methods.

Γιατί κολλάει το Enrollment Status Page;

Το Enrollment Status Page (ESP) είναι η οθόνη προόδου που ελέγχει τρεις φάσεις: Device setup (πριν το login), Account setup (μετά το login), και σε user-driven flows το User ESP. Κάθε φάση έχει configurable timeout. Το default είναι 60 λεπτά. Όταν κολλήσει, ο πραγματικός λόγος είναι σχεδόν πάντα ένα από αυτά:

• Required app blocked: ένα Win32 app έχει dependency σε άλλο app που δεν έχει ακόμα εγκατασταθεί, ή το Intune Management Extension (IME) δεν έχει προλάβει να ξεκινήσει.
• Certificate deployment failure: SCEP/PKCS profiles που αποτυγχάνουν σιωπηλά επειδή το NDES connector είναι offline ή το certificate authority δεν είναι διαθέσιμο.
• Mixed LOB + Win32 apps: και τα δύο βασίζονται στο TrustedInstaller service ταυτόχρονα και συχνά σκοντάφτουν το ένα στο άλλο.
• Required policy stuck: policy μαρκαρισμένη ως blocking στο ESP που δεν πηγαίνει ποτέ σε compliant state.

Ο πρώτος μου έλεγχος είναι πάντα ο ίδιος: Intune admin center → Devices → Monitor → Enrollment failures. Εκεί βλέπεις πραγματικά ποιο app ή policy μπλοκάρει. Το δεύτερο βήμα, αν χρειάζεται να ξεκολλήσεις έναν χρήστη τώρα, είναι να πας στο Devices → Enrollment → Enrollment Status Page → [το profile σου] → Settings και είτε να αυξήσεις το «Show error when installation takes longer than» σε 240 λεπτά, είτε να απενεργοποιήσεις προσωρινά το blocking για το συγκεκριμένο app. Η κακή πρακτική είναι να αφήσεις μόνιμα ένα ESP timeout στα 240 λεπτά· αυτό απλά κρύβει το πραγματικό πρόβλημα.

Ακόμα, για την αντιμετώπιση logon-side προβλημάτων μετά από επιτυχή enrollment, δες τον οδηγό μας για τον εντοπισμό πηγής AD account lockout μέσω Event 4740. Πολλά Autopilot devices κολλάνε στο Account Setup επειδή ο ίδιος χρήστης έχει locked λογαριασμό από παλιά κινητή συσκευή. Το είδα τρεις φορές μέσα στον Ιούλιο, οπότε αξίζει να το τσεκάρεις.

Autopilot Device Preparation (v2) vs Classic Autopilot (v1)

Από το 2024 και μετά, η Microsoft έχει δύο ξεχωριστές αρχιτεκτονικές provisioning που τρέχουν παράλληλα: το Classic Autopilot (v1) και το Windows Autopilot Device Preparation (v2). Δεν είναι αναβάθμιση, είναι δύο διαφορετικές προσεγγίσεις που συνυπάρχουν στο ίδιο tenant, και η επιλογή του λάθος για το σενάριό σου προκαλεί τα μισά error tickets που βλέπω.

Η καθοριστική διαφορά: το v1 κατεβάζει το deployment profile πριν το login του χρήστη, βασισμένο σε pre-registered hardware hash. Το v2 κατεβάζει το profile μετά το authentication με Entra ID credentials στο OOBE. Αυτή η αλλαγή δίνει διαφορετική ροή, διαφορετικές δυνατότητες και (φυσικά) διαφορετικά bugs.

Πότε επιλέγω v1 και πότε v2;

Ο δικός μου κανόνας είναι απλός: αν το fleet σου είναι αποκλειστικά Windows 11 και Entra-joined only, πήγαινε σε v2. Έχεις: όχι hardware hash, όχι ESP, δυνατότητα να μιξάρεις LOB + Win32 apps (μέχρι 25 essential apps + 10 PowerShell scripts στο OOBE), simplified percentage progress, και near real-time reporting. Αν χρειάζεσαι Hybrid Join, self-deploying mode, pre-provisioning (white glove), device naming templates ή Windows 10 support, μείνε στο v1.

Το πιο πρόσφατο add στο v2 είναι το Device Association (ανακοινώθηκε 27 Αυγούστου 2026): δίνει τη δυνατότητα η οργάνωση να δημιουργήσει σχέση με μια φυσική Windows 11 συσκευή πριν γραφτεί στο Intune. Μέχρι τώρα το Device Preparation ήταν user-first, οπότε αυτό επαναφέρει μια device-first λογική που πολλοί περιμέναμε. Λεπτομέρειες στην επίσημη τεκμηρίωση Device Preparation.

TPM 2.0 και σφάλμα 0x800705b4 κατά το Device Setup

Το 0x800705b4 εμφανίζεται συνήθως στη φάση Device Setup του ESP σε συσκευές με TPM 2.0. Ο πραγματικός λόγος είναι σχεδόν πάντα ένα από δύο: είτε το TPM vendor certificate είναι stale και δεν μπορεί να γίνει attestation με τον Microsoft attestation service, είτε υπάρχει corrupt AutopilotSettings key στο registry από προηγούμενη αποτυχημένη προσπάθεια.

Το runbook που δουλεύει το 2026:

1. TPM certificate refresh: βεβαιώσου ότι η συσκευή έχει active internet connection. Αν είναι OEM device (Dell, HP, Lenovo), βάλε την πρώτα online για 5-10 λεπτά ώστε να συγχρονιστεί το TPM attestation certificate με τον vendor endpoint.
2. Registry cleanup: από WinRE ή Safe Mode, άνοιξε regedit και διάγραψε τα κλειδιά HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotSettings\devicepreparation και HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotSettings\devicesetup.
3. Επαν-εγγραφή: κάνε restart και άσε το OOBE να τρέξει από την αρχή. Ποτέ μη δοκιμάσεις resume, το state είναι corrupted.
4. Physical device only: αν κάνεις testing σε VM, ξέχνα το self-deploying mode. Το TPM attestation θέλει φυσικό TPM 2.0 module που να έχει vendor certificate.

# PowerShell: έλεγχος TPM readiness πριν το Autopilot
Get-Tpm | Select-Object TpmReady, TpmPresent, ManagedAuthLevel, ManufacturerVersion

# Αναμενόμενο output για ready device:
# TpmReady          : True
# TpmPresent        : True
# ManagedAuthLevel  : Full
# ManufacturerVersion : 7.2.x.x (Intel/AMD/Infineon)

Αν το TpmReady εμφανιστεί False, η συσκευή δεν είναι έτοιμη για Autopilot και θα σκάσει με 0x800705b4 ή παρόμοιο σφάλμα ανεξάρτητα από το πόσες φορές θα επαν-εγγραφεί. Δες πρώτα το BIOS για TPM enable/clear και μετά προχώρα.

Πώς συλλέγω διαγνωστικά logs με Get-AutopilotDiagnostics;

Το Get-AutopilotDiagnostics είναι το script που κάθε Microsoft support engineer θα σου ζητήσει σε ticket για Autopilot. Παρσάρει όλα τα MDM diagnostic logs, τα φιλτράρει σε human-readable format, και δίνει timeline όλων των policies/apps/certificates που πέρασαν από τη συσκευή. Είναι open-source στο PowerShell Gallery και μπορεί να τρέξει είτε live στη συσκευή είτε πάνω σε ένα προϋπάρχον MDM diagnostics ZIP.

# Εγκατάσταση από PowerShell Gallery (elevated PowerShell)
Install-Script -Name Get-AutopilotDiagnostics -Force

# Live τρέξιμο στην ίδια τη συσκευή, δείχνει όλο το timeline
Get-AutopilotDiagnostics -Online

# Ή, από ένα MDM diagnostics ZIP που πήρες από άλλη συσκευή
Get-AutopilotDiagnostics -ZipFile "C:\Temp\MDMDiagReport.zip"

# Αναμενόμενο output: timeline με timestamps, policy names,
# app installs, ESP tracking events, και τυχόν errors με κωδικούς

Πριν καν καλέσεις Microsoft support, τρέξε πρώτα το Get-AutopilotDiagnostics -Online στην προβληματική συσκευή. Στο 70% των tickets που έχω ανοίξει, το output δείχνει άμεσα το app ή το policy που κόλλησε και μου γλυτώνει 2-3 μέρες correspondence. Η επίσημη τεκμηρίωση για MDM log collection υπάρχει στη σελίδα Windows Autopilot troubleshooting FAQ του Microsoft Learn.

Πώς αφαιρώ μια συσκευή από το Autopilot και την επαν-εγγράφω;

Αυτή είναι η δεύτερη πιο συχνή αιτία tickets: κάποιος διέγραψε τη συσκευή μόνο από ένα σημείο και τώρα η επαν-εγγραφή αποτυγχάνει με 8018000a «The device is already enrolled». Ο σωστός τρόπος καθαρισμού πρέπει να αγγίζει και τα τέσσερα σημεία που κρατάνε state:

1. Intune → Devices → All devices: βρες τη συσκευή, «Delete» για να την αφαιρέσεις από MDM management.
2. Microsoft Entra → Devices → All devices: βρες την ίδια συσκευή, «Delete» για να αφαιρέσεις το Entra object.
3. Intune → Devices → Windows → Windows enrollment → Windows Autopilot devices: βρες τη συσκευή με βάση serial number, «Delete», και έτσι αφαιρείς την Autopilot registration.
4. Τοπικά στη συσκευή: τρέξε dsregcmd /leave από elevated PowerShell και μετά κάνε full reset από Settings → Recovery → «Reset this PC» με «Remove everything» και «Clean data».

Μόνο αφού και τα τέσσερα βήματα ολοκληρωθούν, μπορείς να ανεβάσεις ξανά το hardware hash και να ξεκινήσεις καθαρή εγγραφή. Το να παραλείψεις έστω και ένα βήμα (π.χ. δεν καθαρίζεις το Entra object) οδηγεί σε ορφανό record που θα σκάσει την επόμενη προσπάθεια — έχω χάσει μισή μέρα κυνηγώντας ακριβώς αυτό. Για την επόμενη enrollment προσπάθεια, δουλεύω μαζί με τον οδηγό Troubleshoot the Enrollment Status Page του Microsoft Learn για να πιάσω τυχόν residual timeouts.

# PowerShell: bulk cleanup Autopilot registrations με βάση serial
$serials = @("ABC1234", "DEF5678", "GHI9012")
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

foreach ($sn in $serials) {
  $device = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "contains(serialNumber,'$sn')"
  if ($device) {
    Remove-MgDeviceManagementWindowsAutopilotDeviceIdentity `
      -WindowsAutopilotDeviceIdentityId $device.Id
    Write-Host "Αφαιρέθηκε: $sn" -ForegroundColor Green
  } else {
    Write-Host "Δεν βρέθηκε: $sn" -ForegroundColor Yellow
  }
}
# Αναμενόμενο output: μια γραμμή ανά serial με πράσινο (success) ή κίτρινο (not found)

Συχνές ερωτήσεις

Πόσο διαρκεί κανονικά το Autopilot enrollment;

Ένα υγιές Autopilot enrollment με 5-10 required apps διαρκεί συνήθως 25-45 λεπτά. Αν πάει πάνω από 60 λεπτά, δεν είναι αργό δίκτυο· κάτι έχει κολλήσει και θέλει διάγνωση. Τα apps είναι σχεδόν πάντα ο ένοχος.

Πώς κάνω bypass το Enrollment Status Page;

Δεν το κάνεις. Το ESP υπάρχει για να διασφαλίζει compliance πριν ο χρήστης πάρει τη συσκευή. Αν χρειάζεται να ξεκολλήσεις κάποιον τώρα, αύξησε προσωρινά το timeout και επίτρεψε στους χρήστες να συνεχίσουν σε failure. Μην απενεργοποιήσεις εντελώς το ESP.

Χρειάζομαι Intune P2 για Autopilot Device Preparation;

Όχι, το v2 δουλεύει με Intune Plan 1 και Microsoft Entra ID P1. Το Intune Plan 2 προσφέρει επιπλέον features (Remote Help, Endpoint Privilege Management) αλλά δεν είναι απαραίτητο για το ίδιο το Autopilot flow.

Μπορώ να τρέξω Autopilot σε Windows 10;

Ναι για Classic Autopilot (v1). Όχι για Autopilot Device Preparation (v2), το οποίο υποστηρίζει μόνο Windows 11. Δεδομένου ότι το Windows 10 φτάνει End of Support τον Οκτώβριο 2025, όλα τα νέα deployments πρέπει να στοχεύουν σε Windows 11 24H2 ή νεότερο.

Τι είναι το Enrollment Time Grouping;

Είναι feature αποκλειστικά του Autopilot Device Preparation (v2) που προσθέτει αυτόματα μια νέα συσκευή σε ένα target Entra security group τη στιγμή της εγγραφής, χωρίς να χρειάζεται να περιμένεις τον dynamic group evaluation. Λύνει το race condition όπου τα policies δεν έφταναν εγκαίρως στο νέο device.