Windows Autopilot ESP Takılması: Kayıt Hatası Çözümü (2026)

Özet (TL;DR): Windows Autopilot kurulumunda Enrollment Status Page'in (ESP — kısaca kayıt ekranı; cihazın uygulama ve politika yüklemesini takip eden ilerleme sayfası) takılıp kalmasının dört yaygın kök nedeni vardır: LOB (klasik MSI paket) ile Win32 uygulamalarının aynı anda kurulmaya çalışılması, cihaz saatinin gerçek zamandan sapması, süresi dolmamış görünse de varsayılan 60 dakikalık zaman aşımına yetmeyen uygulama sayısı ve Microsoft Entra hybrid join (şirket içi Active Directory ile bulut kimliğinin birlikte kullanıldığı senaryo) dağıtımlarında beklenen 40 dakikalık ek gecikme. Microsoft'un resmi tanı sırası: önce mdmdiagnosticstool.exe ile günlük dosyası toplamak, ardından Get-AutopilotDiagnostics betiğiyle kök nedeni tek komutla görmek, gerekirse kayıt defterinde (registry) FirstSync ve EnrollmentStatusTracking anahtarlarını incelemek. Bu yazıda belirtilerden hata kodu tablosuna, adım adım çözümden önleyici yapılandırmaya kadar tüm süreci Microsoft'un resmi ESP sorun giderme ve Windows Autopilot bilinen sorunlar sayfalarına dayanarak anlatıyoruz.

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı (2016'dan bu yana) · Uç nokta yönetimi ve modern dağıtım konusunda MD-102/MS-102 sertifikalı danışmanlar. Bu yazıdaki hata kodları, kayıt defteri yolları ve varsayılan değerler Microsoft'un resmi destek dokümantasyonundan alınmıştır; kaynak tarihleri metin içinde belirtilmiştir.

Sabah kontrolünde birden fazla cihaz ESP'de "Setup could not be completed" mesajıyla takılı kaldıysa ve filo dağıtımı gecikiyorsa vakit kaybetmeyin — Xen Bilişim'den ücretsiz teknik görüşme talep edin, Autopilot ortamınızı birlikte 15 dakikada teşhis edelim.

Belirtiler: ESP Takılması Nasıl Görünür?

Windows Autopilot dağıtımında ESP, kullanıcı ilk kez oturum açtıktan sonra uygulamaların, güvenlik politikalarının, sertifikaların ve ağ bağlantılarının kurulumunu izleyen bir ilerleme sayfasıdır. Sorun genelde iki noktada belirir:

• Cihaz kurulumu (device setup) aşamasında donma — ilerleme çubuğu belirli bir yüzdede kalır, "Bu biraz zaman alabilir" mesajı saatlerce değişmez.
• Zaman aşımı hatası — Microsoft'un varsayılan olarak belirlediği 60 dakikalık süre dolduğunda kullanıcıya Setup could not be completed. Please try again or contact your support person for help. mesajı gösterilir (ESP profilinde özel mesaj tanımlanmadıysa bu varsayılan metindir).
• "Identifying" (belirleniyor) aşamasında sonsuz bekleme — cihaz hangi uygulama ve politikaların izleneceğini hesaplarken takılır; bu genelde oturum açan kullanıcıya Intune lisansı atanmamış olmasından kaynaklanır.
• Hesap kurulumu (account setup) aşamasına hiç geçmeme — cihaz kurulumu tamamlanır ama kullanıcıya özel uygulama/politika takibi hiç başlamaz.

İlk teşhis adımı her zaman şudur: sorun tek bir cihaza mı özgü, yoksa aynı anda dağıtılan tüm filoyu mu etkiliyor? Toplu bir donma genelde paylaşılan bir nedene (ağ, zaman aşımı süresi, karma uygulama tipi) işaret ederken, tekil bir cihaz sorunu donanım veya yerel yapılandırmaya özgü olabilir.

Hata Kodları ve Kayıt Defteri Eşleme Tablosu

Microsoft'un resmi Windows Autopilot bilinen sorunlar sayfasında listelenen hata kodları ve anlamları:

Hata kodu / mesaj	Anlamı	İlk kontrol
0x800705B4	Genel zaman aşımı; self-deploying modda en sık neden cihazın TPM 2.0 destekli olmaması (ör. sanal makine)	Fiziksel TPM 2.0 kontrolü, sanal makinede self-deploying kullanılmamalı
0x801c03ea	TPM doğrulaması (attestation) başarısız, cihaz Microsoft Entra ID'ye token ile katılamıyor	TPM ürün yazılımı güncel mi kontrol et
0xc1036501	Cihaz otomatik MDM kaydı yapamıyor — Microsoft Entra ID'de birden fazla MDM yapılandırması var	Entra ID Mobility (MDM/WIP) ayarlarında çakışan sağlayıcı ara
0x80004005	Microsoft Entra hybrid join dağıtımlarında zaman aşımı (Şubat 2026'da eklenen bilinen sorun)	İlgili Windows kümülatif güncellemesini uygula (aşağıda detay)
0x80180014	Cihaz daha önce Autopilot ile dağıtılmış, Intune'daki eski cihaz kaydı silinmeden yeniden dağıtılmaya çalışılıyor	Intune'da cihaz kaydını sil, Autopilot Devices listesinden kaldır
"Another installation is in progress, please try again later"	LOB (MSI) ve Win32 uygulaması aynı anda TrustedInstaller'ı kullanmaya çalışıyor, çakışma yaşanıyor	ESP profilinde LOB ve Win32 uygulamalarını karıştırma
0x81039001 / 0x81039023 / 0x81039024	TPM doğrulama denemesi aşıldı veya bilinen TPM güvenlik açığı tespit edildi	OEM'den TPM ürün yazılımı güncellemesi iste

Kayıt defterinde (registry) ESP'nin aldığı ayarları görmek için HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync anahtarına bakın — burada SkipUserStatusPage veya SkipDeviceStatusPage değeri 0xffffffff ise, bir yönetici özel bir OMA-URI (cihaz yönetim politikası kanalı) ile ilgili ESP aşamasını bilerek atlatmış demektir.

Hızlı Tanı: Microsoft'un Resmi Tanılama Araçları

Kök nedeni tahmin etmeye çalışmadan önce Microsoft'un sunduğu iki resmi araçla veriye dayalı teşhis yapın:

1) MDM Diagnostics Tool ile günlük toplama

OOBE (out-of-box experience — cihazın ilk açılış deneyimi) ekranında S mode dışı bir cihazda Shift+F10 ile komut istemini açın, ardından senaryoya göre şu komutu çalıştırın:

# Kullanıcı odaklı (user-driven) dağıtım için:
mdmdiagnosticstool.exe -area Autopilot -cab C:\autopilot-diag.cab

# Self-deploying, white glove veya fiziksel cihaz senaryoları için:
mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\autopilot-diag.cab

Oluşan .cab dosyasındaki MDMDiagReport_RegistryDump.Reg dosyası, MDM kaydına ilişkin tüm kayıt defteri anahtarlarını (enrollment bilgisi, Autopilot profil ayarları, izlenen uygulamalar) içerir.

2) Get-AutopilotDiagnostics betiği ile otomatik analiz

