Windows Autopilot ve Intune Kayıt Hataları: Helpdesk Sorun Giderme Rehberi (2026)

Güncellendi: 23 Ağustos 2026

Windows Autopilot kayıt hataları (80180014, 0x800705b4 ve 0x80070774 dahil) çoğunlukla üç kök nedene indirgenir: eksik veya çakışan cihaz kimliği, tamamlanamayan Enrollment Status Page (ESP) sağlama adımı ve yanlış lisans/kayıt kısıtlaması. Bu rehberde her hatayı olay yönetim akışına oturttum. PowerShell tanı komutlarını, kayıt (registry) izlerini ve helpdesk için birinci temas çözüm oranını (FCR) yükseltecek "sabit düzeltme reçetelerini" veriyorum. Ekiplerimde bu akışı uyguladığımızdan bu yana Autopilot biletlerinde ortalama çözüm süresi (MTTR) neredeyse yarıya düştü, açıkçası bu benim için de sürpriz oldu.

• 80180014 kişisel cihaz kısıtlaması veya eksik/geçersiz donanım karma değeriyle ilgili bir "kurumsal cihaz tanınmadı" hatasıdır.
• 0x800705b4 genellikle Win32/LOB uygulama çakışması, TPM attestation başarısızlığı veya bayat cihaz kaydı nedeniyle ESP'nin 30 dakikada bitememesidir.
• 0x80070774 yalnızca hibrit Entra katılım senaryosunda görülür ve Intune Konnektörü'nün AD etki alanı uyuşmazlığına işaret eder.
• 806 / 808 CSV içe aktarma hataları, cihazın başka bir kiracıda veya sizin kiracınızda mevcut olduğunu gösterir. Önce kaydı silin.
• Get-AutopilotDiagnostics, MDMDiagnosticsTool.exe ve EnrollmentStatusTracking kayıt anahtarı olmadan Autopilot arızası kör tahmindir.
• Cihazı Intune, Entra ID ve Autopilot'tan doğru sırayla silmeden yeniden kayıt denemek FCR'yi düşürür ve biletlerin yaşlanmasına neden olur.

Autopilot kayıt akışı ve nerede kırılır

Bir Autopilot cihazının OOBE'den (Out-of-Box Experience) üretkenlik ekranına ulaşması dört ayrık aşamadan geçer: donanım karma değerinin kiracıda önceden yer alması, Microsoft Entra ID'de kullanıcı kimliğinin doğrulanması, cihazın Intune MDM'ye kaydı ve Enrollment Status Page üzerinden ilkelerin/uygulamaların uygulanması. Bu adımlardan herhangi birinin başarısız olması, son kullanıcıya opak bir hata kodu döner ve helpdesk biletine dönüşür. Deneyimlerime göre biletlerin yaklaşık %70'i son iki adımda (MDM kayıt + ESP) sıkışır. Kalanı ise ağ/proxy veya lisans temellidir.

Sorun gidermeden önce üç kaynağı aynı anda açık tutuyorum: Intune yönetim merkezinde Devices → Enrollment ile Autopilot deployment profiles, Entra admin center'da Devices → All devices ve cihaz üzerindeki MDMDiagnosticsTool.exe. Bu üçlü olmadan hangi aşamanın kırıldığını söylemek tahminden ibaret olur ve MTTR'yi doğrudan büyütür. Yeni bir Microsoft Entra Connect senkronizasyon hatası sorun giderme rehberi aynı zamanda bekleyen Autopilot cihazlarını da bloke edebildiği için hibrit ortamlarda önce senkron durumunu kontrol etmek pratik bir zaman tasarrufudur.

Windows Autopilot hatası 80180014 nasıl düzeltilir?

Hata 80180014, cihazın Entra ID katılımı sırasında "kurumsal olarak sahip olunan" (corporate-owned) olarak tanınamadığında ortaya çıkar. Kayıt tamamen durur, ESP donar ve kullanıcı OOBE'ye takılır. En yaygın üç kök nedeni sırayla eleyerek ilerliyorum: eksik/geçersiz donanım karma değeri (hardware hash), kişisel cihaz engelleyen kayıt kısıtlaması ve Autopilot dağıtım profilinin cihaza atanmamış olması.

Donanım karma değerini yeniden içe aktarma

