RSAT Kurulumu: AD Yönetim Konsolları ve GPMC

Sunucu yönetiminde en sık tekrarlanan alışkanlık, her iş için sunucuya uzak masaüstüyle bağlanmaktır. Oysa Windows tarafındaki yönetim araçlarının tamamı, sunucuya hiç dokunmadan kendi bilgisayarınızdan çalışacak şekilde tasarlanmıştır. Bu rehber o araçların nasıl kurulduğunu, nereden çalıştırılması gerektiğini ve tam olarak neyi yönettiğini ele alıyor. Yalnızca kurulum adımlarını arıyorsanız doğrudan Windows 10 ve 11 kurulumuna geçebilirsiniz.

RSAT Nedir? Sunucuya Bağlanmadan Yönetmek

RSAT (Remote Server Administration Tools), Windows Server rollerini yöneten konsolların istemci bir Windows’a kurulabilen halidir. Kurduğunuz anda bilgisayarınızda Active Directory kullanıcısı açan, grup ilkesi yazan, DNS bölgesi düzenleyen, DHCP havuzu tanımlayan pencereler belirir. Hiçbiri veriyi sizin makinenizde tutmaz; hepsi ağ üzerinden sunucudaki dizine bağlanır ve işi orada yapar.

Bir enerji santralinde operatör, türbinin ayarını değiştirmek için türbinin üstüne çıkmaz. Kontrol odasında oturur: göstergeler oraya taşınmıştır, kumandalar oraya çekilmiştir, türbinin kendisi rahat bırakılmıştır. Türbinin başına gidilen anlar bellidir ve neredeyse tamamı bakım işidir.

Bu ayrım iki tarafı birden korur, önemli olmasının sebebi de bu. Operatör makinenin üstünde değilken kendi iş güvenliği artar; makine de üstünde sürekli biri gezinmediğinde daha sağlıklı çalışır. Yönetim araçlarının mantığı birebir aynıdır ve ilerleyen bölümlerde ikisinin de somut karşılığını göreceksiniz: kontrol odasından çalışmak hem sizi korur hem sunucuyu. RSAT, Active Directory için o kontrol odasıdır ve bu yazının tamamı, kontrol odasını kurmak ile türbinin üstüne çıkma alışkanlığından vazgeçmek üzerine.

Windows Server bu konsolları kendi içinde taşır, çünkü rol zaten üstündedir. İstemci Windows taşımaz, çünkü sıradan bir kullanıcının makinesinde domain yönetim aracının işi yoktur. RSAT tam olarak bu boşluğu kapatan, isteğe bağlı kurulan pakettir. Windows Server’ın rol mimarisine ve hangi rolün ne iş yaptığına Windows Server rehberimizden bakabilirsiniz.

Aracın adındaki “sunucu” kelimesi bir noktada yanıltıcıdır ve bu yazının en çok düzeltmek istediği kavram hatası orada: RSAT bir sunucu işletim sistemini değil, bir dizini yönetir. Bunun pratik sonucu düşündüğünüzden geniş, aşağıda ayrı bir bölümde ele alıyoruz.

Son olarak kurulum yönteminin bir tarihi var ve bugün karşınıza çıkan rehberlerin çoğu o tarihin eski bir noktasında durmuş durumda. Windows 10’un 1809 sürümüne kadar RSAT, Microsoft’un sitesinden indirilen ayrı bir paketti ve her Windows sürümü için ayrı yayınlanırdı. 1809’dan itibaren işletim sisteminin içine İsteğe Bağlı Özellik olarak taşındı. Hâlâ “önce şu paketi indirin” diyen bir rehber okuyorsanız, o rehber güncel Windows’ta çalışmayacak bir yolu tarif ediyor.

RSAT Kurulumu: Windows 10 ve Windows 11

