Windows filo büyüdükçe grup sayısı da genelde aynı oranda büyüyor. ARM64 cihazlara farklı bir Win32 app göndermek için ayrı bir dinamik grup, kişisel cihazları bir device restriction policy’den hariç tutmak için başka bir dinamik grup, Enterprise SKU çalıştıran cihazlara Endpoint Privilege Management vermek için üçüncü bir grup. Her biri Microsoft Entra ID tarafında ayrı bir dinamik kural, ayrı bir senkronizasyon gecikmesi ve ayrı bir bakım yükü demek. Assignment filter’lar bu ihtiyacın büyük kısmını grup oluşturmadan çözüyor.
Bu yazıda assignment filter’ları Windows cihazlar için gerçek dağıtım senaryolarında nasıl kullanacağınızı, hangi property’lerin işinize yarayacağını, include/exclude modunun pratikte ne anlama geldiğini ve hangi Windows workload’larında filter’ın hiç işe yaramadığını anlatıyorum. Filter evaluation engine’in check-in sırasında kuralı nasıl işlediği, cache davranışı gibi iç mekanizma detayları bu yazının kapsamı dışında; burada odak günlük kullanımda doğru stratejiyi kurmak.
Filter mi, Dynamic Group mü?
Assignment filter’lar grup atamasının yerine geçmiyor, üzerine ekleniyor. Bir policy’yi önce bir gruba (ya da doğrudan All devices/All users virtual grubuna) atarsınız, filter o atamayı device property’lerine göre daraltır. Bu yüzden ilk karar her zaman aynı: hedeflemeyi grup mu, filter mı yapmalı?
Kural basit. Conditional Access, lisanslama, SharePoint veya Autopilot deployment profile gibi Intune dışı bir servis de aynı gruba ihtiyaç duyuyorsa dynamic group kullanmanız gerekiyor, çünkü bu servisler filter okuyamıyor. Ama grup sadece Intune tarafında bir policy’yi daraltmak için varsa ve kullandığınız kriter OS sürümü, üretici, model, sahiplik tipi veya cihaz kategorisi gibi bir device property ise, aynı işi filter ile yapabilirsiniz. Fark sadece mimari zevk meselesi değil: dynamic group üyeliği Microsoft Entra ID tarafında işlenip Intune’a senkronize olurken, filter cihaz her check-in yaptığında doğrudan değerlendiriliyor. Grup üyeliği işlem gecikmesine bağlı değil.
Pratikte en çok işe yarayan model, geniş bir taban grup (genelde All devices) kullanıp üzerine filter ile ince ayar yapmak. “Start broad, refine narrow” yaklaşımı: her policy için ayrı bir grup üretmek yerine tek bir geniş atama üzerinden birden fazla filter kombinasyonu çalıştırabilirsiniz.
Windows Cihazlarda Kullanılabilecek Property’ler
Windows platformu için pratikte en çok işinize yarayan property’ler şunlar: operatingSystemSKU (Enterprise, Professional, Education gibi Windows SKU’su), cpuArchitecture (amd64, x86, arm64), manufacturer ve model, deviceOwnership (Corporate/Personal), deviceTrustType (Azure AD joined, Azure AD registered, Hybrid Azure AD joined), enrollmentProfileName ve operatingSystemVersion.
operatingSystemSKU için Intune admin center portalda SKU adlarını göstermiyor, Enterprise, Professional, Education gibi değerleri doğrudan rule syntax editöründe kendiniz yazmanız gerekiyor. Bir cihazın gerçek SKU değerini görmek isterseniz cihazda şu komutu çalıştırabilirsiniz:
Get-WmiObject -Class Win32_OperatingSystem | Select-Object OperatingSystemSKUoperatingSystemVersion property’si osVersion‘ın yerini alıyor; osVersion hâlâ çalışıyor ama artık deprecated, yeni filter oluştururken kullanılamıyor. operatingSystemVersion ile -gt, -ge, -lt, -le gibi karşılaştırma operatörlerini de kullanabiliyorsunuz, bu da build bazlı hedeflemeyi doğrudan mümkün kılıyor.
Include ve Exclude Modunun Pratik Etkisi
Bir filter’ı bir assignment’a eklerken üç seçenek var: filter uygulamamak, filtrelenen cihazları dahil etmek (Include) veya filtrelenen cihazları hariç tutmak (Exclude). Burada kafa karıştıran nokta genelde “match” kelimesinin hangi yönde çalıştığı.
Include modunda, cihaz filter kuralıyla eşleşiyorsa policy uygulanıyor; eşleşmiyorsa uygulanmıyor. Exclude modunda ise tam tersi: cihaz kuralla eşleşiyorsa policy uygulanmıyor, eşleşmiyorsa uygulanıyor. Yani “Exclude modunda kişisel cihazları filtrele” dediğinizde, filter kuralı hâlâ deviceOwnership -eq "Personal" yazıyor olacak; mod bunu “bu cihazları dışarıda bırak” anlamına çeviriyor.
Bir device restriction policy’yi All devices’a atayıp (device.deviceOwnership -eq "Personal") kuralına sahip bir filter’ı Exclude modunda eklemek, tek bir filter ile hem kurumsal cihazları kapsama almanızı hem kişisel cihazları otomatik olarak dışarıda bırakmanızı sağlıyor. Aynı işi ayrı bir “kurumsal cihazlar” dynamic grubu kurmadan yapıyorsunuz.
Windows İçin Pratik Filter Senaryoları
Birkaç senaryo üzerinden gidersem daha net oluyor.
ARM64 cihazlara özel Win32 app. Bir uygulamanın ARM64 sürümünü sadece Copilot+ PC gibi ARM64 mimarili cihazlara göndermek istiyorsanız, uygulamayı All devices grubuna atayıp (device.cpuArchitecture -eq "arm64") kuralını Include modunda ekleyebilirsiniz. Ayrı bir “ARM cihazlar” grubu kurmanıza gerek kalmıyor.
Enterprise SKU’ya özel güvenlik özellikleri. Endpoint Privilege Management veya Windows LAPS gibi bazı özellikler lisans olarak tüm SKU’larda anlamlı olmayabiliyor. (device.operatingSystemSKU -eq "Enterprise") kuralıyla bu tür policy’leri sadece Enterprise SKU çalıştıran cihazlara sınırlayabilirsiniz.
Hybrid join ve cloud-native cihazları ayırmak. Aynı ortamda hem hybrid Azure AD joined hem tamamen cloud-native Azure AD joined cihazlarınız varsa ve bazı policy’lerin (örneğin belirli bir sertifika veya VPN profili) sadece birine gitmesi gerekiyorsa, (device.deviceTrustType -eq "Azure AD joined") ya da -eq "Hybrid Azure AD joined" kuralı bunu ayrı bir dynamic group kurmadan çözüyor.
Autopilot ile kaydolan cihazları ayırt etmek. Belirli bir Autopilot deployment profile üzerinden gelen cihazlara özel bir device restriction veya kiosk profili uygulamak isterseniz, (device.enrollmentProfileName -startsWith "Autopilot") kuralı işe yarıyor. Bu, Autopilot’un ZTDid attribute’una dayanan bir dynamic group kurallarından daha basit ve check-in anında değerlendiriliyor.
Kişisel cihazları hariç tutmak. Yukarıda değindiğim deviceOwnership senaryosu özellikle BYOD’un da desteklendiği ortamlarda sık karşılaşılan bir ihtiyaç.
Filter Kullanılamayan Windows Workload’ları
Assignment filter’ları bir strateji üzerine kurmadan önce bilmeniz gereken önemli bir sınır var: her Windows policy tipi filter desteklemiyor. Settings Catalog, Update rings, çoğu device configuration profili (Device restrictions, VPN, Wi-Fi, Endpoint Protection, PKCS/SCEP/Trusted certificate) ve çoğu endpoint security profili (Antivirus, Firewall, Endpoint detection and response, Disk encryption, EPM) filter destekliyor. Ama şu Windows workload’ları desteklemiyor:
- PowerShell scripts (Windows)
- Security baselines
- Feature updates for Windows (ayrı feature update policy’si; update ring’ler bundan farklı, onlar filter destekliyor)
- Wired network profili
- Policy sets
- Custom compliance policies for Windows (preview)
- S mode supplemental policies
Attack surface reduction profilinde de bir istisna var: Web protection (Microsoft Edge Legacy), Application control ve App and browser isolation ayarları filter desteklemiyor, ASR profilinin geri kalanı destekliyor.
Birden Fazla Filter Çakıştığında Ne Oluyor?
Bir cihaz aynı policy için filtrelenmiş birden fazla atamanın kapsamına giriyorsa (örneğin hem Include modlu bir filter içeren gruba hem Exclude modlu bir filter içeren başka bir gruba üyeyse), Intune belirli bir öncelik sırası uyguluyor: Exclude her zaman kazanıyor, ardından filtresiz atama, en son Include geliyor.
Aynı modda birden fazla filter varsa (örneğin cihaz iki farklı Include filter’ının kapsamına giriyorsa) OR mantığı çalışıyor: cihaz filtrelerden herhangi birine uyuyorsa policy uygulanıyor. Bu davranışı bilmeden karmaşık grup+filter kombinasyonları kurarsanız, bir cihazın neden beklenmedik şekilde policy aldığını ya da almadığını anlamak zorlaşıyor. Strateji kurarken mümkün olduğunca az sayıda çakışan atama tasarlamak, sonradan sorun ayıklamayı kolaylaştırıyor.
Ölçek ve Performans
Büyük ortamlarda grup ve filter tasarımının performansa doğrudan etkisi var. Her policy için ayrı bir grup açmak yerine aynı grupları farklı policy’lerde yeniden kullanmak, Intune’un grup üyeliğini assignment mesajlarına çevirme sürecini daha verimli çalıştırıyor. “Install_App”, “Config_Policy” gibi tek amaçlık gruplar çoğaldıkça Intune’un izlemesi gereken grup sayısı da artıyor, bu da senkronizasyon yükünü büyütüyor.
Bunun yanında, sadece Intune tarafından kullanılan ve device property’sine dayanan dynamic group’ları (örneğin device.deviceOSType -eq "Windows" gibi basit bir kural) assignment filter’a çevirmek genelde daha iyi bir tercih. Filter check-in anında doğrudan değerlendiriliyor, grup senkronizasyon gecikmesine bağlı değil. Ama bu grup Conditional Access, lisanslama gibi başka bir servis tarafından da okunuyorsa, dynamic group’u kaldırmamanız gerekiyor; o servisler filter okuyamıyor.
Filter Sayısını Takip Etmek
Tenant başına 200 assignment filter, filter başına 3.072 karakter kural limiti var. Filter sayısı 40-50 makaleden oluşan bir ortamda hızlıca birikebiliyor, özellikle her policy için ayrı filter yazma alışkanlığı varsa. Mevcut filtreleri ve kural uzunluklarını toplu olarak görmek için Microsoft Graph beta uç noktasını kullanabilirsiniz:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
Get-MgBetaDeviceManagementAssignmentFilter -All |
Select-Object DisplayName, Platform, @{N='RuleLength';E={$_.Rule.Length}} |
Sort-Object RuleLength -DescendingBu, hem toplam filter sayısını hem hangi kuralın 3.072 karakter limitine yaklaştığını görmenizi sağlıyor. Assignment filter Graph kaynağı şu an sadece beta’da, v1.0 karşılığı yok; production otomasyonunda bunu kullanırken beta endpoint’lerin davranış değiştirebileceğini göz önünde bulundurmak gerekiyor.
Filtreyi Devreye Almadan Önce Doğrulama
Bir filter yazdıktan sonra doğrudan production assignment’a eklemek yerine önce Preview devices ile kaç cihazın kuralla eşleştiğini kontrol edebilirsiniz. Preview özelliği, henüz preview aşamasında olan bazı property’ler (örneğin cpuArchitecture) için çalışmıyor; bu durumda filter’ı yine de kullanabilirsiniz, sadece önizleme listesi gösterilmiyor.
Filter devreye girdikten sonra bir cihazda beklediğiniz sonucu almadıysanız Devices > All devices > [cihaz] > Filter evaluation raporuna bakın. Bu rapor hangi filtrenin ne zaman değerlendirildiğini, sonucun Match mi No match mi olduğunu ve hangi property değerinin kullanıldığını gösteriyor. Değerlendirme sonucunun admin center’a yansıması 30 dakikaya kadar sürebiliyor, sonuçlar da 30 gün saklanıyor; bu sürenin dışına çıkmış bir sorunu geriye dönük incelemek mümkün olmuyor.
Yüksek etkili bir assignment’ta (örneğin All devices’a atanan bir compliance policy) filter değiştirmeden önce değişikliği önce küçük bir pilot gruba uygulamak, filter’daki bir yazım hatasının veya beklenmeyen bir eşleşmenin tüm filoyu etkilemesini önlüyor. Filter kuralı basit görünse de yanlış bir operatör (-contains yerine -eq gibi) beklenenden çok daha geniş ya da dar bir cihaz kümesiyle eşleşmesine yol açabiliyor.