Cihazın Intune'da tanınmasını sağlamak için Devices → Windows enrollment → Devices → Import altında karma değerinin göründüğünü doğrulayın. CSV dosyasını Excel'de yeniden kaydetmeyin; elektronik tablo düzenleyicileri BOM veya kaçış karakterleri ekler ve dosya geçersizleşir (bunu ilk defa 2023'te yaşadığımda tam iki gün kaybetmiştim). PowerShell ile taze bir karma dosyası üretmek en güvenli yoldur.

# Cihazda çevrimiçi hash çıkarma (yönetici PowerShell)
Install-Script -Name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Get-WindowsAutopilotInfo.ps1 -OutputFile C:\Temp\autopilot-hash.csv

# Tek adımda Intune'a online kayıt (çoklu cihaz dağıtımı için)
Get-WindowsAutopilotInfo.ps1 -Online -GroupTag "Finance-Laptops-2026"

Kayıt kısıtlamalarını kontrol etme

Intune yönetim merkezinde Devices → Enrollment → Enrollment restrictions → Device type restrictions altında "Personally owned" için Windows (MDM) değerinin Allow olduğundan emin olun. "Block" ayarlanmışsa Autopilot cihazları hibrit senaryolarda kurumsal olarak sınıflandırılamaz ve 80180014 döner. Karmaşayı önlemek için Autopilot cihaz gruplarını her zaman Corporate ownership etiketi ile eşleyin.

Dağıtım profili atamasını doğrulama

Autopilot deployment profile'ın cihazın üye olduğu dinamik cihaz grubuna atanmış olması gerekir. Dinamik üyelik kuralı tipik olarak (device.devicePhysicalIds -any _ -contains "[ZTDId]") şeklindedir. Cihaz grup üyeliğinin gerçekten dolduğunu Entra'da Groups → Members altında doğrulayın; Entra grup değerlendirmesi bazen 15 dakikaya kadar gecikir.

ESP zaman aşımı (0x800705b4) nedenleri ve çözümü

0x800705b4 saf bir ERROR_TIMEOUT'tur ve ESP'nin varsayılan 30 dakikalık pencere içinde cihaz hazırlığı ya da hesap kurulumu aşamasını tamamlayamadığı anlamına gelir. Pratikte dört nedenle karşılaşıyorum: Win32 ile Line-of-Business (LOB) uygulama yükleyici çakışması, eski/güncel olmayan TPM ürün yazılımı (özellikle Lenovo ThinkPad ve HP EliteBook eski modelleri), bayat cihaz kaydı ve Intune tarafında geçici Azure Front Door throttling. Bu sırayla elemek en hızlı yoldur.

Hangi uygulamanın kilitlendiğini bulmak

ESP takip kayıtları HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking altında tutulur. InstallationState = 4 değeri "hata ile bitti" demektir. Cihazın hâlâ OOBE'de olduğu sırada Shift+F10 ile CMD açıp aşağıdaki komutu çalıştırarak hangi Win32/LOB paketinin döngüye soktuğunu tam olarak görebilirsiniz.

# PowerShell (OOBE sırasında Shift+F10 -> powershell)
Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\ESPTrackingInfo\Diagnostics\ExpectedPolicies' `
  | ForEach-Object {
      [PSCustomObject]@{
          Kaynak       = $_.PSChildName
          DurumKodu    = (Get-ItemProperty $_.PSPath).InstallationState
          SonHata      = (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).LastError
      }
  } | Where-Object DurumKodu -eq 4 | Format-Table -AutoSize

TPM attestation başarısızlığı

Self-deploying modda cihaz TPM ile Microsoft'un attestation servisine kanıtlanmalıdır. Eski cihazlarda TPM 1.2 yeterli değildir; TPM 2.0 zorunludur. Ayrıca OEM'in ürün yazılımı (özellikle 2021 öncesi Lenovo/HP modellerinde) attestation için gerekli sertifikayı düzgün taşımayabilir. Şu üç şeyi sırayla yapıyorum: BIOS/UEFI'de TPM'i temizle, OEM sitesinden en güncel BIOS/TPM firmware'ini yükle, cihazı Autopilot'ta yeniden kaydet. Sanal makinelerde en az 2 vCPU ve 4 GB RAM ayarlı olmalı, aksi hâlde TPM attestation zaman aşımı garantilidir.

Bayat cihaz kaydı

Aynı seri numarası Intune'da ve Autopilot devices listesinde ve Entra'da birden fazla kayıt tutuyorsa OOBE aynı hata döngüsünde takılır. Çözümü ilerideki cihazı kiracıdan tamamen kaldırma bölümünde adım adım verdim; sıralı silme kritiktir. Sıralı silmeden yeni bir kayıt denemek yalnızca aynı hatayı üretir.

Hibrit Entra katılım hatası 0x80070774

0x80070774 yalnızca hybrid Microsoft Entra join Autopilot senaryolarında görülür ve iki temel gerçeği söyler: (1) domain controller'a ulaşılamamıştır ya da (2) Intune Connector for Active Directory'nin kurulu olduğu etki alanı ile hedeflenen bilgisayar hesabı OU'sunun etki alanı eşleşmiyor. ESP profilinden düzeltilebilecek bir hata değildir; altyapı tarafında düzeltilmelidir.

Intune Connector for AD sürüm ve sağlık kontrolü

Konnektör 2026 itibarıyla 6.2501.x.x veya üzeri olmalıdır; eski sürümler bilinen Kerberos ve token yenileme hatalarına sahip. Sunucuda Event Viewer > Applications and Services Logs → Microsoft Intune → ODJConnectorService altında Event ID 30132 "insufficient permissions" için tarama yapın. Konnektörün servis hesabının hedef OU üzerinde Create Computer Objects ve Read All Properties izinleri olması şart.

# Konnektör sunucusunda ODJ olaylarını hızlı özet
Get-WinEvent -LogName 'Microsoft-Intune-Connector/Operational' -MaxEvents 200 |
  Where-Object { $_.Id -in 30132, 30140, 30146 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Etki alanı uyuşmazlığını doğrulama

Bir Intune Connector yalnızca kendi kurulu olduğu etki alanı için ODJ blob üretebilir. Çok etki alanlı bir ormanda her etki alanı için ayrı bir konnektör gerekir. Autopilot deployment profile'daki Computer name template ve Domain Join profile'daki Organizational unit (OU) değerinin, çalışan konnektörün kurulu olduğu etki alanına ait olduğundan emin olun. Konnektörün OOBE sırasında cihaza ulaşamamasının ikinci en yaygın nedeni ise cihazın DNS ile SRV kayıtlarını çözememesidir; ağ ekibinden VLAN ve DHCP option 15/6 yapılandırmasını doğrulamasını isteyin.

Hata 80180026 ve lisans/kayıt kısıtlaması sorunları

Hata 80180026 ("Bir sorun oluştu. Doğru oturum açma bilgilerini kullandığınızı ve kuruluşunuzun bu özelliği kullandığını onaylayın.") tipik olarak MDM otomatik kaydının Azure'da etkin olduğu, ancak eski Intune PC istemcisinin (legacy Intune agent) hâlâ makinede kurulu olduğu durumlarda ortaya çıkar. Ayrıca Autopilot devrelerinde kullanıcının Intune Plan 1 veya Microsoft 365 E3/E5 lisansı yoksa aynı hata dönebilir.

Lisans denetimi tek satırda

# Microsoft Graph PowerShell ile kullanıcının atanmış lisanslarını listele
Connect-MgGraph -Scopes "User.Read.All"
$upn = '[email protected]'
Get-MgUser -UserId $upn -Property AssignedLicenses |
  Select-Object -ExpandProperty AssignedLicenses |
  ForEach-Object { (Get-MgSubscribedSku -SubscribedSkuId $_.SkuId).SkuPartNumber }

Kayıt kısıtlaması cihaz limitini kontrol edin

Kullanıcı başına varsayılan cihaz limiti 5'tir. Sık cihaz değiştiren yöneticiler bu limiti sessizce aşabilir ve 80180026 hatası verir. Intune'da Devices → Enrollment → Device limit restrictions altında ilgili policy'yi denetleyin veya eski cihaz kayıtlarını Entra'dan temizleyin. Active Directory hesap kilitleme sorun giderme rehberinde kullandığımız gibi burada da amaç kök nedeni tek denemede tespit etmektir; tahmin ederek deneme, FCR skorunuzu doğrudan aşağı çeker.

CSV içe aktarma hataları 806 ve 808

806 (ZtdDeviceAlreadyAssigned) içe aktarmaya çalıştığınız cihazın kendi kiracınızda zaten kayıtlı olduğunu, 808 (ZtdDeviceAssignedToOtherTenant) ise cihazın başka bir Microsoft 365 kiracısı için kayıtlı olduğunu söyler. 808, özellikle ikinci el veya Distribütör Reseller'dan gelen yeni cihazlarda karşımıza çıkar.

Hata	Kök Neden	Kim Çözer	Beklenen MTTR
806 (Same tenant)	Karma zaten kiracınızda	Intune yöneticisi (kaydı sil, yeniden içe aktar)	10 dk
808 (Other tenant)	Karma başka bir M365 kiracısına atanmış	Cihazı satan ortak / satıcının Autopilot yöneticisi	1-5 iş günü
Malformed CSV	Excel BOM veya alan sırası bozuk	Analist (yeniden üret, doğrudan Notepad'de aç)	5 dk
ZtdInvalidHash	Karma cihazın gerçek donanımı ile eşleşmiyor	Analist (Get-WindowsAutopilotInfo ile yeniden üret)	15 dk

808 hatası için ortak/satıcıdan cihazı kendi Autopilot listelerinden silmesini isteyin. Microsoft doğrudan başka bir kiracıdaki kaydı sizin adınıza kaldırmaz. Bu SLA riskini önlemek için Purchase Order'a "Autopilot claim removal within 3 business days" maddesi ekletmek benim tercihim.

Get-AutopilotDiagnostics ile tanı ve log toplama

Autopilot arızası hakkında güvenilir tek karar mercii cihazın kendi ürettiği tanı paketidir. Windows 11'in Autopilot Diagnostics sayfası (ESP hata ekranında görünür) veya MDMDiagnosticsTool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -zip ile üretilen ZIP; ancak ben pratikte topluluk aracı Get-AutopilotDiagnostics.ps1'i tercih ediyorum. Çıktısı bileti dört saniyede kapatacak formattadır.

# OOBE sırasında Shift+F10 -> PowerShell (yönetici)
Install-Script -Name Get-AutopilotDiagnostics -Force
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

# Canlı ESP durumunu ve MDM adımlarını renkli göster
Get-AutopilotDiagnostics.ps1 -Online

# Kayıtları toplu ZIP olarak dışa aktar (Level 2 destek için)
MDMDiagnosticsTool.exe -area 'Autopilot;DeviceEnrollment;DeviceProvisioning;TPM' -zip C:\Temp\autopilot-diag.zip

ZIP paketini destek biletine eklerken üç dosyayı özellikle vurguluyorum: MDMDiagReport.html (kayıt/dekayıt zaman çizelgesi), AutopilotDDSZTDFile.json (cihazın gördüğü profil) ve microsoft-windows-user-device-registration-*.evtx (Entra join hata kodları). Sonuncusu 0x80070774 kök neden analizinde vazgeçilmezdir.

Cihazı kiracıdan tamamen kaldırma (doğru silme sırası)

Bayat cihaz kaydı Autopilot biletlerinin en sık tekrarlanan sebebidir. Cihaz üç yerde birden vardır: Intune (managed device), Microsoft Entra ID (device object) ve Windows Autopilot devices. Yanlış sıra ile silinirse hayalet kayıtlar geri gelir. Kabul edilen sıra şudur:

1. Intune → Devices → All devices üzerinden cihazı seçin, Retire ya da Wipe, ardından Delete.
2. Microsoft Entra admin center → Devices → All devices altında aynı cihazı bulun ve silin (device ID ile eşleştirin).
3. Intune → Devices → Windows enrollment → Devices (Autopilot listesi) altındaki karma kaydını silin. Bu adım ZtdDeviceDeleted olayını tetikler ve seri numarasını serbest bırakır.
4. Cihazı sıfırlayın (Reset this PC → Remove everything) ve OOBE'yi yeniden başlatın.

Helpdesk için ölçmeniz gereken metrikler: MTTR ve FCR

Autopilot arızalarının iş etkisi genellikle "bilet sayısı" değil, "yeni işe alım gecikmesi" olarak konuşulur. IT operasyon analisti olarak bu görünürlüğü kazanmak için üç metriği aylık olarak takip ediyorum: kategori bazında MTTR (mean time to resolve), Autopilot alt kategorisi için FCR (first-contact resolution) ve reopen rate (7 gün içinde tekrar açılan bilet oranı). Reopen rate, çözümün gerçekten kök nedene mi yoksa geçici bir düzeltmeye mi işaret ettiğinin en dürüst göstergesidir.

Sonraki ay ne ölçelim?

• Autopilot MTTR (hedef < 90 dk): Kategoriyi "Endpoint Provisioning" alt-etiketi ile bölerek Windows Autopilot, Intune ve ESP timeout ayrı çıkarın.
• Autopilot FCR (hedef ≥ %65): Get-AutopilotDiagnostics ekli biletlerin FCR'sini eklenmemişlerle kıyaslayın. Genellikle 20+ puan fark bulacaksınız, bu aracın kullanıldığı için bir iş vakasıdır.
• Reopen rate (hedef ≤ %8): Yeniden açılan biletlerin %70+ 'ı bayat cihaz kaydı kökenlidir. Silme sıralamasının uygulanmasını ölçün.
• Deferred defect count: 808 hataları için "vendor deregistration pending" bekleyen cihaz sayısı; bu, satın alma sözleşme dilinizi düzeltmeniz gereken açık bir sinyaldir.

Uzun vadede en büyük kaldıraç, tekrarlayan Autopilot arızalarının nedenlerini Windows 11 24H2 BitLocker kurtarma anahtarı döngüsü çözümü gibi diğer endpoint sorunlarının yanına koyup bir "provisioning health" panosunda birleştirmektir. Ayda bir kez ürettiğim bu pano, hem CIO düzeyi karar alıcılar için hem de otomasyon backlog'unu önceliklendirmek için bugüne kadarki en kaldıraçlı çıktım oldu.

Resmi referanslar için Microsoft'un Intune Windows kayıt hataları sorun giderme kılavuzu, Windows Autopilot bilinen sorunlar sayfası ve Autopilot sorun giderme SSS her ayı takip etmeniz gereken üç sayfadır. Microsoft yayın notlarını sessizce güncellediği için bunları RSS ile beslemek pratik bir alışkanlıktır.

Sıkça Sorulan Sorular

Windows Autopilot için hangi lisanslar gereklidir?

Klasik Autopilot senaryoları için asgari Intune Plan 1 lisansı gerekir; genellikle Microsoft 365 E3 veya E5, Microsoft 365 Business Premium ile Enterprise Mobility + Security E3/E5 paketlerinde bulunur. Windows 11 device preparation için ayrıca Microsoft Entra ID P1 gerekir.

Autopilot cihazını Intune'dan nasıl tamamen kaldırırım?

Doğru sıra: Intune'da Retire → Delete, ardından Microsoft Entra admin center'da cihaz nesnesini sil, en son Windows enrollment → Devices altındaki Autopilot karma kaydını sil. Ancak bu sırayla silinirse seri numarası serbest kalır ve OOBE temiz başlar.

ESP zaman aşımını nasıl artırabilirim?

Intune yönetim merkezinde Devices → Windows → Enrollment → Enrollment Status Page altında ilgili profili düzenleyin ve "Show error when installation takes longer than specified number of minutes" alanını (varsayılan 60) artırın. 90-120 dakika büyük görüntü tabanlı Win32 dağıtımları için genellikle yeterlidir; daha yükseği kök soruna işaret eder.

Sanal makinede Windows Autopilot çalışır mı?

Evet, ancak self-deploying mod TPM attestation gerektirir ve çoğu hypervisor'un sanal TPM'i attestation sertifikası sunmaz. En az 2 vCPU ve 4 GB RAM verin; user-driven modda Hyper-V ve Azure VM'ler sorunsuz çalışır, self-deploying için fiziksel cihaz kullanın.

CSV içe aktarma neden 808 hatası veriyor?

808 (ZtdDeviceAssignedToOtherTenant) cihazın karma değerinin başka bir Microsoft 365 kiracısına atanmış olduğunu gösterir. Yalnızca eski sahip veya cihazı satan Microsoft ortağı Autopilot kaydını kendi kiracısından silebilir; sizin tarafınızda çözüm yoktur, satıcıya deregister talebi açın.