Tek bir ön koşul var ve kurulumun tökezlediği yerlerin başında geliyor: RSAT, Windows’un Home sürümlerine kurulmaz. Pro, Enterprise ve Education sürümlerinde çalışır. Makinenizin sürümünü bilmiyorsanız kuruluma başlamadan önce bakın, çünkü Home’da özellik listesinde arattığınızda hiçbir sonuç çıkmaz ve bu, “kurulum bozuk” gibi görünen ama aslında hiç başlamamış bir durumdur.

Arayüzden kurmak için Settings → System → Optional features yolunu izleyin, Add an optional feature düğmesine basın ve arama kutusuna RSAT yazın. Karşınıza tek bir paket değil, rol başına ayrılmış bir liste gelir. İhtiyacınız olanı seçmek yeterlidir; hepsini kurmak zorunda değilsiniz.

Aynı işi PowerShell ile yapmak hem daha hızlı hem de tekrarlanabilir. Önce hangi bileşenlerin mevcut olduğuna ve hangilerinin zaten kurulu olduğuna bakın:

Get-WindowsCapability -Online -Name RSAT* | Select-Object Name, State | Format-Table -AutoSize

Bu komutu yönetici olarak açılmış bir PowerShell penceresinde çalıştırın. Sıradan bir oturumda, sadece okuma yapan bu komut bile yükseltme ister; kurulum denemesine sıra bile gelmez.

Hiç RSAT kurulmamış bir Windows 11 Pro makinede çıktı şöyle görünüyor:

Name                                                          State
----                                                          -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0             NotPresent
Rsat.AzureStack.HCI.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0                 NotPresent
Rsat.CertificateServices.Tools~~~~0.0.1.0                NotPresent
Rsat.DHCP.Tools~~~~0.0.1.0                               NotPresent
Rsat.Dns.Tools~~~~0.0.1.0                                NotPresent
Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0         NotPresent
Rsat.FileServices.Tools~~~~0.0.1.0                       NotPresent
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0             NotPresent
Rsat.IPAM.Client.Tools~~~~0.0.1.0                        NotPresent
Rsat.LLDP.Tools~~~~0.0.1.0                               NotPresent
Rsat.NetworkController.Tools~~~~0.0.1.0                  NotPresent
Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0               NotPresent
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0            NotPresent
Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0             NotPresent
Rsat.ServerManager.Tools~~~~0.0.1.0                      NotPresent
Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 NotPresent
Rsat.StorageReplica.Tools~~~~0.0.1.0                     NotPresent
Rsat.SystemInsights.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.VolumeActivation.Tools~~~~0.0.1.0                   NotPresent
Rsat.WSUS.Tools~~~~0.0.1.0                               NotPresent

Bu tablodan üç sonuç çıkıyor ve üçü de kurulumu kolaylaştırıyor.

Birincisi, “RSAT” diye tek bir paket yok. Yirmi bir ayrı bileşen var ve her biri bağımsız kuruluyor. Sahada sık duyulan “RSAT’ı kurdum ama grup ilkesi konsolu gelmedi” cümlesinin sebebi neredeyse her zaman budur: paket değil, bileşen kurulur.

İkincisi, State sütunu makinenin gerçek halini gösterir. Yukarıdaki çıktıda hepsi NotPresent, yani bu makinede hiçbir RSAT bileşeni kurulu değil. Kurduklarınız Installed olarak görünmeye başlar; kurulumu doğrulamanın en hızlı yolu aynı komutu tekrar çalıştırmaktır.

Üçüncüsü, adları ezberden yazmayın. Her adın sonunda ~~~~0.0.1.0 biçiminde bir sürüm soneki var ve bu sonek Windows sürümüne göre değişebilir. Adı çıktıdan kopyalayın.

Listedeki bileşenlerin çoğu, çoğu kurumun hiç çalıştırmadığı rollere ait: Rsat.IPAM.Client.Tools, Rsat.StorageReplica.Tools, Rsat.NetworkController.Tools gibi. Active Directory yönetimi için gereken ikisi şunlar: kullanıcı, grup ve bilgisayar nesneleri için Rsat.ActiveDirectory.DS-LDS.Tools, grup ilkesi için Rsat.GroupPolicy.Management.Tools.

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0