Topladığınız .cab dosyasını elle didiklemek yerine, PowerShell Gallery'deki resmi betikle saniyeler içinde okunabilir bir özet alın:

Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -CABFile C:\autopilot-diag.cab

Bu betik hangi uygulamanın başarısız olduğunu, hangi aşamada takıldığını ve varsa hata kodunu doğrudan ekrana yazar — Event Viewer'da tek tek olay arama ihtiyacını büyük ölçüde azaltır.

3) EnrollmentStatusTracking anahtarını kontrol edin

Windows 10, sürüm 1903 ile gelen EnrollmentStatusTracking CSP'si (cihaz yönetim politikası kanalı), her uygulamanın kurulum durumunu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking altına yazar. Device\Setup\Apps\Tracking\Sidecar\Win32App_{AppID} alt anahtarındaki InstallationState değeri 4 (Error) ise, ESP o uygulamada durmuş demektir — hangi paketin sorunlu olduğunu Intune Management Extension günlüklerinden doğrulayın.

Kök Neden Analizi: Beş Ana Senaryo

Microsoft'un resmi dokümantasyonunu esas aldığımızda, ESP takılmasının neredeyse her zaman şu beş kategoriden birine indiği görülür:

1) LOB (MSI) ve Win32 uygulaması aynı ESP profilinde karışmış

