Büyük Ölçekli Intune Dağıtımlarında Performans ve Ölçeklenebilirlik En İyi Uygulamaları

Tenant’ta birkaç yüz cihaz varken çalışan grup ve atama mantığı, aynı tenant 20.000 veya 100.000 cihaza çıktığında aynı şekilde davranmıyor. Portal’da hata görmezsiniz, politika “Assigned” görünür, ama cihaza ulaşması beklenenden çok daha uzun sürer. Büyük ölçekli Intune ortamlarında asıl sorun genelde belge sayfalarında yazan limitler değil; grup senkronizasyon gecikmesi, Graph API throttling’i ve Autopilot ESP zaman aşımı gibi mimari kararların birikimli etkisi oluyor. Bu yazıda 100.000+ cihazlı ortamlarda Microsoft’un resmi olarak önerdiği grup tasarımı, Windows Autopilot ring stratejisi, çok adminli tenant yönetimi ve Graph API otomasyonunda dikkat edilmesi gereken noktaları anlatıyorum.

Grup Tasarımı Ölçekte Neden Belirleyici

Intune, atama (assignment) için neredeyse tamamen Microsoft Entra gruplarını kullanıyor. Bir politika veya uygulama bir gruba atandığında, Intune bu grubun üyelerini arka planda cihaz ve kullanıcı bazlı hedefleme mesajlarına çeviriyor. Bu işlem aynı grup nesneleri tekrar tekrar kullanıldığında çok daha verimli çalışıyor.

Sahada sık görülen bir hata deseni “app group” yaklaşımı: her uygulama için ayrı Uygulama_Required, Uygulama_Available, Uygulama_Uninstall grupları oluşturup aynı cihazları bu gruplara tekrar tekrar eklemek. Bu yaklaşım Intune’un izlemesi gereken grup sayısını gereksiz yere büyütüyor ve senkronizasyon gecikmesini artırıyor. Aynı “Mühendislik” kullanıcı grubunu 10 farklı politika için tekrar kullanmak, aynı cihazları 10 farklı gruba dağıtıp her birini ayrı bir politikaya bağlamaktan çok daha performanslı.

Microsoft Entra’dan Intune’a grup üyeliği senkronizasyonu genelde 5 dakika içinde tamamlanıyor, anlık değil. 100.000 üyeyi aşan gruplarda ilk senkronizasyon ek gecikme yaşıyor; ilk tam sync her zaman sonraki artımlı sync’lerden daha yavaş oluyor. Kullanıcıyı bir gruba ekledikten hemen sonra cihazı enroll etmek, atamanın henüz cihaza ulaşmamış olması riskini taşıyor.

Dinamik grup kurallarında memberOf operatörünü kullanmaktan kaçının. Bu operatör transitive (geçişli) grup üyeliği sorgusu tetikliyor ve büyük ortamlarda değerlendirme süresini ciddi şekilde uzatıyor. Cihazları başka bir grubun üyeliğine göre hedeflemeniz gerekiyorsa, enrollment profile adı veya cihaz kategorisi gibi doğrudan bir özellik üzerinden kural kurmak genelde aynı sonucu daha hızlı veriyor.

Assignment Filter mi, Dynamic Group mu?

Sadece Intune tarafından tüketilen ve basit cihaz özelliklerine (işletim sistemi, üretici, model, sahiplik, cihaz kategorisi) dayanan dinamik gruplar yerine assignment filter kullanmak, büyük ortamlarda ek bir performans kazancı sağlıyor. Filtreler grup üyeliği hesaplaması gerektirmeden, cihaz check-in sırasında doğrudan değerlendiriliyor.

Örneğin device.deviceOSType -eq "Windows" kuralıyla dinamik grup oluşturup bir politikayı bu gruba atamak yerine, politikayı All devices‘a atayıp operatingSystemSKU -eq "Windows" filtresi eklemek aynı sonucu, grup üyeliği işlemesine bağımlı olmadan veriyor. Ancak dinamik gruplar hâlâ gerekli: Autopilot deployment profile atamaları, Conditional Access, lisanslama gibi cross-workload senaryolar filtre ile çözülemiyor, çünkü bu servisler Entra grup üyeliğine ihtiyaç duyuyor.

