Windows Server 2025: Roller ve Lisanslama

İstanbul Büyükşehir Belediyesi gibi büyük bir belediyenin günlük operasyonunu düşünün. Tek bir çatı altında nüfus hizmetleri, su ve kanalizasyon, toplu ulaşım, itfaiye, çevre sağlığı, zabıta ve onlarca farklı daire başkanlığı çalışır. Her daire kendi uzmanlık alanında hizmet verir, kendi ekibini yönetir, kendi prosedürlerine göre işler; ancak hepsi aynı belediye başkanlığı altında toplanır, aynı bütçe kaynağından beslenir, aynı kurumsal kimlikle vatandaşa görünür. Bir vatandaş nüfus kaydı için bir şubeye, su aboneliği için başka bir birime, imar işlemi için başka bir katta başvurur; hepsinde aynı kurumsal çatı altında işlem yapar.

Kurumsal BT altyapısında Windows Server ekosistemi tam olarak bu belediye rolünü üstlenir. Active Directory kimlik yönetir, DNS ad çözümler, DHCP otomatik IP dağıtır, File Server dosya paylaşır, Print Server yazıcıları yönetir, Group Policy masaüstlerini standartlaştırır. Her biri kendi başına bir servistir; ancak hepsi aynı domain çatısı altında birbirine entegre çalışır. Dış ürünlerle karşılaştırıldığında Windows Server’ın gerçek avantajı tek bir rolün üstün olması değil, 10-15 rolün birlikte entegre çalışıyor olmasıdır.

Bu rehber iki soruyu birlikte cevaplıyor. Önce hangisini alacağınızı: sürümler arasındaki farkın nereden çıktığını, çekirdek bazlı lisanslamanın nasıl hesaplandığını, CAL kaleminin neden çoğu bütçede unutulduğunu ve destek takviminin yükseltme planınızı nasıl belirlediğini. Ardından içine ne kuracağınızı: kimlik, ağ, dosya, yazdırma ve yama rollerinin her birinin ne işe yaradığını ve hangi tuzağı barındırdığını.

Windows Server Nedir?

Windows Server, Microsoft’un kurumsal sunucular için ürettiği işletim sistemidir. Masaüstü Windows’tan ayrıldığı yer arayüzü değil, aynı anda onlarca veya yüzlerce kullanıcıya hizmet verecek şekilde tasarlanmış olması ve rol adı verilen servis paketlerini barındırabilmesidir.

Belediye benzetmesini sürdürelim. Masaüstü Windows bir dairedir: içinde bir aile yaşar, kendi işini görür, kimseye hizmet vermek zorunda değildir. Windows Server ise belediye binasıdır. Binanın kendisi tek başına bir şey üretmez; değerini içine yerleştirilen daire başkanlıkları üretir. Nüfus müdürlüğü kurulmadan kimlik verilmez, su idaresi kurulmadan abonelik açılmaz. Sunucuyu kurmak binayı dikmektir, asıl iş hangi rollerin içine yerleşeceğine karar vermekle başlar.

Masaüstü Windows’tan Farkı Nedir?

Fark dört başlıkta toplanır. Birincisi eşzamanlı erişim: masaüstü Windows’un dosya paylaşımı aynı anda sınırlı sayıda bağlantı kabul eder, Windows Server’da böyle bir tavan yoktur, sınırı lisansınız belirler. İkincisi roller: Active Directory, DNS, DHCP, dosya sunucusu, yazdırma sunucusu gibi servisler yalnız sunucu sürümünde bulunur. Üçüncüsü donanım tavanı: masaüstü sürümler işlemci ve bellek kapasitesinde sınırlıdır, sunucu sürümleri kurumsal donanımın tamamını kullanır. Dördüncüsü destek ömrü: sunucu sürümleri on yıla varan destek takvimiyle gelir, bu da altyapı planlamasının zeminidir.

Sahada en sık gördüğüm hata, bir Windows 11 makinesine klasör paylaştırıp onu sunucu yerine koymaktır. İlk beş kullanıcıda sorun çıkmaz, altıncıda bağlantılar sırayla düşmeye başlar ve kimse sebebini anlamaz. Sorun donanımda değil, işletim sisteminin kendisine konmuş eşzamanlı bağlantı sınırındadır. O sınır aşıldığında karşınıza çıkan hata mesajı diskten, ağdan veya kullanıcıdan bahseder, gerçek sebepten değil.

Sunucuda Masaüstü Olsun mu? Server Core ve Desktop Experience

Windows Server kurulurken sihirbazın sorduğu ve çoğu kurulumda düşünülmeden geçilen bir soru var: Server Core mu, Desktop Experience mı? Seçim sürümden bağımsızdır, Standard da Datacenter da her iki şekilde kurulabilir.

Fark, grafik arayüzün hiç kurulup kurulmamasıdır. Desktop Experience tanıdık masaüstünü getirir: Server Manager, yönetim konsolları, dosya gezgini, tarayıcı. Server Core’da bunların hiçbiri yoktur; makine açıldığında karşınıza komut satırı gelir, yerel yapılandırma için sconfig adlı metin tabanlı bir menü bulunur, gerisi PowerShell’dir. Yönetim uzaktan yapılır: Windows Admin Center, RSAT konsolları veya PowerShell oturumu.

Belediye benzetmesiyle söylersek, Desktop Experience binanın halka açık danışma katıyla birlikte gelmesidir. Server Core ise aynı binanın danışma katı hiç yapılmamış halidir: daire başkanlıkları aynen çalışır, ama içeri yalnız servis girişinden girilir.

Kazanç üç yerde ortaya çıkar. Bellek ve disk arayüzü çizmek yerine servise gider. Kurulu olmayan bir bileşenin açığı sizi ilgilendirmediği için saldırı yüzeyi küçülür. Her ay yamalanacak kalem sayısı azaldığı için yeniden başlatma sıklığı düşer; sürekli ayakta olması beklenen bir domain controller’da bu üçüncü madde ilk ikisinden daha çok hissedilir.

