Windows Autopilot’ta Self-Deploying Mode ve Pre-Provisioning ilk bakışta aynı işi yapıyor gibi görünür. Her iki senaryoda da TPM 2.0 ve device attestation kullanılır, cihaz Enrollment Status Page (ESP) ile provisioning tamamlanana kadar bekletilir ve kurulumun önemli bölümü OOBE sırasında gerçekleşir.
Asıl fark, cihazı kimin hazırladığı ve cihazın sonunda bir kullanıcıyla mı yoksa yalnızca cihaz kimliğiyle mi çalışacağıdır. Self-Deploying Mode, kullanıcı girişi olmadan kiosk, dijital tabela veya shared device hazırlamak için kullanılır. Pre-Provisioning ise IT, OEM veya reseller tarafından önceden hazırlanan ve daha sonra belirli bir kullanıcıya teslim edilen kurumsal cihazlar içindir.
Bu farkı bilmeden profil seçmek, özellikle primary user, Microsoft Entra hybrid join, uygulama hedefleme ve ESP davranışı tarafında beklenmedik sonuçlara yol açabilir. Aşağıda iki modun aynı görünen parçalarının nerede ayrıldığını inceleyeceğiz.
Key Takeaways
- Self-Deploying Mode kullanıcıya bağlı olmayan cihazlar içindir ve yalnızca Microsoft Entra join’i destekler.
- Pre-Provisioning, user-driven deployment’ın Technician Flow ve User Flow olarak iki zamana bölünmüş halidir.
- Her iki mod da fiziksel TPM 2.0 ve device attestation destekli cihaz ister; sanal TPM yeterli değildir.
- Pre-Provisioning’de cihaz kullanıcıya teslim edilmeden önce device-targeted uygulamalar ve policy’ler kurulabilir.
İçindekiler
Self-Deploying ve Pre-Provisioning Kısa Karşılaştırma
İki senaryonun ortak noktası Windows Autopilot servisi, Intune atamaları, TPM tabanlı cihaz doğrulaması ve ESP’dir. Buna rağmen deployment profile içinde seçilen mod, OOBE’nin kimlik doğrulama ve teslimat şeklini tamamen değiştirir.
| Özellik | Self-Deploying Mode | Pre-Provisioning |
|---|---|---|
| Temel kullanım | Kiosk, dijital tabela, shared device | Tek kullanıcıya verilecek kurumsal cihaz |
| Deployment profile | Deployment mode: Self-deploying | Deployment mode: User-driven, pre-provisioning izni açık |
| Kullanıcı girişi | Deployment sırasında gerekmez | User Flow sırasında kullanıcının girişi gerekir |
| Hazırlayan | Cihaz kendi provisioning akışını yürütür | IT, OEM veya reseller Technician Flow’u yürütür |
| Microsoft Entra join | Microsoft Entra join | Microsoft Entra join veya Microsoft Entra hybrid join |
| Primary user | Otomatik atanmaz | User Flow sırasında kullanıcı cihazla ilişkilendirilir |
| TPM 2.0 | Gerekli | Gerekli |
| Sanal makine | Desteklenmez | Desteklenmez |
| Kullanıcı bekleme süresi | En kısa deneyim, çünkü kullanıcı ESP’si yoktur | Teknisyen device ESP’yi tamamladığı için kısalır |
Self-Deploying Mode Hangi Problemi Çözer?
Self-Deploying Mode cihazın bir kullanıcı tarafından kurulmasını beklemez. Windows Autopilot profili cihaza uygulandıktan sonra cihaz Microsoft Entra ID’ye katılır, Intune’a enroll olur ve device-targeted policy ile uygulamaları alır. Ethernet bağlantısında kullanıcı etkileşimi gerekmeyebilir. Wi-Fi kullanılan cihazlarda dil, bölge, klavye ve ağ seçimi gibi OOBE adımları görülebilir.
Bu modelde kullanıcı kimlik bilgisi yerine cihazın TPM 2.0 donanımı kullanılır. Bu yüzden cihazda atanmış bir kullanıcı bulunması beklenmez. Microsoft, self-deploying senaryosunu kiosk, dijital tabela ve birden fazla kişinin kullandığı cihazlar için konumlandırır.
Provisioning tamamlandığında cihaz normal sign-in ekranında bırakılabilir. Kiosk veya dijital signage policy’siyle local account ve automatic logon yapılandırılmışsa cihaz otomatik olarak bu hesaba giriş yapabilir.
Self-Deploying Mode ile ilgili önemli sınırlar
- Microsoft Entra hybrid join desteklenmez.
- Intune primary user’ı otomatik olarak ayarlamaz.
- Kullanıcıya atanmış Company Portal uygulamaları, primary user olmadığı için beklenen şekilde sunulmayabilir.
- Self-deploying deployment sırasında kullanıcı ESP’si çalışmaz.
- TPM 2.0 veya attestation desteği yoksa sanal makineler dahil deployment başarısız olur.
Self-Deploying Mode’da neden hybrid join yok?
Microsoft Entra hybrid join cihazın on-premises Active Directory domain’ine katılmasını ve daha sonra Microsoft Entra ID’ye kaydolmasını gerektirir. Bu işlem domain controller erişimi ve kullanıcı veya cihaz tarafında ek bir domain akışı ister. Self-Deploying Mode ise kullanıcı girişi olmadan cihazın kendi kimliğiyle tamamlanacak şekilde tasarlanmıştır. Bu nedenle Self-Deploying Mode yalnızca Microsoft Entra joined cihazları destekler.
Pre-Provisioning Ayrı Bir Deployment Mode mu?
Pre-Provisioning, Self-Deploying Mode’un kullanıcı cihazları için kullanılan başka bir adı değildir. Profilin temel deployment mode’u User-driven olarak kalır. OOBE sayfalarında pre-provisioned deployment’a izin veren ayar açılır. Bu nedenle Pre-Provisioning’in tamamı user-driven senaryonun üzerine kuruludur.
Microsoft Entra join ve Microsoft Entra hybrid join için pre-provisioned senaryolar bulunur. Ancak Microsoft yeni cihazların mümkün olduğunda cloud-native olarak Microsoft Entra join ile dağıtılmasını önerir. Hybrid join, on-premises Active Directory bağımlılığı devam eden ortamlar için kullanılabilir.
TPM 2.0 ve Device Attestation Akıştaki Yeri
Self-Deploying Mode’da TPM, cihazın Microsoft Entra tenant’ına kullanıcı olmadan katılabilmesi için kullanılır. Pre-Provisioning’de ise aynı mekanizma Technician Flow’un kullanıcıdan bağımsız çalışmasını sağlar. İki senaryoda da TPM 2.0 donanımı ve device attestation desteği gerekir.
Hyper-V virtual TPM dahil olmak üzere sanal TPM’ler bu senaryolar için desteklenmez. Uygun olmayan bir cihazda deployment, TPM doğrulama aşamasında 0x800705B4 timeout hatasıyla sonlanabilir. Ayrıca TPM sağlayıcısının attestation servislerine erişim için gerekli HTTPS bağlantıları firewall veya proxy tarafından engellenmemelidir.
Cihaz tarafında ilk kontrol için aşağıdaki PowerShell komutu kullanılabilir:
Get-Tpm | Select-Object TpmPresent, TpmReady, ManagedAuthLevel, ManufacturerIdTxt, ManufacturerVersionBu komut TPM’nin Windows tarafından görülüp görülmediğini ve hazır olup olmadığını gösterir. Ancak bu çıktı tek başına Autopilot attestation’ın başarılı olacağını garanti etmez. OEM firmware sürümü, TPM üreticisi ve gerekli ağ erişimi de ayrıca kontrol edilmelidir.
Technician Flow: Pre-Provisioning Nerede Gerçekleşir?
Pre-Provisioning’in ayırıcı kısmı Technician Flow’dur. Bu akışı IT çalışanı, OEM veya reseller çalıştırabilir. Cihaz ilk OOBE ekranındayken Windows tuşuna beş kez basılır ve Windows Autopilot provisioning veya Windows sürümüne göre Pre-provision with Windows Autopilot seçilir.
Windows Autopilot Configuration ekranında atanan profile, organization name, varsa assigned user ve cihazı Intune’da aramak için kullanılabilecek QR kod gösterilir. Bilgiler güncellendiyse Refresh ile profile yeniden indirilebilir. Ardından Provision seçilerek Technician Flow başlatılır.
Technician Flow sırasında device ESP çalışır. Cihaza atanan device policy’ler, sertifikalar, security template’ler, network profile’lar ve uygun uygulamalar bu aşamada işlenir. Win32 veya LOB uygulamanın bu aşamada kurulabilmesi için uygulamanın device context’te çalışacak şekilde yapılandırılmış olması gerekir. Uygulama cihaza veya cihaza önceden atanmış kullanıcıya atanmış olmalıdır.
Başarılı akışın sonunda Reseal seçilir ve cihaz kapatılır. Böylece kullanıcı cihazı aldığında kurulumun zaman alan bölümü daha önce tamamlanmış olur. Technician Flow başarısızsa ekrandan tanılama logları toplanabilir ve cihaz resetlenerek işlem tekrarlanabilir.
User Flow: Kullanıcı Cihazı Aldığında Ne Olur?
Technician Flow tamamlandıktan ve cihaz reseal edildikten sonra kullanıcı normal user-driven Autopilot deneyimini görür. Kullanıcı gerekiyorsa dil, bölge ve klavye seçeneklerini belirler, ağa bağlanır ve Microsoft Entra join senaryosunda kendi Microsoft Entra kimlik bilgileriyle oturum açar.
Hybrid join kullanılıyorsa domain controller erişimi gerekir. Cihaz yeniden başladıktan sonra Active Directory kimlik bilgileri istenebilir. Bu nedenle OEM veya reseller tarafından çalıştırılan hybrid join Technician Flow’unun domain controller erişimi gerektiren bölümü kullanıcı tarafına bırakılır.
User Flow sırasında device ESP yeniden çalışabilir. Bunun amacı Technician Flow’dan sonra cihaza atanmış yeni device policy veya uygulamaların kontrol edilmesidir. Daha sonra User ESP account setup fazında kullanıcıya atanmış policy ve uygulamalar işlenir. Bu aşamalar tamamlanmadan masaüstüne geçiş ESP ayarlarıyla engellenebilir.
Microsoft, test senaryolarında Technician Flow ile User Flow arasında en az 90 dakika beklenmesini önerir. Ayrıca User Flow’un Technician Flow’dan sonraki altı ay içinde çalıştırılması gerekir. Daha uzun bekleme, IME tarafından kullanılan sertifikaların geçerliliğiyle ilgili sorunlara ve Win32 application detection hatalarına yol açabilir.
Technician Flow sonrasında cihaz Microsoft Entra tarafında compliant görünebilir. User Flow başladığında compliance yeniden değerlendirildiği için durum geçici olarak değişebilir. Yeni kullanıcı oturumu ve policy değerlendirmesi tamamlandıktan sonra raporlama durumunun güncellenmesi beklenmelidir.
ESP İki Modda Nasıl Farklı Çalışır?
ESP’nin amacı cihaz provisioning sürerken ilerlemeyi göstermek ve yapılandırma tamamlanmadan masaüstüne geçişi engellemektir. ESP, device ESP ve User ESP olarak iki ana bölümden oluşur. Device ESP cihaz policy’lerini ve device-context uygulamaları takip eder. User ESP kullanıcı hesabı, user policy’leri ve user-context uygulamaları takip eder.
Self-Deploying Mode’da atanmış bir kullanıcı olmadığı için User ESP’nin kullanıcıya özel bölümü deployment’ın parçası değildir. Cihaz device ESP’de beklenen uygulama ve policy’leri tamamlar, ardından kiosk, shared device veya sign-in ekranına geçer.
Pre-Provisioning’de Technician Flow device ESP’nin önemli bölümünü önden tamamlar. User Flow sırasında device ESP’nin bir bölümü yeni atamaları kontrol etmek için yeniden çalışabilir ve User ESP account setup ile kullanıcıya özel işlemler devam eder.
Hangi Senaryoda Hangi Mod Seçilmeli?
Self-Deploying Mode seçilecek senaryolar
- Cihaz kiosk veya dijital signage olarak kullanılacaksa.
- Cihazı birden fazla kullanıcı kullanacaksa ve belirli bir primary user olmayacaksa.
- Deployment sırasında kullanıcıdan Microsoft Entra kimlik bilgisi istenmeyecekse.
- Microsoft Entra hybrid join gerekmiyorsa.
- Device-targeted policy ve uygulamalarla otomatik giriş yapılacaksa.
Pre-Provisioning seçilecek senaryolar
- Cihaz belirli bir çalışana teslim edilecekse.
- Uygulama ve security policy kurulumunu kullanıcı cihazı almadan önce tamamlamak istiyorsanız.
- OEM, reseller veya IT ekibi Technician Flow’u çalıştırabiliyorsa.
- Kullanıcıya kısa bir OOBE deneyimi bırakılmak isteniyorsa.
- Mevcut gereksinim nedeniyle Microsoft Entra hybrid join kullanılacaksa.
Yeni cihazlarda Microsoft Entra join, kullanıcı deneyimi ve cloud-native yönetim açısından tercih edilen seçenektir. Hybrid join kullanımı devam ediyorsa domain controller erişimi, Intune Connector for Active Directory ve domain join profile gibi bağımlılıklar ayrıca planlanmalıdır.
Deployment Öncesi Kontrol Adımları
Toplu dağıtıma başlamadan önce iki cihazla pilot test yapmak, mod seçiminden kaynaklanan hataları erken görmek için yeterlidir. Aşağıdaki kontroller özellikle önemlidir:
- Cihazın Windows Autopilot’a kayıtlı olduğunu ve doğru profile atandığını Intune admin center > Devices > Windows > Device onboarding > Enrollment > Windows Autopilot > Devices bölümünden kontrol edin.
- Self-Deploying için profile deployment mode’un gerçekten Self-deploying olduğunu kontrol edin.
- Pre-Provisioning için profile’ın User-driven olduğunu ve pre-provisioned deployment’a izin verdiğini kontrol edin.
- ESP profilinin cihaza atandığını, gerekli uygulamaların blocking olarak seçilip seçilmediğini ve timeout değerini inceleyin.
- TPM 2.0, device attestation ve TPM sağlayıcısına ait HTTPS erişimini OEM ve network ekibiyle teyit edin.
- Win32 uygulamalar için installation behavior değerinin cihaza uygun olduğunu, detection rule’ların da SYSTEM bağlamında çalışabildiğini test edin.
- Hybrid join kullanılıyorsa User Flow sırasında cihazın domain controller’a erişebileceği bir ağ veya VPN planlayın.
Self-Deploying denemesi TPM doğrulamasında duruyorsa önce donanım ve ağ erişimini kontrol etmek gerekir. Pre-Provisioning Technician Flow tamamlanıyor ancak kullanıcı masaüstüne geçemiyorsa ESP’de beklenen uygulamaları, User Flow atamalarını ve gerekiyorsa compliance değerlendirmesini inceleyin.
Doğru Seçim
Self-Deploying Mode’un ana fikri kullanıcı olmadan cihazı hazır hale getirmektir. Pre-Provisioning’in ana fikri ise kullanıcıya teslim edilmeden önce device provisioning işini IT, OEM veya reseller tarafına taşımaktır.
Bu nedenle kiosk veya shared device için Self-Deploying Mode, belirli bir kullanıcıya verilecek kurumsal laptop için Pre-Provisioning daha uygun olur. İki modda da TPM 2.0, device attestation, doğru Autopilot profile ve ESP hedeflemesi dağıtımın temel şartıdır. Profile seçiminden önce cihazın kullanım şeklini ve Microsoft Entra join modelini netleştirmek, sonradan primary user veya hybrid join kaynaklı değişiklik ihtiyacını azaltır.
Microsoft Kaynakları