Hem LOB (per-machine MSI paketleri) hem Win32 yükleyicileri, Windows'un TrustedInstaller bileşenini kullanır ve bu bileşen eşzamanlı kuruluma izin vermez. OMA-DM ajanı bir MSI kurulumu başlatırken Intune Management Extension eklentisi aynı anda bir Win32 uygulaması kurmaya çalışırsa, ikinci kurulum "Another installation is in progress, please try again later" hatasıyla başarısız olur ve ESP durur.

2) Cihaz saati gerçek zamandan sapmış

Gerçek zamanlı saatin (real-time clock) birkaç dakika veya daha fazla sapması, hem TPM doğrulamasını hem ESP zaman aşımı hesaplamasını bozabilir. Bu özellikle uzun süre depoda bekleyen veya pil boşalmış cihazlarda görülür.

3) Zaman aşımı süresi, uygulama sayısına yetmiyor

Varsayılan zaman aşımı 60 dakikadır. 20 zorunlu uygulama, ortalama 3 dakikalık kurulum süresiyle zaten bu sınıra dayanır. ESP zaman aşımına uğradığında bu her zaman bir "hata" değil, çoğunlukla planlama eksikliğidir.

4) Microsoft Entra hybrid join dağıtımında beklenen ek gecikme

Hybrid Microsoft Entra join (şirket içi Active Directory ile bulut kimliğinin bağlı çalıştığı model) dağıtımlarında ESP, profildeki zaman aşımı değerine ek olarak yaklaşık 40 dakika daha sürebilir — bu, şirket içi AD bağlayıcısının (on-premises AD connector) yeni cihaz kaydını Microsoft Entra ID'ye işlemesi için gereken süredir. 30 dakikalık bir zaman aşımı ayarladıysanız, gerçek süre 70 dakikaya kadar çıkabilir; bu bir arıza değil, bilinen bir mimari sınırlamadır.

5) Microsoft 365 Apps veya paket içi yeniden başlatma çakışması

Microsoft 365 Apps, Intune'a "Microsoft 365 Apps (Windows 10 and later)" uygulama tipiyle eklenip ESP tarafından izlendiğinde, başka bir izlenen Win32 uygulamasının kurulumu sırasında devreye girerse ESP askıda kalabilir. Benzer şekilde, bir uygulama paketinin içine gömülü yeniden başlatma (reboot) komutu da ESP'yi kilitleyebilir — yeniden başlatma davranışı paket içinde değil, Intune'daki dönüş kodu (return code) ayarında tanımlanmalıdır.

Adım Adım Çözüm (En Kolaydan En Zora)

Adım 1 — Saat senkronunu doğrulayın

1. OOBE ekranında Shift+F10 ile komut istemini açın.
2. Kablolu veya kablosuz ağ bağlantısını doğrulayın.
3. Aşağıdaki komutla saati varsayılan zaman sunucusuyla (time.windows.com) senkronlayın:

w32tm /resync /force

Bu, en hızlı ve en sık gözden kaçan adımdır — özellikle depoda uzun süre bekleyen cihazlarda TPM doğrulama ve ESP zaman aşımı hatalarının kökeninde sıkça bu vardır.

Adım 2 — Resmi tanı araçlarıyla kök nedeni doğrulayın

Yukarıdaki "Hızlı Tanı" bölümündeki mdmdiagnosticstool.exe ve Get-AutopilotDiagnostics adımlarını uygulayın. Bu adım, sonraki adımlarda doğru yola gitmenizi sağlar — kör tahminle zaman kaybetmeyin.

Adım 3 — LOB/Win32 karışıklığını giderin

Tanı çıktısında "Another installation is in progress" hatası görüyorsanız, ESP profiline atanan uygulama listesini gözden geçirin:

• Aynı ESP kapsamında hem LOB (MSI) hem Win32 uygulaması varsa, birini diğer tipe dönüştürün veya kurulumu ESP dışına (ESP tamamlandıktan sonra) alın.
• Karma kurulum gerçekten zorunluysa, ESP kullanmayan Windows Autopilot device preparation modelini değerlendirin — bu model LOB ve Win32 karışımını destekler.

Adım 4 — Zaman aşımı süresini gerçekçi hale getirin