Bir tuzak var ve geri dönüşü yok. Windows Server 2012 döneminde iki kurulum tipi arasında sonradan geçiş yapılabiliyordu. 2016’dan itibaren bu desteklenmiyor: yanlış seçtiyseniz sunucuyu yeniden kurmaktan başka yolunuz kalmaz. Karar kurulum ekranında verilir, sonra değil.

Ne zaman Desktop Experience doğru seçimdir: ekibiniz sunucuyu PowerShell’den yönetmeye alışkın değilse, ya da üstünde çalışacak uygulamanın üreticisi kurulum ve destek için grafik arayüz şart koşuyorsa. Bunlar gerçek kısıtlardır ve “modern olan Core’dur” denerek görmezden gelinmez. Kendi lab ortamımızdaki sunucular da Desktop Experience ile kurulu, çünkü bu rehberlerdeki ekran görüntüleri o arayüzden alınıyor.

Hangi Ölçekten İtibaren Gerekli Olur?

Pratik eşik on bilgisayardır. Bunun altında her makinede ayrı kullanıcı hesabı tutmak, parolaları tek tek yönetmek ve paylaşımları elle vermek katlanılabilir bir yüktür. On makineden sonra bu model sessizce çöker: kimin hangi klasöre eriştiği kimse tarafından bilinmez, işten ayrılan personelin hesabı üç makinede açık kalır, parola politikası diye bir şey kalmaz.

Merkezi yönetim ihtiyacı ortaya çıktığı anda konu Windows Server’dan çok Active Directory’ye kayar; sunucu işletim sistemi o noktada bir amaç değil, kimlik altyapısının üzerine kurulduğu zemindir. Kimlik katmanının nasıl tasarlandığı, forest ve OU yapısından FSMO rollerine kadar Active Directory rehberimizde ele alınıyor.

Sürümler: Standard, Datacenter ve Essentials

Windows Server 2025 üç sürümle geliyor ve aralarındaki asıl fark özellik listesi değil, sanallaştırma hakkı. Yani aynı lisansla kaç işletim sistemi örneği çalıştırabileceğiniz.

Belediyenin imar dairesine geldik. İmar durumu belgesi arsanın üzerine kaç kat çıkabileceğinizi söyler; arsayı satın almış olmanız istediğiniz yüksekliğe çıkma hakkı vermez. Windows Server sürümleri de aynı işi görür: donanımı satın aldınız, ama o donanımın üstünde kaç sanal sunucu çalıştırabileceğinizi sürüm belirler.

Standard ve Datacenter: Ayrım Sanallaştırma Hakkında

Standard sürüm, lisanslanan sunucu üzerinde iki işletim sistemi örneği (fiziksel veya sanal) çalıştırma hakkı verir. Datacenter sürüm ise sınırsız örnek hakkı taşır. İkisi de aynı çekirdek bazlı modelle lisanslanır ve ikisi de CAL ister; fark tamamen üstünde kaç sanal sunucu döndüreceğinizde toplanır.

Hesap basittir. Aynı donanım üzerinde iki sanal sunucu çalıştıracaksanız Standard yeterlidir. Üçüncü ve dördüncü sanal sunucu için ikinci bir Standard lisansı alınır, yani lisans “yığılır”. Sanal sunucu sayısı arttıkça bu yığın bir noktada Datacenter’ın fiyatını geçer ve geçtiği yerde Datacenter almak ucuza gelir. Kesişme noktası donanımınızın çekirdek sayısına ve aldığınız kanala göre değiştiği için burada bir rakam vermiyorum; kendi çekirdek sayınızla iki senaryoyu yan yana hesaplamak dakikalar sürer.

Bu karar sanallaştırma platformu seçiminden bağımsız değildir. Hyper-V zaten Windows Server lisansının içinde gelir, yani Datacenter almış bir kurumun ayrıca sanallaştırma lisansı satın almasına gerek kalmaz. Platform karşılaştırması ve boyutlandırma için hypervisor ve sanallaştırma rehberimize bakabilirsiniz.

Essentials: Küçük Ofis Sürümü ve Sınırları

Essentials, en fazla 25 kullanıcı ve 50 cihaz için tasarlanmış küçük işletme sürümüdür. En belirgin avantajı CAL gerektirmemesidir: erişen kullanıcı başına ayrıca lisans almazsınız. Lisans, tek soketli bir sunucuda 10 çekirdeğe ve tek bir sanal makineye kadar kapsam sunar.

Ama Essentials’ın gerçek sınırı bu sayılar değil, satış kanalıdır: yalnızca OEM’den, yani sunucuyla birlikte satın alınabiliyor. Bunun pratik sonucu şudur: elinizdeki sunucuya sonradan Essentials ekleyemezsiniz. “Küçük ofisiz, Essentials alalım” kararı donanım satın alma anında verilmek zorundadır; o an geçtikten sonra masada kalan seçenek Standard’dır ve bütçe planı bir anda CAL kalemiyle birlikte büyür.

Hangi Sürüm Hangi Senaryoda?

Karar ağacı kısa: 25 kullanıcıyı geçmeyecekseniz ve sunucuyu yeni alıyorsanız Essentials en ucuz yoldur. Sanal sunucu sayınız ikiyi geçmeyecekse Standard’dır. Yoğun sanallaştırma yapıyorsanız ya da yapacaksanız Datacenter’ı baştan hesaplayın; sonradan Standard’dan Datacenter’a geçmek mümkündür ama iki kez ödeme yapmış olursunuz.

Lisanslama: Çekirdek Bazlı Model ve CAL