Kurulu olmayan her şeyi tek seferde eklemek de mümkün:

Get-WindowsCapability -Online -Name RSAT* |
  Where-Object State -eq 'NotPresent' |
  Add-WindowsCapability -Online

İsteğe Bağlı Özellikler bileşenleri varsayılan olarak Windows Update üzerinden indirir. Makineleriniz güncellemeleri bir WSUS sunucusundan alıyorsa ya da internete kapalı bir ağdaysanız kurulum ilerlemez; teşhisi aşağıdaki hatalar bölümünde ele alıyoruz.

Windows Server’da RSAT: Capability Değil Feature

Windows Server tarafında aynı araçlar var ama kurulum mekanizması farklı ve bu fark sık sık zaman kaybettirir. İstemci Windows’ta bunlar birer capability (İsteğe Bağlı Özellik), Windows Server’da ise birer feature’dır. İkisi ayrı defterde tutulur ve ayrı komutlarla sorgulanır.

Bunu ölçmek için ayrı bir kuruluma gerek yok, istemci tarafının sorgusunu sunucuda çalıştırmak yetiyor. Lab’daki Windows Server 2025 makinesinde denediğimde sonuç boş döndü:

Get-WindowsCapability -Online -Name RSAT*

Hiçbir satır dönmemesi bir arıza değil, hatta doğru cevap. Sunucuda RSAT bileşenleri capability defterinde kayıtlı değil; orada oldukları yer feature defteri. Bu yüzden istemcide işe yarayan Add-WindowsCapability komutu sunucuda karşılığını bulamaz. Doğru komut şu:

Install-WindowsFeature -Name GPMC, RSAT-AD-Tools, RSAT-AD-PowerShell

Kurulumun gerçekten oturup oturmadığını aynı yerden sorabilirsiniz. Lab ortamımızdaki Windows Server 2025 makinesinde üç bileşeni sorduğumda aldığım çıktı şu:

Get-WindowsFeature RSAT-AD-Tools, GPMC, RSAT-AD-PowerShell |
  Format-Table Name, DisplayName, InstallState

Name               DisplayName                                    InstallState
----               -----------                                    ------------
GPMC               Group Policy Management                           Installed
RSAT-AD-Tools      AD DS and AD LDS Tools                            Installed
RSAT-AD-PowerShell Active Directory module for Windows PowerShell    Installed

Bakılacak sütun InstallState ve üç değer alır. Installed bileşenin kurulu olduğunu, Available kurulabilir durumda beklediğini, Removed ise ikili dosyalarının makineden tamamen çıkarıldığını söyler. Sonuncusu kurulum sırasında ayrıca bir kaynak göstermenizi gerektirir, dolayısıyla “komutu çalıştırdım ama kurulmadı” durumunda ilk bakılacak yer burasıdır.

Çıktıdaki DisplayName sütunu ayrıca kullanışlı bir ayrıntı taşıyor: bileşenin adı RSAT-AD-Tools ama görünen adı AD DS and AD LDS Tools. Arayüzde ararken bileşen adını değil bu görünen adı göreceksiniz.

Arayüzden yapmak isterseniz Server Manager → Manage → Add Roles and Features yolunu izleyip Features adımında Remote Server Administration Tools ağacını açın. Roller ve araçlar burada ayrı ayrı listelenir.

İki davranışı bilmek işinizi kolaylaştırır. Birincisi, bir sunucuyu domain denetleyicisine yükselttiğinizde Active Directory yönetim araçları kendiliğinden kurulur; ayrıca eklemenize gerek kalmaz. İkincisi, bir üye sunucuya rolü kurarken -IncludeManagementTools parametresini vermezseniz rol gelir ama onu yöneten konsol gelmez. Rol kurulu olduğu halde konsolun bulunamaması genellikle bu unutulmuş parametredir.

Server Core kurulumlarında konsolların yeri yoktur, çünkü grafik arayüz yoktur. Server Core’u yönetmenin yolu zaten budur: araçları başka bir makineye kurup oradan bağlanmak. Core ve Desktop Experience arasındaki seçimi Windows Server kurulumu yazımızda ayrıntılı ele aldık.

