Bir filter’ı Preview devices ile test edip beklenen cihaz sayısını gördükten sonra production assignment’a eklemek, çoğu zaman işin bittiği anlamına gelmiyor. Birkaç gün sonra “bu cihaz filtre kapsamına girmiş görünüyor ama policy hâlâ uygulanmadı” ya da tam tersi “cihaz artık kapsam dışında olmalıydı ama uygulama hâlâ kurulu” gibi sorularla karşılaşmak mümkün. Bu soruların cevabı filter’ın kural syntax’ında değil, değerlendirme motorunun ne zaman çalıştığında ve hangi property değerini okuduğunda saklı.
Bu yazıda assignment filter’ların günlük kullanımına değil, filter’ın cihazda ve serviste nasıl değerlendirildiğine odaklanıyorum: cihaz property’lerinin Intune’a nereden ve ne zaman ulaştığı, filter değerlendirmesinin hangi olaylarla tetiklendiği, bir property değiştiğinde sonucun ne zaman güncellendiği ve Preview devices özelliğinin gerçekte ne sorguladığı. Filter syntax’ı, include/exclude mantığı ve hangi Windows workload’larının filter desteklediği önceki bir yazıda ele alındığı için burada tekrar etmiyorum.
Filter Değerlendirmesi Hangi Olaylarla Tetikleniyor?
Microsoft’un dokümantasyonuna göre bir assignment filter üç noktada değerlendiriliyor: cihaz enroll olduğunda, cihaz Intune servisiyle check-in yaptığında ve “policy’nin değerlendirildiği başka herhangi bir zamanda” – örnek olarak bir compliance taraması veriliyor. Bu üçüncü madde net bir liste değil, bu yüzden hangi tetikleyicilerin filter’ı yeniden çalıştırdığını cihaz başına kesin olarak öngörmek her zaman mümkün olmuyor.
Burada önemli olan nokta, filter’ın grup üyeliği gibi önceden hesaplanmış (precomputed) bir veri kümesine bakmaması. Dynamic group üyeliği Microsoft Entra ID tarafında ayrı bir işlemle hesaplanıp Intune’a senkronize ediliyor; filter ise check-in anında doğrudan cihazın o anki property kaydına bakıyor. Bu da group membership senkronizasyon gecikmesine bağlı olmayan, düşük gecikmeli bir değerlendirme demek.
Cihaz Property’leri Intune’a Nasıl Ulaşıyor?
Filter kuralında kullanılan manufacturer, model, operatingSystemVersion, operatingSystemSKU gibi property’ler havada durmuyor; bunların kaynağı cihazın kendi Windows MDM istemcisi. Windows’un OMA-DM istemcisi, her yönetim oturumunun başında ./DevInfo node’u altındaki Man (manufacturer) ve Mod (model) değerlerini otomatik olarak sunucuya gönderiyor; bu davranış DevInfo CSP dokümantasyonunda açıkça tanımlı. OS sürümü ve donanım bilgisi için benzer şekilde DevDetail CSP node’ları (SwV, FwV gibi) kullanılıyor. Yani bu property grubu, cihaz her check-in yaptığında yeniden gönderiliyor; Intune tarafında ayrı bir “hardware inventory” görevi beklemeye gerek kalmıyor.
Buna karşılık filter’da kullanılan bazı property’ler cihazdan değil, enrollment sırasında Intune veya Microsoft Entra ID tarafında set edilen bilgilerden geliyor. enrollmentProfileName için Microsoft dokümantasyonu net: bu değer “cihaz enroll olduğunda cihaza uygulanıyor”. Yani bir Autopilot deployment profile adına göre yazılmış bir filter, cihazın sonraki check-in’lerinde değil, enrollment anında belirlenen bir değeri okuyor. deviceTrustType da benzer şekilde cihazın Microsoft Entra join tipine bağlı; dokümantasyon burada ayrıca bir uyarı içeriyor: bu property’nin Intune’daki değerleri, aynı isimdeki Microsoft Entra ID property’siyle karıştırılmamalı, ikisi farklı yerlerde tutulan farklı değerler.
cpuArchitecture property’sinde de kaynağın zamanlaması açıkça belirtilmiş: Microsoft, bu property’nin şu an enrollment senaryolarında desteklenmediğini, desteğin ileride ekleneceğini (tarih verilmeden) belirtiyor. Pratik sonucu şu: yeni enroll olan bir cihaz için cpuArchitecture bazlı bir filter, cihaz enroll olduğu anda değil, bu property Intune kaydına işlendikten sonra beklenen sonucu veriyor. Aradaki gecikmenin kesin süresi dokümante edilmiyor; bu noktada net check-in sayısı veya dakika vermek yerine, yeni enroll olan bir cihazda mimari bazlı filter’ların ilk birkaç check-in’de tutarsız sonuç verebileceğini bilmek yeterli.
Check-in Sıklığı Filter Sonucunu Nasıl Etkiliyor?
Windows cihazlar için check-in zamanlaması sabit değil, cihazın enrollment yaşına göre değişiyor. Yeni enroll olan bir Windows cihazı ilk 15 dakika boyunca 3 dakikada bir, sonraki 2 saat boyunca 15 dakikada bir check-in yapıyor; bu pencereden sonra düzenli bakım (maintenance) senkronizasyonuna geçiyor, bu da yaklaşık 8 saatte bir gerçekleşiyor. Cihazlar iki maintenance sync arasında en az 6,5 saat bekletiliyor; yani check-in’i manuel tetiklemediğiniz sürece bir property değişikliğinin filter sonucuna yansıması bu pencereye bağlı.
Enrolled bir Windows cihazının her check-in’inde yalnızca policy ve app güncellemeleri değil, donanım envanteri (hardware inventory) ve uygulama envanteri güncellemeleri de aynı oturumda taşınıyor. Bu da yukarıdaki DevInfo/DevDetail davranışıyla örtüşüyor: property senkronizasyonu ayrı bir zamanlamaya sahip değil, filter değerlendirmesini tetikleyen check-in’in kendisiyle aynı oturumda ilerliyor.
Cihazda bir sonraki check-in’in ne zaman planlandığını görmek isterseniz, MDM enrollment’ının kendi zamanlama görevlerine bakabilirsiniz. Bu görevler EnterpriseMgmt altında enrollment GUID’i başına oluşturuluyor:
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*\" |
Get-ScheduledTaskInfo |
Select-Object TaskName, LastRunTime, NextRunTimeNextRunTime sütunu, bir sonraki maintenance sync’in yaklaşık ne zaman tetikleneceğini gösteriyor. Bir property değişikliğinin filter sonucuna hemen yansımasını görmek istediğinizde bu zamanı beklemek yerine en pratik yol, cihazda check-in’i manuel tetiklemek. Company Portal üzerinden Sync ya da Intune admin center’da cihaz üzerinde Sync remote action’ı, sonraki maintenance penceresini beklemeden yeni bir check-in oturumu başlatıyor.
Property Değiştiğinde Sonuç Ne Zaman Güncelleniyor?
Microsoft’un troubleshooting dokümantasyonu bu konuda somut bir örnek veriyor ve bu örnek filter’ın çalışma mantığını iyi özetliyor. Bir uygulama, device category property’sine dayanan bir filter ile bir kullanıcı grubuna atanmış olsun. Kullanıcı yeni bir cihazda ilk kez enroll olup check-in yaptığında, cihazda henüz bir kategori atanmamış oluyor. Filter bu durumda kategoriyi null olarak değerlendiriyor ve kural buna göre sonuç veriyor; Include modunda uygulama kurulmuyor olabilir, Exclude modunda ise kategori kriteriyle eşleşmediği için uygulama kuruluyor.
Kullanıcı daha sonra Company Portal üzerinden bir cihaz kategorisi seçtiğinde, bu enrollment ve ilk check-in’den sonraki bir olay. Cihazın bir sonraki check-in’inde kategori property’si güncelleniyor ve filter artık farklı bir sonuç veriyor. Ama dokümantasyon burada net bir uyarı içeriyor: uygulama önceki check-in’de zaten kurulmuş durumdaysa, filter sonucu değiştiği için otomatik olarak kaldırılmıyor. Yani filter her değerlendirmede en güncel property değerine bakıyor, ama daha önce alınmış bir aksiyonu (kurulum gibi) geriye dönük olarak iptal etmiyor.
Bu davranış Microsoft dokümantasyonunda özellikle app assignment senaryosu (device category, Include/Exclude ve app install) için tanımlanmış. Aynı mantığın compliance policy veya configuration profile gibi başka workload’larda birebir aynı şekilde işlediği ayrıca dokümante edilmiyor; “filter yeniden değerlendirilir ama geçmiş aksiyon otomatik geri alınmaz” prensibinin genel bir davranış olarak genişletilmesi mantıklı bir teknik çıkarım, fakat her workload için ayrı ayrı doğrulanmış bir Microsoft ifadesi değil.
Filter Evaluation Raporu Neyi Gösteriyor?
Devices > All devices > [cihaz] > Filter evaluation raporu, o cihaz için değerlendirilmiş her filter’ı, değerlendirme zamanını, sonucu (Match / No match), kullanılan modu (Include/Exclude) ve hangi property değerinin okunduğunu listeliyor. Burada dikkat edilmesi gereken bir ayrıntı var: raporun “Filter information” bölümü, log verisinden değil filter’ın şu anki haliyle güncel adı, açıklaması ve kuralından besleniyor. Yani filter’ı değerlendirmeden sonra değiştirdiyseniz, raporda gördüğünüz kural metni değerlendirme anındaki değil, en son kaydedilen hali. Bunu ayırt etmek için raporun Evaluation time ve Last modified alanlarına birlikte bakmak gerekiyor.
Uygulama tarafında ayrı bir rapor var: Apps > [uygulama] > Device install status ekranında Filter sütunundan Filters evaluated seçilerek her cihaz için filter sonucu ve bunun uygulama atamasına etkisi (App assignment applied / not applied) görülebiliyor. Bu rapor Available olarak atanan uygulamalarda görünmüyor; Available bir uygulamanın filter sonucunu görmek için kullanıcının Company Portal’da uygulama listesine gitmesi (ve böylece bir değerlendirme tetiklemesi) gerekiyor.
Her iki rapor için de değerlendirme sonucunun admin center’a yansıması 30 dakikaya kadar sürebiliyor, sonuçlar 30 gün saklanıyor. Bu süre dolduğunda “We were not able to retrieve any filter evaluation results” mesajıyla karşılaşıyorsunuz; geriye dönük inceleme bu pencereyle sınırlı.
“Not evaluated” Sonucu Ne Anlama Geliyor?
Raporda bazen Match veya No match yerine Not evaluated sonucu görülebiliyor. Bu, cihazın aynı policy için birden fazla çakışan atamaya sahip olduğu ve filter mode önceliği (Exclude > No filter > Include) nedeniyle o filter’ın hiç işletilmediği durumlarda ortaya çıkıyor. Çakışma çözümünün kendisi ayrı bir konu olduğu için burada detaylandırmıyorum; rapor tarafında bilmeniz gereken, Not evaluated gördüğünüzde sorunun filter kuralında değil, aynı policy’ye giden başka bir atamada aranması gerektiği.
Preview Devices Gerçekte Neyi Sorguluyor?
Filter oluştururken kullanılan Preview devices özelliği, kuralı canlı olarak enrolled cihazlara karşı çalıştırıp eşleşen cihaz listesini gösteriyor. Burada anlaşılması gereken nokta şu: bu sorgu cihazın o anki fiziksel durumuna değil, Intune’un cihaz kaydında elinde tuttuğu property değerlerine bakıyor. Filter değerlendirme motoru zaten aynı kaynağı okuyor; Preview devices bu kaynağı önceden görmenizi sağlayan bir sorgu arayüzü, cihazlara ayrıca ulaşıp anlık bir durum sormuyor.
Bunun pratik sonucu, bir cihazda az önce değişen bir property’nin (örneğin yeni takılan bir Group Tag ya da elle değiştirilen bir kategori) cihaz yeni bir check-in yapana kadar Preview devices listesinde de eski haliyle görünmeye devam etmesi. Preview sonucu ile gerçek filter sonucu arasında bir tutarsızlık yaşarsanız önce cihazın son check-in zamanına bakmak, filter kuralını yeniden yazmaktan daha hızlı sonuç veriyor.
Preview devices, deneysel (preview) aşamasındaki property’ler için çalışmıyor; bu durumda “You cannot use Filter preview with experimental properties” mesajı görünüyor. Bu, o property’yi filter kuralında kullanamayacağınız anlamına gelmiyor – sadece önizleme listesi üretilemiyor, filter’ın kendisi normal şekilde kaydediliyor ve check-in’de değerlendiriliyor.
Değerlendirme Motorunu Anlamanın Pratik Karşılığı
Bir filter’ın “yanlış” çalıştığını düşündüğünüzde ayırt edilmesi gereken üç farklı olasılık var: filter kuralı yanlış yazılmış olabilir, cihazın property kaydı henüz güncellenmemiş olabilir (check-in beklemede), ya da property daha önce değişmiş ama daha önce alınmış bir aksiyon (kurulum, profil uygulaması) geriye dönük olarak etkilenmemiş olabilir. Filter Evaluation raporundaki Evaluation time, cihazın son check-in zamanıyla karşılaştırıldığında bu üçünü birbirinden ayırmak, kural syntax’ını tekrar tekrar değiştirmekten daha az zaman alıyor.