Windows Server lisanslaması iki ayrı kalemden oluşur ve bunlardan biri neredeyse her zaman unutulur. Birincisi çekirdek lisansı, sunucunun kendisi içindir. İkincisi CAL, sunucuya erişen her kullanıcı veya cihaz içindir. Çekirdek lisansı tek başına yasal bir kurulum oluşturmaz.

İmar dairesi benzetmesi burada tam oturur. İmar durumu binanın kaç kat olacağını söyler; bu, çekirdek lisansıdır, yapıya ilişkindir. İskân belgesi ise binada kaç bağımsız bölümün oturulabilir olduğunu belirler; bu da CAL’dir, kullanıma ilişkindir. Binayı imara uygun diktiniz diye içine sınırsız daire koyamazsınız.

Çekirdek Bazlı Lisanslama Nasıl Hesaplanır?

Kural üç maddedir. Sunucudaki her fiziksel çekirdek için bir lisans gerekir. Bunun fiziksel işlemci başına alt sınırı 8, sunucu başına alt sınırı 16 çekirdek lisansıdır. Lisanslar 2’li ve 16’lı paketler halinde satılır.

Üç örnekle netleşir:

• Tek işlemci, 8 çekirdek: fiili ihtiyaç 8, ama sunucu başına taban 16 olduğu için 16 lisans alınır. Kullanmadığınız 8 çekirdek için ödersiniz.
• Tek işlemci, 24 çekirdek: taban aşıldı, 24 lisans.
• İki işlemci, her biri 6 çekirdek: fiili 12, ama işlemci başına taban 8 olduğundan 16 lisans.

Buradan çıkan ve çoğu kurumun sonradan fark ettiği sonuç şudur: küçük sunucu almak lisans maliyetini düşürmez. 16 çekirdeklik taban, dört çekirdekli mütevazı bir makineyi de aynı yere oturtur. Donanımı küçültüp bütçe kısmayı planlıyorsanız, tasarruf donanım tarafında kalır, lisans tarafında kalmaz.

CAL Nedir, Kullanıcı mı Cihaz mı?

CAL iki türlüdür ve aralarında seçim yapmak bir tercih değil, hesaptır. User CAL bir kullanıcının herhangi bir cihazdan erişmesine izin verir. Device CAL ise bir cihazın herhangi bir kullanıcı tarafından kullanılmasına izin verir.

Kural şu: hangisinin sayısı azsa onu alırsınız.

• Vardiyalı bir üretim tesisinde 60 çalışan var ama ortak kullanılan 20 terminal üzerinden çalışıyorlar. 20 Device CAL yeterlidir.
• Ofiste 30 çalışan var, her birinin dizüstü bilgisayarı, telefonu ve evde masaüstü var. 30 User CAL doğru seçimdir, cihaz saymaya kalkarsanız 90’a çıkarsınız.

İkisini karıştırmak da mümkündür; kurum içinde her iki modeli birlikte kullanmak yasak değildir. Uzak masaüstü kullanacaksanız ayrıca RDS CAL gerekir, o Base CAL’in yerine geçmez, üstüne biner.

Evaluation Sürümü ve Kalıcı Lisansa Geçiş

Windows Server’ın deneme sürümü 180 gün çalışır. Süre dolduğunda sunucu saatlik aralıklarla kapanmaya başlar. İyi haber şu: yeniden kurulum gerekmez, deneme sürümü yerinde kalıcı sürüme çevrilebilir.

Önce mevcut durumu ve hedefleri okursunuz:

DISM /online /Get-CurrentEdition
DISM /online /Get-TargetEditions

İlk komutun çıktısında sürüm adının sonunda Eval görünmelidir. İkinci komut hangi kalıcı sürümlere geçebileceğinizi listeler; istediğiniz sürüm listede yoksa temiz kurulumdan başka yol yoktur. Geçiş tek komutla yapılır:

DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

Essentials farklı davranır, onda slmgr.vbs /ipk <anahtar> kullanılır. Standard’dan Datacenter’a geçiş de kurulumdan sonra istediğiniz an aynı DISM komutuyla yapılabilir.

İki kısıt baştan bilinmelidir. Datacenter deneme sürümü yalnız kalıcı Datacenter’a dönüşür, Standard’a inemezsiniz. Ve 2016’dan bu yana Desktop Experience deneme sürümünden Core kalıcı sürüme geçiş yoktur.

Dikkat: Domain Controller’ı deneme sürümünden kalıcıya çeviremezsiniz. Bu, “önce deneme sürümüyle kurayım, lisansı sonra alırım” diye başlayan AD projelerinin 180. günde çarptığı duvardır ve o noktada elinizde kolay bir çıkış kalmaz. Microsoft’un tarif ettiği yol şudur: kalıcı sürüm çalışan başka bir sunucuya ikinci bir Domain Controller kurulur, FSMO rolleri oraya taşınır, ardından deneme sürümündeki DC’den Active Directory Domain Services kaldırılır. Yani kimlik altyapısını bir kez daha, üstelik saat işlerken taşımanız gerekir. AD kuracaksanız lisansı kurulumdan önce alın.

Sahada En Sık Yapılan Lisans Hatası

En sık karşılaştığım hata CAL’in hiç hesaba katılmamasıdır. Sunucu alınır, çekirdek lisansı doğru sayılır, kurulum yapılır, sistem çalışır. CAL kalemi bütçeye hiç girmemiştir çünkü sunucu çalışmaya CAL olmadan da devam eder; eksiklik teknik bir arıza olarak değil, denetim anında bir uyumsuzluk olarak ortaya çıkar. Kurum o noktada plansız bir maliyetle karşılaşır.

İkinci sık hata, sanal sunucuları saymadan Standard almaktır. “Bir sunucu aldık, bir lisans yeter” varsayımı, üstünde dört sanal makine döndüğü anda geçersizdir.