RSAT ile Gelen Konsollar: GPMC, ADUC ve Diğerleri

Kontrol odasını kurmakla iş bitmiyor, sıra panelin kendisini tanımaya geliyor: hangi gösterge neyi ölçüyor, hangi kol neyi çeviriyor. RSAT’ta o panel bir konsol takımıdır ve takımın her parçasının bir dosya adı vardır.

Kurulum bittiğinde konsollar Başlat menüsünde Windows Tools klasörü altında toplanır. Ama sahada kimseyi oradan açarken görmezsiniz: herkes konsolun dosya adını yazar. Win + R ile Run kutusunu açıp dsa.msc yazmak, Active Directory Users and Computers’ı açmanın en kısa yoludur ve bu adlar her Windows’ta aynıdır. Bir belgede ya da bir meslektaşınızın mesajında gpmc.msc gördüğünüzde kastedilen şey budur: kurulu bir konsolu adıyla çağırmak.

Bu tablo bir envanterdir, kullanım kılavuzu değil. Her konsolun kendi derinliği var ve büyük kısmını ayrı yazılarda ele aldık: GPMC ile politika oluşturma, linkleme ve LSDOU sırası grup ilkesi yönetimi yazımızda, ADUC ile kullanıcı, grup ve birim açma kullanıcı ve OU yönetimi yazımızda, domain.msc üzerinden UPN soneki eklemek ise UPN suffix yazımızda anlatılıyor.

Konsolların yanında bir de PowerShell modülü gelir ve uzun vadede asıl kazancınız orada. RSAT-AD-PowerShell bileşeni kurulduğunda Get-ADUser, Get-ADComputer, New-ADUser gibi komutlar kullanılabilir hale gelir. Tek bir kullanıcıyı ararken konsol daha hızlıdır; iki yüz kullanıcıyı bir birimden diğerine taşırken konsol tek başına bir gün yer, aynı iş komutla birkaç satırdır. Domaine katılmış bir bilgisayarın dizinde gerçekten oluşup oluşmadığını Get-ADComputer ile doğrulamayı domaine bilgisayar ekleme yazımızda örnekledik.

Yönetim Araçları Nereden Çalıştırılmalı?

Kural tek cümleye sığıyor: yönetim araçları yönetilen makinede değil, yöneticinin makinesinde çalışır. Ama bu cümlenin iki yarısı var ve sahada ikisi ayrı ayrı ihmal ediliyor: hangi makineden çalıştığınız, ve hangi hesapla çalıştığınız. Bu bölüm birincisini ele alıyor, hemen ardından gelen bölüm ikincisini.

Sahada en sık karşılaştığım manzara şu: sırf bir kullanıcı açmak için domain denetleyicisine uzak masaüstüyle bağlanılıyor. İş iki dakika sürüyor, kimse rahatsız olmuyor, ertesi gün aynısı tekrarlanıyor. Zararsız göründüğü için de kimse durup bunun neye mal olduğunu sormuyor.

Bu alışkanlığın bedeli tek kalemde ödenmiyor. Üç ayrı yerden ödeniyor ve üçü birbirinden bağımsız: birini kapatsanız diğer ikisi işlemeye devam eder.

Birinci katman: güvenlik kaydınız. Microsoft’un ayrıcalıklı erişim rehberi bunu açıkça yazıyor: bir domain denetleyicisine yapılan her etkileşimli ve uzak oturum açma yüksek hassasiyetli bir olaydır ve onaylı liste dışındaki her giriş alarm üretmelidir. Günlük yönetimi sunucuya bağlanarak yapan kurumda bu alarm her gün çalar. Her gün çalan alarm, bir süre sonra alarm olmaktan çıkar; gerçek bir saldırgan aynı kapıdan girdiğinde onun oturumu da kalabalığın içinde sıradan görünür. Yani buradaki kayıp yalnızca risk değil, kurumun kendi erken uyarı sisteminin körelmesidir.