1. Intune admin center'da Devices > Enrollment > Enrollment Status Page profiline girin.
2. Show an error when installation takes longer than specified number of minutes alanını, zorunlu uygulama sayısına ve ortalama kurulum süresine göre yeniden hesaplayın (kural: uygulama sayısı × ortalama kurulum dakikası + %30 pay).
3. Hybrid Entra join kullanıyorsanız bu hesaba ayrıca 40 dakikalık bilinen gecikmeyi ekleyin.

Adım 5 — Uygulama kurulum sırasını sadeleştirin

Microsoft 365 Apps'i ESP'de izliyorsanız, uygulama tipini "Microsoft 365 Apps" yerine Win32 tipiyle paketleyip dağıtmayı deneyin — bu, ESP hanginde en sık karşılaşılan çakışmayı ortadan kaldırır. Paket içine gömülü yeniden başlatma komutlarını kaldırıp, yeniden başlatma davranışını Intune'daki uygulama dönüş kodu ayarlarına taşıyın.

Adım 6 — Temiz yeniden dağıtım (önceki adımlar çözmediyse)

1. Intune admin center'da cihaz kaydını (Devices > All devices) silin.
2. Devices > Windows Autopilot > Devices listesinden cihazı kaldırın (deregister).
3. Cihazı sıfırlayın, OOBE'ye geri döndürün.
4. Autopilot servisinin yeniden kaydı algılaması için birkaç dakika bekleyip dağıtımı tekrar başlatın.

Bu adım özellikle 0x80180014 hatasında (cihaz daha önce dağıtılmış ve eski kayıt temizlenmeden yeniden denenmiş) zorunludur.

Bu adımları ortamınızda tek başınıza yürütmek yerine bir uzmanla birlikte gözden geçirmek isterseniz WhatsApp'tan Xen Bilişim'e yazın, 15 dakikalık ücretsiz teknik görüşmede filo dağıtımınızı birlikte inceleyelim.

Senaryoya Özel Dallar

User-driven mi, self-deploying/pre-provisioned mi? Self-deploying ve pre-provisioned (teknisyen ön hazırlığı) modlarda TPM 2.0 zorunludur; 0x800705B4 ve TPM tabanlı hatalar bu modlara özgüdür. User-driven modda böyle bir zorunluluk yoktur, sorunlar genelde uygulama kurulumu veya kimlik doğrulama kaynaklıdır.

Microsoft Entra join mi, hybrid join mi? Saf bulut (Entra join) dağıtımlarda 40 dakikalık ek gecikme yaşanmaz; sorun varsa doğrudan uygulama/ağ katmanındadır. Hybrid join'de ise önce bu bilinen gecikmeyi hesaba katıp gerçek bir zaman aşımı olup olmadığını ayırt edin — panik yapmadan önce süreyi doğru ölçün.

Tek cihaz mı, tüm filo mu? Tek cihaz sorunluysa donanım (TPM ürün yazılımı, saat sapması) veya o cihaza özgü uygulama hedeflemesi araştırılmalı. Aynı anda birden fazla cihaz etkileniyorsa kök neden hemen her zaman paylaşılan bir ayardır: zaman aşımı süresi, ESP profilindeki uygulama listesi veya ağ/güvenlik duvarı kısıtı.

Yönetici Tarafı Kontroller ve Destek Talebi Hazırlığı

• Zorunlu uygulama listesini gözden geçirin: ESP profilindeki "Block device use until these required apps are installed" listesini yalnızca gerçekten kritik uygulamalarla sınırlı tutun; geri kalanını ESP tamamlandıktan sonra arka planda dağıtın.
• Uygulamaların doğru şekilde hedeflendiğini doğrulayın: ESP'nin bir uygulamayı izleyebilmesi için uygulamanın zorunlu (required) atamayla, cihaz bağlamında ve kullanıcı bağlamı kısıtlaması olmadan hedeflenmiş olması gerekir.
• ESP profilini devre dışı bırakmanın yetmeyebileceğini bilin: Microsoft'un resmi dokümantasyonuna göre bir ESP profilini devre dışı bırakmak, politikayı cihazdan/kullanıcıdan otomatik kaldırmaz — kullanıcılar ilk oturum açışta ESP'yi görmeye devam edebilir.
• Kullanıcı bağlamında çalışan betikleri kontrol edin: "Run this script using the logged on credentials" seçeneği Yes olan PowerShell betikleri ESP sırasında hiç çalışmayabilir; ESP'de kullanılacak betikleri Sistem (System) bağlamında (bu seçeneği No yaparak) çalıştırın.
• Destek talebi açacaksanız: Microsoft destek talebine mdmdiagnosticstool.exe ile ürettiğiniz .cab dosyasını, Get-AutopilotDiagnostics çıktısının ekran görüntüsünü ve etkilenen cihaz(lar)ın seri numarasını ekleyin — bu, çözüm süresini belirgin şekilde kısaltır.