Bu bölümdeki çekirdek minimumları, CAL kuralları ve sürüm hakları 4 Ağustos 2026 itibarıyla Microsoft’un Windows Server 2025 lisanslama rehberinden doğrulanmıştır. Lisans kuralları değişebilir; satın alma kararı vermeden önce güncel hali kontrol edilmelidir. Bilerek fiyat yazmıyoruz: rakam kanala, bölgeye, kura ve bayiye göre değişir, yayınlanan bir fiyat eskidiğinde yanlış bütçe kurdurur.

Destek Yaşam Döngüsü ve Sürüm Planlaması

Windows Server 2025, Microsoft’un Fixed Lifecycle Policy takvimini izler: destek süresi baştan bellidir, sürüm çıktığı gün bitiş tarihi de yazılıdır.

Mainstream ve Extended Destek Arasındaki Fark

Mainstream dönemde ürün canlıdır: güvenlik güncellemeleri, hata düzeltmeleri, yeni özellikler ve garanti kapsamındaki destek talepleri bu dönemde karşılanır. Extended döneme geçildiğinde yalnız güvenlik güncellemeleri gelmeye devam eder. Yeni özellik gelmez, güvenlik dışı hatalar düzeltilmez.

Planlama açısından anlamlı olan tarih 2034 değil, 2029’dur. Bir sunucu extended döneme girdiğinde teknik olarak çalışmaya devam eder ama artık gelişmeyen bir platformun üzerinde durursunuz; yeni yazılım sürümleri desteklemeyi bırakır, sürücü güncellemeleri seyrelir, uyumluluk sorunları birikmeye başlar. Yükseltme penceresini mainstream bitişine göre planlamak, extended’ın son yılında acele etmekten her zaman ucuzdur.

Destek Dışı Kalan Sunucu Ne Riskler Taşır?

Extended destek de bittiğinde güvenlik güncellemesi kesilir. Bunun anlamı sunucunun bozulması değil, o günden sonra keşfedilen her açığın kapatılmadan kalmasıdır. Saldırgan tarafında ise tam tersi olur: destek dışı kalmış sürümler, yamanmayacakları bilindiği için öncelikli hedef haline gelir.

İkinci ve daha az konuşulan risk uyumluluktur. ISO 27001 denetiminde veya bir siber sigorta poliçesinde “desteklenen bir işletim sistemi kullanılıyor mu” sorusu doğrudan sorulur; destek dışı bir sunucu bulgu üretir. Sertifikasyon süreçlerinde bu kalemin nasıl ele alındığını ISO 27001 rehberimizde anlatıyoruz.

Windows Server Rolleri

Windows Server kutudan çıktığında yalnızca bir işletim sistemidir; asıl işini üzerine yüklenen rollerle görür. Aşağıda bir kurumsal ağın omurgasını kuran rolleri sırayla ele alıyoruz: her birinin ne işe yaradığını, hangi tuzağı barındırdığını ve kendi rehberinde nerede derinleştiğini. Rollerin çoğu birbirine bağımlıdır ve neredeyse tamamı, ilk sıradaki kimlik katmanını varsayar.

Active Directory Domain Services (AD DS)

AD DS, kurumun tüm kullanıcı, bilgisayar ve grup kimliklerini tek merkezde tutan dizin servisidir. Belediyenin nüfus müdürlüğü gibi çalışır: kimlik kaydı tek yerde durur, sorgulama her birimden yapılır.

Bu rehber açısından asıl önemli olan AD DS’in ne olduğu değil, diğer rollerin ona ne kadar bağlı olduğudur. DNS onsuz çalışır ama AD onsuz çalışmaz; domain controller kendini DNS’e kaydeder, istemci de domain’i DNS üzerinden bulur. DHCP dağıttığı adresi AD’de yetkilendirilmeden dağıtamaz. File Server ve Print Server yetkileri AD gruplarından okur. NPS ağa girmek isteni AD’de doğrular. Yani bu sayfadaki rollerin çoğu, AD DS’i varsayarak tasarlanmıştır.

Pratik sonucu şudur: Windows tarafını rol rol değil katman katman kurmak gerekir ve ilk katman kimliktir. AD kurulmadan atılan her adım, sonradan geri dönüp yeniden yapılır. Mimari tasarımdan (forest, domain, OU) FSMO rollerine, replikasyondan güvenlik sıkılaştırmasına kadar kimlik katmanının tamamı Active Directory rehberimizde ele alınıyor.

DNS Sunucusu: Active Directory’nin Adres Defteri

DNS isimleri adrese çevirir, ama Windows Server’da asıl kritik yanı Active Directory ile iç içe olmasıdır: domain üyeleri hangi Domain Controller’a başvuracaklarını DNS kayıtlarından öğrenir, yani DNS kimlik altyapısının adres defteridir. Kerberos, LDAP ve DNS’in neden aynı Domain Controller’da bir arada geldiğini LDAP rehberimizde ele alıyoruz. Bu yüzden AD’li bir ortamda domain üyeleri birincil DNS olarak mutlaka iç Domain Controller’ı kullanmalıdır; ISS’in ya da 8.8.8.8’in birincil yazılması, sahada en sık gördüğüm aralıklı kimlik doğrulama arızasının sebebidir.

DNS’in kendi mekaniğini ve kayıt türlerini DNS nedir rehberimizde, Windows tarafında zone kurulumu, forwarder yapılandırması ve AD entegre replikasyonu ise Active Directory DNS yapılandırma rehberimizde adım adım gösteriyoruz.

DHCP Sunucusu: Otomatik Adres Dağıtımı

DHCP, ağa bağlanan cihaza IP adresini otomatik veren servistir; oteldeki resepsiyon gibi, cihaz adresi elle almak yerine sunucudan belirli süreliğine kiralar. Küçük ofiste modemdeki DHCP yeter, ama çok VLAN’lı ve elli üstü çalışanlı bir kurumda merkezi Windows DHCP çok daha kontrollüdür: rezervasyon, failover ve IP havuzu disiplini ancak orada oturur.