İkinci katman: zamanınız. Güvenliği tamamen bir kenara bırakıp sadece iş yükünü sayın, aynı yere çıkıyorsunuz. Bir kullanıcı açmak için denetleyiciye bağlanmak beş kişilik bir yerde zahmetsiz görünür: günde bir kez olur, birkaç dakika sürer. Beş yüz kişilik bir yerde aynı alışkanlık günün tamamını yer. İşin kendisi zorlaşmaz, yalnızca sayısı artar, ve arkasında hiçbir şey birikmez; ertesi sabah aynı yerden başlarsınız.

Google’ın SRE ekibi bu tür işe bir ad vermiş: toil. Tanımın belirleyici maddesi de tam bizim durumumuz, işin sistem büyüdükçe doğrusal artması. Elle yapılan bir işin tehlikesi zor olması değil, kurum büyüdükçe sizi daha meşgul edip daha yetkin yapmamasıdır.

Üçüncü katman: oturumun taşıdığı yetki. Denetleyiciye bağlanan hesap çoğu zaman ihtiyacından kat kat fazlasını taşır, ve o yetki oturum açık kaldığı sürece makinenin üstünde durur. Bu üçüncüsü aslında bir sonraki bölümün konusu: hangi hesapla bağlandığınız, nereden bağlandığınız kadar belirleyicidir.

Aynı disiplinin protokol tarafındaki karşılığını başka yazılarda ölçtük. LDAP şifresiz bağlantıda parolayı ağda okunur halde taşıyor, HTTP aynısını web girişinde yapıyor, Telnet ise bunu doğrudan cihaz yönetiminde yapıyor. Üçünde de soru aynı: bu kimlik nereden geçiyor ve yolda kim görebiliyor? Yönetim aracını sunucudan indirip kendi makinenize almak da aynı sorunun bir başka cevabıdır. Kimliğin dolaştığı yüzeyi daraltırsınız.

Pratik bir not: yönetim makineniz domaine üye değilse konsolu kendi oturumunuzla açmak yetmez, çünkü konsol sizin oturumunuzun kimliğiyle bağlanmaya çalışır. Bu durumda konsolu yönetim hesabının kimliğiyle başlatın:

runas /netonly /user:AD\yonetim.hesabi "mmc dsa.msc"

/netonly parametresi, verdiğiniz kimliğin yalnızca ağ bağlantılarında kullanılacağını söyler; yerel oturumunuz değişmez. Parolayı yanlış yazarsanız komut hata vermez, konsol açılır ve domaine bağlanamaz. Bu yüzden bağlantı kurulmadığında ilk şüphelenilecek yer parolanın kendisidir.

Yönetim Araçlarını Hangi Hesapla Çalıştırmalı?

Doğru makineden çalışmak işin yarısı. Diğer yarısı, o araçları çalıştıran hesabın günlük işlerinizi yaptığınız hesap olmaması.

Ben yönetim hesabımı normal kullanıcı hesabımdan her zaman ayrı tutarım. Sunuculara girdiğim hesapla kendi bilgisayarımda gezinmem. Bu alışkanlığın kaynağı teknik bir okuma değil, çocukluk: arkadaşlarım birbirlerinin bilgisayarlarına keylogger kurar, eşek şakası olsun diye birbirlerinin sosyal medya hesaplarını ele geçirirlerdi. O yaşta gördüğüm şey basitti ama yıllar sonra hâlâ geçerli. Parolayı almak için sunucuya girmeye gerek yoktu, klavyeyi dinlemek yetiyordu. Bu yüzden klavyemin gördüğü hesapla domainin gördüğü hesabın aynı olmasını hiç istemedim.