Enrollment sırasında hızlı politika teslimatı gerekiyorsa enrollment time grouping özelliğini değerlendirebilirsiniz. Bu özellik cihazı enrollment sırasında ilgili güvenlik grubuna ekliyor, dinamik grup üyeliğinin işlenmesini beklemeden ilk check-in’de politika teslimatı sağlıyor. Ancak bu özellik gerçek bir Entra grup üyeliği oluşturuyor ve enrollment sonrasında da kalıcı kalıyor; grubu başka hiçbir servis okumuyorsa yönetim yükü ekliyor demektir, o yüzden ihtiyaç yoksa kurmaya değmiyor.

Include/Exclude Grup Karışımından Kaçının

Bir kullanıcı grubuna atama yapıp bir cihaz grubunu exclude etmek (veya tersi), Intune tarafından desteklenmiyor. Bunun nedeni exclude edilen grubun üyeliğinin de anlık işlenmemesi; bu durum bazı cihazların aslında kapsam dışı bırakılması gereken bir politikayı veya uygulamayı almasına yol açabiliyor.

Windows Autopilot Dağıtımlarını Ring Bazlı Yapmak

Büyük bir Autopilot dağıtımında cihazları OEM veya reseller üzerinden satın alma anında tenant’a kaydettirmek, 4K hardware hash’i manuel CSV ile yüklemekten çok daha sürdürülebilir. Manuel yükleme test ve pilot senaryoları için makul, ama binlerce cihazlık bir fleet için operasyonel yük oluşturuyor.

Ölçekte işe yarayan desen, her cihaz persona’sı (bilgi işçisi, geliştirici, kiosk gibi) için ayrı bir group tag tanımlamak, bu tag’e karşılık gelen bir dinamik Entra grubu kurmak ve bu gruba bir deployment profile ile bir ESP profili bağlamak. Group tag başına tek profil kuralını korumak, konfigürasyonu izole tutuyor ve zamanla tek seferlik istisnaların tenant’a yayılmasını önlüyor.

Tüm fleet’i tek seferde devreye almak yerine Windows Update ring mantığına benzer bir aşamalandırma öneriyorum: önce IT ekibi ve gönüllülerden oluşan bir pilot grup, ardından farklı departmanlara yayılan küçük bir erken benimseyen grubu (~%5), son olarak kalan fleet. Her ring’i bir sonrakine geçmeden önce izlemek ve ring hedeflemesi için her politika için ayrı grup oluşturmak yerine assignment filter kullanmak, hem takip edilebilirliği hem de senkronizasyon yükünü kontrol altında tutuyor.

Enrollment Status Page Zaman Aşımı ve Uygulama Sayısı

ESP’nin varsayılan zaman aşımı süresi 60 dakika. Cihaza atanan zorunlu (blocking) uygulama sayısı arttıkça bu süre yetersiz kalabiliyor ve kullanıcı “Setup could not be completed” hatasıyla karşılaşıyor. Bu, büyük ölçekli Autopilot dağıtımlarında en sık karşılaşılan tıkanma noktalarından biri.

Cihazda hangi uygulamanın ESP sırasında hangi aşamada takıldığını görmek için HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking registry anahtarını kontrol edebilirsiniz. Bu anahtar altındaki Device ve ESPTrackingInfo alt anahtarları, device setup ve account setup fazlarında Win32 uygulama kurulum durumunu ve Intune Management Extension’ın kurulum durumunu tutuyor.

Çok Sayıda Admin Olan Ortamlarda Politika Sprawl’ını Önleme

Okul bölgeleri veya bölgesel IT yapıları gibi 15’ten fazla lokal adminin aynı tenant’ı paylaştığı ortamlarda, her lokal adminin kendi Windows Autopilot profilini, kendi ESP profilini veya kendi update ring’ini oluşturmasına izin vermek nesne sayısını kısa sürede yönetilemez hale getiriyor. Microsoft’un önerdiği kısmi delege modelinde, ortak profil ve politikaların oluşturulması merkezi ekipte kalıyor; lokal adminlere sadece okuma ve atama yetkisi veriliyor.