Rol kurulumundan scope, exclusion, rezervasyon ve failover yapılandırmasına kadar adım adım uygulamayı Windows Server DHCP kurulum rehberimizde, adres kiralama döngüsünün protokol tarafını ve 169.254.x.x adresinin ne anlama geldiğini ise DHCP nedir rehberimizde ele alıyoruz.

File Server: NTFS İzinleri, ABE ve Shadow Copy

Bir noterlik arşivini düşünün. Noter ofisi yıllarca binlerce senet, sözleşme, vasiyet ve vekaletname kayıt altına alır; bu belgeler hiçbir zaman masa üzerinde bırakılmaz, belirli kurallar altında arşiv odasında korunur. Her belgenin bir dosya numarası, bir yıl-ay tasnifi ve bir erişim kaydı vardır; kim hangi belgeyi ne zaman çıkardı, ne zaman iade etti noter kayıt defterinde görünür. Belirli belgelere yalnızca noter veya noter yardımcısı erişebilir, bazı dosyaları ise yetkili avukatlar imza karşılığı görebilir; arşiv odasının kapısı gelişigüzel açık bırakılmaz. Bu disiplin yıllar içinde binlerce müşteriye ilişkin kayıtların korunmasını, aranabilirliğini ve yetki kontrolünü aynı anda sağlar.

Windows Server File Server rolü, kurumsal BT altyapısında tam olarak bu noter arşiv disiplinini üstlenir. Kullanıcıların dosyalarını kendi yerel bilgisayarlarında dağınık biçimde tutmak yerine, merkezi bir sunucuda organize edilmiş paylaşımlar altında toplar. SMB (Server Message Block) protokolü üzerinden kullanıcılar ağ üzerinden dosyalara ulaşır; okur, değiştirir, kaydeder. Her klasör için NTFS izinleri ve paylaşım izinleri ayrı ayrı kurulur; hangi kullanıcı veya grubun hangi klasöre hangi seviyede (okuma, yazma, tam yetki) eriştiği matris halinde tanımlanır. ABE (Access-Based Enumeration) özelliği ile kullanıcı yalnızca erişim yetkisi olduğu klasörleri görür, diğerleri gizlenir; bu hem güvenlik hem görsel sadelik açısından önemlidir. Quota ile departman bazlı disk kullanımı sınırlandırılır, File Screening ile belirli uzantıların (örneğin MP3, MP4) kurumsal alana yazılması engellenir.

Bu paylaşımların altında çalışan protokolü, sürüm farklarını ve paylaşım izniyle NTFS izninin nasıl kesiştiğini SMB nedir rehberimizde ele alıyoruz.

Sahada en sık karşılaştığım hata, dosya sunucusunu sadece “ortak alan” olarak kurup yetki matrisini detaylandırmamaktır. Herkesin her şeyi görebildiği bir ortak klasör kaçınılmaz olarak mahrem belgelerin yanlış ellere geçmesiyle sonuçlanır; iş akışları bozulur, muhasebe dosyası pazarlamaya açılır, insan kaynakları dosyası başka bir birime sızar. İkinci kritik hata, dosya sunucusuna yedekleme planı kurmamaktır; fidye yazılımı saldırılarının ilk hedefi dosya sunucusudur, yedeği olmayan bir File Server kurumun en büyük varlığını tek darbede çöpe atar. Doğru kurulum hem yetki matrisini, hem Volume Shadow Copy (VSS) ile zamanlanmış anlık görüntüleri, hem de ayrı bir medyaya düzenli yedekleme yapısını birlikte taşır. Noter arşiv odasına çelik kapı, yangın önleme sistemi ve sigorta koymadan nasıl tamamlanmış sayılmazsa, File Server da yetki, snapshot ve yedekleme üçlüsü olmadan tamamlanmış sayılmaz. Buradaki Shadow Copy’nin adındaki gölgenin, kurumun haberi olmadan kullanılan araçları anlatan gölge BT ile hiçbir ilgisi olmadığını da belirtelim: VSS kurumun kendi kurduğu, kasıtlı ve meşru bir kopyadır.

DFS (Distributed File System)

Ziraat Bankası’nın Türkiye genelindeki 1700’ü aşkın şubesini düşünün. Bir müşteri İstanbul’daki şubede hesap açar, ancak Kayseri’ye seyahat ettiğinde oradaki şubeden aynı hesaba ulaşır, Hakkari’de para çeker, Trabzon’da havale gönderir. Müşteri için bu bir “tek banka deneyimi”dir; hangi şubeye gittiği önemli değildir, “Ziraat Bankası” adı altında her yerde aynı hesaba erişim sunulur. Arka planda ise her şube kendi altyapısına, kendi personeline ve kendi kasasına sahiptir; merkezi sistem şubeler arası işlemleri gerçek zamanlı senkronize eder. Bir şubede yapılan yatırma, diğer şubenin ekranında saniyeler içinde görünür. Müşteri tek bir mantıksal çatı altında hizmet alır, bankacı ise onlarca fiziksel noktanın senkronizasyonuyla ilgilenir.