Önleyici Kontroller

• ESP profilini kurmadan önce uygulama tiplerini planlayın: Aynı profilde LOB (MSI) ve Win32'yi asla karıştırmayın; standart olarak Win32'yi tercih edin.
• Zaman aşımını gerçek veriyle hesaplayın: Pilot dağıtımda uygulamaların gerçek kurulum süresini ölçün, üretime geçmeden zaman aşımını buna göre ayarlayın.
• Saat senkronunu otomasyona alın: Depoda uzun süre bekleyen cihaz filolarında, dağıtım öncesi bir kontrol listesine w32tm /resync /force adımını ekleyin.
• Microsoft 365 Apps'i Win32 tipiyle dağıtın: ESP tarafından izlenen ortamlarda "Microsoft 365 Apps" tipini değil Win32 paketleme yolunu tercih edin.
• Yeniden başlatma davranışını pakete gömmeyin: Her zaman Intune'daki dönüş kodu ayarlarını kullanın, uygulamanın kendi yükleyicisinin tetiklediği reboot'a güvenmeyin.
• Hybrid join kullanıyorsanız 40 dakikalık payı standart hale getirin: Zaman aşımı hesaplamalarınıza bu bilinen gecikmeyi varsayılan olarak ekleyin, her seferinde yeniden keşfetmeyin.

Türkiye'deki Filo Dağıtımlarında Dikkat Edilmesi Gerekenler

Türkiye'de Casper, Monster gibi yerli OEM'lerden (orijinal donanım üreticisi) alınan cihazlarda hardware hash'in (donanım parmak izi) otomatik olarak Autopilot servisine yüklenmediği durumlarla sık karşılaşılır — bu OEM'ler her zaman doğrudan Microsoft Partner Center entegrasyonuna sahip olmayabilir. Bu durumda hash'i Get-WindowsAutopilotInfo betiğiyle manuel toplayıp CSV ile içe aktarmanız gerekebilir; bu adım atlandığında cihaz Autopilot profilini hiç almaz ve ESP'ye normal OOBE akışıyla girer, "takılma" değil "hiç görünmeme" sorunu yaşarsınız.

Kurumsal ağlarda Türk Telekom veya Turkcell üzerinden giden kurumsal internet bağlantılarında derin paket denetimi (deep packet inspection) yapan güvenlik duvarları, Autopilot ve Intune uç noktalarını (*.manage.microsoft.com, ztd.dds.microsoft.com) yanlışlıkla engelleyebilir; ESP zaman aşımına uğradığında önce bu noktaların istisna listesinde olduğunu doğrulayın. Ayrıca Türkçe karakter içeren kullanıcı adı veya cihaz adı şablonlarında (ör. %USERNAME% içinde ş/ğ/ı/ö/ç/ü geçen hesaplar) bazı eski görüntü şablonlarında kodlama sorunları görülebiliyor — cihaz adı şablonunu yalnızca ASCII karakterlerle (seri numarası, departman kodu) kurmanızı öneririz.

Son olarak, ESP sırasında toplanan tanı günlükleri (.cab dosyaları) cihaz donanım kimliği ve kullanıcı UPN'i gibi kişisel verilenler içerebilir; bu dosyaları Microsoft destek talebine eklerken veya iç arşivde saklarken KVKK (Kişisel Verilerin Korunması Kanunu) 6698 sayılı kanun madde 12 kapsamındaki "gerekli teknik tedbir" yükümlülüğünü göz önünde bulundurun — günlük dosyalarını sınırlı erişimli bir klasörde tutmak ve gereksiz süre saklamamak yeterli bir başlangıç noktasıdır.