Windows Autopilot deployment profile’ları, ESP profilleri ve Windows update ring’leri bu modelde merkezi ekibin sorumluluğunda tutulması önerilen alanlar. Klasik Configuration Profiles listesi yerine Settings Catalog ve security baseline kullanmak, admin merkezindeki ölçek sorunlarını da azaltıyor. Full delegation modelinde her lokal admine kendi scope tag’i vermek, create/update/delete yetkisi olmayan bir rolle read/assign yetkisi tanımak, izin karmaşasını scope tag bazında ayrıştırıyor.

Microsoft Graph API ile Toplu İşlemlerde Throttling

Büyük ortamlarda cihaz veya politika verisini script’lerle çekmek ya da toplu değişiklik yapmak yaygın. Bu noktada Graph API’nin Intune servis grupları için tanımladığı throttling limitlerini bilmek gerekiyor. Çoğu Intune kaynak grubu için limit şöyle:

managedDevice, deviceHealthScript gibi kaynakların bulunduğu “devices” servis grubunda bu limitler daha yüksek: yazma işlemleri için tenant başına 400/20sn, uygulama başına 200/20sn; herhangi bir istek için tenant başına 4000/20sn, uygulama başına 2000/20sn.

429 (throttled) yanıtı aldığınızda Retry-After header’ında belirtilen süreyi beklemek en hızlı toparlanma yolu; Graph tarafı throttled olduğunuz sürede de istek sayınızı saymaya devam ediyor, bu yüzden körlemesine tekrar denemek durumu kötüleştiriyor. Microsoft Graph SDK’ları tekil istekler için bu bekleme mantığını otomatik uyguluyor. JSON batching kullanıyorsanız (bir batch’te en fazla 20 istek), her alt istek bağımsız throttle ediliyor; batch içindeki bir 429 otomatik tekrar denenmiyor, o alt isteği kendi Retry-After değeriyle sizin yeniden denemeniz gerekiyor.

try {
    $devices = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices"
}
catch {
    if ($_.Exception.Response.StatusCode -eq 429) {
        $retryAfter = [int]$_.Exception.Response.Headers["Retry-After"]
        Start-Sleep -Seconds $retryAfter
        $devices = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices"
    }
    else {
        throw
    }
}

Politika Senkronizasyon Aralıklarını Gerçekçi Beklentiyle Planlama

Cihaz platformuna göre değişse de, Intune’un yerleşik maintenance sync aralığı yaklaşık 8 saat; bir cihaz asla 6.5 saatten daha sık zorunlu senkronizasyon almıyor. Bu, istemci tarafındaki kasıtlı bir throttle. Yeni enroll olan cihazlar daha sık check-in yapıyor: Windows/Android tarafında ilk 15 dakika 3 dakikada bir, sonraki 2 saat 15 dakikada bir, ardından ~8 saatlik döngüye geçiyor.

Politika veya uygulama ataması değiştiğinde, online cihazlara bir bildirim push ediliyor; bu teslimatın süresi anlık ile birkaç saat arasında değişebiliyor, offline cihazlar ise değişikliği bir sonraki check-in’de alıyor. Binlerce cihazlık bir ortamda bir politikayı değiştirip beş dakika sonra “neden hâlâ uygulanmadı” diye sormak yerine, bu değişken teslimat penceresini planlamaya dahil etmek gerekiyor. Acil bir durumda Company Portal veya Intune admin center üzerinden manuel Sync cihaz eylemini tetiklemek check-in’i öne çekiyor, ama bunu her cihaz için elle yapmak büyük ortamda ölçeklenmiyor; asıl çözüm zaten grup ve filtre tasarımını yukarıdaki prensiplere göre kurup değişikliklerin doğal teslimat penceresi içinde yayılmasına izin vermek.