DFS (Distributed File System), Windows Server ekosisteminde tam olarak bu çok şubeli banka modelinin dosya paylaşımı karşılığıdır. İki ana bileşeni vardır. DFS Namespace (DFS-N), birden fazla fiziksel dosya sunucusunu tek bir mantıksal yol altında birleştirir; kullanıcı \\sirket.com\ortak yazdığında ardındaki dosyalar farklı sunucularda (\\srv01\pazarlama, \\srv02\muhasebe) durabilir, ancak kullanıcı için tek yoldur. Sunucu IP’si değişse, sunucu tamamen başka donanıma taşınsa bile kullanıcı yolu değişmez, kısayollar kırılmaz. DFS Replication (DFS-R) ise birden fazla dosya sunucusu arasında klasör bazlı senkronizasyon yürütür; İstanbul ofisindeki sunucuyla Ankara ofisindeki sunucu arasında Remote Differential Compression algoritması sayesinde yalnızca değişen bloklar aktarılır, WAN bant genişliği verimli kullanılır. Her iki ofisteki kullanıcı kendi lokal sunucusundan hızlı erişir, değişiklikler arka planda eşitlenir.

Sahada DFS’in değeri en net, çok lokasyonlu kurumlarda ortaya çıkar. Tek ofisli bir KOBİ için DFS büyük olasılıkla gereksiz karmaşıklıktır; düz File Server yeterlidir. Ancak fabrika + genel müdürlük, şube ağı veya veri merkezi + uzak ofis modelindeki kurumlarda DFS olmadan kullanıcılar WAN üzerinden dosya çekmek için saatlerce bekler veya her ofis için ayrı manuel dosya taşıma rutini kurulur. Sahada en sık karşılaştığım hata, DFS-R’ı kurulumdan sonra çakışma politikası (conflict resolution) ayarlanmadan bırakmaktır; iki lokasyonda aynı dosya farklı zamanda değişirse birinin değişiklikleri sessizce DfsrPrivate\ConflictAndDeleted klasörüne gömülür, kullanıcı fark etmez. İkinci kritik hata, DFS namespace’ine eklenen hedeflerin Site-aware yapılandırılmamasıdır; Ankara’daki kullanıcı yanlış yapılandırma sayesinde İstanbul’daki sunucudan dosya çeker, ağ trafiği hem pahalı hem yavaştır. Doğru DFS kurulumu AD Site yapısıyla entegre, çakışma politikası tanımlanmış, replikasyon programı ve bant genişliği limitleri iş saatlerine göre ayarlanmış bir yapıdır.

Print Server: Merkezi Yazıcı ve Sürücü Yönetimi

Kariyerimin ilk yıllarında bir kurumda helpdesk olarak çalışıyordum. O dönem kurumda Print Server yoktu; her yeni bilgisayar kurulumunda veya yazıcı değişikliğinde elimde bir USB bellek, masa masa dolaşıyordum. Bellekte onlarca farklı yazıcı sürücüsü vardı; kullanıcının bağlanacağı yazıcının markası ve modeline göre doğru sürücüyü seçmem, bilgisayara kurmam, test sayfası basmam ve bir sonraki masaya geçmem gerekiyordu. Hem ben gün boyu yürüyordum hem kullanıcı o süre zarfında bilgisayarını kullanamıyordu; yeni başlayan bir personel için bazen tek yazıcı kurulumu yarım saati buluyordu.

O kurumda Print Server devreye aldığımda bu iş neredeyse tamamen masa başından çıktı. Print Server üzerinde yazıcıları tanımladıktan sonra Group Policy ile hangi OU veya departmanın hangi yazıcıyı otomatik alacağını tanımlıyordum; kullanıcı bir sonraki oturum açışında yazıcı zaten kurulu, sürücü yerinde, test sayfası basabilir durumdaydı. Masa masa dolaşma faslı neredeyse sıfıra indi; yeni başlayan personele yazıcı kurmak için artık asansöre binmiyordum, ayağımla değil panelden deploy ediyordum. O günden sonra şu kuralı oturttum: kurumda beş yazıcıdan fazlası varsa Print Server tartışma konusu değil, zorunluluktur.

Windows Server üzerindeki Print Server rolü, kurumsal ağda tam olarak bu merkezi baskı merkezini temsil eder. Kullanıcıların bilgisayarlarına ayrı ayrı yazıcı kurmak yerine Print Server üzerinde yazıcılar tanımlanır, sürücüler tek noktada hazırlanır ve Group Policy veya Print Management konsolu aracılığıyla kullanıcılara dağıtılır. Kullanıcı baskı komutu verdiğinde iş önce Print Server’a düşer, sunucu kuyruğa alır, sırayla yazıcıya gönderir; bir yandan print queue yönetimi, print job izleme ve hata raporlama merkezi olarak yürür. Printer Pool yapısı ile aynı işi birden fazla yazıcıya dengeli dağıtmak, Branch Office Direct Printing ile uzak ofislerde baskı trafiğini ağa taşımadan doğrudan yazıcıya yönlendirmek mümkündür.

Sahada en sık karşılaşılan hata, yazıcıların Print Server üzerinden değil doğrudan IP ile kullanıcı bilgisayarlarına kurulmasıdır. Bu model ilk bakışta “zaten çalışıyor” görünür, ancak iki bariz zayıf noktası vardır: sürücü güncellemesi geldiğinde her bilgisayara tek tek gitmek gerekir ve yazıcı IP değişirse onlarca kullanıcı çalışamaz hale gelir. İkinci yaygın hata, farklı marka yazıcıların aynı ortamda gelişigüzel çoğalmasıdır; her marka farklı sürücü stack’i, farklı yönetim paneli ve farklı sarf malzemesi getirir. Marka standardizasyonu sunucu filosunda ne kadar kritikse yazıcı filosunda da o kadar önemlidir; Serçe Bilişim olarak projelerde genellikle iki en fazla üç markaya indirgenmiş bir yazıcı havuzu öneriyoruz. Son olarak Print Server üzerine yazıcı başına yetki matrisi kurmak, renkli baskıyı belirli OU’larla sınırlamak ve aylık sayfa raporunu takip etmek, çoğu kurumun farkına varmadığı ciddi bir maliyet kaleminde belirgin tasarruf yaratır.

NPS / RADIUS: 802.1X Kimlik Doğrulama ve VPN Authentication