Aynı disiplinin gündelik hali, kullanıcı bilgisayarlarında karşınıza çıkan yükseltme penceresidir. Sıradan bir kullanıcı yönetici hakkı gerektiren bir şey yapmaya kalktığında Windows User Account Control penceresini açar ve bir yönetici hesabı ister. Oraya domain yönetici hesabınızı yazmak en kolay yoldur ve tam olarak yapılmaması gereken şeydir: o kimlik artık kullanıcının makinesinden geçmiştir. Ben bunun yerine her zaman o makinenin yerel yönetici hesabını kullandım. Parolası her makine için ayrı üretilip dizinde saklanan bir hesaptı, yani LAPS kurulu bir ortamda zaten hazır bekleyen hesap. Pencere yine açıldı, iş yine yapıldı, ama domain hesabı o klavyeye hiç dokunmadı.

Sahada bu ayrımı çoğu yerde bulamıyorum. Denetleyiciye bağlanan ya da yükseltme penceresine parola yazan hesap çoğu zaman Enterprise Admins ya da Schema Admins üyesi oluyor. Ömründe belki bir kez, orman genelinde bir değişiklik yaparken gerekecek yetkiler, her sabah açılan sıradan bir oturumun üstünde taşınıyor.

Bu hesapların yardım masası işlerinde kullanıldığını da görüyorum. Kullanıcının makinesine gidilir, yükseltme penceresi açılır ve oraya orman düzeyinde yetkisi olan bir hesabın parolası yazılır. O parola üç yoldan açığa çıkabilir. Kullanıcı omzunuzun üstünden bakıyordur. Makinede zaten bir klavye dinleyici vardır. Ya da hiç kimsenin parolayı görmesine gerek kalmaz: o hesapla açılan oturum makinenin üstünde bir kimlik izi bırakır ve makineyi elinde tutan biri, parolayı hiç öğrenmeden o kimliği yeniden kullanabilir. Üçüncüsü en sinsisidir, çünkü hiçbir aşamada “parola çalındı” diyebileceğiniz bir an yoktur.

İlk ikisi yukarıdaki çocukluk hikayesiyle birebir aynı olay, yalnız bedeli farklı. Orada bir sosyal medya hesabı gidiyordu; burada kurumun tamamı gidiyor.

Peki doğrusu ne? Bir kullanıcının parolasını sıfırlamak için Domain Admins üyeliği gerekmez. Active Directory’nin devretme mekanizması, “şu birimdeki hesapların parolasını sıfırlayabilir” kadar dar bir yetkiyi tek başına vermeye izin verir. Yardım masasındaki bir kişiye ihtiyacı olan tek yetkiyi vermek ile domainin tamamını vermek arasındaki fark, bir kutucuk kadar iş ve bir olay müdahalesi kadar sonuç doğurur. Devretme, ADUC içinde bir birime sağ tıklayınca açılan sihirbazdan yapılır ve çoğu kurumda o sihirbaz hiç açılmamıştır.

1.500 cihazlık bir Active Directory geçişinde bu yapıyı tam olarak böyle kurduk: şubelerdeki BT personeline araçları kendi makinelerine kurduk, yetkileri de yalnızca kendi birimleriyle sınırlı olacak şekilde devrettik. Sonuç, merkeze bağımlı olmayan ama kimsenin domain controller’a girmediği bir düzen oldu. Vakanın tamamı Active Directory modernizasyon projesi sayfasında.

RSAT Hangi Dizinleri Yönetir? Windows AD ve Samba AD

Yaygın bir varsayım var: bu araçlar Windows’a özgüdür, dolayısıyla yalnızca Windows Server üzerinde çalışan bir Active Directory’yi yönetirler. Varsayımın ilk yarısı yanlış, ikinci yarısı eksik. İkisini birden düzeltmek, bu araçların ne olduğunu anlamanın da en kısa yolu.

GPMC ya da ADUC bir domaine bağlanırken karşı taraftaki işletim sistemini hiç sormaz. Dört şey konuşur:

1. DNS. _ldap._tcp gibi SRV kayıtlarını sorup domain denetleyicisinin kim olduğunu ve nerede durduğunu bulur.
2. Kerberos. Kimliğinizi doğrulatıp bilet alır, yani parolanız ağda hiç dolaşmaz.
3. LDAP. Dizindeki nesneleri okur ve yazar. Bir kullanıcı açtığınızda giden şey budur.
4. SMB. SYSVOL paylaşımına erişip grup ilkesi dosyalarını okur ve yazar.