Saha Vakası: 60 Kişilik Üretim Firmasında Toplu ESP Zaman Aşımı

Firma X — 60 kişilik üretim/lojistik firması — yeni dizüstü filosu, hibrit çalışma modeline geçiş

Bir üretim firması, saha ve ofis çalışanları için 60 yeni dizüstü bilgisayarı Windows Autopilot user-driven modda dağıtıma aldı. İlk parti 15 cihazın 11'i ESP'de "Setup could not be completed" hatasıyla takıldı; kalan 4'ü sorunsuz tamamlandı. İlk bakışta rastgele görünen bu dağılım, ekibin dikkatini paylaşılan bir nedene değil, uygulama bazlı bir nedene yöneltti.

Süre: Teşhis ve kalıcı çözüm toplam 2,5 saat sürdü (ilk parti sonrası, kalan 45 cihaz için önlem alınarak). Karar noktaları: (1) Get-AutopilotDiagnostics çıktısında başarısız cihazların tamamında aynı LOB muhasebe yazılımının kurulumu sırasında durduğu görüldü; (2) ESP profilinde bu LOB (MSI) uygulamasının, aynı anda izlenen bir Win32 güvenlik ajanıyla çakıştığı doğrulandı; (3) LOB uygulaması Win32 formatına yeniden paketlenip test edildi; (4) kalan 45 cihazlık partiye güncellenmiş paket ve %30 pay eklenmiş yeni bir zaman aşımı değeriyle devam edildi. Sonuç: Kalan 45 cihazın tamamı ilk denemede sorunsuz tamamlandı, proje takvimi bir günlük gecikmeyle kurtarıldı. Xen ekibinin rolü: Uzaktan tanı, paket yeniden yapılandırma ve ESP profil ayarlarının kalıcı olarak güncellenmesi. Uyarı: LOB ve Win32 uygulamalarını aynı ESP profilinde karıştırmadan önce pilot bir grupta mutlaka test edin — sorun üretime geçtikten sonra çok daha maliyetli hale gelir.

Windows ve uç nokta yönetimi hizmetlerimizi inceleyin veya filo dağıtımınızın ücretsiz ön değerlendirmesini talep edin.

Benzer Hatalarla Farkı

ESP takılmasını, sık karıştırılan komşu senaryolardan ayırmak zaman kazandırır:

• Windows Autopilot ile sıfır dokunuş cihaz kaydı — bu yazı kurulumun tamamını (lisans, hardware hash, deployment profile, ESP yapılandırma) baştan anlatır; elinizde zaten çalışan bir kurulum varsa ve yalnızca ESP takılıyorsa doğrudan bu makaledeki tanı adımlarına odaklanın.
• Windows 365 Cloud PC kurulumu — görünüşte benzer bir "bulut cihazı hazır olmuyor" şikayeti üretir, ama Windows 365'te ESP değil sağlayıcı (provisioning) süreci devrededir; kök neden neredeyse hiç LOB/Win32 çakışması değil, genelde lisans ataması veya ağ profili eksikliğidir.
• Sıradan bir Intune kayıt hatası (MDM enrollment failed) — ESP'ye hiç girmeden, cihaz Intune'a kaydolamadan başarısız oluyorsa sorun ESP katmanında değil, kimlik doğrulama veya MDM kapsamı (scope) ayarındadır; bu makaledeki adımlar bu aşamaya kadar gelmemiş bir cihaz için geçerli değildir.

Sıkça Sorulan Sorular (SSS)

ESP'nin varsayılan zaman aşımı süresi kaç dakikadır?

Microsoft'un varsayılan değeri 60 dakikadır. Bu süre Intune admin center'daki ESP profilinde "Show an error when installation takes longer than specified number of minutes" ayarından değiştirilebilir; zorunlu uygulama sayısı arttıkça bu değerin de yükseltilmesi gerekir.

ESP'de "Another installation is in progress" hatası neden çıkar?

Bu hata, aynı ESP profilinde hem LOB (MSI) hem Win32 tipi uygulamaların aynı anda kurulmaya çalışılmasından kaynaklanır. Her iki tip de Windows'un TrustedInstaller bileşenini kullanır ve bu bileşen eşzamanlı kuruluma izin vermez. Çözüm, iki tipi aynı profilde karıştırmamak veya ESP kullanmayan Windows Autopilot device preparation modeline geçmektir.