NPS (Network Policy Server), Windows’un RADIUS sunucusu rolüdür: ağa bağlanmak isteyen cihazın kimliğini, henüz ağa alınmadan önce Active Directory üzerinde doğrular ve tanımlı Network Policy kurallarından bir karar üretir. Çözdüğü asıl sorun, paylaşılan Wi-Fi ve switch parolalarını ortadan kaldırmaktır: erişim ortak bir sırra değil kişinin AD hesabına bağlanır, hesap kapandığı an erişim de kapanır.

NPS bir üründür; asıl konu onun konuştuğu protokoldür. RADIUS’un ne olduğunu, 802.1X akışını, EAP yöntemlerini ve ağa bağlanamayan bir kullanıcıda izlenecek teşhis sırasını RADIUS sunucusu nedir rehberimizde, aynı işi Linux’ta FreeRADIUS ile sıfırdan kurmayı FreeRADIUS kurulum rehberimizde ele alıyoruz. NPS’in Windows tarafındaki rol kurulumunu ise ayrı bir rehberde göstereceğiz.

AD CS: Kurumun Kendi Sertifika Otoritesi

Active Directory Certificate Services (AD CS), Windows Server’ın sertifika otoritesi rolüdür: kuruma ait sunucular, kullanıcılar ve cihazlar için sertifika üretir ve bu sertifikaların domain üyesi makineler tarafından sorgusuz kabul edilmesini sağlar. Bir sertifika, “bu isim bu anahtara aittir” iddiasının altına atılmış imzadır; imzayı atan makam da CA’dır.

Bu rolün diğerlerinden farkı, kendisi için değil komşuları için var olmasıdır. Listedeki rollerin çoğu doğrudan bir iş yapar: File Server dosya sunar, DHCP adres dağıtır, DNS isim çözer. AD CS ise kimseye görünür bir hizmet vermez, ama üstündeki servisleri mümkün kılar. Domain controller’ın LDAPS’i sertifikasız çalışmaz; NPS’in 802.1X ile ağa aldığı her cihaz, önce NPS’in sertifikasını doğrular; iç web panellerinin HTTPS’i buna dayanır. Sertifikanın olmadığı yerde bu servisler kurulur, portları açılır, ama el sıkışmayı tamamlayamaz.

Kurulumunun da diğer rollerden ayrılan bir yanı var: sihirbazda verilen kararların çoğu geri alınamaz ve yanlışı çoğu zaman aylar sonra, bir servis dururken fark edilir. En pahalıya mal olanı, CA’yı domain controller üzerine kurmaktır.

Sertifika otoritesinin ne olduğunu, güven zincirinin nasıl kurulduğunu ve iç CA ile public CA arasındaki kararı sertifika otoritesi rehberimizde ele aldık. Rolün kurulumunu, geri alınamayan dört kararın hangileri olduğunu, CA’nın neden domain controller’a kurulmadığını ve kurulumun gerçekten çalıştığının nasıl doğrulandığını ise AD CS kurulum rehberimizde adım adım gösteriyoruz.

Web Server (IIS): Sertifikayı Kullanan Rol

AD CS’in ürettiği sertifikaları tüketen rollerin en görünürü web sunucusudur: IIS (Internet Information Services). IIS, Windows Server ile birlikte gelen, ayrı lisans istemeyen web sunucusu rolüdür; iç portalları, yönetim arayüzlerini ve .NET uygulamalarını barındırır. Kurumun kendi CA’sından bastırılan bir sertifikayla HTTPS’e taşındığında, domaine üye makineler siteyi hiçbir tarayıcı uyarısı olmadan açar; sahte bir sayfa ise aynı güveni üretemez.

Bu rolün ilk kez uğraşanı yakalayan yanı kurulum değil, kurulum sonrasının incelikleridir: sitenin çalıştığı application pool kimliğinin klasöre erişim izni, sertifikanın Common Name değil Subject Alternative Name taşıması gerektiği, host header verilen bir sitenin DNS’te ayrıca bir A kaydı istemesi. Bunların her biri “her şeyi doğru yaptım ama açılmıyor” vakalarının kaynağıdır.

IIS’i sıfırdan kurmayı, iç CA’dan SAN’lı sertifikayla HTTPS bağlamayı, SNI ile tek IP’de birden çok siteyi ve sunucu sıkılaştırmasını IIS kurulum ve HTTPS rehberimizde uçtan uca gösteriyoruz.

Yama ve Güncelleme Yönetimi: WSUS Sonrası Dönem

Sağlık Bakanlığı’nın her yıl yürüttüğü ulusal aşı kampanyasını düşünün. Yeni bir aşı veya hatırlatıcı doz piyasaya çıktığında önce küçük bir test grubunda denenir, yan etki profili çıkarılır, dağıtım zinciri kurulur ve ancak sonra milyonlara ulaşır. Soğuk zincir disiplini, dozaj takibi, advers reaksiyon raporlaması ve yaş/risk gruplarına göre önceliklendirme; kampanyanın aksamadan yürümesi için zorunludur. Sağlık otoritesi aynı zamanda geri çağırma (recall) mekanizması da işletir; hatalı parti tespit edilirse saha depolarından çekilir ve yerine güncel parti gönderilir. Bu model, merkezi dağıtım, kontrollü uygulama ve sürekli gözetimin birlikte yürüdüğü bir disiplini temsil eder.

Kurumsal BT’de yama ve güncelleme yönetimi tam olarak bu aşı kampanyası disiplinini ister. Güvenlik yamaları gecikirse saldırgan sızıntı noktasını bulur; yamalar test edilmeden dağıtılırsa bazen uygulama kırılmaları yaşanır; herkese aynı anda uygulanırsa bir hata tüm filoyu aynı anda vurur. Doğru model, Microsoft’un yıllardır önerdiği ring tabanlı dağıtım yaklaşımıdır: önce pilot grup (BT ekibi ve birkaç gönüllü kullanıcı), sonra erken dağıtım (belirli departmanlar), ardından geniş dağıtım (tüm filo). Her halkada birkaç günlük bekleme süresi, telemetri ve hata raporu kontrolü disiplini oturtulur.