Dördü de kendi başına birer protokol ve her birinin nasıl çalıştığını ayrı yazılarda ele aldık; buradaki mesele hangisinin ne yaptığı değil, dördünün birlikte ne anlama geldiği.

Bu dördünü Active Directory’nin beklediği şekilde konuşan her sunucu bu konsollarla yönetilir. İşletim sistemi ölçüt değildir.

Bunu lab ortamımızda ölçtük. Ubuntu üzerinde çalışan bir Samba AD DC ile ayrı bir domain kuruldu, o domainin bir grup ilkesi nesnesi yalnızca samba-tool ile, yani Linux komut satırından oluşturuldu, ve Windows tarafındaki GPMC o domaine bağlanıp aynı GPO’yu açtı, ayarlarını gösterdi ve düzenlenebilir halde sundu. Konsolun tarafında hiçbir özel yapılandırma yapılmadı. Kurulumun tamamı ve ölçüm kayıtları Samba AD DC kurulumu yazımızda.

Ekranda dikkat çeken şey, dikkat çeken hiçbir şeyin olmaması. Konsol bir uyumluluk uyarısı vermiyor, kısıtlı bir kipe düşmüyor, ilkeyi “yabancı” diye işaretlemiyor. Ağaçta Forest yazıyor ve altındaki domain Ubuntu üzerinde çalışıyor; bunu ekrandan anlamanın hiçbir yolu yok, çünkü konsol açısından anlaşılacak bir fark yok.

Ama bu araçlar “evrensel” de değil ve sınır tam olarak şurada: bunlar genel amaçlı bir LDAP istemcisi değildir. OpenLDAP ya da FreeIPA gibi dizinlere doğrultulamazlar. Sebebi eksik bir özellik değil, farklı bir yapı. O dizinler Active Directory’nin şemasını uygulamaz ve SYSVOL diye bir paylaşım sunmaz. ADUC’un okumaya çalıştığı nesne sınıfları orada yoktur; GPMC’nin yazacağı politika dosyasının duracağı yer yoktur. Konsol bir eksiklik bildirmez, sadece bağlanamaz.

Ölçüt bu yüzden “Windows mu?” değil, “Active Directory mi?”. Bunu bir kez yerine oturttuğunuzda, yönetim makinenizin Active Directory ile Windows’un aynı şey olmadığını gösteren en somut kanıt olduğunu görürsünüz.

RSAT Sık Yapılan Hatalar ve Teşhis

Kontrol odası kurulurken tökezlenen yerler bellidir ve ilginç olan şu: neredeyse hiçbiri odanın içinde değildir. Arızaların çoğu odaya giden hatta çıkar. Paket nereden geliyor, isim nasıl çözülüyor, hangi kimlikle bağlanılıyor. Aşağıdakiler sahada en sık karşılaştıklarım.

İsteğe bağlı özelliklerde RSAT hiç çıkmıyor. Neredeyse her zaman sürüm meselesidir: makine Windows Home’dur. Kurumsal bir cihazda beklenmedik bir durumsa, cihazın gerçekten kurumsal imajla kurulup kurulmadığı sorusunu da sormaya değer.

İndirdiğim RSAT paketi kurulmuyor. Eski yöntemi anlatan bir rehberi izliyorsunuz demektir. Güncel Windows 10 ve 11 sürümlerinde ayrı paket indirilmez, indirilen eski paket de kurulmaz. Doğru yol yukarıdaki İsteğe Bağlı Özellikler yoludur.

Kapalı ağda ya da WSUS’lu ortamda kurulum ilerlemiyor. Buradaki cevap Windows sürümüne göre değişir ve bu ayrımı yapmayan bir rehber sizi artık var olmayan bir ayarı aramaya gönderir.

