Windows tarafında bir ayarı Intune üzerinden dağıtmak isteyip de doğru template’i bulamadığınız, ya da template’in içinde o ayar olmadığı için custom OMA-URI’ye dönmek zorunda kaldığınız bir noktaya muhtemelen herkes gelmiştir. Settings Catalog tam olarak bu boşluğu kapatıyor: Windows’un desteklediği neredeyse her CSP tabanlı ayarı tek bir arama kutusundan bulup, kendi ihtiyacınıza göre bir araya getirdiğiniz bir politika türü. Artık Microsoft’un önceden hazırladığı bir grup ayarla sınırlı değilsiniz, GPO’da olduğu gibi ayar bazında ilerliyorsunuz.
Bu rehberde Windows 10/11 cihazlar için sıfırdan bir Settings Catalog politikası oluşturma sürecini, ayar arama ve filtreleme mantığını, applicability rules ile hedefleme yapısını, JSON export/import ile profil klonlamayı ve var olan bir politikayı değiştirirken nelere dikkat etmeniz gerektiğini anlatıyorum.
Settings Catalog ile Templates Arasındaki Fark
Intune’da Windows için politika oluştururken iki yol karşınıza çıkıyor: Templates ve Settings catalog. Templates, BitLocker, Wi-Fi, kiosk gibi belirli senaryolar için Microsoft’un önceden gruplandırdığı ayar setlerini sunuyor. Settings catalog ise kategori ayrımı yapmadan tüm ayarları tek listede gösteriyor; belirli bir alanın (örneğin tüm firewall ayarlarının ya da tüm BitLocker ayarlarının) tamamını görmek veya çok spesifik bir ayarı aramak istediğinizde asıl kullanmanız gereken yer burası.
Politikayı Oluşturma
Intune admin center’da Devices > Manage devices > Configuration > Create > New policy yolunu izleyin. Platform olarak Windows 10 and later, profile type olarak Settings catalog seçip Create‘e basın. Bu işlem için hesabınızda en az Policy and Profile Manager built-in rolü olması gerekiyor.
Basics sayfasında profile anlamlı bir isim verin. Tek bir ayarı değil bir grup ayarı yönetecekseniz isimde bunu belirtmek işinizi kolaylaştırıyor, örneğin Win10: BitLocker ayarları gibi. Next ile Configuration settings sayfasına geçtiğinizde Add settings ile ayar seçici açılıyor.
Ayar Arama ve Filtreleme
Ayar seçicide üç şekilde ilerleyebilirsiniz: kategoriye göre (örneğin Authentication veya BitLocker), anahtar kelimeyle arama yaparak (office, bluetooth, internet explorer gibi) veya Add filter ile listeyi daraltarak. Filtre; Windows OS edition, user/device scope ve Android enrollment mode gibi özelliklere göre çalışıyor. OS edition filtresi burada sadece hangi ayarların listede görüneceğini belirliyor, profilin hangi cihazlara uygulanacağını değil; o kısmı birazdan applicability rules ile ayrı bir mekanizma olarak yapıyoruz.
Bir kategoriyi açtığınızda Select all these settings ile kategorideki tüm ayarları tek seferde ekleyebilirsiniz. Eklenen her ayar, işletim sisteminin varsayılan değeriyle birlikte gelir. Yönetmek istemediğiniz bir ayarı politikadan çıkarmak için satırdaki eksi (-) işaretine tıklayın; bu, ayarı Not configured durumuna alır ve politikadan tamamen kaldırır. Cihazlar bir sonraki check-in’de bu ayarın artık kilitli olmadığını görür, ayar başka bir politika veya kullanıcı tarafından değiştirilebilir hale gelir.
User Scope ve Device Scope Ayarları
Ayar isimlerinde gördüğünüz (User) veya (Device) etiketi, ayarın hangi registry hive’ına yazılacağını gösteriyor. User scope ayarlar HKEY_CURRENT_USER altına, device scope ayarlar HKEY_LOCAL_MACHINE altına yazılıyor. Bu ayrım assignment tarafında da önemli: device scope bir ayarı bir kullanıcı grubuna atarsanız, o kullanıcı oturum açıp sync olduğunda ayar cihazdaki tüm kullanıcılara uygulanır. User scope bir ayarı bir cihaz grubuna atarsanız da benzer şekilde cihazdaki herkese uygulanır, bu davranış GPO’daki loopback merge’e benziyor. Aynı ayar hem user hem device scope’ta atanmışsa user scope kazanır.
Applicability Rules ile Hedefleme
Bazı senaryolarda bir grubun tamamına değil, grup içindeki belirli özelliklere sahip cihazlara ayar göndermek gerekiyor; örneğin sadece Windows Enterprise cihazlarda ya da sadece belirli bir build aralığındaki cihazlarda. Bunun için grup içinde ayrı bir alt grup oluşturmak yerine Applicability Rules sekmesini kullanabilirsiniz.
Burada iki seçenek var: Assign profile if (kriteri karşılayanlara uygula) ve Don’t assign profile if (kriteri karşılayanları hariç tut). Property olarak OS edition veya OS version (min/max build numarası) seçebilirsiniz. Kritere uymayan cihazlarda profilin durumu Not applicable olarak görünür, bu bir hata değildir.
Scope Tag ve Assignment
Scope tags sayfasında dağıtık IT yönetimi kullanıyorsanız profili ilgili scope tag ile ilişkilendirin. Assignments sayfasında ise profili hedef kullanıcı veya cihaz gruplarına atayın, gerekiyorsa assignment filter ile daraltın. Review + create ile profili kaydettiğinizde profil hemen atanmış olur; cihazlar bir sonraki check-in’de ayarları alır.
Profili JSON Olarak Dışa/İçe Aktarma
Bir profili sıfırdan kurmak yerine mevcut bir profili temel alıp değiştirmek isteyebilirsiniz; özellikle aynı yapıyı farklı bir tenant’ta ya da farklı bir cihaz grubu için tekrar kurmanız gerektiğinde JSON export/import işinizi kısaltıyor. Profil listesinde ilgili Settings Catalog politikasını seçip context menüden (…) Export JSON diyerek dosyayı indirebilirsiniz. Yeni bir profil oluşturmak için de Create > Import policy ile bu dosyayı seçip yeni bir isim vermeniz yeterli.
Bu JSON, arka planda Graph’taki deviceManagementConfigurationPolicy nesnesinin bir görünümü. Her ayar, settings koleksiyonu altında ya choiceSettingValue (dropdown/enum tipi ayarlar için) ya da simpleSettingValue (string, integer gibi tekil değerler için) taşıyan bir settingInstance olarak tutuluyor. Küçük ölçekte tek tek export/import yeterli olsa da toplu denetim veya CI/CD tarzı bir senaryoda Graph üzerinden doğrudan okuma daha pratik:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies?`$filter=name eq 'Win10: BitLocker ayarları'"configurationPolicies uç noktası şu an beta’da; production automation’da kullanacaksanız endpoint şemasının zaman zaman değişebileceğini göz önünde bulundurun ve önemli script’leri düzenli test edin.
Var Olan Bir Politikayı Değiştirirken Dikkat Edilmesi Gereken Nokta
Settings Catalog politikaları için ayrı bir versiyon numarası veya geri alma mekanizması yok. Graph tarafında sadece createdDateTime ve lastModifiedDateTime tutuluyor. Yani zaten atanmış bir profilde ayar değiştirdiğinizde bu değişiklik, profilin atandığı tüm kullanıcı ve cihazlara doğrudan yansıyor; ayrı bir onay veya kademeli rollout adımı yok.
Değişiklik kaydedildikten sonra Intune, online cihazlara check-in için bildirim gönderiyor; bu bildirimin cihaza ulaşma süresi anlık ile birkaç saat arasında değişebiliyor. Cihaz o an offline ise değişikliği bir sonraki normal check-in’inde alıyor. Windows için yeni enroll olmuş bir cihazda check-in ilk 15 dakika boyunca her 3 dakikada bir, sonraki 2 saat boyunca her 15 dakikada bir, ardından yaklaşık 8 saatte bir çalışıyor.
Conflict ve Per-Setting Raporlama
Aynı ayarı farklı değerlerle iki politikadan göndermeniz durumunda conflict oluşuyor. Profili açıp View report‘a girdiğinizde her ayar için kaç cihazda başarılı uygulandığını, kaç cihazda conflict veya error olduğunu görebiliyorsunuz; bu sayılara tıklayarak etkilenen cihaz listesine de inebiliyorsunuz. Profil hiç deploy olmadıysa Devices > Monitor > Assignment failures ekranı da ayrı bir kontrol noktası.
Compliance policy ile configuration profile aynı ayarı farklı değerlere çekmeye çalışırsa compliance policy her zaman öncelikli. İki configuration profile birbiriyle çelişiyorsa bu, Intune tarafında conflict olarak işaretlenir ve elle çözülmesi gerekir.
Reusable Settings Groups Hakkında Kısa Bir Not
Intune’da reusable settings groups diye bir özellik de var ve bazı yerlerde Settings Catalog’un genel bir parçasıymış gibi anlatılıyor; oysa şu an (preview aşamasında) sadece Windows Firewall Rules, Attack Surface Reduction altındaki Device Control ve Endpoint Privilege Management elevation rules politikaları için destekleniyor. Genel amaçlı bir Settings Catalog profilinde ortak bir ayar grubunu tekrar kullanmak istiyorsanız bu özellik şu an için kapsam dışı; ilgili endpoint security profilini oluştururken Reusable settings (preview) sekmesinden bakabilirsiniz.
Ayarın Cihazda Gerçekten Uygulandığını Doğrulama
Portal tarafında Succeeded görmek, ayarın cihazda beklediğiniz gibi durduğunu garanti etmiyor; bu durum sadece politika değerlendirmesinin hata vermeden tamamlandığını gösteriyor. Cihaz tarafında ayarın kendisini görmek için ilgili registry değerine bakmak en hızlı yol. Daha kapsamlı bir kontrol gerekiyorsa cihazda Settings > Accounts > Access work or school > Export your management log files ile MDM diagnostic log’unu alabilirsiniz; bu log C:\Users\Public\Public Documents\MDMDiagnostics altına, biri ham log biri de Excel’de açılabilen özet dosyası olmak üzere iki dosya halinde düşer ve içinde her CSP node’unun son alınan değeri yer alır. Aynı raporu komut satırından almak isterseniz:
MdmDiagnosticsTool.exe -area DeviceProvisioning -cab C:\Temp\MDMDiag.cabPortal durumu ile bu log arasında fark görüyorsanız önce sync zamanlamasını (cihaz gerçekten check-in yaptı mı) kontrol etmek, doğrudan ayarı yeniden göndermeye çalışmaktan daha hızlı sonuç veriyor.
Settings Catalog’u bir kere doğru kurduktan sonra asıl zaman kazandıran kısım, yeni bir ayar ihtiyacı çıktığında tekrar template aramak yerine doğrudan arama kutusuna yazıp bulabilmek. GPO’dan gelenler için de bu yapı, alışık oldukları ayar bazlı çalışma şekline en yakın deneyim.