Yıllarca kurum içi yama dağıtımında standart araç WSUS (Windows Server Update Services) olarak konumlanıyordu. Ancak Microsoft, Eylül 2024 itibarıyla WSUS’u resmi olarak deprecated ilan etti; mevcut kurulumlar çalışmaya devam ediyor, güvenlik güncellemeleri zaman içinde gelmeye devam edecek, ancak aktif geliştirme durdu ve yeni özellik beklenmiyor. Microsoft’un işaret ettiği yeni yön bulut tabanlı yönetim araçları üzerinden yama orkestrasyonudur. Windows Autopatch Microsoft’un yönetilen servis modelidir, Intune lisansına bağlıdır, özellikle Microsoft 365 E3/E5 abonesi kurumlar için hazır gelir. Microsoft Intune mobil cihaz yönetimi (MDM) üzerinden Windows, macOS, iOS ve Android cihazlara politika uygular; yama dağıtımı bu politikaların bir parçasıdır. Azure Update Manager Azure ve hibrit sunucular için yama orkestrasyonu sağlar; Azure Arc ile on-prem sunucular da kapsama alınır. Windows Update for Business (WUfB) ise daha minimal bir yaklaşım olarak GPO veya Intune politikaları üzerinden Windows Update ayarlarını merkezi kontrol eder; kurum içinde ayrı sunucu kurmak istemeyen KOBİ’ler için pratik bir başlangıç noktasıdır. Üçüncü taraf alternatifler olarak ManageEngine Patch Manager Plus, PDQ Deploy, Automox ve Ivanti özellikle çok işletim sistemli ortamlarda güçlü çözümler sunar.

Saha gerçeği şu: mevcut WSUS kurulumu olan kurumların acil göç etmesi gerekmiyor, ancak 2-3 yıllık BT yol haritasına modern bir alternatifi mutlaka eklemeleri gerekiyor. Sıfırdan kurulum yapan kurumlar bugün WSUS kurmamalı; Microsoft 365 ekosistemi varsa Windows Autopatch + Intune, yoksa en azından WUfB + GPO başlangıç noktasıdır. Test ring disiplini hangi araçla olursa olsun evrenseldir; yamayı pilot gruba 3-7 gün önce bıraktıktan sonra gözetim altında tam dağıtımı başlatmak, yıllar içinde büyük bir sistem kazası riskini sessizce önler. Serçe Bilişim olarak projelerde “hangi aracı kullanıyoruz?” sorusundan önce “hangi ring yapısını kurduk, nasıl test ediyoruz?” sorusunu cevaplamayı bekleriz; araç değişir, disiplin kalır.

Kurulum ve İlk Yapılandırma

Windows Server kurulumu üç aşamada ilerler: sürüm ve lisans kararı, kurulum medyasının hazırlanması, ve sunucu ayağa kalktıktan sonraki ilk yapılandırma. Bu üçünden en çok atlanan sonuncusudur; oysa sonraki her rol onun üzerine kurulur.

İlk yapılandırmada dört şey rol yüklemeden önce oturmalıdır: kalıcı bir sunucu adı, statik IP adresi, doğru DNS tanımı ve senkronize saat. Dördü de sonradan değiştirilebilir görünür ama değildir. Domain Controller kurulduktan sonra sunucu adını değiştirmek ayrı bir prosedürdür; Kerberos beş dakikadan fazla saat farkını tolere etmez ve zaman kayması kimlik doğrulama hatası olarak, saatle ilgisi yokmuş gibi görünen mesajlarla karşınıza çıkar.

Bu bölümde kurulumun kendisini adım adım anlatmıyoruz, çünkü ayrı bir rehberi var. Sürüm seçiminden kurulum medyasının hazırlanmasına, hostname ve statik IP tanımından NTP senkronizasyonu ve temel güvenlik sıkılaştırmasına kadar adım adım uygulama Windows Server kurulum rehberimizde ele alınıyor.

Sonuç: Sunucu Bir Kutu Değil, Bir İmar Planıdır

Windows Server’ı satın alınan bir ürün gibi düşünmek, belediye binasını dikip içine hangi dairelerin gireceğine karar vermemeye benzer. Bina ayakta durur, elektriği gelir, kapısı açılır; ama vatandaş hâlâ hiçbir işini halledemez. Değeri üreten şey binanın kendisi değil, içine yerleşen rollerin birbirini varsayarak çalışmasıdır.

Bu yüzden doğru sıra donanımdan değil karardan başlar. Kaç sanal sunucu çalıştıracağınız sürümü belirler, sürüm ve çekirdek sayısı lisans maliyetini belirler, erişecek kullanıcı ve cihaz sayısı CAL kalemini belirler, destek takvimi de bütün bunların ne kadar süreyle geçerli kalacağını belirler. Dördü birbirine bağlıdır ve dördü de sunucu satın alınmadan önce hesaplanabilir. Sonradan hesaplanmaya kalkıldığında ise seçenekler daralmış olur: Essentials kanalı kapanmış, deneme sürümündeki Domain Controller çevrilemez hale gelmiş, bütçe CAL kalemini görmemiş olur.

Serçe Bilişim olarak kurumsal Windows altyapısı projelerinde ilk oturumu her zaman bu dört soruya ayırıyoruz. Doğru kurulmuş bir Windows Server, üzerine on yıl boyunca rol ekleyebileceğiniz bir zemindir; yanlış lisanslanmış bir Windows Server ise ilk denetimde veya ilk yükseltmede sizi baştan başlatır.

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.