Mekanizma şu: Windows 10 sürüm 1709’dan itibaren WSUS, İsteğe Bağlı Özellik içeriğini yerel olarak barındıramıyor. Sebep bir eksiklik değil, mimari fark. Bu içerik tek tek dosya indirmeye dayanır, WSUS ise servis paketleri dağıtır; Microsoft’un kendi belgesine göre bu iki dosya biçimi birbiriyle uyumlu değildir. Bozulan tek bir dosyayı onarmak için birkaç kilobaytlık parçayı indirmek gerekir, WSUS’un dağıttığı paket ise bunun için tasarlanmamıştır.

Windows 10 1709 ile Windows 11 21H2 arasındaysanız çözüm, isteğe bağlı bileşenlerin doğrudan Windows Update’ten alınmasına izin veren ilkeyi açmaktır: Computer Configuration → Administrative Templates → System → Specify settings for optional component installation and component repair. İnternet erişimi hiç yoksa aynı ilkedeki Alternate source file path alanına bir \sources\sxs klasörü ya da WIM: önekiyle bir WIM dosyası gösterilebilir.

Windows 11 22H2 ve sonrasındaysanız bu ilkeye hiç ihtiyacınız yok. Şirket içi UUP güncellemeleriyle birlikte İsteğe Bağlı Özellik içeriği WSUS üzerinden yeniden sunulmaya başladı. Dahası, o ilkenin içindeki ilgili kutucuklar Windows 11 24H2’de tamamen kaldırıldı. Sürüm sınırlarını Microsoft’un FoD ve dil paketleri belgesi açıkça yazıyor; hâlâ o kutucuğu tarif eden bir rehber okuyorsanız, o rehber eskimiştir.

Konsol açılıyor ama domaini bulamıyor. Kurulum değil isim çözümü sorunudur. Yönetim makinesi domainin DNS sunucusunu kullanmıyorsa konsol denetleyiciyi bulamaz. Buradaki tuzak, hatanın sessiz olabilmesidir: dış dünyaya bakan bir çözümleyici, sorduğunuz iç isme “bulunamadı” demek yerine alakasız bir adres döndürebilir ve o zaman elinizde kendinden emin bir yanlış cevap olur. Kurumsal DNS tasarımını Active Directory DNS yapılandırması yazımızda ele aldık.

Konsol açılıyor, nesneleri görüyorum ama değişiklik kaydedilmiyor. Bu bir kurulum sorunu değil, yetki sorunudur ve aslında sistemin doğru çalıştığının işaretidir. Dizini okumak için sıradan bir domain kullanıcısı yeterlidir; yazmak ayrı yetki ister. Konsolu hangi hesapla açtığınıza bakın.

Sunucudaki bir ayarı konsolda hiç göremiyorum. Yönetim makineniz sunucudan eski bir Windows sürümü çalıştırıyor olabilir. Yeni sunucu sürümleriyle gelen özelliklerin arayüz karşılığı eski konsollarda bulunmaz. Kural basit: yönetim makinesini yönettiğiniz en yeni sunucu kadar güncel tutun.

Sonuç

Yönetim araçlarını kurmak yarım saatlik bir iştir. Asıl iş, sunucuya bağlanma alışkanlığından vazgeçmektir ve o daha uzun sürer, çünkü uzak masaüstü tanıdıktır ve her seferinde çalışır.

Ama iki tarafı yan yana koyduğunuzda hesap net. Kontrol odasını kurmanın bedeli bir kereliktir. Türbinin üstüne her gün çıkmanın bedeli ise her gün ödenir: denetleyiciye açılan her oturum, gerçek bir saldırıyı fark etmenizi sağlayacak kaydın içine bir gürültü satırı daha ekler; her tekrarlanan elle iş, sistem büyüdükçe biraz daha uzar; ve gereğinden geniş yetkiyle açılan her oturum, o makinede bir şey ters gittiğinde kaybedeceğiniz şeyi büyütür.

Kontrol odası zaten kutunun içinde geliyor. Yapılması gereken tek şey onu kurmak ve oraya oturmak.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.