Microsoft Entra hybrid join dağıtımında ESP neden daha uzun sürüyor?

Hybrid join dağıtımlarında ESP, profildeki zaman aşımı değerine ek olarak yaklaşık 40 dakika daha sürebilir; bu süre, şirket içi Active Directory bağlayıcısının yeni cihaz kaydını Microsoft Entra ID'ye işlemesi için gereklidir. Bu bir arıza değil, Microsoft'un belgelediği bilinen bir mimari sınırlamadır.

Cihaz saati ESP takılmasına gerçekten neden olabilir mi?

Evet. Gerçek zamanlı saatin birkaç dakika veya daha fazla sapması hem TPM doğrulamasını hem ESP'nin zaman aşımı hesaplamasını bozabilir. OOBE ekranında Shift+F10 ile açılan komut isteminde w32tm /resync /force komutuyla saati senkronlamak, en hızlı ve en sık gözden kaçan çözüm adımıdır.

ESP profilini devre dışı bırakırsam kullanıcılar ESP'yi görmeye devam eder mi?

Evet, görebilir. Microsoft'un resmi dokümantasyonuna göre bir ESP profilini devre dışı bırakmak, politikayı otomatik olarak cihaz veya kullanıcıdan kaldırmaz; ilk oturum açışta kullanıcı yine ESP ile karşılaşabilir. Kalıcı olarak kaldırmak için profil atamasını ve öncelik sırasını birlikte gözden geçirin.

Get-AutopilotDiagnostics betiğini nasıl kurarım?

PowerShell Gallery üzerinden resmi olarak dağıtılır. Install-Script -Name Get-AutopilotDiagnostics -Force komutuyla kurup, mdmdiagnosticstool.exe ile ürettiğiniz .cab dosyasını Get-AutopilotDiagnostics -CABFile <dosyaYolu> komutuna vererek okunabilir bir tanı özeti alabilirsiniz.

Sorunu kendimiz çözemezsek Microsoft desteğine mi, iş ortağımıza mı başvurmalıyız?

Bu yazıdaki adımlar sonuç vermezse iki yol da geçerlidir: Microsoft destek kaydı açabilir (yukarıdaki .cab dosyasını ve tanı çıktısını eklemeniz istenecektir) veya Microsoft Kayıtlı İş Ortağınızdan (Xen Bilişim gibi) uzaktan teşhis desteği alabilirsiniz. İkincisi genelde daha hızlıdır çünkü ortamınıza ve önceki yapılandırmanıza zaten aşinadır.

Sonuç: Sistemli Tanı, Tek Seferde Kalıcı Çözüm

Windows Autopilot ESP takılması, ilk bakışta belirsiz bir "kurulum donuyor" şikayeti gibi görünse de arkasındaki nedenler Microsoft'un resmi dokümantasyonunda net biçimde tanımlanmıştır: karışık uygulama tipi, saat sapması, yetersiz zaman aşımı süresi veya hybrid join'e özgü beklenen gecikme. Doğru sırayla ilerlemek — önce mdmdiagnosticstool.exe ve Get-AutopilotDiagnostics ile veri toplamak, sonra kök nedene özel çözümü uygulamak — çoğu vakada birkaç saat içinde kalıcı sonuç verir.

Asıl değer, sorunu her filo dağıtımında yeniden keşfetmek yerine önlemektir: uygulama tipi planlaması, gerçekçi zaman aşımı hesaplaması ve pilot test disiplini kurulduğunda ESP neredeyse hiç sorun çıkarmaz hale gelir. Türkiye'deki kurumlar için buna OEM hash entegrasyonu, kurumsal ağ istisnaları ve tanı günlüklerinin KVKK'ya uygun saklanması gibi yerel bir katman da eklenmeli.

Ortamınızda Windows Autopilot kurulumu, ESP yapılandırması veya bu tür kesintilerin önlenmesi için destek arıyorsanız, uç nokta güvenliği ve yönetimi hizmetlerimize göz atabilir ya da doğrudan bize yazabilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Windows Autopilot benimseme ve kesintisiz filo dağıtımı yolculuğunda kurulumdan tanıya, önleyici yapılandırmadan olay müdahalesine kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.