Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2

Windows Server 2016 TP2 DNS Politikaları – Bölüm 1

Windows Server 2016 TP2 DNS Politikaları – Bölüm 2

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Bu ilk bölümde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını inceliyoruz. Makalemizin ikinci ve üçüncü bölümünde de Nano Server kurulumu, yapılandırması ve yönetimi konularını detaylandıracağız.

Yeni İşletim Sistemi Dağıtımı : Windows Server Nano 

Windows Server vNext ile yeni bir işletim sistemi kurulum seçeneği geliyor : Windows Server Nano. Şu an için Windows Server Technical Preview 2 sürümü üzerinde henüz bu seçenek yok. Bundan sonraki çıkacak sürümde gelmesini bekliyoruz.

Windows Server Nano, üzerinde servisleri çalıştırma amacına yönelik, tamamen uzaktan yönetim mimarisine göre tasarlanmış yeni nesil Windows Server sürümüdür. Windows Server Nano, Windows Server işletim sisteminin 64-bit mimaride çalışan, komut satırı tabanlı bir dağıtım. Windows Server 2012 R2 ya da Windows Server 2012 R2 Core’dan farkı konsol arayüzünün olmadığı, mikro servisler için tasarlanmış yeni bir dağıtım.

Windows Server mühendislerinin deyimi ile Nano Server, “Windows NT 3.5’den bu yana en önemli değişiklik” olarak görülüyor.

Windows Server Core sürüme göre işletim sistemi çekirdeği ya da bir diğer ifade ile disk yüzeyinde kapladığı alan daha da küçültülmüş bir sürüm. Windows Server 2012 R2 Core sürümü için kapladığı alan 4 GB iken, Windows Server Nano için bu değer 0.4 GB boyutunda.

Windows Server ve Windows Server Nano karşılaştırıldığında elde edilen sonuçlar:

Yüzde 93 daha küçük VHD boyutu

Yüzde 92 daha az kritik güncelleme gereksinimi

Yüzde 80 daha az yeniden başlatma gereksinimi

Yaklaşık 1 TB RAM’e sahip Nano Server üzerinde 1000 Nano Server sanal sunucu (VM) koşturma deneyimi

Server Core sürümünün yirmide bir (1/20) boyutunda. 8.3 GB boyutundaki Server Core 410 MB’a iniyor!

Server Core ile 300 sn. olan kurulum zamanı 40 sn.’ye düşüyor.

Not : Bu rakamlar yapılacak yeni optimizasyonlarla RTM sürümünde daha da aşağıya düşebilir.

Bu kazanımlar aşağıdaki aksiyonlarla sağlanmış durumda:

Nano Server üzerinde Grafik arayüzü bileşenleri kaldırılmış

Nano Server üzerinde 32-bit desteği (WOW64) kaldırılmış

Nano Server üzerinde MSI ve Server Core bileşenlerinden çoğu kaldırılmış

Nano Server’ın yerel konsol oturumu açma desteği yok

Nano Server’a uzak masaüstü oturum açma desteği yok

Nano Server üzerinde .NET Framework’ün refactor edilmiş hali olan .NET Core bileşeni geliyor. Bu .NET Core içerisinde de CoreCLR runtime temel bileşeni ile geliyor.

Nano Server üzerinde Core PowerShell bileşeni geliyor. Core PowerShell de PowerShell’in CoreCLR üzerinde çalışacak şekilde refactor edilmiş hali. Tam olarak PowerShell kod uyumluluğunu destekliyor. PowerShell Remoting ile uzak bağlantıda Invoke-Command, New-PSSession, Enter-PSSession gibi cmdletler tamamen destekleniyor. Core Engine bileşenlerinin çoğu destekleniyor. İlk başlangıçta cmdlet sayısı sınırlı. Zaman içerisinde cmdletler de zenginleşiyor olacak.

Nano Server yönetimi tamamen uzaktan Server Manager vb. yönetim konsolları, PowerShell ya da WMI ile sağlanıyor.

Nano Server uzaktan yönetimi için Microsoft tarafından özel olarak tasarlanmış yeni nesil web-tabanlı yönetim konsolu geliyor. Bu konsol uzaktan yönetimi yapacak Windows Server 2016 üzerinde çalışıyor olacak. Bu yeni nesil konsol ile sadece Nano Server değil Core ve GUI tabanlı Windows Server işletim sistemlerinde çalışan sunucular da yönetilebiliyor olacak.  Bu konsol içerisinden yönetilebilecek bileşenlerden bazıları:

Task Manager

Registry Editor

Event Viewer

Device Manager

Sconfig

Control Panel

File Explorer

Performance Monitor

Disk Management

Users/Groups Manager

Nano Server’a sonradan isteğe bağlı Windows Rol ya da feature DISM (Deployment Image Servicing and Management) aracı kullanılarak eklenebiliyor. Fakat bu rol ya da feature’lara ait binary’ler işletim sistemi üzerinde mevcut değil.

Nano Server sistemlerinin yönetimi, kontrol ve izlemesi için PowerShell Desired State Configuration bileşeni kullanılıyor.

Nano Server üzerinde geleneksel Windows uygulamaları şu an için desteklenmiyor ve gelecekte de desteklenmeyeceği belirtiliyor. Çıkış amacı altyapı servisleri için (Hyper-V, File Server, Clustering, Web Server vb.) tasarlanmıştır.

Nano Server ile C#, Java, Node.js, Python, MySQL, OpenSSL, Ruby (2.1.5), SQLite, Nginx gibi uygulama dilleri ve runtime platformları da desteklenmektedir.

Nano Server fiziksel, sanal, Windows Server container ya da Hyper-V Container platformalarında destekleniyor.

Nano Server, uzaktan dosya transferi, uzaktan script çalıştırma, Visual Studio vb. araçlarla uzaktan hata giderme (debugging) operasyonlarını da destekliyor.

Windows Nano Server, Core Edition’da olduğu gibi Windows işletim sisteminin kurulum seçeneği olarak gelecek.

Nano Server özellikle uzun yılların birikimi, müşteri talepleri ve bulut teknolojilerinin geldiği nokta ile ön görülen yol haritası da göz önünde bulundurularak aşağıdaki ihtiyaçlara cevap verecek şekilde geliştiriliyor:

Mümkün olan en minimum seviyede yama ve yeniden başlatma ihtiyacı

İşletim sistemi imajlarında çok daha küçük boyutlar

İşletim sistemi hazırlanması ve provizyonlama sürecinde mümkün olan en az kaynak kullanımı (özellikle bulut mimarisine hizmet veren sunucular için)

Windows Server sürücü desteği Nano server için de geliyor.

İşletim sistemi provizyonlama süresinin daha da azaltılması

Sunucu rolleri ve isteğe bağlı feature’ların Nano Server dışına çıkartılması

Yerel yönetim araçları yerine web tabanlı grafiksel yönetim araçları (Azure Portal benzeri)

Nano Server üzerinde gelen rol ve feature’lar : Hyper-V, Clustering, Storage rolleri, Core CLR, ASP.NET vNext, PaaSv2 ve Container’lar.

Nano server üzerinde yerleşik olarak Antimalware koruması geliyor.

Windows Nano Server gelecek kuşak bulut altyapı ve uygulamalarının üzerine inşa edileceği önemli bir sürüm. Güçlü altyapısı ile hem modern bulut altyapılarını güçlendirecek özellikleri barındırması hem de bulut tabanlı uygulamalar için optimize edilmiş olması Windows Nano Server’ı öne çıkaran yenilikler.

Windows Server 2012 ve sonrasında Windows Server Core ve Windows Server GUI modları arasında dönüşüm ya da geçiş feature ekleme ya da kaldırma ile mümkün olabiliyordu. Fakat aynı durumunda Nano Server için olmayacak. Nano Server rol ya da feature desteği şu an için sınırlı sayıda. Core Edition ya da GUI sürümler üzerinde desteklenen belli bir kısmı zaman içerisinde de destekleniyor olacak.

Nano Server, şu anki Windows Server Technical Preview 2 sürümünde kurulum ekranında henüz bir seçenek olarak gelmiyor. Bunun sebebi de Nano Server işletim sistemi imajının sürücülerle özelleştirilme gereksinimidir. İleriki TP sürümlerinde ya da RTM sürümünde kurulum seçeneklerinden bir tanesi olacak. Fakat şu an için işletim sistemi medyası içerisinde NanoServer klasörü altında .wim imajı geliyor. Bunu kullanarak Nano Server işletim sistemi imajı hazırlanabilir.

Makelemizin ikinci bölümünde adım adım bunu gerçekleştiriyor olacağız.

Nano Server İstatistik Sonuçları:

Yama ve Servis Kalitesinde Açık Ara Önde:

Aşağıdaki grafiklerde de görüldüğü gibi 2014 yılı içerisinde “Important” kategorisinde Windows Server Full GUI sürümü için 26, Core sürümü için 23 güncelleme yayınlanırken, eğer Nano Server kullanıyor olsaydık bu rakam 9’a iniyor. Yine “Critical” kategorisinde Windows Server Full GUI sürümü için 23, Core sürümü için 8 güncelleme yayınlanırken, eğer Nano Server kullanıyor olsaydık bu rakam 2’e iniyor. Bu güncellemeler sonrasında da yeniden başlatma ihtiyacı rakamlarına baktığımızda Windows Server Full GUI sürümü için 11, Core sürümü için 6, eğer Nano Server kullanıyor olsaydık da 3 kez sistemi yeniden başlatıyor olacaktık.

Dolayısıyla Nano Server daha az güncelleme gereksinimi ile çok daha minimum seviyede yeniden başlatma ihtiyacı ile yüksek oranda hizmet servis kalitesine sahip.

Çok Daha Güvenli:

Yine aşağıdaki grafiklerde de görüldüğü gibi Windows Server Core sürümü açılış sürecinde 98 adet sürücü yüklerken, eğer Nano Server kullanıyor olsaydık bu rakam 73’e iniyor. Yine Server Core sürümü üzerinde çalışan servis sayısı 46 iken, Nano Server kullanıyor olsaydık bu rakam 22’ye iniyor. Server Core sürümü üzerindeki açık port sayısı 31 iken, Nano Server ile bu rakam da 12’ye kadar düşüyor.

Bu rakamlar da gösteriyor ki, Nano Server çok daha hızlı ve performanslı bir çalışma mimarisine sahip, gereksiz tüm servislerin minimal seviyede işletildiği, sadece çalıştırdığınız rollerin ihtiyacı olan servislerin koşturulduğu, güvenlik olarak da gereksiz tüm erişim portlarının kaldırıldığı ve çok daha güvenli bir mimaride gelen yeni bir sürüm.

Kaynak Utilizasyonunda Daha Verimli:

Kaynak kullanımı açısından elde edilen aşağıdaki istatik rapolarına göre de Server Core sürümü üzerinde çalışan Process sayısı 26 iken Nano Server ile bu rakam 21’e düşmüş. Açılışta Server Core tarafından yapılan IO miktarı 255MB iken, Nano Server ile bu rakam 150 MB’a  düşürülmüş. Server Core üzerinde kernel memory kullanımı 139 MB iken, Nano Server ile bu değer de 61 MB’a inmiş.

Kurulum ve Yaygınlaştırmada Muhteşem Sonuçlar:

Şu ana kadar incelediğimiz Nano Server işletme sürecindeki tüm istatistiki raporlara paralel kurulum sürecindeki rakamlar da net olarak Nano Server’ın gücünü ve farkını ortaya koyuyor.

Server Core için 300 sn. olan kurulum süresi, Nano Server ile 40 sn.’ye yani yaklaşık 7.5 katına indirgenmiş durumda. Disk üzerinde kapladığı alan bakımından Server Core 4.84 GB iken, Nano Server 400MB’a yakın bir değer, yani 10 katında da aşağıda bir disk alanı kullanımı söz konusu. Sanal sunucu (VM) olarak disk kullanım boyutlarını karşılaştırdığımızda da Server Core için elde edilen değer 6.3 GB iken Nano Server için bu rakam sadece 410 MB. Disk alanı kullanımında da Nano Server açık ara önde ve müşterinin beklentilerine cevap verecek boyutlarda. 

Bütün bu rakamlar gösteriyor ki, Nano Server için önemli derecede mühendislik çalışmaları yapılmış, işletim sistemi kaynak tüketimi yönüyle minimal seviyelere indirgenmiş buna karşın hızlı başlama süreci, artırılmış güvenlik, daha az güncelleme gereksinimleri vb. değerlerle özellikle sanallaştırma ve bulut mimarileri için önemli bir süreci başlatacağı gözüküyor.

ÖZETLE :

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü olacak olan “Windows Server Nano’yu” inceliyoruz. İlk bölümde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını inceledik. Makalemizin ikinci bölümünde de Nano Server kurulumu, üçüncü bölümde de yapılandırması ve yönetimi konularını detaylandıracağız.Makalemizin ikinci bölümünde görüşmek üzere esenkalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

 Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2

Windows Server 2016 TP2 DNS Politikaları – Bölüm 1

Windows Server 2016 TP2 DNS Politikaları – Bölüm 2

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Makalemizin ilk bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiştik. Makalemizin bu bölümünde de Nano Server kurulumunu gerçekleştireceğiz.

Bu bölümde ele alacağımız konular:

Windows Nano Server Kurulumu ve Yapılandırması

İhtiyacınız olan paketlerle Nano Server imajının hazırlanması

İlave aygıt sürücülerinin eklenmesi

Unattend.xml katılımsız kurulum dosyası ile yaygınlaştırılması

Nano Server İle Çalışmaya Başlamak

Nano Server bulut tabanlı veri merkezi altyapılarında en iyi performans ve güvenlik standartlarına göre optimize edilmiş, uzaktan yönetim modeline göre tasarlanmış Windows sunucu ailesinin yeni nesil işletim sistemi dağıtımıdır.

Windows Nano Server karakteristik özellikleri:

Yerel olarak oturum açma yeteneği yoktur.

Uzak masaüstü bağlantısı ile oturum açma yeteneği yoktur.

Çok düşük boyutta disk alanı kullanır.

Çok hızlı kurulur.

Diğer Windows Server sürümlerine göre çok daha az yeniden başlatma ihtiyacı duyar.

Nano Server'ın ideal olarak kullanılabileceği senaryolar:

Cluster ya da Stand-alone mimaride çalışan Hyper-V Host Sunucusu

Scale-Out File Server (SOFS) yapıları için Storage Host Sunucusu

Tamamen bulutta geliştirilmiş uygulamalar için Container ya da sanal işletim Sistemi (VM ya da Hyper-V guest)

Nano Server Mimarisinde Paketlerle Rol ve Feature Eklenmesi

Windows Server 2016 Technical Preview sürecinde Nano Server işletim sistemi medyası içerisinde NanoServer klasörü içerisinde bulunuyor.

NanoServer klasörü içerisinde .wim imajı ve Packages alt klasörü geliyor. Packages klasörü altındaki paket dosyaları kullanılarak Nano Server VHD imajına rol ve feature eklenmesini gerçekleştirip, daha sonra da bu imajdan açılış gerçekleştireceğiz.

Aşağıdaki tabloda Nano Server tarafından desteklenen ve paketlerle eklenebilen rol ve feature listesini görmektesiniz:

WIM İmajınını VHD'ye Dönüştürmek

Öncelikle Windows Server Technical Preview 2 ISO’su ya da medyasi içerisindeki NanoServer klasör içeriğini sunucunuzun ayrı bir klasörüne kopyalayın. Ben bu işlem için C:\NanoServerVHD\ ana klasörünü oluşturdum.

C:\NanoServerVHD\WIM altına da Nano Server WIM imajını kopyaladım.

C:\NanoServerVHD\Packages altına da Nano Server rol ve feature paket dosyalarını kopyaladım.

Şimdi deScript Center adresinden Convert-WindowsImage.ps1 script dosyasını aynı klasör içerisine indirin. Bu PowerShell script medya üzerindeki .wim imajını tanımlanan dosya yoluna VHD imajı olarak dönüştürmemizi sağlıyacak.Şu anki son versiyonunun Windows 10 desteği de gelmiştir. Ben de uygulamalarımı Windows 10 üzerinde gerçekleştiriyorum.

Convert-WindowsImage.ps1 şu an itibariyle Windows 10, Windows 8, Windows 8.1 ya da Windows Server 2012 R2 sistemler üzerinde çalıştırılarak Windows 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 7, Windows 8 ve Windows 8.1 işletim sistemlerine ait ISO ya da WIM imajlarından VHD ya da VHDX imaj üretmeyi sağlıyor. Bunun için işlem yapılan sistem üzerinde Hyper-V rolünün bulunma zorunluluğu da yok. Ben makaledeki adımlarda bir Windows 10 Insider Preview versiyonu üzerinde bu işlemleri administrator hesabı ile oturum açarak gerçekleştiriyorum.

Windows PowerShell komut satırı uygulamasını “Run as administrator” seçeneği ile başlatıyoruz.

Şimdi de aşağıdaki şekilde öncelikle Convert-WindowsImage.ps1 PowerShell script dosyasını çalıştırıyoruz.

Bu şekilde çalıştırdıktan sonra herhangi bir dosya uzantısı kullanmadan Convert-WindowsImage cmdlet ile komutları işletebilirsiniz.

Şimdi de aşağıdaki komutla WIM imajından VHD oluşturma sürecini başlatacağız:

Convert-WindowsImage -Sourcepath <path to wim> -VHD <path to new VHD file> –VHDformat VHD -Edition 1

Komutumuzu çalıştırdıktan sonra VHD imaj oluşturma süreci başlıyor.

Gerçekleştirilen adımlar:

Komut satırında Edition ile verdiğimiz imajın seçilmesi

Boş bir VHD disk oluşturulması

VHD’nin bağlanması

GPT sitili ile yapılandırılıp, bölümlenmesi

Sistem volume oluşturulması

Boot volume oluşturulması

Biçimlendirme işlemleri

İşletim sistemi imajının (Nano Server) VHD’ye aktarımı

VHD’nin bootable olarak yapılandırılması

İmajın kapatılması

İşlem adımları başarıyla tamamlandıktan sonra VHDX klasörü altında VHD dosyamızın başarıyla oluştuğunu görüyoruz.

Eğer VHD değil de VHDX oluşturmak istersek de aşağıdaki komutu kullanabilirsiniz:

Yukarıdaki adımlara benzer şekilde disk bölümleme, biçimlendirme vb. adımlar başarıyla tamamlandıktan sonra VHDX dosyamız hazır hale geliyor.

Aynı klasör içerisinde VHDX imajımız da hazır.

İmajı hazırladığım ana klasör altında dism isimli bir klasör açtım.

Windows Server 2016 TP2 medyasında Sources klasörü içerisindeki aşağıdaki dosyaları dism klasörüne kopyaladım:

api*downlevel*.dll

*dism*

*provider*

VHD ya da VHDx’i mount ederken kullanmak için de yine ana klasör altında MountDir dizini açıyoruz.

Bir paket dosyasını yüklemek için Nano Server VHD'nin bulunduğu dizine gidiyoruz, VHD ya da VHDX imajını mount edip ve DISM.exe Add-Package opsiyonunu kullanarak rol ya da feature ekliyoruz. Ben örnek olarak VHDX için bu işlemleri yapıyor olacağım. Siz benzer adımları VHD paketi kullanıyorsanız onun için de gerçekleştirebilirsiniz. Aşağıdaki örnekte Hyper-V rolü ve temel sürücücülerinin imaj içerisine eklenmesini görüyorsunuz:

cd \NanoServerVHD
md mountdir
dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

Bu komut sonrasında MountDir dizini içerisine Nano Server imajını açıyor.

Şimdi de aşağıdaki komutları çalıştırarak VHD imajı içerisine Hyper-V rolü için gerekli paketleri ekliyoruz:

dism\dism /Add-Package /PackagePath:.\packages\Microsoft-NanoServer-Compute-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\en-us\Microsoft-NanoServer-Compute-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\Microsoft-NanoServer-OEM-Drivers-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\en-US\Microsoft-NanoServer-OEM-Drivers-Package.cab /Image:.\mountdir

İsteğe bağlı olarak Failover Cluster, Storage gibi diğer rol ya da feature bileşenlerine ait paket eklemelerine de devam edebilirsiniz:

Eklenecek rol, feature ya da ilave sürücü kalmadıysa da aşağıdaki komut ile imajı kapatabilirsiniz.

dism\dism /Unmount-Image /MountDir:.\MountDir /Commit

Rol ve feature eklemeleri sonunda imajımızın boyutu biraz daha artmış oldu.

İlave Sürücülerin Eklenmesi

Sahip olduğunuz donanımlar ya da sistem Nano Server sürümünün tam uyumlu çalışması için ilave sürücülere gereksinim duyabilir. Nano Server'a bu ilave sürücüleri eklemeden önce, yukarıda gerçekleştirdiğimiz adımlarla temel sürücüleri ilave edin ve Nano Server'ı VHD'den açmayı deneyin. Eğer sonuç başarısız olursa ya da sürücülerden dolayı sorunlar yaşarsanız bu durumda aşağıdaki adımları gerçekleştirerek ilave sürücüleri ekleyebilirsiniz:

Nano Server kurulumunu yapacağınız fiziksel sunucu üzerine Windows Server 2016 TP2 kurulumunu yapın.

Device Manager açın ve aşağıdaki kategorilerde bulunan aygıtları tanımlayın:

Network adapters

Storage controllers

Disk drives

Bu kategorilerdeki her aygıt için Properties'den Driver tabına geçip Driver Details tıklayın.

Sürücü dosyası adı ve yolunu not edin. Örneğin; e1i63x64.sys isimli dosya için C:\Windows\System32\Drivers konumu gibi.

Komut satırında dosya adını arattırın ( dir e1i*.sys /s /b). Bu örnekte sürücü harfi aynı zamanda C:\Windows\System32\DriverStore\FileRepository\net1ic64.inf_amd64_fafa7441408bbecd\e1i63x64.sys konumundadır.

Run as admin ile komut satırına geçin ve Nano Server VHD'nin bulunduğu dizine gidip aşağıdaki komutları çalıştırın:

md mountdir

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /Add-Driver /image:.\mountdir /driver: C:\Windows\System32\DriverStore\FileRepository\net1ix64.inf_amd64_4d8ace23eb3ebde1

dism\dism /Unmount-Image /MountDir:.\MountDir /Commit

Yukarıdaki adımları ihtiyacınız olan tüm aygıt vb. sürücüler için gerçekleştirin.

Nano Server Yapılandırması

Yapılandırmayı tamamlamak için, bilgisayar adı ve Administrator şifresi tanımlanır.Bu görevleri tamamlamak için en iyi yol Unattend.xml dosyasını kullanmaktır. Örnek Unattend.xml dosyasında offlineServicing bölümünde bilgisayar adı, oobeSystem  bölümünde Administrator şifresi, specialize bölümünde de takım adı ve organizasyon kaydediliyor ve yapılandırılıyor. Fakat Nano Server'i domaine üye yapmıyor. Bu değerleri kendi ihtiyacınıza göre düzenleyebilirsiniz.

Bu örnekte offlineServicing bölümü DISM komutunu çalıştırır çalıştırmaz uygulanıyor, diğer bölümler sunucu ilk başlatıldığında imaja ekleniyor.

Not :

Bu haliyle Unattend.xml dosyası Nano Server'ı domaine üye yapmaz. Dolayısıyla bu dosyayı Nano Server'ı stand-alone rolünde Workgroup ortamında çalışan sunucu olarak hazırlar. Domaine üye yapma aksiyonunu sizin ayrıca gerçekleştirmeniz gerekiyor. ComputerName ve AdministratorPassword değerleri sadece anlık örnekler.

Bu Unattend.xml dosyası Windows 10 Technical Preview ya da Windows Server Technical Preview öncesi versiyonlarda çalışmaz.

Düzenleme yapılmış ve hazırlanmış unattend.xml dosyasını C:\NanoServerVHD klasörüne konumlandırın.

VHDX ya da VHD imajını mount edin ve admin yetkisi ile açılmış komut satırında aşağıdaki komutları çalıştırarak offlineServicing ayarlarını uygulayın:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /image:.\mountdir /Apply-Unattend:.\unattend.xml

Şimdi de kurulum esnasındaki dosyaları depolaması için "Panther" isimli bir klasör oluşturup, Unattend.xml dosyasını da buraya kopyalıyoruz ve sonrasında VHD'yi aşağıdaki komutlarla unmount ediyoruz:

md .\mountdir\windows\panther
copy .\unattend.xml .\mountdir\windows\panther

Bu işlemden sonra tekrar aşağıdaki komut ile imajı kapatıyoruz.

dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

Bu VHDX ile Nano Server ilk açtığımızda belirttiğimiz diğer ayarlar da uygulanmış olacaktır.

Artık VHDX imajımız açılışa hazır. Bunu Hyper-V konsolunda bir Virtual Machine oluşturup disk olarak bağladıktan sonra Nano Server ile çalışmaya başlayabiliriz.

Nano Server sunucumuz açıldıktan sonra şimdi bir bağlantı testi ile erişimi gerçekleştireceğiz.

Öncelikle aşağıdaki komutla Nano Server sunucu ip adresini bağlanılacak güvenilen host listesine ekliyoruz:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.1.53 -Concatenate

Nano Server sunucumuza bağlanmak için de Enter-PSSession cmdlet kullanıyoruz. Unattend.xml dosyasında administrator hesabı için belirttiğimiz şifreyi girip OK ile onaylayınca bağlantı gerçekleşmiş olacak.

Nano Server sunucumuza bağlantı sağladıktan sonra PowerShell komut satırından desteklenen tüm cmdletleri kullanarak uzaktan yönetimi gerçekleştirebilirsiniz.

Örneğin Nano Server üzerindeki modül listesini kontrol edelim:

Gördüğünüz gibi temel modül bileşenleri geliyor.

PowerShell.exe çağırdığımızda Nano Server üzerinde de otomatik modül yükleme özelliği ile CoreCLR altındaki temel modülleri hafızaya yüklediğiniz görüyoruz.

$PSVersionTable ile gelen versiyon bilgisi:

PowerShell Remoting bağlantımız aktif iken Nano Server üzerinde Windows Firewall aşağıdaki komutlarla devre dışı bırakıyoruz.

Nano Server paylaşımlarına başarıyla erişim sağladıyabildiğimiz test ediyoruz.

Event Viewer konsolundan Nano Server sunucumuza bağlanıp oluşan olay günlüklerini kontrol ediyoruz:

ÖZETLE:

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceledik. Makalemizin ilk bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiştik. Makalemizin bu bölümünde de Nano Server kurulumu ve ilk yapılandırmasını detaylı olarak paylaştık. Üçüncü ve son bölümde de detaylı yapılandırmalara ve yönetim seçeneklerine devam edeceğiz.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com 

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1
Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2
Windows Server 2016 TP2 DNS Politikaları – Bölüm 1
Windows Server 2016 TP2 DNS Politikaları – Bölüm 2 

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Makalemizin ilk iki bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiş, Nano Server kurulumu ve bağlangıç kontrollerini yapmıştık. Bu bölümde de yapılandırma ve yönetim konularını detaylandırıyoruz:

Bu bölümde ele alacağımız konular:

Uzaktan yönetim araçları ile Nano Server Yönetimi

Nano Server’ın Domaine Üye Yapılması

Nano Server üzerinde Hyper-V yönetimi

Nano Server üzerinde failover cluster kurulumu ve yönetimi

Nano Server Sunucumuzun TCPIP Ayarlarını Yapılandırmak

Şimdi de Nano Sunucumuzun TCPIP ayarlarını yapılandıralım.

Öncelikle mevcut durumda Nano Server sunucumuza yine PowerShell Remoting ile bağlanıyoruz:

Hemen akabinde aşağıdaki NETSH komutuyla mevcut TCPIP yapılandırmasının bir çıktısını alıyoruz:

Burada dikkat etmeniz gereken kısım mevcut durumdaki ağ arabiriminin adı. Bende gelen çıktıda “Ethernet 2” olarak gözüken arabirim. Şimdi bu arabirime sabit ip adresi, alt ağ maskesi (subnet mask), varsayılan ağ geçidi (default gateway) ve DNS sunucu tanımlarını aşağıdaki komutları sırasıyla çalıştırarak yapılandırıyoruz:

Sıra geldi Nano Sunucumuzu domain ortamımıza üye yapmaya.

Nano Server Domaine Üye Yapmak

Online Olarak Nano Server'ı Domaine Üye Yapmak:

Nano Server çalışırken, istediğiniz zaman aşağıdaki adımları gerçekleştirerek domaine üye yapabilirsiniz. Bu işlem için de domain içerisinde çalışan bir Windows Server Techical Preview sistemine sahip olmanız gerekiyor.

Windows Server TP versiyonunda domaine üye ve hali hazırda çalışan bir sunucudan aşağıdaki komutu kullanarak bir data blob çıkartıyoruz:

djoin.exe /provision /domain <domain-name> /machine <machine-name> /savefile .\odjblob

Bu komut oluşan data blob'unu "odjblob" isimli dosyaya yazar.

"odjblob" dosyasını aşağıdaki komut ile Nano sunucusuna kopyalanır.

Bu işlem için aşağıdaki gibi NET USE metodunu da kullanabilirsiniz.

net use z: \\<ip address of Nano Server>\c$

NOT : Eğer net use komutu başarısızlıkla sonuçlanırsa, Windows Firewall kurallarını kontrol etmenizi öneririm. Bunu kontrol etmek için de PowerShell komut satırını admin yetkisi ile açarak aşağıdaki komutları çalıştırın:

$ip = "<ip address of Nano Server>"
Enter-PSSession -ComputerName $ip -Credential $ip\Administrator

Administrator hesabının şifresini girdikten sonra Nano Server sunucusuna uzaktan PowerShell oturumu açmış olacaksınız. Nano Server sunucu adı PowerShell komut satırında göründükten sonra aşağıdaki komutu çalıştırın:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=yes

Komut başarıyla uygulandıktan sonra Exit-PSSession komutunu çalıştırıp PowerShell oturumundan çıkın ve yukarıdaki net use komutunu tekrar çalıştırın. Eğer başarılı olursanız da aşağıdaki komutları da çalıştırarak "odjblob" dosyasını Nano Server sunucusuna kopyalayın.

md z:\Temp
copy odjblob z:\Temp

Windows Powershell komut satırını Admin modunda çalıştırın ve aşağıdaki komutları kullanarak Nano Server sunucusuna PowerShell Remoting ile bağlanın:

$ip = "<ip address of Nano Server>"
Enter-PSSession -ComputerName $ip -Credential $ip\Administrator

Administrator hesabının şifresini girdikten sonra Nano Server sunucusuna uzaktan PowerShell oturumu açmış olacaksınız. Nano Server sunucu adı PowerShell komut satırında göründükten sonra aşağıdaki komutu çalıştırın:

 djoin /requestodj /loadfile c:\Temp\odjblob /windowspath c:\windows /localos

Nano Server sunucusunu aşağıdaki komut ile yeniden başlatın ve PowerShell oturumundan çıkın:

shutdown /r /t 5
Exit-PSSession

Sunucumuz yeniden başladıktan sonra domaine üye olduktan sonra active directory içerisinde bilgisayar hesabı oluşmuş olacak.

Bilgisayar hesabı özelliklerinden işletim sistemi bilgilerini de kontrol ediyoruz:

Gördüğünüz gibi kod adı “Tuva” olan Nano Server, Windows Server TP2 ismi ile 10.0 versiyonu 10074 build numarası ile geliyor.

DNS sistemine NanoServer01 ismiyle dinamik kaydın gerçekleştiğini kontrol ediyoruz:

Bilgisayar hesabı üzerinde sağ tuş Manage ile Computer Management konsoluna uzaktan bağlanabilirsiniz:

Şimdi de Nano Server sunucumuzu Server Manager konsoluna ekleyip uzaktan yönetimi gerçekleştirelim:

Server Manager konsolunda Manage menüsünden Add Servers ile aşağıdaki gibi Nano Server sunucumuzu ekliyoruz.

All Server kategorisi altına Nano Server sunucumuz geldi.

Gelen sağ tuş menüsünden listelenen seçenekleri örneğin; Windows PowerShell kullanarak Nano Server üzerine bağlantı gerçekleştirilebilir.

Windows Nano Sunucusunu Tek Adımda Domaine Üye Yapmak

Yukarıda unattend.xml dosyasının varsayılan durumda Windows Nano Server sunucusunu domaine üye yapmadığını belirtmiştik. Aşağıda domaine üye mevcut bir Windows Server Technical Preview sunucusundan üretilmiş örnek bir data blob dosyasını görmektesiniz. Bu blob içerisinde bilgisayar adını da içermektedir. Dosyanın diğer bölümleri Administrator şifresi ve organizasyonel bilgileri içermektedir.

Öncelikle domaine üye olan bir Windows Server Technical Preview sunucusundan aşağıdaki komut çalıştırılır:

djoin.exe /provision /domain <domain-name> /machine <machine-name> /savefile .\odjblob

“odjblob” isimli dosya açılır (Notepad vb. uygulamalarda) ve içerik kopyalanır ve bu içerik unattend.xml dosyası içerisindeki <AccountData> bölümüne yapıştırılır.

Not : “odjblob” dosya içeriğini unattend.xml dosyasına yapıştırdıktan sonra sonundaki boşlukları sildiğinizden emin olun.

Bu unattend.xml dosyası  C:\NanoServerVHD klasörü altına kopyalanır. Ve aşağıdaki komutlar çalıştırılarak VHD dosyası mount edilip "offlineServicing" bölümündeki ayarlar uygulanır:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /image:.\mountdir /Apply-Unattend:.\unattend.xml

Kurulum esnasındaki Windows sistem dosyaları tarafından kullanılmak üzere "Panther" isimli bir klasör oluşturulur ve unattend.xml dosyası bu klasör içerisine kopyalanır.  Daha sonra aşağıdaki komutlarla VHD unmount edilir:

md .\mountdir\windows\panther

copy .\unattend.xml .\mountdir\windows\panther

dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

Hazırlanan VHD'den Nano Server sunucusunun ilk açılışında diğer ayarlar da otomatik olarak uygulanır.

Windows Nano Server'da Dual-Boot Yapılandırması ve Acil Durum Araçları

Dual-boot aynı sunucu üzerine birden fazla işletim sisteminin kurulması ve açılışta istenilen işletim sisteminden açarak çalışmayı sağlayan bir kurulum modelidir. İhtiyaç durumuna göre hangi sistemden çalışmak istiyorsak o sistemden açarak kullanabilirsiniz. Windows NT tabanlı işletim sistemlerinden günümüze kadar sunucu-tabanlı tüm işletim sistemleri tarafından desteklenen bir özelliktir. Benzer şekilde Windows Nano Server için de dual boot kurulum desteklenmektedir. Windows Nano Server sürümünü başka bir Nano Server kurulumu ya da diğer işletim sistemi sürümleri ile dual-boot yapacak şekilde aşağıdaki adımları gerçekleştirerek yapılandırabilirsiniz:

Windows Nano Server üzerinde Windows Command komut satırını Admin modunda çalıştırın ve aşağıdaki komutu çalıştırarak açılış için yeni bir girdi oluşturun:

bcdedit /copy {current} /d “Nano Server”

Tekrar bcdedit yazın  ve  boot loader girdisi içerisine yeni eklenen ID alanını süslü parantezler dahil kopyalayın.

Aşağıdaki komutları  kopyalanan GUID değeri ile {GUID} içerisindekini değiştirerek çalıştırın:

bcdedit /set {GUID} device vhd=[c:]\NanoServer\NanoServer.vhd

bcdedit /set {GUID} osdevice vhd=[c:]\NanoServer\NanoServer.vhd

bcdedit /set {GUID} path \windows\system32\boot\winload.exe

Eğer Emergency Management Services (EMS) ve Hypervisor daha sonra kullanacaksanız aşağıdaki komutlarla bunları etkinleştirebilirsiniz:

bcdedit /ems {GUID} ON

bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200

bcdedit /set HypervisorLaunchType Auto

Not : Bilgisayarınız için doğru port numarası kullandığınızdan emin olun.

Windows Server Nano İlk Açılışta Çalışacak Komutları Yapılandırmak

Windows Server Nano kurulumu tamamlandıktan sonra ve ilk oturum açılmadan önce Windows %WINDIR%\Setup\Scripts\ dizininde bir arama gerçekleştirilerek SetupComplete.cmd isminde bir dosya olup olmadığını kontrol eder. Eğer bulursa da script'i çalıştırır. Eğer bulamazsa da kurulum normal olarak devam eder. Windows bu aşamadaki aksiyonları ve gerçekleşen adımları Setupact.log dosyasına kaydeder.

Bu özellik bazı aksiyonlar için faydalıdır. Örneğin; ilk açılış sonrasında IP bilgilerini görüntülemek için "SetupComplete.cmd" dosyasını kullanabileceğiniz gibi, Nano Server imajına da sabit bir ip atamak için de kullanılabilir.

SetupComplete.cmd İle IP Bilgisini Görüntülemek

Notepad uygulaması ile "ipconfig" komutunu içeren SetupComplete.cmd isimli bir dosya oluşturun ve bunu NanoServer klasörüne kaydedin.

Aşağıdaki komutları çalıştırın:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir
md .\mountdir\Windows\Setup
md .\mountdir\Windows\Setup\Scripts
copy .\SetupComplete.cmd .\mountdir\Windows\Setup\Scripts
dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

SetupComplete.cmd dosyasını kullanarak sabit ip atamak için SetupComplete.cmd isimli dosyayı düzenleme modunda açın ya da yeni bir dosya açın ve aşağıdaki komutu içerisine ekleyin:

powershell.exe -command "Import-Module C:\windows\system32\windowspowershell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Utility.psd1; Import-Module C:\windows\system32\WindowsPowerShell\v1.0\Modules\NetAdapter\NetAdapter.psd1; $ifa = (Get-NetAdapter -Name Ethernet).ifalias; netsh interface ip set address $ifa static 192.168.1.203"

Not: Yukarıdaki komutta ağ arabirimlerinden ismi Ethernet olan tanımlandı. (-Name Ethernet)

Uzaktan Windows Nano Server Yönetimi

Windows Nano Server %100 oranında uzaktan yönetilen bir işletim sistemi. Yerel bilgisayara oturum açma ya da uzak masaüstü ile (RDP) oturum açma hiçbir şekilde desteklenmemektedir. Bu kısıtlamaların yanında uzaktan çeşitli çözümlerle yönetimi gerçekleştirmek mümkündür. Bu seçenekler:

Windows PowerShell

Windows Management Instrumentation (WMI)

Windows Remote Management

Emergency Management Services (EMS)

Herhangi bir uzaktan yönetim aracını kullanabilmek için Nano Server'ın ip adresini biliyor olmamız gerekiyor. Nano Server ip adresini elde etmek için kullanılan yöntemler:

Nano Server sunucusunun ilk açılışına bir tane otomatik çalışacak BAT dosyası konumlandırıp içerisine de ipconfig komutu eklenmesi sonrasında ilk açılışta komut satırı penceresinde ip bilgisi görüntülenecektir. Görüntülenen ip adresinin bir yere not edilmesi gerekir.

Sunucuya bir seri kablo bağlantısı ile bağlanıp EMS aracı kullanılabilir. Yapılandırma esnasında Nano Server sunucusuna atanan bilgisayar adı kullanılarak ping vb. yöntemlerle öğrenilebilir. Örneğin; ping NanoServer-PC /4.

Windows Nano Server İle EMS Kullanımı

Emergency Management Services (EMS) Windows Server 2003 işletim sisteminden bu yana kullanılan ve sunuculara yerel ağ bağlantısı ya da internet gibi standart ağ bağlantı yöntemleri ile bağlanılamaması durumunda sunuculara yönetim ya da sistem kurtarma amaçlı bağlanmak için kullanılan bir özelliktir. EMS ile doğrudan klavye, ekran ya da fare bağlı olmayan sunucular da yapılandırılabildiği için yerden, enerjiden ve donanım maliyetlerinde de tasarruf sağlamış olacaksınız.Bir başka ifade ile EMS, sunucunuzu uzaktan standart yönetim araçları ile yönetebilecek duruma getirmeyi sağlayan acil kurtarma aracınızdır.

EMS ile gerçekleştirilen aksiyonlara örnek olarak:

Cevap alınamayan sunucuları kurtarmak

Sunucuları kapatma ve açma

EMS aynı zamanda yerden, enerjiden ve donanım maliyetlerinde de tasarruf sağlayarak EMS kullanımı için yönetim bilgisayarı ile Nano Server bilgisayarını birbirine seri bir kablo ile bağlamanız gerekir. Sonrasında da PuTTY.exe gibi non-Microsoft SSH/Telnet gibi bir uzak bağlantı uygulamasına sahip olmanız gerekir.

Windows Nano Server sunucusunu VHD'den açın, ve yönetim sunucusundan Admin yetkisi ile komut satırını açın ve PuTTY.exe çalıştırın. Hız değerini Nano Server yapılandırırkenki değere ayarlayın, bağlantı tipi olarak seri bağlantıyı seçin ve Serial line için PuTTY.exe tarafından kullanılacak uygun değeri girin.

PowerShell Remoting İle Windows Nano Server Yönetimi

Windows PowerShell Remoting özelliği ile Windows Nano Server yönetimi için öncelikle aşağıdakileri sağlamanız gerekir:

Nano Server'ın ip adresini yönetim bilgisayarınızın Trusted Host listesine eklenmesi

Nano Server'ın administrators grubuna bağlantıda kullanılan kullanıcı hesabının üye yapılması

CredSSP aktifleştirilmesi

Nano Server'ın ip adresini yönetim bilgisayarınızın Trusted Host listesine eklenmesi için admin yetkisi ile açılan PowerShell komut satırında aşağıdaki komutu çalıştırın:

Set-Item WSMan:\localhost\Client\TrustedHosts "<IP address of Nano Server>"

Nano Server sunucusuna uzaktan PowerShell oturumu açmak için yine admin yetkisi ile açılan PowerShell komut satırında aşağıdaki komutları çalıştırın:

$ip = “<IP address of Nano Server>”
$user = “$ip\Administrator”
Enter-PSSession -ComputerName $ip -Credential $user

Bu işlem sonrasında Nano Server üzerinde Windows PowerShell komutları kullanılarak yönetim gerçekleştirilebilir.

Not : Windows Server 2016 Technical Preview 2 sürümü ile Nano Server üzerinde normal bir Windows Server Technical Preview üzerindeki gibi tüm Windows PowerShell komutları desteklenmemektedir. Get-Command -CommandType Cmdlet komutu kullanılarak aktif komutların listesi alınabilir.

Nano Server üzerine açılan PowerShell oturumunu Exit-PSSession komutu ile sonlandırabilirsiniz.

WinRM Üzerinden Windows PowerShell CIM Oturumu İle Windows Nano Server Yönetimi

Windows PowerShell ile Windows Remote Management (WinRM)  üzerinden WMI komutlarını çalıştırmak için CIM oturumları kullanılabilir. Windows PowerShell komut satırında aşağıdaki komutları kullanarak CIM oturumları başlatılabilir:

$ip = “<IP address of the Nano Server>”
$ip\Administrator
$cim = New-CimSession –Credential $user –ComputerName $ip

Bağlantı kurulduktan ve oturum açıldıktan sonra WMI komutları kullanılarak yönetim gerçekleştirilebilir. Örneğin:

Get-CimInstance –CimSession $cim –ClassName Win32_ComputerSystem | Format-List *
Get-CimInstance -Query "SELECT * from Win32_Process WHERE name LIKE 'p%'"

Windows Remote Management (WinRM)

Windows Remote Management (WinRM) kullanılarak uzaktan Nano Server üzerinde komutlar çalıştırılabilir. WinRM'in kullanılabilmesi için öncelikle servisin yapılandırılması ve code page ayarlanması yapılır. Bunları da yine admin yetkisi ile açılan komut satırında çalıştırıyoruz:

winrm quickconfig

winrm set winrm/config/client @{TrustedHosts="*"}

chcp 65001

Bu aşamadan sonra artık uzaktan Nano Server sunucusunda aşağıdaki örnekteki gibi komutları çalıştırabilirsiniz:

winrs –r:<IP address of Nano Server> -u:Administrator -p:<Nano Server administrator password>
ipconfig

Windows Nano Server İle Hyper-V Rolü

Windows Nano Server üzerinde Hyper-V Server rolünün kullanımı Windows Server Core sürümü ile iki istisna hariç çok yakın benzerlik göstermektedir:

Tüm yönetim uzaktan gerçekleştirilmeli ve yönetim bilgisayarı Nano Server sunucusunun işletim sistemi ile aynı versiyon ve build numarasında olmalıdır.Hyper-V Manager ya da Hyper-V PowerShell cmdlet'lerin önceki versiyonları desteklenmemektedir.

RemoteFX kullanılamaz.

Şu anki son sürümde desteklenen Hyper-V özellikleri:

Hyper-V rolünün etkinleştirilmesi

Generation 1 ve Generation 2 sanal sistemlerin oluşturulması

Sanal switch'lerin oluşturulması

Sanal sistemlerin başlatılması ve Windows sanal işletim sistemlerinin çalıştırılması

Not: Şu anki Nano Server sürümünde Hyper-V Replica desteklenmemektedir.

Sanal sunucuların canlı aktarımı (live migration) için, sanal sistemin SMB paylaşımı üzerinde oluşturulmalı ya da mevcut sanal sistemlere SMB paylaşımındaki kaynakların atanmalıdır. Kimlik doğrulama yönteminin de doğru biçimde yapılandırılması önemlidir. Bunun için de iki seçeneğimiz bulunmaktadır:

Constrained delegation:

Constrained delegation önceki sürümlerdeki gibi çalışıyor. Detaylı bilgi için aşağıdaki linkleri inceleyebilirsiniz:

Enabling Hyper-V Remote Management - Configuring Constrained Delegation For SMB and Highly Available SMB

Enabling Hyper-V Remote Management - Configuring Constrained Delegation For Non-Clustered Live Migration

CredSSP

Yukarıda PowerShell Remoting ile CredSSP kullanımından bahsetmiştik. Öncelikle Nano Server üzerinde yukarıdaki hazırlıklar yapıldıktan sonra Hyper-V Manager konsolunda “connect as another user” seçeneği ile Hyper-V Manager'ı CredSSP kullanacak şekilde yapılandırılmalıdır. Bunu kullanmış olduğunuz hesap ile aynı olsa bile yapmanız gerekir.

Hyper-V Windows PowerShell cmdlet komutları CimSession ya da Credential parametrelerinde CredSSP ile çalışacak şekilde kullanılır.

Windows Nano Server İle Failover Clustering

Windows Nano Server üzerinde Failover Clustering kullanımı Windows Server Core sürümü ile çok yakın benzerlik göstermektedir. Aşağıdaki noktalara özellikle dikkat etmek gerekir:

Tüm yönetim Failover Cluster Manager konsolu ile ya da Windows PowerShell komutları ile uzaktan yönetilmelidir.

Windows Server'da olduğu gibi cluster içerisindeki tüm Nano Server sunucuların aynı domainin üyesi olması gerekir.

Windows Server'da olduğu gibi cluster yönetimi için kullanılan domain hesabı tüm Nano Server'lar üzerinde Administrator yetkilerine sahip olmalıdır.

Tüm komutlar admin yetkili komut satırlarında çalıştırılmalıdır.

Not: Şu anki Nano Server sürümünde bazı özellikler desteklenmemektedir:

Nano Server sunucularda Cluster Validation Test desteklenmemektedir.

Failover Clustering cmdletler Windows PowerShell üzerinden yerel olarak Nano Server üzerinde çalıştırılamamaktadır.

Hyper-V ve File Server dışındaki cluster rolleri desteklenmemektedir.

Windows Server Technical Preview 2 Failover Clustering özellikleri destekleniyor.

Failover Cluster yönetimi için aşağıdaki PowerShell cmdlet'ler desteklenmektedir:

Yeni bir cluster kurulumu için:

New-Cluster -Name <clustername> -Node <comma-separated cluster node list>

Cluster yapısına yeni bir node eklemek için:

Add-ClusterNode -Name <comma-separated cluster node list> -Cluster <clustername>

Cluster yapısından bir node çıkarmak için:

Remove-ClusterNode -Name <comma-separated cluster node list> -Cluster <clustername>

Scale-Out File Server rolünü eklemek için:

Add-ClusterScaleoutFileServerRole -name <sofsname> -cluster <clustername>

ÖZETLE:

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceledik. Windows Server Nano ile ilgili yeni gelişmeleri sizlerle paylaşmaya devam edeceğiz. Windows Server 2016 ile gelen yenilikleri incelemeye devam edeceğimiz bir başka makalemizde görüşmek dileğiyle sağlıcakla kalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com 

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Authentication Policy (Kimlik doğrulama politikaları) ve Authentication Policy Silo (Kimlik doğrulama politika depoları)” yapı taşlarıdır.  Bu yapı taşları sayesinde hesapların tanımlanan kuralların dışında hareket etmesi engellenmektedir. Özellikle yüksek seviyede yetkiye sahip kullanıcı hesapları ile belirlenen sistemlerde ya da aygıtlarda kullanılabilmesi ya da bu aygıtlardan erişim yapılabilmesi gibi kısıtları sağlamaktadır. Silo tanımlamaları ve Authentication Policy yönetimi active directory içerisinde Active Directory Administrative Center yönetim konsolu ve Active Directory Windows PowerShell cmdlet’ler kullanılarak gerçekleştirilmektedir.

Öncelikle Authentication Policy Silo kavramını biraz açalım. Authentication Policy Silo, sistem yöneticileri tarafından kullanıcı hesabı, bilgisayar hesabu ya da servis hesaplarının atandığı konteynır ya da kap olarak işlev gören yapılardır. Böylece belli hesapların o konteynır ya da kaba uygulanan kimlik doğrulama politika kuralları ile yönetilmeleri ve bu kurallara uygun aksiyon göstermeleri sağlanmış olacaktır. Bu sayede sistem yöneticilerinin kullanıcı hesabı seviyesinde kaynaklara erişimi izleme gereksinimi de azalmış olacak, kötü niyetli kullanıcıların hesap bilgilerini çalarak kaynaklara erişimi de önlenecektir.

Windows Server 2012 R2 ile gelen yeteneklerle özellikle Enterprise Admins, Schema Admins, Domain Admins ve Administrators gibi yüksek seviyede yetkiye sahip kullanıcı hesaplarının authentication policy silo yapı taşları ile kontrol altına alınması ve yönetilmesi hedeflenmiştir. Böylece belirttiğimiz gruplara üye kullanıcı hesaplarının domain içerisinde kullanılabilecekleri alanlar, konumlar, sistemler ya da aygıtlar sınırlandırılmıştır. Authentication Policy Silo yapı taşlarına ilave olarak bu hesapları active directory domaininiz içerisindeki “Protected Users” grubuna da üye yaparak düşük seviyeli kimlik doğrulama protokolleri ve kriptolama algoritmalarının kullanıldığı ortamlardan erişim sağlanmamasını da garanti altına alarak daha güvenli bir ortam oluşturabilirsiniz. “Protected Users” grubunu ayrı bir makalede detaylarıyla ele alıyor olacağız.

Bir diğer bakış açısı ile domain seviyesinde uygulanan Default Domain Policy ayarlarından gelen 10 saat kullanım süresi olan TGT ya da Protected Users grubuna üye olduktan sonra 4 saat kullanım süresi olan TGT sizin ihtiyaçlarınızı karşılamıyorsa Authentication Policy size daha özel TGT ticket kullanım süreleri belirlemenize olanak sağlamaktadır.

Protected Users grubuna üye yapılması önerilmeyen yönetilen servis hesabı ya da  bilgisayar hesapları için korumayı etkinleştirmek istiyorsanız Authentication Policy yapıları bu ihtiyacınızı karşılayacaktır.

Authentication Policy ve Silo yapıları ile yüksek değere sahip hesapların güvenlik ve yönetim anlamında sadece yüksek değere sahip sistemler ya da aygıtlar üzerinden erişimine izin vermiş olacaksınız. Örnek olarak oluşturacağınız, “Tam Yetkili Hesaplar Silo” yapı taşı ile Enterprise, Schema ve Domain Admins hesaplarını kontrol altına alabiliriz. Ve bu siloya uygulanacak kimlik doğrulama politikalarında da domain controller sunucuları ve domain administrator konsolları haricindeki erişim noktalarından şifre (password) ya da smart kart tabanlı kimlik doğrulama yöntemleri ile erişimi kapatabilirsiniz.

Authentication Policy Silo içerisinde hangi hesapların kısıtlanacağı ve bu silonun üyelerine uygulanacak kimlik doğrulama kuralları tanımlanır. Silolar organizasyon yapınızın ihtiyaçlarına göre tanımlanır ve oluşturulurlar. Aşağıdaki tabloda active directory schema içerisinde kullanıcılar, bilgisayarlar ve servisler için tanımlanmış silo listesini görmektesiniz:

Kimlik Doğrulama Politikaları (Authentication Policy):

Authentication Policy nesneleri Kerberos protokolü tarafından sağlanan ticket için (TGT – Ticket Granting Ticket) yaşam ömrü özellikleri ve hesap tipleri için erişim kontrol şartlarını tanımlamak için kullanılır. Authentication Policy ile yapılan kontroller:

Hesaba ait ticket için (TGT) yaşam ömrü yenilenemez olarak ayarlanabilir.

Aygıta oturum açmak için kriter olarak password ya da sertifika kriteri konulabilir.

Kullanıcı ve aygıtların servislere erişimi için kimlik doğrulama sürecine ait belli gereksinim kriterleri uygulanabilir.

Authentication Policy tanımlamalarında kullanılan hesap tipleri:

Kullanıcı Hesapları

Servis Hesapları

Bilgisayar Hesapları

Kullanıcı Hesapları : Koruma altına alınacak yüksek yetki seviyesine sahip kullanıcı hesaplarının mutlaka Protected Users grubuna üye yapılması önerilir. Böylece NTLM gibi zayıf kimlik doğrulama kullanımları kabul edilmeyecektir. Authentication Policy ile kullanıcılara atanan TGT ticket’ın kullanım süresi daha düşük değerlere ayarlanabilir, sadece belli aygıtlardan oturum açabilme ya da erişim yapabilmeye zorlanabilir. Bu temel senaryoların dışında özellikle kimlik doğrulama süreci için karmaşık kriterler de etkinleştirilebilir.

Servis Hesapları : Koruma altına alınacak yönetilen servis hesapları bu kategoriye girmektedir. Yönetilen servis hesapları ile ilgili olarak aşağıdaki makalelerden de detaylı bilgi alabilirsiniz:

Windows Server 2012 R2 İle Stand-Alone Yönetilen Servis Hesapları

Windows Server 2012 R2 ile Group Managed Service Accounts-1

Windows Server 2012 R2 ile Group Managed Service Accounts-2

Authentication Policy yapılarında kullanılan servis hesapları : stand-alone servis hesapları (MSA), group managed servis hesapları (Gmsa) ve bu iki tip servis hesabından türemiş özel hesaplar. Politikalarla bir aygıtın erişim kontrol şartları belirlenerek yönetilen servis hesabı bilgilerinin kullanımı sadece spesifik aygıtlarla sınırlandırılabilir. Servis hesaplarının kesinlikle Protected Users grubuna üye yapılması önerilmez, çünkü tüm gelen kimlik doğrulama istekleri başarısızlıkla sonuçlanacaktır.

Bilgsayar Hesapları : Koruma altına alınacak bilgisayar hesapları ya da bilgisayar hesabı nesnesinden türetilen özel hesap tipleri bu kapsama girer.  Politikalarla erişim kontrol şartları belirlenerek, kullanıcının kimlik doğrulamasına kullanıcı ya da aygıtın özellikleri baz alınarak sınırlılıklar getirilebilir. Bilgisayar hesaplarının da kesinlikle Protected Users grubuna üye yapılması önerilmez, çünkü tüm gelen kimlik doğrulama istekleri başarısızlıkla sonuçlanacaktır. Varsayılan olarak NTLM kimlik doğrulama istekleri reddedilir. Diğer yandan bilgisayar hesapları için TGT ticket yaşam ömrü ya da geçerlilik süresi yapılandırılamaz.

ÖNEMLİ NOT: Authentication Policy sadece belli hesaplara uygulanacaksa bu durumda Silo kullanmadan doğrudan hesaba ilişkilendirilerek de etkinleştirilebilir.

Ortam Gereksinimleri:

Active Directory domain yapısı içerisindeki tüm domain controller sunucular Windows Server 2012 R2 versiyonunda çalışmalıdır.

Active Directory domain fonksiyonel seviyesi Windows Server 2012 R2 seviyesinde olmalıdır.

NOT: Active Directory forest fonksiyonel seviyesi için bir gereksinim zorunluluğu yoktur.

Domain Controller sunucular için Dynamic Access Control (DAC) desteği yapılandırılmalı ve ilgili ayarlar Domain Controllers OU’suna GPO olarak uygulanmalıdır. Bu amaçla aşağıdaki GPO ayarını Default Domain Controllers Policy içerisinden Computer ConfigurationàAdministrative TemplatesàSystemàKDC altından “KDC support for claims, compound authentication, and Kerberos armoring” ayarını etkinleştiriyoruz.

Yukarıdaki adımla Domain Controller sunucular için Dynamic Access Control(DAC) desteğini etkinleştirdikten sonra, domaine üye Windows 8, Windows 8.1, Windows Server 2012 ve Windows Server 2012 R2 sistemler için de Dynamic Access Control (DAC) desteği için Kerberos claim (device claim) yapılandırmasının da yine uygun GPO üzerinden aktifleştirilmesi gerekir. Bunun için de ben Default Domain Policy GPO’su içerisinden Computer ConfigurationàAdministrative TemplatesàSystemàKerberos altından “Kerberos client support for claims, compound authentication, and Kerberos armoring” ayarını etkinleştiriyorum. Siz bu ayarı sadece uygulamak istediğiniz Windows 8, Windows 8.1, Windows Server 2012 ve Windows Server 2012 R2 bilgisayar hesaplarının bulunduğu OU’ya da bağlayabilirsiniz.

Authentication Policy Yapılandırmaları:

Bu başlık altında da adım adım authentication policy ve authentication policy silo yapılarının oluşturulmasını ve uygulanmasını gerçekleştirerek admin yetkisine sahip hesapların sadece belli bilgisayardan sistemlere erişime zorlayarak kısıtlamış olacağız.

Authentication Policy ve Silo yapılandırmaları Active Directory Administrative Center (ADAC) yönetim konsolu üzerinden gerçekleştirilir.

Bunun için ilgili konsolu dsac.exe aracı ile açıyoruz.

ÖNEMLİ NOT : Authentication Policy ve Silo yapılandırmaları Active Directory Users and Computers konsolundan (dsa.msc) yönetilemez.

ADAC konsolunu açtıktan sonra ilk olarak authentication policy silo ve authentication policy oluşturuyoruz. Bu sayede hedeflediğimiz kapsamı tanımlıyor olacağız. Varsayılan durumda herhangi bir silo ya da policy tanımı bulunmamaktadır.

İlk olarak Authentication Policy tanımını yapıyoruz. Bunun için Authentication Policies altında iken Tasks panosundan ya da sağ tuş kısayolu ile Newà Authentication Polices tıklıyoruz.

Karşımıza Create Authentication Policy form ekranı gelecektir.

Burada Display Name kutusunu authentication policy için bir isim tanımlaması giriyoruz. Organizasyon isimlendirme standartlarınıza göre uygun bir görünen isim belirleyebilirsiniz.

Hemen sol bölümde gelen User kategorisine tıklayarak “Specify a Tciket Granting Ticket lifetime for user accounts” seçeneği ile 45 ile 2147483647 (2³¹-1) aralığında dakika cinsinden TGT kullanım süresi belirleyebilirsiniz. Ben şu anda 120 dakikalık süre tanımlıyorum.

Bu ayardan sonra OK ile onaylıyoruz. “Admin Erisim Politikasi” isimli politikamız Authentication Policies altına geldi.

Şimdi de Authentication Policy Silo oluşturacağız. Bunun için de yine ADAC konsolu içerisinde Authentication Policy Silos altında iken Tasks panosundan ya da sağ tuş kısayolu ile Newà Authentication Policy Silo tıklıyoruz.

Yine öncelikle silo için bir görünen isim (Display Name) tanımı yapıyoruz. Bu senaryoda “Admin Silo” isimli tanımımı giriyorum. Ve Silo politikalarının uygulanmasına zorlamak için “Enforce silo policies” seçeneğini seçiyorum. Bu seçenek yerine “Only audit silo policies” seçilmesi durumunda koruma yerine sadece izleme modunda politikalar aktif olacaktır. Yine Permitted Accounts kategorisi altından admin yetkisine sahip kullanıcıların kullandığı bilgisayar hesaplarını ve admin yetkisine sahip kullanıcı hesaplarını listeye Add ile ekliyoruz.

Aynı ekranda Authentication Policy altından “Use a single policy for all principals that belong to this authentication policy silo” seçeneği seçili iken The authentication policy that applies to all accounts in this silo etiketinin yanında gelen liste kutusundan bu siloya uygulanacak authentication policy nesnesini gösteriyoruz. Aşağıdaki şekilde de görüldüğü gibi biz biraz önce oluşturduğumuz “Admin Erisim Politikasi” isimli authentication policy seçiyoruz.

OK ile onaylıyoruz. Authentication Policy Silo konsolda listelendi.

Şimdi de politikanın atanmasını gerçekleştireceğiz. Bu aşamaya kadar henüz authentication policy silo uygulanmış durumda değil. Policy Silo ataması bizim kontrolümüzde manuel olarak gerçekleştirilen bir süreçtir. Policy ataması için yine ADAC konsolu içerisinde oluşturduğumuz Admin Silo isimli Authentication Policy Silo üzerine çift tıklayarak karşımıza gelen Authentication Policy Silo form arayüzünden gerçekleştirilir. Bu ekranda Permitted Accounts altında politikayı etkinleştirmek istediğimiz hesap üzerine çift tıklayarak hesabın özelliklerine gidiyoruz.

Hesap özelliklerinde Silo sekmesine geçiyoruz. Authentication Policy Silo kategorisi altından Assign Authentication Policy Silo seçili iken bu hesabı ilişkilendirmek istediğimiz silo’yu liste kutusundan seçiyoruz.

OK ile onaylıyoruz.

Bu adımları Permitted Accounts listesinde bu politikalardan etkilenmesini istediğiniz tüm hesaplar için ayrı ayrı uygulayabilirsiniz. Bu uygulama ile aslında bu hesaplar için msDS-AssignedAuthNPolicySilo isimli özniteliği (attribute) yapılandırmış olduk.

ADAC konsolundan grafiksel arayüz ile bu atama her hesap için ayrı ayrı gerçekleştirilmesi gerekir. Toplu atamalar için Set-ADAccountAuthenticationPolicySilo isimli PowerShell cmdlet kullanılabilir.

Şimdi uyguladığımız Authentication Policy kuralının testini gerçekleştirelim.

Oturum açma sürecinden sonra KDC tarafından atanan kerberos ticket geçerlilik süresinin Authentication Policy içerisinde belirlediğimiz gibi 120 dakika yani 2 saat olarak geldiğini görüyoruz.

Öncelikle FullAdmin kullanıcısı ile Permitted Accounts listesine eklediğim Windows 8.1 işletim sisteminden oturum açmaya çalıştığımız başarıyla gerçekleştiğini, fakat policy silo kapsamı dışındaki sistemlerden ise oturum açmak istediğinizda aşağıdaki hata ile karşılaştığınızı göreceksiniz:

Windows PowerShell İle Authentication Policy Yapılandırmaları:

Authentication Policy ve Silo yönetimi için kullanılan cmdlet listesini aşağıdaki şekilde elde edebilirsiniz:

Öncelikle Domain Admins grubuna üye olan hesapları “Protected Users” grubuna da üye yaparak koruma altına alıyoruz. Bunun için aşağıdaki şekilde görülen cmdletleri sırayla çalışıtırıyoruz:

Şimdi de Authentication Policy ve Authentication Policy Silo oluşturulmasını gerçekleştiriyoruz:

Aşağıdaki adımda da AuthenticationPolicy’ye “ad://ext/AuthenticationSilo” claim ID için silo eşleştirmesi gerçekleştirerek hangi aygıtlardan işlem yapılacağını belirledik.

Aşağıdaki cmdlet komutları ile de hem Authentication Policy hem de Authentication Policy Silo nesnelerini Enforce moduna aldık:

Bu adımdan sonra test ettiğimizde 2 saatlik TGT atamasının gerçekleştiğini görmüş olacağız. Bu ve benzeri çoğu senaryoyu ihtiyacınıza göre GUI ya da PowerShell cmdletler kullanılarak etkinleştirebilirsiniz.

ÖZETLE :

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Authentication Policy (Kimlik doğrulama politikaları) ve Authentication Policy Silo (Kimlik doğrulama politika depoları)” yapı taşlarıdır. Bu makalemizde bu yapı taşlarını nasıl kullandığımızı uygulamalı olarak inceledik. Bir sonraki makalemizde görüşmek üzere.

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Protected Users” güvenlik grubudur. Bu grup sayesinde üye olan hesaplar için güvensiz kimlik doğrulama protokolleri, zayıf kriptolama algoritmaları ve hassas kullanıcı hesaplarına delegasyon atamaları sınırlandırılarak active directory domain ortamının güvenliği artırılmıştır. Windows Server 2012 R2 ile tanıştığımız bu grubu detaylarıyla bu makalemizde inceliyoruz.

“Protected Users” grubu kurumsal yapı içerisindeki hesap bilgilerini etkin biçimde koruma altına almak ve yönetmek için tasarlanmış özel amaçlı bir güvenlik grubudur. Özellikle domain ortamına oturum açma ile başlayan kimlik doğrulama sürecinde hesap bilgilerine sıkılaştırılmış özel bir koruma sağlar. Bu gruba üye olan hesaplar otomatik olarak koruma altına alınırlar. “Protected Users” grubuna üye olan hesap kısıtlı ya da sınırlı kullanımı olan ve varsayılan olarak proaktif biçimde güvenliği sağlanmış demektir. Normal hesaplar gibi gelişigüzel her bilgisayarda ya da ortamda kullanılamaz. Bu kısıtlardan ya da korumadan etkilenmemenin tek yolu hesabı bu gruptan çıkarmaktır.

ÖNEMLİ UYARI : Servis hesapları ve bilgisayar hesaplarını Protected Users grubuna üye yapmamalısınız. Bu grup bilgisayar üzerinde yerel koruma sağlamaz, zira şifre ve sertifika bilgisi yerel olarak her zaman ulaşılabilir bir durumdadır. Gerek servis hesaplarında gerekse de bilgisayar hesaplarında Protected Users grubuna üye yapılmaları durumunda,  kimlik doğrulama süreci “kullanıcı adı ya da şifre yanlış” şeklinde bir hata mesajı ile başarısızlıkla sonuçlanır.

Sadece domain ortamlarında mevcut olan bu global güvenlik grubu sayesinde Windows Server 2012 R2 ve Windows 8.1 işletim sistemlerinin çalıştığı bilgisayar ya da aygıtlarda kullanılan kullanıcı hesaplarına engellenemez ya da devre dışı bırakılamaz bir koruma sağlanır.

ÖNEMLİ NOT : Protected Users grubunun kullanılabilmesi için active directory schema versiyonunun Windows Server 2012 R2 seviyesi olan “versiyon 69” yükseltilmesi gereken. Ayrıca PDC Emulator rolüne sahip olan domain controller sunucusunun işletim sisteminin de Windows Server 2012 R2 versiyonunda olması zorunludur.

Protected Users grubu ile iki katmanda koruma sağlanır:

İstemci-katmanında koruma : Windows 8.1 ya da üzeri bir işletim sisteminde çalışan bir aygıttan ya da Windows Server 2012 R2 ya da üzeri bir sunucu işletim sisteminden oturum açma esnasında tetiklenir.

Domain Controller katmanında koruma : İstemci katmanında korumaya ilave olarak Windows Server 2012 R2 domain fonksiyonel seviyesinde çalışan domain controller sunucular için de domain controller seviyesinde koruma gerçekleştirir.

ÖNEMLİ NOT: Windows 8.1 istemci işletim sisteminde çalışan aygıtlardan ya da Windows Server 2012 R2 öncesi sunuculardan oturum açan kullanıcı hesapları için Protected Users grubu ile herhangi bir koruma sağlanmaz.

Protected Users grubunun karakteristik özellikleri:

Protected Users grubunun üyelerinin NTLM, Digest Authentication veya CredSSP ile kimlik doğrulama sürecinden geçmeleri desteklenmez. Bir diğer deyişle NTLM, Digest Authentication veya CredSSP bu grubun üyesi olan hesaplar için kullanılamaz. Windows 8.1 çalışan bir aygıt üzerinde şifreler önbelleklenmez, bundan dolayı bu kimlik doğrulama protokollerinden birini kullanan aygıtlar domain ortamına oturum açmak istediklerinde başarısızlıkla sonuçlanacak ve oturum açamayacaklardır.

Bu grubun üyesi olan hesaplar için Kerberos protokolü ile DES ya da RC4 gibi zayıf kriptolama tipleri kullanılamaz. Yani domain ortamınızın en azından AES kriptolama standardına göre yapılandırılması gerekir.

Bu grubun üyesi olan hesaplar için Kerberos delegasyonu da desteklenmez. Bundan dolayı Kerberos delegasyonunu kullanarak diğer sistemlere yapılan eski bağlantılar da başarısızlıkla sonuçlanacaktır.

Kerberos Ticket Granting Tickets (TGTs) için dört saat olan varsayılan yaşam süresi, Authentication Policy ve Silo kuralları ile Active Directory Administrative Center (dsac.exe) konsolu kullanılarak yapılandırılabilir. Yani dört saat sonunda bu gruba üye olan hesaplar tekrar kimlik doğrulama sürecine tabi tutulurlar.

Aşağıdaki tabloda Protected Users grubunun özelliklerini görmektesiniz:

Protected Users Grubuna İlişkin Olay Kayıtları

Protected Users grubuna ilişkin olarak olayları çözümlemek amaçlı iki adet operasyonel olay kaydı kategorisi bulunmaktadır. Bu kayıtlar Event Viewer konsolunda Applications and Services Logs\Microsoft\Windows\Microsoft \Authentication altından erişilebilir ve varsayılan durumda kapalıdır.

Protected Users Grubunun Yapılandırılması:

Protected Users grubu istemci-tarafında koruma sağlayan bir özellik olup, kullanılabilmesi için belli ortam gereksinimlerinin sağlanması gerekir:

Protected Users grubunun oluşması için Active Directory Schema versiyonunun Windows Server 2012 R2’ye genişletilerek versiyon 69 yükseltilmesi gerekir.

Protected Users grubunun diğer domain controller sunuculara çoğaltılması için PDC Emulator FSMO rolüne sahip sunucunun Windows Server 2012 R2 işletim sisteminde  çalışması gerekir.

Hesapların bulunduğu domain ortamındaki tüm domain controller sunucularına Protected Users global security grubunun çoğaltılmış olması gerekir.

Bu koruma sadece Windows 8.1 aygıtlarından ya da Windows Server 2012 R2 sunucu sistemlerinden Windows Server 2012 R2 domain controller üzerinden kimlik doğrulaması yapılan oturum açılışlarında uygulanabilir.

Domain Controller sunucular için koruma yapılabilmesi için domain fonksiyonel seviyesinin Windows Server 2012 R2 olması gerekir.

NOT : Protected Users grubu domain fonksiyonel seviyesi Windows Server 2012 R2 altında olan domain yapılarında da uygulanabilir. Böyle bir durumda öncelikle PDC Emulator rolü Windows Server 2012 R2 sunucuya atanıp, Protected Users grubunun tüm diğer domain controller sunuculara çoğaltılması tamamlandıktan sonra, istenirse domain fonksiyonel seviyesi tekrar alt versiyonlara indirgenebilir.

UYGULAMA ADIMLARI:

Protected Users grubunun işleyişini test etmek için aşağıdaki şekilde görüldüğü gibi FullAdmin isimli bir kullanıcı hesabı oluşturuyoruz.

FullAdmin kullanıcı hesabını Domain Admins, Enterprise Admins, Schema Admins gibi yüksek seviyede yetkiye sahip yönetimsel gruplara üye yapıyoruz.

Şu an için Protected Users grubuna henüz üye yapmıyoruz. FullAdmin kullanıcısı ile Windows 8.1 ile çalışan bir bilgisayardan domain ortamına oturum açıyoruz.

Oturum açan kullanıcımıza ait kullanıcı bilgileri, grup üyelikleri ve atanan hakları listeliyoruz.

Yine oturum açan FullAdmin hesabına atanan Kerberos TGT ticket içeriğini görüntülüyoruz. Gördüğünüz gibi 10 saatlik yaşam ömrü olan TGT atanmış.

Yine klist.exe aracı ile KDC (Key Distribution Center) tarafından FullAdmin hesabına atanan Kerberos ticket listesine baktığımızda da sağlıklı bir biçimde alındığını ve Domain seviyesindeki GPO tanımından gelen 10 saatlik ömrü olan ticket verildiğini kontrol ediyoruz.

İstemci bilgisayarımızın Event Viewer konsolunda Security günlükleri içerisinde oturum açma esnasındaki kimlik doğrulama protokolünün Kerberos olduğu ve yüklenen kimlik doğrulama paketinin de yine Kerberos paketi olduğunu kontrol ediyoruz. Bunun için Security kategorisinde “Filter Current Log” seçeneği ile gelen ekranda XML sekmesine geçip aşağıdaki XML sorgusunu yapıştırıyoruz. Siz isterseniz Security kategorisinde oluşan olay kayıtları içerisinden elle arayarak da ulaşabilirsiniz. Aşağıdaki sorgu işimizi biraz daha hızlandırıp sadece istediğimiz olayları görüntüleyecektir.

Aşağıdaki şekilde görüldüğü gibi Kerberos kimlik doğrulama paketine ilişkin kayıtları görüyorsunuz.

Bu aşamada hesabımız henüz Protected Users grubuna üye olmadığı için herhangi bir kısıtlama ya da sınırlandırma söz konusu değil. Normal kullandığımız kullanıcı hesabı davranışlarının aynısını gerçekleştiren bir hesap olarak işlev gösteriyor:

İstediği versiyonda çalışan işletim sistemine RDP vb. bağlantı gerçekleştirebilir.

Hem Kerberos hem de NTLM ile oturum açabilir. (Bunu tüm DC’ler üzerindeki KDC servisini kapatarak test edebilirsiniz. Kerberos servisine ulaşamayınca NTLM seviyesine düşerek kimlik doğrulamasını bununla yapacaktır.)

Protected Users grubuna üye yapıldığında kısıtlanan kriptografi algoritmaları için şu anda herhangi bir sınırlandırma bulunmamaktadır.

Şimdi Protected Users grubuna üye yapma sürecine başlayalım.

Öncelikle domain fonksiyonel seviyemizin Windows Server 2012 R2 seviyesinde olduğunu kontrol ediyoruz.

PDC Emulator FSMO rolüne sahip domain controller sunucumuz Windows Server 2012 R2 işletim sisteminde çalışıyor.

FullAdmin hesabımızı Protected Users grubuna üye yaptık.

Şimdi Windows 8.1 istemci bilgisayarımızdan tekrar oturum açıyoruz. Aşağıdaki şekilde görüldüğü gibi Kerberos ticket’ın yaşam süresi 4 saate düşmüş oldu. Bu Protected Users grubu üyeleri için varsayılan değer.

İstemci üzerindeki Security olay kayıtlarından oturum açma esnasında yüklenen paketin Negotiate seviyesine çıktığını görüyoruz. Negotiate en güçlü, güvenilir kimlik doğrulama protolünün kullanımını sağlar.

Yukarıdaki başlıklarda Protected Users grubuna üye olan kullanıcılar için Kerberos dışında NTLM kimlik doğrulama protokolü desteklenmediğini belirtmiştik. Ben demo ortamımda çalışan domain controller sunucularım üzerinde Kerberos kimlik doğrulama sürecini gerçekleştiren KDC(Key Distribution Center) servisini kapatıyorum. (Bunu tüm domain controller sunucularımda yapıyorum. Aksi halde kullanıcımız diğer domain controller’ın KDC servisinden servis almaya devam edecektir.

Bu işlem sonrası tekrar Windows 8.1 istemcimden oturum açmaya çalıştığımda aslında beklenen KDC servisinden servis alamadığı için kimlik doğrulamanın NTLM seviyesine düşerek gerçekleşmesidir. Fakat kullanıcı hesabımı Protected Users grubuna üye yaptığımdan dolayı aşağıdaki hata mesajını alarak oturum açma sürecimizin başarısızlıkla sonuçlandığını görüyorsunuz.

Kullanıcı hesabını Protected Users grubundan çıkartırsanız bu durumda NTLM kimlik doğrulaması ile oturum açabildiğini göreceksiniz. Bu durumda yine klist ile kerberos bilgilerini listelemek istediğimizde herhangi bir kerberos ticket atanmadığını görüyor olacaksınız.

Yine bu süreçle ilgili olay kaydı için de istemci üzerindeki Event Viewer konsolunda Security kategorisinde Filter Current Log seçeneği kullanılarak aşağıdaki XML sorgu ile kimlik doğrulama paketinin NTLM olduğunu kontrol edebilirsiniz.

Ağdan Erişim Testleri:

Protected Users grubuna üye kullanıcımızla ağ üzerindeki kaynaklara IP Adresini kullanarak ağ yolu tanımlaması ile (UNC Path) ya da net use komutu ile erişmek istediğimizde de aşağıda görüldüğü gibi başarısızlıkla sonuçlandığını göreceksiniz.

Bunun nedeni IP ile ağ bağlantılarına erişimde NTLM kimlik doğrulamasını kullanıyor olmasından kaynaklanıyor. NTLM’de Protected Users grubu üyeleri için kullanılamadığından erişim başarısızlıkla sonuçlanıyor. IP yerine netbios adi ya da host adını kullandığınızda ise sorunsuz bağlanıldığını göreceksiniz.

ÖZETLE :

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri olan  “Protected Users” güvenlik grubunu kullanarak güvensiz kimlik doğrulama protokolleri, zayıf kriptolama algoritmaları ve hassas kullanıcı hesaplarına delegasyon atamalarının sınırlandırılmasını detaylarıyla bu makalemizde inceledik. Bir başka makalemizde görüşmek dileğiyle hoşçakalın.

Portalımızda Cluster servisi ile çok detaylı makaleler anlatıldığı için burada fazla detaya girmeden özetle Cluster Servisini anlatmak gerekirse, Windows’un servislerinizin yüksek erişebilirliğini sağlamak için kullanılan servistir. Cluster ile sunucu yedekliliği hedeflenmektedir.  Bu makalemizde sizlere Windows Server 2012 R2 ile birlikte Cluster servisindeki yenilikleri anlatacağım.

Konuyu detaylandırmadan önce aşağıda hazırlamış olduğum özet tabloda görüleceği üzere geliştirilen 7 özelliğin 5’i Hyper-V alanında. Yeni gelen 10 özelliğin üçü de Hyper-V ortamı için. Görüleceği üzere Windows Server 2012r2 ile gelen sanallaştırma servisi olan Hyper-V hem sürümü üçe yükselmiş oldu hem de Cluster servisindeki yeniliklerle servis sürekliliği arttırılmış / iyileştirilmiş oldu.

Şimdi yukarıdaki özet tabloda verilen bilgilerin detayını 2 ana başlık altında inceleyelim.

1)     Genel Cluster Servisindeki Yenilikler

Cluster Bağımlılıklarının Azaltılması:Server 2012R2 öncesindeki işletim sisteminde Cluster kurarken 1196 ve 1579 Event numaralı hata mesajların alınmaması ve sonradan soruna neden olmamak adına Cluster ve Servis isimlerini, DNS ve AD üzerinde oluşturup yetkilendirirdik. Artık buna gerek kalmadan Cluster’ı kurup PowerShell üzerinden yazılacak New-Cluster –AdministrativeAccessPoint komutu ile işlemi tamamlayabileceğiz. Detaylarına aşağıdaki linkten ulaşabilirsiniz.

https://technet.microsoft.com/en-ie/library/dn265970.aspx

Özellikle Kerberos Authentication yapılarındaki Cluster kurulumlarında tercih edilen bir yöntemdir.

Dynamic Witness: Aşağıda linkini verdiğim makalede “Split Brain” senaryosuna ve Quorum modellerini detaylı anlatmıştık. Cluster’ımızın kontrolsüz bir şekilde down olma durumunu engellemek için Server 2012 ile tanıştığımız Dynamic Quorum ile istediğimiz sunucunun oy hakkını alabiliyorduk. Bunu daha çok WAN üzerinden çalışan Multi Site Cluster yapılardaki uzak node’ların veya Always On SQL Cluster yapınızdaki AG node’umuzun oy hakkının alınarak olası bir problemde Cluster’ın down olmasını önlemek için kullanmaktayız.

http://www.cozumpark.com/blogs/windows_server/archive/2014/03/02/microsoft-cluster-mimarisinde-quorum-yapilandirmasi-ve-split-brain-senaryosu.aspx

Yapılan çalışmalar sonucunda Dynamic Witness’ın yeterli gelmediği gözlenmiştir. Bunun üzerine 2012R2 ile birlikte Dynamic Witness özelliği geliştirilmiştir. Bu özellik ile node sayısı ne olursa olsun (çift veya tek) Cluster’a eklenecek witness ile node durumuna göre sistem otomatik hesaplama yaparak Cluster’ın devamlılığını sağlamaya çalışmaktadır. Konunun daha rahat anlaşılması için bir örnekle anlatalım:

Yukarıdaki resimde 3 Node’lu cluster eklediğimiz Witness Diskli yapımızda tek sayı olduğundan Witness Diskin oy hakkı yok. Node’lardan biri erişilemez olduğunda Witness Diskin oy hakkı verilerek servis sürekliliği sağlanmakta. Multi Site çözümlerde Witness olarak file share kullanılması önerilmektedir.

Quorum user interface improvements (Quorum için Kullanıcı Ara yüzünün Geliştirilmesi:):

Hem GUI hem de PowerShell üzerinden kolaylıkla Quorum yönetimi yapılabilmektedir. Failover Cluster Management Tools üzerinden yapmak için Cluster üzerinden sağ tıklanıp MoreActions > Configure Cluster Quorum girilir. PowerShell ile yapmak için Set-ClusterQuorum komutu ile yapılmaktadır.

Dynamic Witness ile oy yönetim tablosunun GUI ara yüzden rahatlıkla izlenebilmesi için Failover Cluster Management Tools üzerinden görüntülenmesi sağlandı.Aşağıda örnek görüntüsünü paylaştığım Server 2012 Cluster yapımızda Failover Cluster Management Tools üzerinden Node kısmına geldiğinizde sadece status bilgileri yer almaktaydı.

Aşağıdaki örnek görüntülerini verdiğim Server 2012 R2 ile birlikte ise kolaylıkla Dynamic Quorum yapısı izlenebilmekte.

Çift sayıdaki node’larınız için Cluster High Avaibility için disk veya file share witness kullanılması gerekmektedir. Aşağıda Validation Rapor görüntüsü görülmektedir.

Force Quorum Esnekliği: Cluster’ın yarısından 1 fazlasına ait node’lar erişilemez olduğunda Cluster down olur. Böyle bir durumla karşılaşıldığında sistem sürekliliğinin devam edilmesi adına uygun göreceğiniz tek bir node üzerinde Cluster servisi önce stop edilir arkasında da PowerShell üzerinden Start-ClusterNode with –FixQuorum ile Force Quorum (/fq) ile başlatılmaktadır.

Server 2012 R2 öncesi sistemlerde diğer node’lara erişim sağlandığında veya sorun düzeldiğinde devreye alınabilmesi için önce Cluster servisi durdurulur arkasından da Force Quorum “Net Start ClusSvc /FQ” komutu ile start edilirdi. 2012R2 ile birlikte Node’lar da sorun düzeldikçe sisteme otomatik join olmaktalar. İşlem tamamlandığında ilk müsait zamanda Cluster’ı “Net Start ClusSvc /PQ” komutu ile restart ettiğinizde çok ufak bir kesinti ile çalışmaya devam edecektir.

Tie Breaker: Failover Cluster’ın olmazsa olmaz 3 bileşeni vardır. Disk, Network ve Quorum. Multi-Site Cluster yapılarda eğer network bağlantısı bir şekilde kesilirse yukarıda da paylaştığım gibi Split Brain Senaryosu oluşup disk veya veri bozulmasına neden olabilir.

Server 2012 R2 ile birlikte gelen Tie Breaker özelliği ile Disaster ortamları için eğer Multi Site Cluster oluşturuyorsanız olası Split Brain durumlarına karşı istediğiniz node’un öncelik durumunu LowerQuorumPriorityNodeID PowerShell komutu ile düşürüp olası network problemlerin de sistem sürekliliği sağlanmış olacaktır.

Global Update Manager (GUM) Mode:En özet şekilde GUM, her türlü Cluster bilgisinin (Cluster Database) node’lar arasında iletilmesinden sorumludur. Server 2012 ile tanıştığımız bu özellik 2012’de yönetilemezken 2012R2’de yönetilebilmektedir.

GUM’un 2 tipi bulunmaktadır. Bunlar;

a)      All (write) and Local (read): Server 2012’nin Default ayarı olan bu ayarda; Aktif node cluster veri tabanından sorumlu olup olası değişikliği tüm node’lara aktarmakla yükümlüdür. Bir node veri tabanına erişmek istediğinde tutarlı veri oluşturma adına gerekli kontrollerin yapılmasını da aktif node yapar.

b)      Majority (read and write): Tüm değişiklikle zaman damgası ile oluşturulur ve tüm node’lar veri tabanına erişmek istediklerinde en güncel versiyonuna erişip kullanırlar. Majority Mode’u isterseniz aktif node kontrolüne verilebileceği gibi isterseniz tüm node’ların değişiklikte bulunabileceğini (Get-Cluster).DatabaseReadWriteMode PowerShell komutu ile oluşturabilirsiniz.

Cluster Dashboard: Failover Cluster Management Tools ile bağlandığımızda Server 2012’de sadece aşağıdaki gibi bir link görebilmekteydik.

Fakat 2012R2 ile birlikte anlık durum bilgisine doğrudan erişilebilinmektedir.

Node’lar arası İletişimde IPSec’in kapatılması:Her saniye tüm Node’lar birbirini port 3343 portundan kontrol eder. Eğer 5 kere arka arkaya node cevap vermezse down olduğu düşünülür.

IPSec ile şifrelenmiş networkte gecikmeler yaşanabileceğinden Cluster tarafında sorunlara neden olabilir. Ya node’un down kabul edilme sayısının 5’den daha yüksek değerlere taşınmalı ya da Server 2012R2 ile bu yeni gelen özellik ile node’lar arası iletişimde Heartbeating network bacağında IP kapatılması gerekmektedir. Microsoft tarafından IPSec’in Heartbeating network bacağında kapatılması önerilmektedir.

IPSec’in kapatılması için PowerShell üzerinden “(Get-Cluster). NetFTIPSecEnabled = 0” komutunun çalıştırılması yeterlidir.

2)     Hyper-V Cluster’a Gelen Yenilikler

Shared Virtual Hard Disk for Guest Cluster (Paylaşılmış Sanal Disk):Hyper-V üzerinde daha önceden cluster yapmak istediğimizde ya iSCSI kullanmak zorundaydık veya Hyper-V sunucusuna direk bağlı LUN disklere ihtiyacımız vardı. Şimdi ise Hyper-V Cluster alanımız içerisindeki (CSV) bir vhdx dosyasını gösterip paylaşılmasıyla yapılabilmekte.

Bu işlem için öncelikle Hyper-V Management üzerinde CSV alanda diski oluşturup sunuculara ekledikten sonra Advanced alan içinde “Enable virtual hard disk sharing” işaretlenmeli.

VM Drain on Shutdown: Cluster olan Hyper-V sunucunuzda olan olası bir problem sonucu kontrolsüz kapanacak olduğunda üzerinde çalışan tüm sanal sunucular önce saved moduna alınır sonra Cluster’a üye diğer Hyper-V node’lara aktarır.

Default’ta açık olan bu özellik istenilirse PowerShell üzerinden yazılacak “(Get-Cluster).DrainOnShutdown 0” komutu ile kapatılabilir.

VM Component Health Detection (Network sağlık kontrolü): Server 2012 ve üstü işletim sistemine sahip Sanal sunucunuzun external portunda oluşan olası bir problemde 1 ping kaybıyla kesinti olmaksızın live migration yapılarak Cluster’a üye uygun başka bir Hyper-V hostuna taşır.

Bu işlem her bir network portu için ayrı ayrı yapılmaktadır. Sanal sunucunuzun network portunun kontrol edilmesini istiyorsanız ilgili network adaptörün Advanced sekmesi altındaki “Protected Network” seçilir.

Optimized CSV Placement Policies: Scale-out File Server Cluster üzerinde oluşturulmuş CSV LUN’unuz içerisindeki sanal sunucuların disklerini farklı File Server üzerinden çalıştırarak performans kazanımı sağlanmaktadır.

Artan CSV Esnekliği: File Server Cluster üzerinde konuşlandırdığınız CSV alanınızda bulunan sanal sunucularınız için eğer bir disk performans kaybı yaşanırsa meta datalar CSV’nin sahibi diğer bir File Server Cluster Node’u üzerinden sağlanır.

CSV Cache Allocation: File Server ve Hyper-V ortamlarında kullanılan, Server 2012’de Default’da disable olan bu özellik 2012 R2 ile birlikte enable geldi. 2012R2 ile birlikte fiziksel RAM’in %80’inine kadar cache için ayrılabilmekte. 2012’de bu oran %20’yi geçemiyordu.

Bu özellik ile blok seviyesinde okuma performansının artışı sağlanmaktadır. İstediğimiz değeri PowerShell üzerinden (Get-Cluster).BlockCacheSize = xxx komutu üzerinden MB cinsinden değer belirleyebiliriz. Detaylı bilgiye aşağıdaki adresten ulaşabilirsiniz.

http://blogs.msdn.com/b/clustering/archive/2012/03/22/10286676.aspx

CSV Diagnosibility: 2012R2 ile CSV volume durumunu daha iyi loglama ve inceleme imkânımız oluşmaktadır. PowerShell üzerinden Get-ClusterSharedVolumeState, FileSystemRedirectedIOReason ve BlockRedirectedIOReason komutlarıyla öğrenilebilmektedir.

Kaynak:

https://technet.microsoft.com/en-ie/library/dn265972.aspx#BKMK_CAU

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B354#fbid

https://technet.microsoft.com/tr-tr/library/dn282283.aspx

Herkese merhaba, bu makalede Windows Server 2016 ile gelen yeni bir özellik olan olan Nano Server için image oluşturma ile ilgili bilgiler vereceğim. Daha önce workshoplarda ve webcastlerde de belirttiğimiz PowerShell ile Nano Server image ları oluşturabiliyorduk. Makaleyi yazmaya karar vermeden önce Image Builder hakkında bilgiler elime ulamıştı ve iki gün öncede release oldu. Yani şu anda herkese açık bir şekilde download edebilirsiniz.

Download adresi için aşağıdaki linki kullanabilirsiniz. Kurulumuda makalede belirteceğim ama zaten çok karışık bir durum yok standart kurulum ekranları.

Download için adres : http://aka.ms/NanoServerImageBuilder

Kuruluma dosyayı download ettikten sonra çift tıklayarak başlıyoruz. Bu arada lisans antlaşmasını kabul ederek Next diyerek devam ediyoruz.

Diğer ekranda kurulumun nereye yapılacağını belirliyoruz. Ben kurulum yerini değiştirmeden Next ile devam ediyorum.

Gelen Ekranda Install butonuna basarak kurulumu başlatıyoruz.

Gördüğünüz gibi kurulum çok basit ve hızlı son ekranda Finish diyerek kurulumu bitiriyoruz.

Windows start menü den aşağıdaki Icona tıklayarak uygulamayı başlatabilirsiniz.

Uygulamayı açtıktan sonra aşağıdaki gibi bir menü karşınıza çıkacaktır. Burada iki tip kurulum için image oluşturabiliyorsunuz. Birincisi Hyper-V ortamında kullanmak için vhd ve vhdx image diski diğeri ise bir fiziksel sunucuya kurulum yapabilimek için bir usb boot bir kurulum ortamı. Biz bu makalede Hyper-V ortamında kullanmak için bir vhdx sanal disk oluşturacağız. Esasında diğer seçenek olan fiziksel sunucuya kurulum adımlarıda aynı. Bu durumda “Create a new Nano Server image” seçeneği ile devam ediyoruz.

Bu aşamadan önce Windows Serve 2016 Dvd sini mount etmiş olmamız gerekiyor. Ya da DVD nin bir klasöre açılmış olması gerekiyor. Daha sonra mount ettiğimiz DVD yi göstermemiz gerekiyor ki biliyorsunuz nano server kurulum dosyaları Windows Server 2016 DVD sinin içinde bulunmakta.

Bu aşamada lisans sözleşmesi geliyor. I have read seçeneginiz seçip Next butonuna basıyoruz. Diğer aşamaya geçiyoruz.

Bu aşamada Deployment Type mızı seçiyoruz. Makalemizin başında da betlirttiğimiz gibi Nano Server Image Builder ile birlikte iki çeşit image oluşturabiliyoruz. Hem fiziksel sunucu için hem de sanal sunucu olarak kurabiliyoruz. İşte bu aşamada bunu seçebiliyoruz. Daha sonra  Image oluşturulduktan sonra hangi klasöre kaydedileceğinizi seçiyoruz. Oluşan sanal serverın diskinin boyutunu seçiyoruz. Son olarakta image olurşurken oluşacak logların hangi klasörde olacağınız geçiyoruz.

Bu bölümde yaratacağımız image ın Edition nını seçiyoruz. Biliyorsunuz Nano server da bir windows server esasında bu yüzden Windows Server 2016 da olan editionlar Standart ve Datacenter Nano Server da da kullanıyoruz. Optional Packages bölümden oluşurulacak olan image ı hangi role için kullanmak istiyorsak o package leri seçmemiz gerekiyor. Listeden doğru packageleri seçiyoruz. Ben bir web server yapılandırağım için IIS paketini ve Windows Server Antimalware paketini seçip diğer adıma geçiyorum.

Bu aşamada eğer yaratılan imajı kullanacağımız sunucuda ekstra dirver ihtiyacı varsa bunları seçiyoruz. Nano Server Windows Server 2016 daki bütün driverlar Nano Serverın içinde de barınıyor. Eğer yine ihtiyacımız olan bir driver olursa bu bölümden Add kısmından driveri ekliyoruz. Eğer ekliyeceğimiz bir driver yok ise bu bölümde herhangi bir driver eklemeden next ile diğer bölüme geçiyoruz.

Destination Machine bölümü ; bu bölümde kuracağımız image için bir computer name belirlemek istersek bir computer name yazıyoruz. Fakat image larda genelde computer name belirtilmez, image provisioning işleminde sonra computer name tarafı değiştirilir. Image içinde kullanacağımız Administrator şifre si ve kullanacağımız saat ayarını seçiyoruz.

Bu bölümde yaratacağımız image ın otomatik olarak kullandığımız Windows Domainine join olma işlemlerini ayarlıyoruz. Burada iki seçeneğimiz mevcut. Eğer yarattığımız imaj otomatik olarak networke katılacak ise ilk seçenek olan domain name tarafına kullandığımız domain ismini yazıyoruz. Eğer offline domain özelliğini kullanmak istiyorsak iki seçenek olan Domain Blob file mızı buradan göstermemiz gerekiyor. Eğer blob file kullanacak isek burada dikkat etmemiz gereken nokta bir önceki adım olan “Destination Machine” adımında computer name kısmını boş bırakmamız gerekmektedir. Gerekli bilgileri yazıp next ile Network ayarlarımıza geçiyoruz.

Bu aşamada standart network ayarlarımızı yapıyoruz. Yapımızdaki network konfigürasyonuna göre IP ayarlarını giriyoruz. Eğer ortamdaki DHCP serverdan otomatik IP alınmasını istiyorsak ilk seçenek olan “Enable DHCP to obtain an IP address aıtomatically” seçeneğini aktif etmemiz gerekiyor. Diğer önemli husus ise ekran görüntüsünde de görüldüğü gibi Remote Powershell ve WinRM özelliğinin aktif edilmesi. Bu özelliğin aktif edilmesi kullanacağımız Nano Serverın yönetimi açısından kolaylık sağlayacaktır. O yüzden bu özelliği seçmenizi öneririm. Gerekli ayarlardan sonra next ile Advanced Configuration bölümüne geçiyoruz.

Bu erkanda iki seçeneğiniz mevcut. Create basic Nano Server Image diyerek image işlemlerimizi bitirebiliriz. Ya da Advanced settings ile birlikte image mıza ekstra bazı özellikler ekleyebiliyoruz. Bu özellikler nedir peki ;

1.     Add Servicing Packages : Bu seçenek ile update fileları image mıza ekliyebiliyoruz.

2.     Embed files scripts or binaries : Bu seçenekte ise image provisining işleminden sonra çalışmasını istediğimiz batch dosyalarımız ya da scriptlerimiz varsa onların çalışmasını sağlayabiliriz.

3.     Set Remote options : Bu arada Nano serverın EMS (Emergency Management Services) özelliğini açabiliyoruz. Önerim bu özelliğin aktif olmasıdır.

4.     Set debugging methods : Bu bölümde debug ile ilgili ayarlarımızı açıyoruz.

Ben burada Continue to configure advanced settings diyerek EMS özelliğini aktif ediyorum.

Bir önceki adımda anlattığım gibi Nano Server ‘ın image dosyamızda default olarak açık gelmesi için advanced options tan aşağıdaki seçenekte Enable Emergency Management Services özelliğini aktif etmemiz gerekiyor.

Aşağıdaki ekran görüntüsünü eklememin nedeni Nano server üzerindeki Debug methodlarının ne kadar ayrıntılı olduğunu göstermek istedim. Ben burada TCP/IP ayalarından Debug methodu aktif edip configurasyonlarıma devam ediyorum.

Artık Image oluşturma işlemlerimizin sonuna gelmiş bulunmaktayız. Son olarak genel ayaların bir özetini gösteren bir ekran bizi karşılıyor. Create butonuna tıklayarak image mızın oluşturulmasını sağlayabiliriz. Eğer bu ekranda eksik birşeyler görüyorsak diğer ekranlara geçerek bunları düzeltebiliriz. Ben herhangi bir eksik görmüyorum ve create diyorum.

Create dedikten sonra image mızın oluşturma işlemleri başlıyor. Bu ekranda dikkat etmemiz diğer güzel bir özellikte en alt kısımda bütün bu configurasyon bilgilerinin PowerShell komutlarını görebilirsiniz. Bu komutlar sayesinde PS üzerinden de image oluşturma işlemlerini yapabilirsiniz.

Son ekranda image mızın başarılı şekilde ve hangi path te oluşturulduğunu görüyoruz.

Windows Server 2016 ile gelen önemli özelliklerden Nano Server ‘ın image nın nasıl oluşturulacağı hakkında bilgiler vermek istedim. Başka bir makalede görüşmek üzere.

Windows Server 2016 ürününün TRM olması ile ürünü kurcalayıp kullananlar artmaya başladı. Uzun zamandır deneme sürümleri ile uğraşıyorduk ancak kullanıma sürülmesi farklı bir ambiyans getirdi. Bizlerde makale serilerimizi RTM versiyon ile çoğaltmaya başladık.

Bu Makalemizde Windows Server 2016 Hyper-v tarafından gelen yeniliklerden önemlisi sayılabilecek Nested Virtualizationözelliğini ele alacağız. Nested Virtualization makale başlığımızda olduğu gibi kelime anlamı olarakİç İçe Sanallaştırma anlamını içermektedir. Windows Server 2016 öncesinde Hyper-v rolünü barındıran sistemlerde, İşlemci desteğimize göre Virtualization Support özelliğini Bios üzerinden açarak Hyper-v rolünü kurup sanallaştırma işlemlerimizi yapabiliyorduk. Şu an itibari ile iç içe sanallaştırma kullanma imkanına sahibiz. Reel ortamlarda kullanılır mı tartışılır ancak test ortamları için ilaç olduğunu düşünüyorum. Sözümüzü fazla uzatmadan adımlara başlayalım.

Server Manager üzerine girerek işlemlerimize başlayalım. Bu işlemi resmimizde yer alan 2 Add roles and features linkine tıklayarak yapabileceğimiz gibi,

Managebutonuna tıkladığımızda açılan Add Roles and Features menüsünden de yapabiliriz.

Açılan ekranda sihirbaz ile yapabileceklerimiz noktasında bilgi verilmektedir. Next ile bir sonraki ekranımıza ilerleyelim.

Açılan ekranımızda iki seçeneğimiz yer almaktadır. Bunlardan birincisi olan;

Role-based or feature-based insallation : Rol ve Özellik bazında ekleme kurulum yapma imkanı verir. Windows Server 2016 içerisinde sahip olduğumuz sürüme göre, içerisinde bulunan ve ihtiyacımız olan rol ve özellikleri buradan ekleyip kaldırabilmekteyiz.

Remote Desktop Services installation: Eski zamanlarda Terminal Servis olarak anılan ve şimdi RDS (Remote Desktop Services) uzak masaüstü yapılandırmasını hızlı ve standart olarak buradan yapabilmekteyiz.

Bu nedenle biz RDS kurulum ve yapılandırması yapmayacağımız için Role-based or feature-based insallation seçimini yaparak Next ile ilerliyoruz.

Windows Server 2008 ve 2012 ile birlikte sunucu kümesi oluşturarak bu küme üzerine toplu olarak ve farklı bir sunucu üzerinden Rol ve Özellik ekleme ve kaldırma işlemleri yapabilir duruma geldik. Tabi bu işlem Windows Server 2012 üzerinden doğrudan yapılabilirken Windows Server 2008’e bazı özellikler katmamız gerekiyordu. Bizim ortamımızda tek bir sunucumuz olduğundan ve bu sunucumuza Hyper-v rolünü kuracak olduğumuzdan Adı, ip adresi ve versiyon bilgisi sunulan sunucumuzu seçerek Next ile ilerliyoruz.

Karşımıza gelen ekrandan kuracak olduğumuz Hyper-v rolünü seçiyoruz.

Hyper-v rolünü kurmak istediğimizde bu rolün kurulabilmesi için farklı özelliklerin ve bileşenlerin gerekli olduğunu gösteren bir ekran karşımızda belirliyor. Rol kurulumu için gerekli olan bu bileşenlerinde yüklenmesi için Add Features butonuna tıklayalım.

Biz Hyper-v rolünü, Hyper-v üzerindeki Windows Server 2016 işletim sistemine kurmak istediğimiz için aşağıdaki hata ile karşılaşıyoruz. İşte İç İçe Sanallaştırma özelliği burada devreye giriyor. Bu yeni özelliği kullanabilmek adına bir takım gereklilikleri yerine getirmek durumundayız.

Öncelikle fiziksel katman üzerinde olup üzerinde Hyper-v rolü olan işletim sistemimiz üzerinde, Yönetici olarak Powershell’i açıp aşağıdaki komutu çalıştırmamız gerekmektedir.

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

Komutu tersine çevirmek yani bu özelliği iptal etmek için aşağıdaki komutu girmemiz gerekmektedir.

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false

Bu komut ile İç İçe sanallaştırma yapabilmek adına ilk gereksinimi sağlıyoruz. Bu komut setinde “vmname” alanına Fiziksel Hyper-v üzerinde bulunan ve içerisine Hyper-v rolü kuracak olduğumuz sanal makinanın adını girmemiz gerekmektedir.

Komut sonrası ekranımızda bir çıktı görünmeyecektir. Durum aşağıdaki gibi olacaktır.

Komutumuzda kullandığımız “vmname” kısmına aşağıdaki aşağıda ki resimlerimizde görüldüğü gibi Hyper-v2016 olan sanal makinamızın adını girdik.

Sanal Makinamızın içinde Hyper-v rolünü aktif edebilmek için ikinci kriterimiz Hyper-v kurulacak olan sanal makinamızda Dinamik Bellek (Dynamic Memory) aktif olmamalıdır.

Sanal Makinamızın içinde Hyper-v rolünü aktif edebilmek için üçüncü kriterimiz Hyper-v kurulacak olan sanal makinamızda MAC adresi sahtekarlığını etkinleştir (dhcp spoofing) aktif olmamalıdır.

Sanal Makinamızın içinde Hyper-v rolünü aktif edebilmek dördüncü ve son kriterimiz Hyper-v kurulacak olan sanal makinamızda En az 2 sanal işlemciolmamalıdır.

Gereksinimleri karşıladık. Hata aldığımız ekrana kadar olan adımları tekrarlayalım. Şimdi Hyper-v rolünü seçmemize izin veriliyor ve hata gelmiyor.Next ile bir sonraki adıma ilerleyebiliriz.

Bu ekranda bir özellik eklemeyeceğimiz ve gerekeli özelliklerin eklenmesine yukarıda onay verdiğimiz için Next ile bir sonraki adıma ilerliyoruz.

Yapılandırma öncesi sihirbazı Nextile geçelim.

Bu ekranımızda sanal makinaların kullanabilmesi için bir Ethernet seçmeliyiz. Bu Ethernet ile sanal switch oluşturulup sanal makinalarımıza tahsis edilecek. Burada seçim yapmadan sonradan yapılandırma imkanımızda var. Bir seçimimizi yapıp Nextile bir sonraki adıma ilerliyoruz.

Migration ekranında Host için Paylaşımsız Canlı Aktarım Shared-Nothing live Migration gönderimlerinin kabul edilip edilmeyeceği ile ilgili seçim yapabilirsiniz. Bu seçenekte daha sonra yapılandırılabilir. Biz bu ekranı olduğu gibi bırakarak Next ile bir sonraki ekrana ilerliyoruz.

Bu ekranımızda sanal makine ayarlarının ve disklerinin tutulabildiği yolları belirleyebiliriz. Özelleştirme yapıp özel bir seçim yapmayacaksanız benim gibi bu ekranı Nextile geçebilirsiniz.

Bu ekranımızda Role kurulumundan sonra eğer gerekir ise, yeniden başlatma işleminin otomatik gerçekleşmesi için Restart the destination server automatically if required seçimini yapıyoruz ve karşımıza gelen soruyu Yes ile geçiyoruz.

Install ile kurulumu başlatalım.

Kurulum başladı.

Bu işlemler sırasında bilgisayarlarımız birkaç kez yeniden başlayacak.

Gerekli yapılandırma adımları tamamlandığında login ekranı gelmekte. Login olup oturumumuzu açalım.

Oturumumuz açıldıktan sonra rol yapılandırması tamamen bitiyor. Close ile ekranımızdan çıkış yapıp adımları sonlandırabiliriz.

Start menüsünde görüldüğü gibi Windows Administrative Tools altında Hyper-v Manager ikonu oluştu.

Yönetim konsolumuzu yukarıdaki kısa yola tıklayarak açalım.

Yeni bir sanal makine oluşturuyorum.

Sanal makinamız sorunsuz çalışmakta.

Evet aşağıdaki resmimize dikkatli bakacak olursak en arka katmanda fiziksel makinamız üzerindeki Hyper-v konsulu gözükmekte. Bu konsol içerisinde yer alan sanal makinamızdaki İç İçe sanallaştırma içerisinde yer alan Hyper-v konsolu ve son olarak en ön ekranda ise İç İçe sanallaştırma içerisinde yer alan test amaçlı oluşturduğumuz sanal makinamız görünmekte.

Umarım yararlı olur. Bir başka makalede görüşmek dileğiyle.

Windows Server 2016 RTM olarak hızlı bir şekilde IT dünyasına giriş yaptı. Birçok profesyonel IT blog yazarı Windows Server 2016 ile birlikte yeni makalelerini sıralamaya başladılar. Portalımızda bu konuda daha önce çokça kaynak yayımlandı. Ancak RTM olması ile birlikte makaleler yeniden hızlındı. Bu makalemizde Windows Server 2016 Backup özelliğini ele alıyor olacağız. Öncelikle Backup özelliğini aktif edip sonrasında Bare metal Backup ve Restore işlemi yapacağız. Bilindiği üzere Windows Server 2016 Backup özelliği sonradan yüklenmek zorunda olan bir özelliktir. Şimdi fazla uzatmadan adımlarımıza başlayalım.

Server Manager üzerine girerek işlemlerimize başlayalım. Bu işlemi resmimizde yer alan 2 Add roles and features linkine tıklayarak yapabileceğimiz gibi,

Managebutonuna tıkladığımızda açılan Add Roles and Featuresmenüsünden de yapabiliriz. Add Roles and Features‘e tıklayalım.

Açılan ekranda sihirbaz ile yapabileceklerimiz noktasında bilgi verilmektedir. Next ile bir sonraki ekranımıza ilerleyelim.

Açılan ekranımızda iki seçeneğimiz yer almaktadır. Bunlardan birincisi olan;

Role-based or feature-based insallation : Rol ve Özellik bazında ekleme kurulum yapma imkanı verir. Windows Server 2016 içerisinde sahip olduğumuz sürüme göre, içerisinde bulunan ve ihtiyacımız olan rol ve özellikleri buradan ekleyip kaldırabilmekteyiz.

Remote Desktop Services installation: Eski zamanlarda Terminal Servis olarak anılan ve şimdi RDS (Remote Desktop Services) uzak masaüstü yapılandırmasını hızlı ve standart olarak buradan yapabilmekteyiz.

Bu nedenle biz RDS kurulum ve yapılandırması yapmayacağımız için Role-based or feature-based insallation seçimini yaparak Next ile ilerliyoruz.

Windows Server 2008 ve 2012 ile birlikte sunucu kümesi oluşturarak bu küme üzerine toplu olarak ve farklı bir sunucu üzerinden Rol ve Özellik ekleme ve kaldırma işlemleri yapabilir duruma geldik. Tabi bu işlem Windows Server 2012 üzerinden doğrudan yapılabilirken Windows Server 2008’e bazı özellikler katmamız gerekiyordu. Bizim ortamımızda tek bir sunucumuz olduğundan ve bu sunucumuza Active Directory rolünü kuracak olduğumuzdan Adı, ip adresi ve versiyon bilgisi sunulan sunucumuzu seçerek Next ile ilerliyoruz.

Karşımıza gelen ekrandan biz bir rol kurulumu yapmayacağımız için Next ile bir sonraki ekrana ilerleyelim ve kuracak olduğumuzWindows Server Backupözelliğini seçelim Next ile ilerleyelim.

Bu ekranımızda Windows Server 2016 Backup özelliği kurulumundan sonra eğer gerekir ise, yeniden başlatma işleminin otomatik gerçekleşmesi için Restart the destination server automatically if required seçimini yapıyoruz ve karşımıza gelen soruyu Yes ile geçiyoruz.

Installbutonuna tıklayarak kuruluma başlayalım.

Kurulumumuz tamamlandı. Close ile ekranımızı kapatalım. Windows Server 2016 Backup özelliği yeniden başlatma gerektirmeyen bir özelliktir.

Start menümüzde Windows Accessories altında Windows Server Backup ikonumuz göründü. Kurulum adımımız tamamlandı. Şimdi Bare metal yedekleme yapıp sonrasında yedeğimizden geri dönüş işlemi yapacağız. İmaj bazlı yedekleme çoğu zaman hayat kurtarıcı olabiliyor. Bunu işletim sistemimiz üzerinden bir yedekleme yazılımına para vermeden yapıyor olmak güzel bir durum.

İkona tıkladığımızda Yedekleme konsolumuz açılıyor.

Windows Server 2016 Backup ile Bare metal Backup & Restore

Backup Once… linkine tıklayarak adımlarımıza başlayalım.

Different options seçimi ile ilerleyeceğimiz için Next ile sonraki adıma geçelim.

Bize belirli bir klasörü belirli bir rolü yedeklemeyeceğimiz için yani tüm sistemi bare metal olarak imaj yedek alacağımız için Full server seçimi ile ilerlemek durumundayız. Tabi burada Custom seçeneğini seçerek belirli bir klasörü, Örnek olarak Hyper-v gibi belirli bir rolü veya sunucumuzda çok sayıda disk var ise bunları hariç tutarak yedekleme yapabiliriz.

 Biz şimdilik Nextile ilerleyelim. Bu bahsettiklerimizi farklı makalelerde ele alacağız.

Yedeklememizi localde C: sunusundan farklı olarak bir diskimiz var ise Local drivers seçimi bu diskimize yapabileceğimiz gibi network üzerinde paylaşımda yazma yetkimiz olan bir alana da yapabiliriz. Biz mevcut seçim ile Nextbutonuna basarak sonraki ekrana ilerleyelim.

Yedek olan diskimiz otomatik olarak seçildi. Birden fazla diskimiz varsa diğer seçim değiştirmemiz mümkün. Nextile sonraki adıma ilerleyelim.

Biz hatırlarsanız Full yedekleme yaptığımız için ve yedeklememizi full yedekleme içerisinde yer alan E: diskine yaptığımız için yedeklemeyi yapabilmek adına bu diski hariç tutacağım şeklinde bir uyarı geldi. Bu uyarıyı OKile geçelim.

Aynı sunucu üzerinde bulunan alana yedekleme yaptığımız için ve sanal sistem üzerinde test ortamı kurduğum için bu uyarıyı aldım. Yes ile geçiş yapıyoruz.

Yedeklemesi yapılacak olan bileşenler karşımıza geldi. Biz ilk aşamada full seçimini yapmadan custom ile ilerleyip Bare metal seçimini yapacaktık. Bu durumda otomatik olarak geri kalan unsurlar seçilecekti. Bare metal tüm yapıyı kapsamaktadır. Backup ile yedeklemeyi başlatalım.

Yedeklememiz başladı.

İşlem alınacak veri kapasitesi ve sunucumuzun performansına göre zaman alacaktır.

Yedeklememiz tamamlandı. Close ile ekranımızı kapatalım.

Konsolumuzda görevin başarı ile tamamlandığını gösteren loğu görebilmekteyiz.

Yedeğimiz E: diskimizde WindowsServerBackup olarak oluştu.

Ben test amacı ile mevcut sistemi imaj bazlı yedekten döneceğim. Bu işlem öncesinde birkaç değişiklik yapıp farklı gözlemleyelim. Mevcut durumda arka planımız kırmızı.

Arka planı yeşil olarak değiştiriyorum.

Yedeklemiş olduğum sunucuda Hyper-v kurulu ve içerisinde bir sanal makine var.

Sanal makinayı siliyorum.

Sanal makinamız silindi. Yedeklemeden sonra mevcut durumda değişiklik yaptık. Yedekten geri döndüğümüzde arka planımızın kırmızı ve silinen sanal makinamızın geri geldiğini görüyor olacağız.

Şimdi imaj bazlı yedeğimizi dönmek için sistemin komple uçtuğunu düşünelim. Bu durumda dönüş yapar gibi yol alalım. Sunucumuzu Windows Server 2016 medyasından boot edelim.

Gelen ekranımızda Nextile sonraki ekrana ilerleyelim.

Karşımıza gelen ekrana yedekten geri dönebilmek için Repair your computer seçimini yapalım.

Açılan ekranımızda Troubleshootikonuna tıklayalım.

Bir sonraki adımda imaj dönüşü yapacağımız için System Image Recovery ikonuna tıklayalım.

Karşımıza gelen ekranda Windows Server 2016 ikonuna tıklayalım.

Sistemdeki sürücüler tarandı ve tek bir yedeğimiz olduğu için yedeğimiz otomatik olarak bulundu.

Farz edelim yedeğimiz bir ağ üzerinde olsun bu durumda Select a system image seçimini yapıyor olup Next ile ilerlememiz gerekirdi.

Bu ekranımızda Advanced… butonumuza tıklayalım.

Karşımıza gelen ekranda Search for a system image on the network seçimini yapalım. Bu senaryoda normalde ortamda DHCP var ise sistemimiz ip alacak ve network üzerindeki paylaşım içerisindeki yedeğimize ulaşıyor olacaktık. Ethernet kartımız tanınmaz ise Install a driver seçeneği ile Ethernet kartımızı tanıtıp ağı gösterme imkanına sahibiz.

Gelen ekrana ağ üzerindeki yolu gösterip yedeğimizi buldurabiliriz. Bu kısım bilgilendirme amaçlıydı biz E: sürücümüz üzerindeki yedeği döneceğimiz için ilk ekranımızdan ilerlemeye devam ediyor olacağız.

Yedeğimiz seçili ikenNext ile sonraki adıma geçelim.

Biz mevcut yedeği döneceğimiz için Next ile ilerleyelim.

Restore işlemine ait özet bilgi görünmekte. Finishile dönüşü başlatalım.

İmajın mevcut sistem üzerine dönüleceği uyarısını Yes ile geçerek işlemi başlatalım.

İşlem başladı.

Bilgisayar performansı ve yedekleme boyutuna göre işlemimiz belirli bir zaman alacak. İşlemimiz tamamlandı sistemi yeniden başlatmak için Restart now butonuna tıklayalım.

Sistemimiz sorunsuzca açıldı. Login olalım.

Görüldüğü gibi yedeğimiz sorunsuzca dönüldü. Masaüstü arka planımız yedekleme yaptığımız andaki gibi kırmızı olarak geldi.

Silmiş olduğumuz sanal makinamız yerli yerinde.

Sanal makinamız sorunsuzca açılmakta.

Windows Server Backup özelliği ile birçok yapıda ücretsiz ve sorunsuz çözüm üretmek mümkün. Umarım yararlı olur. Bir başka makalede görüşmek dileğiyle.

Sistem yöneticileri görev aldığı organizasyonda ilk planda kullanılacak yapıyı tasarlar, kurgular ve bu bu kurgulanan yapıyı hayata geçirir. Hayata geçirilen bu yapı sağlıklı olarak çalışmaya başladıktan sonra artık sistemin bakım ve yedeklenme aşamasına geçilir. Neticede çalışan bir yapı beklenmedik bir anda zarar görebilir, bilerek veya yanlışlıkla sistemi kullanan kişi veya kullanıcılar verileri silebilir. Bu gibi olmasını istemediğimiz durumlarda ilk aklımıza gelen yedekten geri dönmektir. Bunun için yapının büyüklüğüne göre uygun bir yedekleme yazılımı seçmeli ve sistemimizi bu yedekleme yazılımı ile yedeklemeliyiz.

Büyük yapılardan sonra orta ölçekli veya ufak yapılarda aşağıdaki gibi direk Windows Server İşletim sistemlerinde bulunan Nt Backup veya Windows Server Backup özelliğini kullanabilirsiniz. Yine geniş kaynağımıza aşağıdaki link üzerinden ulaşabilirsiniz.

Yukarıda büyük işletme ve kobi ayrımı yaptık. Burada asıl baz alınması gereken kobi veya işletmenin büyüklüğü değil ortamda bulunan BT yapısının büyüklüğüdür. Çok büyük bir yapıda BT yapısı ufak olabilir buna göre yedekleme yazılımı seçimi yapmakta yarar vardır.

Yedekleme dosya, imaj, sanal platform, mail server gibi birçok farklı amaç için kullanılabilir. Bu nedenle bu yedekleyeceğiniz yapı için en uygun yazılımı seçmeniz gerekmektedir. Şimdi makalemizin asıl konusuna gelelim. Makalemizde Windows Server 2016 işletim sistemindeki backup özelliğini ele alacağız.

Şimdi ufakça makalemize giriş yapalım. Elimizde Windows Server 2016 üzerinde yapılandırılmış Hyper-v rolü kurulmuş bir fiziksel makine var. Bu fiziksel makine üzerinde 1 adet sanal makinemiz var. Windows 10 işletim sistemi olan sanal makineyi açık ve çalışıyorken yedekleyeceğiz. Öncelikle aşağıdaki resimde göründüğü gibi sanal ortamımıza göz atalım.

Şu anda sanal makinemiz açık bu duruma göz atalım.

Windows Server Backup’uçalıştıralım.

Yedekleme işlemini başlatmak için “Backup Once..” linkine tıklayalım.

Biz zamanlanmış bir yedekleme işlemi yapmayacağımız için “Different options” seçimini yaparak “Next” ile ilerleyelim.

Sadece Hyper-v makinelerini yedekleyeceğimiz Full yedek alamayacağımız için “Custom” seçimini yapalım ve “Next” ile ilerleyelim.

Bu ekranımızda “Add Items” butonumuza tıklayalım.

Yedekleme yapacak olduğumuz “Windows-TEst” isimli sanal makinemizi ve Host companent bileşenlerini seçerek “OK” butonuna tıklayalım. Bu arada sanal makinemizin yanındaki (online) ibaresi açık olduğunu göstermekte.

Seçimimiz gerçekleşti. “OK” butonuna tıklayalım.

Seçtiğimiz öğeler ekranımıza eklendi. “Next” ile bir sonraki ekrana ilerleyelim.

Ben yedekleme işlemini localde bir diske yapacağım için “Local Drives” seçimini yapıyorum. Yedekleme için Networkta yetkili bir paylaşım, storage, nas, type gibi farklı ortamlar kullanabilirsiniz.

Yedekleme yapılacak olan diskimizde gerekli boş alanı gördükten sonra seçimimizi yapıp “Next” ile ilerleyelim.

Artık işlem başlamaya hazır. “Backup” butonuna tıklayalım.

Yedekleme işlemimiz şu anda başladı.

Yedekleme yapılırken sanal makinamız açık ve çalışır durumda.

Yedekleme işlemi başarı ile tamamlandı. “Close” ile çıkış yapalım.

Yedekleme işleminin başarı ile tamamlandığını log üzerinde görebiliriz.

Şimdi geri dönüş testimizi yapabilmek için sanal makinamızı önce “Turn Off…” ile kapatalım.

Şimdi “Delete” ile sanal makinamızı silelim.

Karşımıza çıkan mesaj ekranındaki soruya “Delete” butonuna tıklayarak onay verelim.

Sanal makinamız silindi.

Şimdi yedekten geri dönüş yapabilmek için “Recover” butonumuza tıklayalım.

Geri Dönecek olduğumuz yedek fiziksel bilgisayarımızın bir diskinde olduğu için “This Server” seçeneğini seçerek “NEXT…“ile ilerleyelim. Yedeğimiz ağ üzerinde veya farklı bir ortamda olsaydı “A Backup stored on another location” seçeneğiniz seçmemiz gerekecekti.

Yedeğimizi seçelim. Birden fazla yedek olsa burada farklı zamanlara ait yedekler gözükecekti. Seçimimizi yapıp “Next” ile ilerleyelim.

Burada volume ve file bazlı geri dönüşte yapabiliriz. Biz Hyper-v yedeklemesi yaptığımız ve geri döneceğimiz için “Hyper-v” seçeneğini seçim “Next” ile ilerliyoruz.

Geri dönülecek makinemizi ve companentleri seçip “Next” ile ilerleyelim.

Yedeğimizi farklı lokasyona dönebilir veya bir kopyasını alabiliriz. Biz orijinal lokasyona döneceğimiz için “Recover to orginal location” seçimini yaparak “Next” ile ilerleyelim.

Yedekten geri dönme işlemi için “Recover” butonuna tıklayalım.

Yedekten geri dönüş işlemi başladı.

Geri dönüş işlemi başarı ile tamamlandı. “Close” ile çıkış yapalım.

Loglarımıza baktığımızda geri dönüş işleminin sorunsuz olduğunu görebilmekteyiz.

Sanal makinemizi konsol üzerinden silmiştik. Yedekten geri dönüş işlemi sonrasında konsola sorunsuzca eklendi.

Sanal makinemizi açtığımızda sorunsuz olarak çalıştığını görebilmekteyiz.

Windows Server 2016 server işletim sistemi üzerinde çalışan sanal makinenin yedeğini alabildiğimiz gibi üzerinde snapshot olan sanal makinenin yedeğini de alabiliriz.

Ayrıca CSV alanında yani cluster ortamındaki sanal makinalarımızı da sorunsuz yedekleme imkanına sahibiz. Bu makinalarımızı yine çalışırken yedeklemek mümkün. Bunun için iki koşul var.

1-Sanal makinaları Hyper-v rol özelliği üzerinden değil aşağıdaki gibi tutuldukları klasörleri seçerek yedekleyebiliriz.

2-CSV üzerinde bulunan sanal makine hangi host üzerinde ise yedekleme işlemini o host üzerinde kurulu olan Windows Server Backup özelliği ile yedeklememiz gerekmektedir.

Bir başka makalede görüşmek dileğiyle.

Windows Server 2016’nın hayatımıza girmesi ile birlikte ürünün özelliklerini anlatan makaleler ufaktan hayatımıza girmeye başladı. Makalemizde Windows Server 2016 üzerinde Active Directory kurulumu ve Kullanıcıların domaine alınması adımını ele alacağız. Öncelikle belirtmek gerekirse Windows Server 2008’den sonra gelen Windows Server 2012 ile ek özellikle geldi. Bu durum Windows Server 2016 ile aynı şekilde devam ediyor. Ancak Active Directory kurulumunda Windows Server 2008 ve 2012’den farklı yanı olmadığını söyleyebiliriz.

Sözlerimizi fazla uzatmadan adımlarımıza geçelim. Öncelikle ortamımızı hazırlayalım. http://www.cozumpark.com/blogs/windows_server/archive/2016/10/16/windows-server-2016-surumleri-lisanslama-ve-kurulum.aspx Bu makalemizde Windows Server 2016’nın özelliklerinden bahsetmiş temel kurulumu tamamlamıştık. Şimdi mevcut Windows Server 2016 işletim sistemimiz üzerinde Active Directory rolümüzün kurulumunu yapacağız. Öncelikle sunucumuza yapımıza göre düzenli bir isim verelim. Ben sunucuma DOMAIN-CONTROLLER ismini veriyorum.

Kuruluma başlamadan önce güncellemelerimizi yapmamızda yarar olacağına inanıyorum. İşlerim sistemleri için yayımlanan güncellemeleri birkaç gün geçmesinden sonra, sunucularıma geçmeye özen gösteririm. Neticede bu güncellemeler bir güvenlik açığını yamamak, bir yenilik getirmek veya bir hayatı düzeltmek için yayınlanmakta.

Güncellemelerimizi gördüğünüz gibi tam olarak yaptık. Windows Server 2016 işlerim sistemi taze bir sistem olduğundan fazla güncelleme bulunmamakta. Sunucu işletim sistemleri kullanıcı işletim sistemleri gibi çok ve sık güncelleme almamakta. Ayrıca core tabanlı bir sunucu işletim sistemi kullanıyorsanız bu oran çok daha aşağı inmekte.

Güncellemeden sonra Sunucumuz üzerinde yer alan ip adresini statik olarak belirlemek durumundayız. Bu durumlar On-Premises sistemlerde olmazsa olmaz durumlardan bir tanesidir.

Eski yapıda olduğu gibi daha doğrusu Windows Server 2000 ve 2003 sunucu sistemlerde olduğu gibi DCPROMO.EXE ile kurulum yapamayız.

Bu durumda aşağıdaki gibi bir uyarı ile karşılaşırız. Bu işlemi Server Manager üzerinde Sihirbaz ile yapmamız gerektiği şekilde uyarı alırız.

Bizde şimdi Server Manager üzerine girerek işlemlerimize başlayalım. Bu işlemi resmimizde yer alan 2 Add roles and features linkine tıklayarak yapabileceğimiz gibi,

Managebutonuna tıkladığımızda açılan Add Roles and Features menüsünden de yapabiliriz.

Açılan ekranda sihirbaz ile yapabileceklerimiz noktasında bilgi verilmektedir. Next ile bir sonraki ekranımıza ilerleyelim.

Açılan ekranımızda iki seçeneğimiz yer almaktadır. Bunlardan birincisi olan;

Role-based or feature-based insallation : Rol ve Özellik bazında ekleme kurulum yapma imkanı verir. Windows Server 2016 içerisinde sahip olduğumuz sürüme göre, içerisinde bulunan ve ihtiyacımız olan rol ve özellikleri buradan ekleyip kaldırabilmekteyiz.

Remote Desktop Services installation: Eski zamanlarda Terminal Servis olarak anılan ve şimdi RDS (Remote Desktop Services) uzak masaüstü yapılandırmasını hızlı ve standart olarak buradan yapabilmekteyiz.

Bu nedenle biz RDS kurulum ve yapılandırması yapmayacağımız için Role-based or feature-based insallation seçimini yaparak Next ile ilerliyoruz.

Windows Server 2008 ve 2012 ile birlikte sunucu kümesi oluşturarak bu küme üzerine toplu olarak ve farklı bir sunucu üzerinden Rol ve Özellik ekleme ve kaldırma işlemleri yapabilir duruma geldik. Tabi bu işlem Windows Server 2012 üzerinden doğrudan yapılabilirken Windows Server 2008’e bazı özellikler katmamız gerekiyordu. Bizim ortamımızda tek bir sunucumuz olduğundan ve bu sunucumuza Active Directory rolünü kuracak olduğumuzdan Adı, ip adresi ve versiyon bilgisi sunulan sunucumuzu seçerek Next ile ilerliyoruz.

Karşımıza gelen ekrandan kuracak olduğumuz Active Directory Services rolünü seçiyoruz.

Active Directory rolünü kurmak istediğimizde bu rolün kurulabilmesi için farklı özelliklerin ve bileşenlerin gerekli olduğunu gösteren bir ekran karşımızda belirliyor. Rol kurulumu için gerekli olan bu bileşenlerinde yüklenmesi için Add Features butonuna tıklayalım.

Şimdi kurulacak olan rolümüz seçili hale geldi. Bir sonraki adıma ilerleyebiliriz. Şimdi Next butonuna tıklayarak bir sonraki adıma ilerleyelim.

Bir sonraki ekranımızda özellik ekleme ekranımız bizi karşılamakta. Bir özellik ekleme istediğimiz durumda bu ekranı kullanmalıyız. Biz bu ekranda bir özellik eklemeyeceğimiz için Next ilerleyebiliriz. Burada dikkat edecek olursanız bir önceki ekranda gerekli olan özelliklerin kurulmasına onay vermiştik. Bu ekranımızda gerekli olan .Net ve Group Policy Management özelliklerinin seçilmiş olduğunu görüyoruz.

Bu ekranımızda geçmiş ekranlara göre farklı bir arayüzün gelmiş olduğunu görebilmekteyiz. Artık sistemlerin buluta entegre olması ile birlikte On-Premises sitemimizde yer alan Active Directory yapısını Ofis 365 Azure üzerindeki Active Directory yapısına bağlama imkanına sahibiz. Biz şu anda böyle bir aksiyon almayacağımız için Next ile bir sonraki adıma ilerliyoruz.

Artık adımlarımızı tamamlama noktasına yaklaştık. Şimdiye kadar olan seçimlerimizin bir özeti karşımıza geldi. Installbutonuna tıklayarak kuruluma başlayalım.

Bu ekranımızda yapılan ayarları dışarı aktarma imkanına sahibiz. Export Configuration settings linkine tıklayarak ayarlarımızı dışarı aktaralım.  Bir isim vererek Save butonu ile kayıt işlemini tamamlayalım.

Yine ekranımızda Role kurulumundan sonra eğer gerekir ise, yeniden başlatma işleminin otomatik gerçekleşmesi için Restart the destination server automatically if required seçimini yapıyoruz ve karşımıza gelen soruyu Yes ile geçiyoruz.

Installbutonuna tıklayarak kuruluma başlayalım.

İşlemimiz tamamlandı ancak sadece rolün kurulumu tamamlandı. Active Directory mimarisini devreye alabilmemiz için yapılandırma adımına geçmemiz gerekmektedir. Yapılandırma işlemini Remote this server to a domain controller linkine tıklamamız gerekmektedir. Ben bu işlemin farklı bir yerden daha yapılabildiğini gösterebilmek için Close butonu ile çıkış yapıyorum.

Bu adımı Server Manager üzerinde yer alan Bayrak ikonuna tıklayıp bekleyen işlemlerde gördüğümüz yarım kalan işlemden yapabiliriz. Remote this server to a domain controller linkine tıklayarak yapılandırmaya başlayalım.

Mimarimizi biçimlendirme adımının ilkine geldik. Bizim ortamımızda bir Forest bulunmadığı, Mevcutta olan bir domaine ve foreste dahil olmayacağımız yani, ortamımızda ilk foresti kurup bu forest üzerinde ilk domaini yapılandıracağımız için Add new forest raido butonu ile seçimimizi yapmalıyız. Bunun sonrasında ise kurulacak olan root domain için bir isim belirlemeliyiz. Ben test ortamında olduğum için COZUMPARK.LOKAL ismini veriyor ve bir sonraki ekrana Nextile ilerliyorum.

Bu ekranımızda kurulacak olan Domain yapımız için forest ve domain seviyelerini belirlememiz gerekmektedir. Bu seviye Server İşletim sisteminin yapabileceklerinin kapasitesini belirler diyebiliriz. Örnekolarak Active Directory Recycle bin özelliği için Forest Functional Level seviyesinin en az Windows Server 2008 olması gerekmektedir. Günümüz itibari ile en sonra forest ve domain functional level seviyesi Windows Server 2016 seviyesine gelmiştir. Detay için http://sozluk.cozumpark.com/goster.aspx?id=1629&kelime=Domain-ve-Forest-Function-Level buradan yararlanabilirsiniz. Domain Controller üzerinde DNS ve Global Catalog olmazsa olduğu için bu seçimleri yapmamız gerekmektedir.

Biz Read only domain controller kurmadığımızdan bu seçimi yapmadan varsayılanda olduğu gibi bırakıyoruz. Read only domain controller konusunda http://sozluk.cozumpark.com/goster.aspx?id=798&kelime=RODC-Read-Only-Domain-Controller buradan yararlanabilirsiniz.

DSRM Restore Mode için bir parola veriyoruz. DSRM Restore Mode konusunda bilgi için http://sozluk.cozumpark.com/goster.aspx?id=1198&kelime=directory-services-restore-mode-dsrm buradan yararlanabilirsiniz. Nextile bir sonraki adımımıza ilerliyoruz.

Bu ekranımızda DNS sunucumuz kurulu olmadığından bir uyarı almaktayız. Biz Domain Controller kurulumu sırasında DNS rolünün de kurulup gerekli ayarların otomatik olarak yapılacak olmasından Next ile bir sonraki adıma ilerliyoruz.

Domain adımıza göre oluşan netbios name otomatik olarak gelmekte burada yine Nextile sonraki ekrana ilerliyoruz.

Active Directory ve Log database yolları karşımıza çıkıyor. Biz burada default ayarları bırakarak bir sonraki adıma Next ile ilerliyoruz.

Tüm ayarlarımızı bir script halinde görüp farklı ortamlarda otomatize edebilme imkanına sahibiz. View scriptbutonuna tıklayıp komutları görebiliriz.

Powershell scriptlerimizi görmekteyiz. Biz Next ile sonraki ekrana ilerleyelim.

Bu adımımızda domain kurulabilmesi için bir kontrol yapılmakta. Resmimizde görüldüğü gibi tüm kontroller olumlu. Installile kurulumu başlatalım.

Kurulum işlemimiz başlamış durumda. Bu adım bilgisayarımızın performansına göre 10-15 dakika arasında bir zaman alabilir.

Kurulumumuz tamamlandı. Sistemimizin yeniden başlaması gerekmekte. Gelen ekrandaki uyarıda Close butonuna tıklayarak restart işleminin başlamasını sağlayalım.

Sistemimiz yeniden başlamak üzere ayarlar yapılandırılıyor.

Ayarlarımız tamamlandı ve Domain rolü kuruldu. COZUMPARK\Administrator olarak oturum açabilir duruma gelmiş bulunuyoruz.

Login olduğumuzda Windows 10 işletim sisteminin arayüzüne benzer bir arayüz bizi karşılıyor. Windows 10 1067 kerneli ile Windows Server 2016 kerneli aynı versiyona sahip.

Active Directory User and Computers konsolunda Domain Controllers kabında sunucumuzu görebiliyoruz.

DNS konsolumuza baktığımızda ayarlarımızın sorunsuzca oluşmuş olduğunu görebilmekteyiz.

Yine Active Directory Sites and Services konsolunda replikasyon ayalarının oluşmuş olduğunu görmekteyiz.

Active Directory Domain and Trust konsolunda gerekli öğelerin oluşmuş olduğu görülmekte.

Server Manager üzerinde Active Directory bileşenlerimizin oluşmuş olduğu görülmekte.

Servis konsolunda Active Directory servislerinin start olduğunu görmekteyiz. Kurulum sonrası yapmış olduğumuz kontrollerde Active Directory Domain Controller rolümüzün sorunsuz olarak kurulmuş olduğunu gördük.

Şimdi sunucumuz üzerinde Active Directory and Computers konsolu üzerinde bir kullanıcı tanımlayalım. Bu işlemi ADAC üzerinden ve powershell üzerinden yapma imkanımızda var. Boş bir yerde sağ tıklayarak NewàUser bölümüne tıklayalım.

Açılan ekranımızda kullanıcımıza ait istenen bilgileri girelim.

Kullanıcımıza bir parola verip parolasının expire olmaması için Password never expires seçimini yapalım.

Açılan ekranımızda oluşturulan kullanıcı için yaptığımız ayarların bir özeti sunulmakta. Finish ile adımlarımızı bitirelim.

Windows 10 Kullanıcı Bilgisayarının Domaine Dahil Edilmesi

Öncelikle kullanıcı bilgisayarımız ile Domain controller sunucumuz birbiri ile iletişim kurmak durumundadır. Dolayısı ile Kullanıcı ve Sunucumuz aynı ağ üzerinde olmalıdır.  Sunucumuzun ip adresini hatırlayacak olursanız aşağıdaki gibi yapılandırmıştık.

Çok büyük yapılar ve vlan ortamları olan yapılar haricinde ufak ve orta ölçekli yapılarda vlan yok ise sunucu ve kullanıcı aynı ip bloğunda olmalıdır. Bu nedenle kullanıcı bilgisayarımızın ip adresini aşağıdaki gibi yapılandırıyoruz. DNS olarak özellikle Domain Controller sunucusunun ip adresini vermiş olduğumuzdan emin olmalıyız.

Bu ayarlardan sonra sunucumuza ping atarak erişim olup olmadığını kontrol ettiğimizde durumun aşağıdaki gibi olması gerekir.

Şu anda mevcut kullanıcı bilgisayarımız WORKGROUP yapısına tabi durumda. Ayarları değiştir butonumuza tıklayalım.

Yine açılan ekranımızda Değiştir… butonumuza tıklayalım.

Kullanıcımızı domaine alabilmek adına yetkili bir kullanıcı hesabını kullanmalıyız. Aksine bir kural ve ayar yok ise her kullanıcı belirli sayışa cihazı domaine sahil edebilir.

Ben Administrator hesabımın bilgilerini giriyorum. Sonrasında Tamam butonuna tıklayalım.

Kullanıcı bilgisayarımız sorunsuzca Domaine sahil edildi. Gelen mesajı Tamam butonuna tıklayarak geçelim.

Gelen uyarı mesajını yine Tamam butonuna tıklayarak geçelim.

Bir önceki ekranımızı Kapat butonu ile kapatalım.

Bizden ayarların etkin olabilmesi adına sistemimizin yeniden başlatılması istenmektedir. Şimdi Yeniden Başlatbutonuna tıklayarak sistemimizi yeniden başlatalım.

Sistemimiz yeniden başladığında domain ortamında oturum açmaya hazır duruma geliyor. Oturum açmak için oluşturduğumuz kullanıcı adı ve parolamızı girerek oturum açalım.

Oturum açıldı ve görüldüğü üzere Workgroup yapısından COZUMPARK.LOCAL domain yapısına geçmiş olduğumuzu görebiliyoruz.

Domaine alınan kullanıcı bilgisayarının computer hesabı Active Directory Users and Computer konsolunda Computers kabının altında oluşmuş durumda.

Kurulum sonrası portal üzerinde sorular gelmesinden dolayı bir kullanıcının domaine alınmasını anlatmak istedim. Umarım yararlı olur. Bir başka makalede görüşmek dileğiyle.

Device Guard teknolojisi Windows 10 ve Windows Server 2016 ile birlikte hayatımıza girmiş yeni bir güvenlik teknolojisidir ve daha güvenlidir. Bu teknoloji Donanım ve yazılım güvenlik çözümlerinin birleştirilmesi sonrası oluşturulmuş yeni bir teknolojidir ve daha önceki Windows sürümlerinde bulunmamaktadır. Makalemiz içinde bu teknolojinin gereksinimlerini, çalışma mantığını ve yapılandırması hakkında teknik detayları aktaracağız.

Device Guard; Code Integrity Policies içinde bulunmayan hiçbir uygulama (zararlı olması gerekmemekte) güvenilmeyen uygulama olarak algılanacak ve bu uygulama, bilgisayar üzerinde yönetici haklarına sahip olsak bile çalıştırılmayacak, yüklenemeyecek ve kullanılamayacaktır.

VBS ile birlikte yapılandırıldı zaman koruma kalkanı Windows’ un Kernel i olarak adlandırdığımız çekirdeğini de kapsayacaktır ve kötü amaçlı bir saldırgan tarafından yazılmış olan bir yazılım, işletim sisteminin çekirdeğini yönetmek istediği zaman çalıştırabileceği kodlar çok sınırlı olacaktır.

Virtualization-Based Security ve Code Integrity Policies

Her gün, binlerce farkı türden saldırı yöntemleri gelişmekte ve birçok kez geleneksel koruma yöntemleri yeni saldırılara karşı çaresiz kalmaktadır. Windows 10 Device Guard ile bu güvenlik anlayışı tamamen değişmektedir.
Anti virüs yazılımının veya kullanmış olduğumuz diğer güvenlik çözümlerinin, bilgisayarlarımıza bulaşmakta olan zararlı yazılımları algılamadan önce Code Integrity Politikaları tarafında güvenli bir yazılım olarak imzalandı mı yoksa imzalanmadı mı bunların kontrolü yapılmaktadır.

Code Integrity

Code Integrity iki ana bölümden oluşmaktadır ve bu bolümler KMCI (Kernel Mode Code Integrity) ve UMCI (User Mode Code Integrity) olarak adlandırılmaktadır ve bir işletim sistemi olarak düşünebiliriz.
KMCI daha önceki işletim sistemlerinde bulunmaktaydı ve imzalanmayan sürücülere karşı işletim sistemini korumaktaydı.

Kernel Mode Code Integrity

KMCI teknolojisinin daha önceki işletim sistemlerinde bulunduğunu bilmekteyiz ve yukarıda gösterilen mimaride Windows 8.1 içinde bulunan KMCI mimarisi gösterilmektedir.

Daha önceki işletim sistemlerimiz üzerinde bulunan Kernel mod’ un birçok avantajı bulunmaktaydı ve bu avantajları yeni işletim sisteminde gelişerek devam etmektedir.

Fakat mimariye baktığımız zaman bir güvenlik açığı bulunmakta. Son kullanıcının sahip olduğu ara yüz ile işletim sisteminin yüklü olduğu bölüm aynı platform üzerinde barınmaktadır.

kernel security check

Kernel Mod ile User Mod un aynı platform üzerinde barınması, kullanıcının yakalanacak olduğu bir virüs veya kötü amaçlı bir yazılımın işletim sistemini bozmasına neden oluyordu.

Birçok Windows kullanıcısı yukarıdaki Kernel Security Check uyarısını almıştır. Bu hatanın birçok nedeni vardır ama en bilinen nedenleri yanlış veya imzasız sürücü yüklenmesi ve virüslü bir dosyanın işletim sistemini bozması, bozmaya çalışmasıdır.

Windows işletim sistemleri reload Kernel modüle özelliği ile kullanıcı biriminde yakalandığı bir virüs dosyası işletim sisteminin Kernel Modülüne zarar vermeye çalışıyor. İşletim sistemi bu hata ile karşılaştığı zaman mavi ekran hatası ile bizleri karşılıyor ve onarım işlemine başlıyor. Bu onarım işleminde, Windows un çekirdeği olan Kernel i onarmak ve reload özelliği sayesinde onarım sırasında Kernel i baştan yüklemektir.

Virtualization Based Security

Virtualization-Based Security ve Code Integrity Policies
Device Guard donanım özelliklerinden yararlanarak güvenlik seviyelerini yukarıya çekti ve gelişmiş donanım özelliklerini sonuna kadar kullanmaktadır. CPU virtualization extensions (Intel VT-x or AMD-V) ve level address translation özelliklerini içermektedir. Input/output memory management birimi olan IOMMUs İle güçlendirilmiş bir güvenlik bizlere sunulmaktadır.

Hyper-V Microkernelized

Aslında bugün konuşmaya başlamış olduğumuz Device Guard güvenlik çözümünün ilk adımları çok uzun zaman önce atıldı. Device Guard teknolojisinin çalışma mantığını anlayabilmek için Hyper-V mimarisini iyi bir şekilde analiz etmemiz gerekmektedir. Hikâyenin başlangıcı olan Hyper-V: Microkernelized or Monolithic makalesi ile bu hikâyenin başlangıcı Microsoft’ un güvenliğe vermiş olduğu önemi hatırlayabiliriz.

Hyper-V Architecture

Hyper-V nin ilk çıkmış olduğu günden beri Best practices for configuring Hyper-V hosts yapılandırmalarında Do not collocate other server roles maddesi yer almaktadır. Bu madde detaylı olarak incelendiği zaman, Hyper-V Rolü Windows işletim sistemi üzerinde bir rol olarak yüklendiği zaman ve Hyper-V ile birlikte başka bir rol yüklendiği zaman NOT SUPPORTED durumuna düştüğü ilk zamanlardan beri yazılıp-çizilmektedir.

Security guide for Windows Server 2012 makalesi içinde Chapter 1 Overview bölümü içinde güvenlik gelişimi ve derin bilgiler paylaşıldı.

Bugün, Device Guard teknolojisi Hyper-V mimarisinin bizlere sunmuş olduğu bütün güvenlik yeteneklerini neredeyse sunmaktadır.

CPU virtualization extensions ve SLAT, Code Integrity servisleri ile birlikte yapılandırdığınız zaman Kernel Modu korumaktadır.

Hyper-V Hypervisor

Hyper-V Özelliklerinden bu kadar bahsettik ama yanlış anlaşılmasın, Device Guard teknolojisi Hyper-V sunucusu ile birlikte kullanılan bir teknoloji değildir. Device Guard teknolojisi Hyper-V Hypervisor servislerini kullanmaktadır. Sanal Platformlarda ve fiziksel platformlarda kullanılabilmektedir.

Generation 2 Virtual Machine

Device Guard temel işletim sistemi gereksinimi Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server ve Windows Enterprise IoT işletim sistemleridir.

Device Guard Donanım bazlı yapılandırıldığı zaman Virtualization-Based Securityözelliklerinden yararlanabileceğiz. VBS ile birlikte Windows 10 un yüklenmiş olduğu bilgisayar üzerinde UEFI firmware version kontrolü, UEFI Secure Boot özelliğinin kontrolü Secure firmware update işlemlerinin kontrolü, HVCI compatible drivers kontrolü gibi birçok güvenlik avantajlarından yararlanabileceğiz.

Device Guard requirements for baseline protections adresinde her bir versiyon ile birlikte ürünün gelişimini ve güncel versiyon ile birlikte neler kazanıldığını, Device Guard uyumlu bir sunucu/Bilgisayar üzerinde yapılandırıldığı zaman hangi özelliklerini kullanabileceğimizin bilgilerine ulaşabilirsiniz.

Device Guard teknolojisini, yönetmiş olduğumuz organizasyona yaygınlaştırmadan önce kurumumuzun kullanmış olduğu bütün uygulamaları analiz etmemiz gerekmektedir. Device Guard Mimarisi makalemiz içinde bahsettiğimiz gibi Code Integrity Politikaları içinde olmayan hiçbir yazılım biz imzalamadığımız sürece çalışmayacaktır. Yanlış bir planlama sonrasında kendimize çok fazla iş yükü getirebilir,  ihtiyaç duyulacak bir yazılımın çalışmamasını neden olabiliriz.

Her projede olduğu gibi Device Guard teknolojisini sağlıklı kullanabilmek için iyi bir plan yapmak gerekmektedir. Bu makalemiz içinde kurumumuz için yeni CodeIntegrity Policy lerini oluşturacağız ve kullanacak olduğumuz komut seti Windows 10 ile birlikte geliştirilen New-CIPolicy Power Shell komutlarıdır. Policy i oluşturmadan önce Golden imajımızı incelemek ve temel gereksinimlerini kontrol etmemiz gerekmektedir.

Get-WmiObject

Device Guard projesinde oluşturacak olduğumuz Golden imajın önemi çok büyüktür. Golden bilgisayarımızın imajını almadan önce kurumumuz içinde kullanılmakta olan bütün uygulamaları bu golden bilgisayar üzerine yüklememiz gerekmektedir.  Golden imaj organizasyon seviyesinde alınması ileride oluşabilecek iş yüklerinin önüne geçecektir. Departman bazlı golden imaj zorunluluğu bulunmamaktadır.

SCCM veya benzeri bir yönetim aracı ile organizasyonumuz içinde kullanılan bütün uygulamaların listesini almak ve sonrasında bu uygulamaların her birisini golden imajımıza yükleme işlemi projenin başlangıcı olacaktır.

Yüklemiş olduğunuz uygulamaları Get-WmiObject -Class Win32_Product komutu ile listeleyerek doğrulayabilmekteyiz.

Hatırlatmakta fayda görüyorum golden imaj üzerine yüklemediğiniz hiçbir uygulamaya Device Guard güvenlik çözümü uygulandıktan sonra güvenilmeyecektir. Kısaca CodeIntegrity Policy içinde imzalanmamış bir yazılım olarak kalacaktır.

Generation 2

Golden imajın domainde olmaması ve sıfırdan kurulmuş bir işletim sistemi olması ve son güncelleştirmelere sahip olması önerilmektedir. Eğer Golden imajı bir sanal sistem üzerinde oluşturacaksanız bu sunucu sanallaştırma teknolojisinin Hyper-V olması gerekmektedir ve sanal sunucunun versiyonunun Generation2 olması gerekmektedir.

Get-HotFix

Get-Hotfix | Sort-object InstalledOn -Descending | Select -First 3 komutu ile golden imajımıza yüklenmiş olan en son güncelleştirmeleri kontrol etmemiz önerilmektedir.

windows10

Golden imajımızın Enterprise sürümünde ve en az 1607 versiyonuna sahip olması gerekmektedir. Winver komutu ile golden imajımızın sürümünü kontrol etmekteyiz.

Device Guard Virtualization Based Security

Systeminfo bilgilerini kontrol ettiğimiz zaman Device Guard Virtulization based security yapılandırmasının yapılmadığını görebilmekteyiz.

Golden imajımızı alacak olduğumuz bilgisayarımız üzerinde bütün kontrolleri yaptıktan sonra aşağıdaki komutlar ile golden imajımızı almaya başlıyoruz.

ConvertFrom-CIPolicy

$s1 = (gwmi -List Win32_ShadowCopy).Create(“c:\”,”ClientAccessible”)
$s2 = gwmi win32_shadowcopy |? {$_.id -eq $s1.ShadowID}
$d = $s2.deviceObject + “\”
Cmd /C mklink /d c:\scpy “$d”
New-CIPolicy -l PcaCertificate -f C:\Policy1.xml –s C:\scpy -Userpes
Set-RuleOption –option 3 –FilePath C:\Policy1.xml
ConvertFrom-CIPolicy C:\Policy1.xml C:\Policy1.bin
cp C:\Policy1.bin c:\Windows\System32\CodeIntegrity\SIPolicy.p7b

Code Integrity

Çalıştırmış olduğumuz komutlar golden bilgisayarımız üzerinde c:\scpy klasörü altına bir imaj almış durumda. Bu imaj golden bilgisayarımız üzerinde yüklü bulunan bütün uygulamaların ve işletim sisteminin bilgilerini kapsamaktadır.

SIPolicy.p7b

İşlemleri sırası ile gerçekleştirdiğimiz zaman Policy1.xml dosyasını Policy1.bin dosyasına çevirdik ve bin dosyasını ise SIPolicy.p7b dosyasına dönüştürdük. Oluşturmuş olduğumuz p7b dosyası c:\Windows\System32\CodeIntegrity yolu altında barınmaktadır.

Deploy Code Integrity Policy

Computer Configuration\Administrative template\System\Device Guard\Deploy Code Integrity Policy politikasını aktif duruma getiriyoruz ve oluşturmuş olduğumuz sertifikanın yolunu gösteriyoruz.

Audit Mode

Golden bilgisayarımız üzerinde system bilgilerini kontrol ettiğimiz zaman Device Guard User Mode Code Integrity yapılandırmasının Audit mode olarak çalıştığını görebilmekteyiz. Bu mode izlemek için kullanılmaktadır ve Device Guard herhangi bir eylem gerçekleştirmez.

Device Guard ı Audit Mode olarak yapılandırdığımız zaman kullanıcılarımız kullanmış oldukları bilgisayar üzerinde istedikleri gibi uygulama yükleyebilmektedirler.

Örnek senaryomuz içinde son kullanıcımız bilgisayarı üzerine WordViewerSkus uygulamasını yüklemeye çalışıyor ve kullanıcımız engellenmiyor, başarılı bir şekilde işlemini tamamlayabiliyor. Olay günlükleri içine herhangi bir olay günlüğü düşmemesinin nedeni Golden imajımız içinde Office Word Viewer kurulum dosyasının bulunmuş olması ve Golden imaj üzerine yüklenip, Code Integrety policy si tarafından imzalanmış olmasından kaynaklıdır.

Aynı bilgisayarımız üzerinde başka bir yazılımı yüklemeye çalışıyoruz. Bu yazılımda zararsız, 7zip uygulaması. Device Guard politikasını uygulamış olduğumuz bilgisayarımız üzerine 7zip uygulamasını yükleyebiliyoruz.

Code Integrety Audit Mode

Kullanıcımız, her iki uygulamayı bilgisayarı üzerine yükleyebildi fakat imzalanmayan 7zip uygulaması yüklenirken daha doğrusu ilk çalıştırıldığında Code Integrety olay günlüklerinde 3076 olay günlüğü oluştu. Yapılandırmamız Audit Mode olduğu için Device Guard bir eylem yapmayacak sadece olay günlüğü oluşturacaktır.

Windows Server 2016 RTM olarak hızlı bir şekilde IT dünyasına giriş yaptı. Birçok profesyonel IT blog yazarı Windows Server 2016 ile birlikte yeni makalelerini sıralamaya başladılar. Portalımız üzerinde bu konuda daha önce çokça kaynak yayımlandı. Ancak RTM olması ile birlikte makaleler yeniden hızlındı. Bu makalemizde Windows Server 2016 WSUS rolünü ele alıyor olacağız. Makalemiz iki bölümden oluşacak ilk makalemizde temel kurulum adımlarını ele alırken, ikinci makalemizde WSUS yapılandırması, konsol üzerine kullanıcıları toplamak ve update çekmesini sağlamak noktasında olacak.

WSUS açıklama olarak Windows Server Update Services anlamına gelmektedir. WSUS gereksinimi yapımızdaki sistemleri kendi ortamımızda konumlandıracağımız sunucu üzerinden güncelleme noktasında bize kolaylıklar sağlamaktadır. Bu kolaylıkları ele alacak olursak, Sistemlerimizin güncellenmesini merkezi bir noktadan yönetmek, raporlamak, network ve internet trafiğinde meydana gelecek darboğazların önüne geçmek olarak sıralanabilir.

Aşağıdaki şeklimize bakacak olursak, güncellemelerimizi yapımız içinde bir sunucu üzerinde toplayıp, bu güncellemelerimizi yine yapımıza dağıtabilmekteyiz. Bu bize yukarıdaki paragraftaki saydığımız kolaylıkları sağlamaktadır.

Sözü fazla uzatmadan adımlarımıza başlayalım. Öncelikle rolümüzü kurma adımına başlayalım.

Server Manager üzerine girerek işlemlerimize başlayalım. Bu işlemi resmimizde yer alan 2 Add roles and features linkine tıklayarak yapabileceğimiz gibi, Managebutonuna tıkladığımızda açılan Add Roles and Featuresmenüsünden de yapabiliriz. Add Roles and Features‘e tıklayalım.

Açılan ekranda sihirbaz ile yapabileceklerimiz noktasında bilgi verilmektedir. Next ile bir sonraki ekranımıza ilerleyelim.

Açılan ekranımızda iki seçeneğimiz yer almaktadır. Bunlardan birincisi olan;

Role-based or feature-based insallation : Rol ve Özellik bazında ekleme kurulum yapma imkanı verir. Windows Server 2016 içerisinde sahip olduğumuz sürüme göre, içerisinde bulunan ve ihtiyacımız olan rol ve özellikleri buradan ekleyip kaldırabilmekteyiz.

Remote Desktop Services installation: Eski zamanlarda Terminal Servis olarak anılan ve şimdi RDS (Remote Desktop Services) uzak masaüstü yapılandırmasını hızlı ve standart olarak buradan yapabilmekteyiz. Bu nedenle biz RDS kurulum ve yapılandırması yapmayacağımız için Role-based or feature-based insallation seçimini yaparak Next ile ilerliyoruz.

Windows Server 2008 ve 2012 ile birlikte sunucu kümesi oluşturarak bu küme üzerine toplu olarak ve farklı bir sunucu üzerinden Rol ve Özellik ekleme ve kaldırma işlemleri yapabilir duruma geldik. Tabi bu işlem Windows Server 2012 üzerinden doğrudan yapılabilirken Windows Server 2008’e bazı özellikler katmamız gerekiyordu. Bizim ortamımızda tek bir sunucumuz olduğundan ve bu sunucumuza Active Directory rolünü kuracak olduğumuzdan Adı, ip adresi ve versiyon bilgisi sunulan sunucumuzu seçerek Next ile ilerliyoruz.

Karşımıza gelen ekrandan biz Windows Server Update Services rolünü kuracağımız için bu rolü seçelim.

WSUS rolünün çalışabilmesi için gerekli olan özellik listesi karşımıza geldi. Bu özelliklerin otomatik olarak rol ile birlikte kurulabilmesi için Add Features butonuna tıklayalım.

Bu özellikler üstteki ekranımıza ek olarak aşağıdaki özellikleri kapsamaktadır.

Bu özelliklerimizi gördükten sonraNext ile sonraki adıma ilerleyelim.

IIS rolü üzerinde yapılandırılacak olan özellikler yine bize gösterilmektedir. Next ile bir sonraki adıma ilerleyelim.

WSUS yapılandırma öncesi bize kısa bilgiler sunulmaktadır. Bu ekranımızda Next butonuna tıklayarak bir sonraki adıma ilerleyelim.

WSUS kurulumu sırasında kullanılacak olan veri tabanı noktasında seçim yapmamız gerekmektedir. Sadece WSUS Servicesözelliğini kurarsak farklı bir WSUS sunucu ile bağlantı sağlayabiliriz. WSUS Services+WID Connectivity bileşenlerini aynı anda kurarsak sistemimize WSUS ve dahili veri tabanı kurulacaktır. WID Connectivity ile aynı anda SQL Server Connectivity özelliği aynı anda kurulamamaktadır. SQL Server Connectivity ortamda bir SQL sunucu var ise WSUS veri tabanımızı burada yapılandırma imkanını bize sunmaktadır. Biz ekranımızdaki gibi seçimimizi yaparak Nextile bir sonraki adıma ilerleyelim.

Bu ekranımızda biz dahili veri tabanını seçtiğimiz için bizden WSUS veri tabanının tutulacağı alanın belirtilmesi istenmektedir. Bu işlem için en az 6 GB NTFS formatında bir disk alanı istenmektedir. Tabi bizim seçeceğimiz güncellenecek ürün sayısı, dil çeşitli, güncelleme bileşenleri düşünülerek iyi hesap kitap yapıp ona göre bir alan belirlememizde yarar var. Ortalama bir kurum 50GB ile 200 GB arasında bir alan tahsis ederse amacına ulaşacaktır. Günümüzdeki teknolojiler ile disk genişletmek pek sorun olmadığından ileride bir darboğaz olması durumunda bu tabi ki aşılacaktır. Ben D: diskim üzerinde WSUS-DATABASEşeklinde bir yol belirliyorum. Next ile bir sonraki adıma ilerleyebiliriz.

Bu ekranımızda Windows Server 2016 WSUS rolünün kurulumundan sonra eğer gerekir ise, yeniden başlatma işleminin otomatik gerçekleşmesi için Restart the destination server automatically if required seçimini yapıyoruz.

Bu sorumuza YES ile yanıt veriyoruz.

Artık kurulum adımlarına başlayabiliriz. Installile kurulumu başlatalım.

Kurulum işlemi başladı.

Kurulum işlemi tamamlandı. Launch Post-installation task seçeneği ile yapılandırmanın tamamlanmasını sağlayalım. Bu aradaClose ile bu ekranımızdan çıkabiliriz.

Server managerüzerinden kontrol ettiğimizde WSUS için yapılandırma arka planda devam etmekte.

D: Diskimiz üzerindeki WSUS-DATABASE alanı içerisinde WSUS ile ilgili olan konteynerler oluşmaya başladı.

Server manager üzerindeki işlem tamamlandı.

Start menümüzde Windows Server Update Services kısa yolumuz oluştu. Kısa yolumuzu tıklayarak konsolumuzu açalım.

WSUS konsolumuzu ilk kez açtığımız için bizi bir sihirbaz karşılamakta. Bu sihirbazı bir kereye mahsus yapılandıralım. İlk aşamada sihirbazın yapacağı noktasında bilgi sunulmakta Next ile sonraki adıma ilerleyelim.

Bu ekranımızda ürün geliştirme nokrasında Microsoft ile bağlantı sağlama noktasında bilgi sunulmaktadır. Biz bu ekranda seçim yapmadan Nextile sonraki adıma ilerliyoruz.

Bu adımda senkronizasyon işleminin Microsoft update sistemiyle mi yapımızdaki farklı bir WSUS sunucuyla mı bağlantı yapılacağı noktasında seçim yapmamız gerekmektedir. Biz ortamımızdaki farklı bir WSUS sunucu ile senkronizasyon kurmayacağımız için, ekrandaki gibi varsayılan seçim ile Next butonuna tıklayarak bir sonraki adıma ilerliyoruz.

Ortamımızda bir Proxy varsa firewall tarafında Microsoft sunucularına erişim noktasında sorun yaşamamak adına burada Proxy bilgilerini girmemiz gerekmekte. Bizim ortamımızda bir Proxy olmadığından Next ile sonraki adıma ilerliyoruz.

Bu ekranımızda WSUS sunucumuzun Microsoft sistemleri ile iletişim kurması için Start Connecting butonuna tıklayalım.

Senkronizasyon işlemimiz 5-15 dakika arasında sürecektir. Bu süreyi bekleyerek senkronizasyon işleminin tamamlanmasını sağlayalım ve Next ile sonraki adıma ilerleyelim.

Bu ekranımızda içeride dağıtım yapacağımız güncellemelere göre dil seçimi yapmamız gerekmektedir. WSUS ile çok sayıda sisteme güncelleme dağıtma imkanımız var. Microsoft firmasının tüm sistemlerine güncelleme dağıtabiliyoruz desek abartmış olmayız. Bu nedenle dağıtım yapacağımız ürünlerin dil çeşitliliklerini hesaba katarak seçim yapalım ki veri tabanımız fazla büyümesin. Ben Windows update client sistemleri update dağıtacağım için ve sadece Türkçe işletim sistemlerine sahip olduğum için sadece Turkish seçimini yapıyorum. Bu seçimimizden sonra Next ile sonraki adıma geçelim.

Bu ekranımızda güncelleme dağıtacağımız sistemleri seçmemiz gerekmektedir. Ben yapımda Windows 10 işletim sistemine güncelleme dağıtacağım için Windows 10 seçimini yapıp Nextile ilerliyorum.

Bu ekranımızda dağıtacağımız güncelleme çeşitlerini seçmemiz gerekmektedir. Aşağıdaki seçimler varsayılan seçimler olup geriye kalan seçimler genelde WSUS üzerinden pek dağıtılmazlar. Veri tabanı boyutumuz devasa boyutlara ulaşabilir. Son yıllardaki sistemleri düşünürsek eskiye nazaran ayda bir minik güncellemeler yerine ayda birkaç defa yayımlanan büyük boyutlu güncellemeleri içermektedir. Windows 10 ile GB seviyelerinde güncelleme paketlerini gördük diyebiliriz. Aşağıdaki ayarlar ile bir sonraki adım için Next ile ilerliyoruz.

Bu ekranımızda WSUS sunucumuz ile Microsoft sistemi arasındaki senkronizasyon metodunu seçiyoruz. Bu işlemi manuel yapmayacağımız ve network internet trafiğine yük bindirmeyeceğimiz için otomatik olarak seçip gece vaktinde sistemlerin boş olduğu zamana planlama yaparak Next ile sonraki adıma ilerliyoruz.

Başlangıç senkronizasyonu seçili durumdayken Finishile adımlarımızı tamamlayalım.

Sonunda konsolumuz geldi.

Konsolumuzda şu anda hiçbir veri olmadığından grafik ekranlarımız bir anlam ifade etmiyor. WSUS üzerindeki yapılandırmamız tamamlandığından DASHBOARD ekranı anlam ifade ede duruma gelecektir.

Bu makalemizi burada noktalayıp sonraki makalemizde Active Directory, Group Policy ve Konsol üzerindeki geriye kalan işlemlerimiz tamamlayacağız.

Bir sonraki makalemizde görüşmek dileğiyle.

İlk makalemizde Windows Server 2016 Kurulum işlemimizi yapmıştık. Bu makalemizde ise Wsus yapılandırmamızı gerçekleştireceğiz. Sözü fazla uzatmadan adımlarımıza başlayalım.

Konsol üzerinde düzenli bir yapı kurmak adına işletim sistemleri arasında bir düzenleme yapmanız takip ve düzen açısından iyi olacaktır. Bu nedenle update dağıtacağımız sistemleri gruplar şeklinde ayıralım. All Computeröğesi üzerinde sağ tıklayarak Add Computer Group…’a tıklayalım.

İlk aşamada ben Windows10 işletim sistemine update dağıtımı yapacağım için, Windows 10 işletim sistemlerinin güncellemesini alacak olan kullanıcıları toplamak adına Windows10 isminde bir grup oluşturuyorum. Grubumuza bir isim verip Addbutonuna tıklayalım.

Bu aşamadan sonra örnek olması açısından Server 2016 sunucularımız için bir grup oluşturma adına All Computeröğesi üzerinde sağ tıklayarak Add Computer Group…’a tıklayalım.

Grubumuza bir isim verip Addbutonuna tıklayalım.

Gruplarımızı tanımadık. Makalemizin ilk kısmındaki ekranları hatırlayacak olursak Microsoft firmasının neredeyse tüm sistemlerini Wsus üzerinden güncelleyeceğimizi söylemiştik. Bu nedenle catalog üzerinde bizi çok sayıda güncelleme karşılayacaktır. Gerek dağıtım sırasında gerekse bir yanlışlık yapmamamız açısından sadece dağıtımını yapacak olduğumuz update kataloglarını gruplamamızda yarar var.

Bu nedenle makalemize konu olan Windows 10 işletim sistemlerine güncelleme dağıtmak için, Windows 10 işletim sistemlerini kapsayan bir view filtresi oluşturalım. Updatesmenüsüne sağ tıkladıktan sonra açılan menüden New Update View…’e tıklayalım.

Açılan ekranımızdaki sihirbaz üzerinde filtreleme kriterimizi seçmemiz istenmektedir. Burada update türlerine, işletim sistemi türlerine gruplara zaman periyoduna ve wsus güncellemelerine göre filtreleme yapabiliriz. Biz Windows 10 işletim sistemine göre filtreleme yapacağımız için Updates are for a spesific productseçimini yapalım.

Bir üst ekranımızda bunulan Any Product linkine tıkladıktan sonra filtre oluşturacağımız işletim sistemini seçelim ve OK butonuna tıklayalım.

Filtremize bir isim verip OK ile işlemimizi tamamlayalım.

Aşağıdaki ekranımıza bakacak olursanız Windows 10 filtremiz, Windows 10 ve Server 2016 grubumuz oluşmuş durumda. Şimdi Windows 10 işletim sistemine ait güncellemeleri ortaya çıkartalım. Tabi bu güncellemelerin çıkması için senkronizasyon işleminin tamamlanması ve dolayısı ile biraz zaman ve sabır lazım. Wsus yaklaşık olarak bir iki gün içerisinde tamamen oturan bir roldür. Yapılandırır ve beklemeye başlarsınız.1 numaralı adımda Filtremize tıkladığımızda ve2 numaralı adımda Unapprovedve Any seçimlerini yapıp Refreshbutonuna tıkladığımızda onaylanmamış Windows 10 güncellemelerimiz karşımıza çıkacaktır.

Ortam hazır, updateler dağıtılmak üzere hazır. Şimdi artık kullanıcılarımıza Wsus üzerinden update yapmaları için ayarlar yamamız gerekmekte. Bu ayarları merkezi olarak rahatça dağıtmak için GPO kullanacağız. Öncelikle Active Directory Users and Computer konsolunu açalım.

Yine burada düzenli bir yapı oluşturmamızda yarar var. Bu nedenle update ayarlarını dağıtacak olduğumuz Computerleri bir OU altında toplayalım. Konsol ağacının üstünde sağ tıklayarak NewàOrganizatiın Unit menüsüne tıklayalım.

OU için bir isim verip OKile bu adımı bitirelim.

Computers kabı altında bir adet Windows 10 işletim sistemine sahip Computer öğemiz var.Wsus GPO ayarları computer bazında uygulanabilir olduğundan bu computer öğemizi yeni oluşturduğumuz Windows-10 OU’muza taşıyalım.

Computer öğesi üzerinde sağ tıklayarak çıkan menüden Move…menüsüne tıklayalım. Bu işlemi bu şekilde yapabildiğimiz gibi Mouse ile sürükle bırak yaparak yapmamız mümkün.

Move işleminin yapılacağı alanı yani yeni oluşturduğumuz Windows-10 OU kabını gösterip OK ile taşıma işini tamamlayalım.

Computer öğemiz bizim belirlediğimiz Windows-10 OU kabına taşınmış durumda.

Şimdi Windows-10 Ou kabında bulunan computer öğelerimize update sunucu ayarlarımızı basmamız gerekmekte. Bu nedenle Group Policy Managment konsolunu açalım. Windows-10 OU kabımıza sağ tıklayarak Create GPO in this domain, and Link it here... menüsüne tıklayalım.

Oluşturacak olduğumu GPO için bir isim belirleyip OK butonuna tıklayalım.

GPO öğemiz oluştu.

Bu aşamada GPO ayalarımızı yapabiliriz. GPO öğesine sağ tıklayıp Editkısmına tıklayalım.

Açılan ekranımızda Computer ConfigurationàAdministrative TemplatesàWindows Companents altında yer alan Windows Update kabına gelelim. Burada çok sayıda policy ayarı bizi karşılamaktadır. Tabi bunlardan hangileri sizlere lazım olur ise ona göre ayar yapmanız gerekmektedir. Bize temel olarak 2 policy ayarı yetecektir. Bir tanesinden sistemlerimizin güncelleme ve raporlama yapacağı adresi belirtirken diğerinde güncelleme sunucusunu denetleme sıklığı ayarını yapacağız.

İlk olarak sistemlerimizin otomatik güncelleme ayarını yapmak için Configure Automatic Updates objesi üzerinde çift tıklayalım.

Öncelikle Enabled ile kuralımızı aktif edelim. İkinci adımda 4-Auto download and Schedule the installseçimini yapalım. Burada 5 opsiyon var ancak bizim için ideal seçim 4 olacaktır. Bu seçim ile otomatik olarak Wsus üzerinden indir ancak kurmak için zamanlamayı kullan demiş oluruz. Zamanlama müdahale etmemeniz durumunda resmimize göre 03:00 olacaktır. Bunu yapınıza göre planlamanız mümkün. Bu ayarımızı yapıp OK butonu ile tamamlayalım.

Şimdi ikinci kuralımızı yapılandıralım. Bu kuralımızda update ve raporlama sunucumuzu belirleyeceğiz. Bu nedenle Specify intranet Microsoft update service location objesine tıklayalım.

Öncelikle kuralımızı Enabled ile aktif edelim Set the intranet update service for detection updates: seçimi ile update sunucu adresimizi belirleyelim. Bizim sunucu adresimiz http://192.168.2.100:8530şeklinde. Varsayılan ayarlara müdahale etmediyseniz 8530 portunu eklemelisiniz. Normalde rol kurulduğunda wsus üzerinde bu port otomatik olarak açılır ancak sizin ortamınızda farklı firewall yapınız varsa bu porta izin vermelisiniz. Set the intranet statistics server: kısmında ise raporlama sunucumuzu belirlememiz gerekir. Biz güncelleme ve raporlamayı aynı sunucu üzerinde yapacağımız için adresimizi http://192.168.2.100:8530  şeklinde belirliyoruz.

Bu ayarlardan sonra artık ayarlarımızı kullanıcılarımıza atamamız gerekmekte. Windows-10 kabı içerisinde yer alan RIZAS computer öğesine sahip olan kullanıcı bilgisayarımızda Gpupdate/ force komutu ile gpo ayarlarını hızlıca alalım. Bunu yapmamış olmamız durumunda kullanıcı yeniden login olduğunda veya belirlenen GPO çekme süresinde bu ayarı alır.

Evet ayarlarımızı yaptık. Şimdi kullanıcımıza dönelim1 numaralı alanda güncelleme ekranımızı açtığımızda güncelleme olmadığı bilgisi verilmekte. 2 numaralı alanda ise “Microsoft Update güncelleştirmesini çevrimiçi denetleyin.” seçeneği yer almakta. Normalde bu seçenek çıkmaz. Wsus kullanan sistemlerde bu seçenek çıkar. Nedeni ise Wsus haricinde bize istememiz durumunda manuel olarak Microsoft sunucuları üzerinden güncelleme yapma imkanı vermesidir.

Biz ayarları aldık ama bazı durumlarda sorun yaşanabilir. Ayarları alıp almadığımızı tam olarak anlamak için Rsop.mscöğesini yönetici olacak çalıştıralım. Rsop.msc alınan gpo ayarlarını gösteren bir araçtır.

Gerekli olan ayarları almış durumdayız. 2 adet kural uygulamıştık bu kurallar Windows Update kabı altında kullanıcımıza yansımış durumda.

Bu ayarları alan kullanıcı Wsus üzerinden güncelleme talebinde bulunması halinde Unassigned Computer grubu altına dolayısı ile All Computer grubu altına gelecektir. All Computer seçiminden sonra Refeshbutonuna tıklayalım.

Şu anda kullanıcımıza ait sistem Wsus konsoluna düştü. Sarı dikkat işareti ile güncel olmadığı görünmekte.

Wsus ayarını alan sistemler ilk olarak Unassigned Computer grubuna düşer. Burada düzenli bir yapıyı sağlamak istediğimizi makalemizin başında belirtmiştik. Bu nedenle bu kullanıcı öğesi üzerinde sağ tıklayarak Change Membership... linkini tıklayalım.

İki adet grup tanımlaması yapmıştık. Windows10 olan grubumuzu seçerek OK butonuna tıklayalım.

Şu anda sistemimiz gerekli grup altında yerini aldı.

Makale başında bir filtre oluşturmuştuk. Filtremize tıkladıktan sonra ikinci adımda Unapproved ve Any seçimini yapalım. Bu onaylanmamış tüm güncellemeleri getir anlamına gelmektedir. Refreshbutonumuza tıkladığımızda dağıtılmamış Windows 10 işletim sistemine ait olan güncellemeler karşımıza gelmekte.

Güncellemelerimiz üzerinde sağ tıklatıp Approve… linkine tıklayalım.

Karşımıza güncellemelerin hangi gruba yapılacağını belirleyeceğimiz ekran gelmekte. Biz Windows 10 grubu altındaki sistemlerimize Windows 10 güncellemelerimizi dağıtacağımız için Windows10 grubuna tıklıyor ve sonrasında Approved for Install yapıyoruz.

Güncellemelerimiz başarı ile dağıtım için hazırlandı.Closeile ekranımızdan çıkalım.

Güncellemeler şu an Mcirosoft üzerinden download edilip dağıtıma hazırlanıyor.

Belirli zaman sonrasında kullanıcımızın ayarlı olan 03:00 saatini beklemeden Güncelleştirmeleri denetlebutonuna tıklayarak işlemi manuel yapalım.

Şu anda sistemimiz inen güncelleştirmeleri buldu. İndirip yükleme aşamasına geçti.

Bu güncelleştirmelerimiz yüklendikten sonra durum güncelleştirme geçmişine aşağıdaki gibi yansıyacaktır.

Tüm güncellemeler indirilip kurulduğunda ise sistem tamamen güncel hale gelecektir. Bu kısmında fazla acele etmeden birkaç gün Wsus’un kendine gelmesini beklememizde yarar var.

Tüm güncellemelere yüklendikten sonra konsol üzerinde sistemlerimiz yeşil check işaretine sahip olacaktır. Buraya kadar olan işlemlerde biz manuel müdahale etmemiş olsak, kullanıcı önce zamanı geldiğinde GPO ayarını alacak, Sonrasında zamanı gelince Wsus üzerinden güncellemeleri denetleyecektir. Bundan sonraki adımda yine otomatik güncelleme dağıtma imkanımız var ama ben güncellemelerin Approve edilme kısmının manuel olarak yapılmasından yanayım. Ayrıca güncellemeleri birkaç gün geriden yüklerseniz yararlı olabilir. Bazen güncellemelerde sorun olup geri çekme gibi durumlar yaşanabiliyor.

Gerekli güncellemeler sağlandıktan sonra konsol üzerinde bilgisayar sayımız ve güncelleme durumlarına göre grafiklerimiz şekillenecektir. 

Yeşil: Tüm güncellemeler alınmış her şey yolunda anlamına gelir.

Sarı: Yüklenecek eksik güncellemeler var demektir.

Kırmızı: Yüklemeler sırasında bazı güncellemelerin hata verdiği anlamını ifade eder.

Genel olarak konsol üzerinde yapılması gereken adımlarımızı inceledik. Bundan sonraki aşamada ise konsol üzerinde geri kalan menülere kabaca göz gezdirelim.

Synchronizations: Bu kısımda Wsus sunucumuzun Microsoft sunucuları ile olan iletişimlerinin senkronizasyon durumlarının bilgisi verilir.

Options ekranında ilk makalemizde rol kurulumu sonrasında Wsus yapılandırma sihirbazında yaptığımız ayarları değiştirme ve görme imkanına sahip durumdayız. Burada ek olarak E-Mail Notifications kısmını inceleyelim.

Burada mail gönderici ve alıcı adreslerini belirleyerek günlük senkronizasyon ve update durumları ile ilgili olarak mail bildirimi almamızı sağlayabiliriz. Yollanacak mail için zaman ve dil seçimi yaparak gelen maili rahat yorumlama imkanına sahibiz.

Tabi yukarıdaki ekranımızda belirttiğimiz adreslerin mail alabilmesi için Bir SMTP tanımlaması yapabiliriz. Ortamınızda bir mail sunucunuz varsa, smtp olarak kullanabileceğiniz bir adres varsa gerekli smtp bilgisini burada tanımlayabilirsiniz.

Genel olarak Wsus konusunda 2 bölümden oluşan makaleler ile bilgi vermeye çalıştım. Ortamda ağımıza bağlı olan domainde olmayan sistemlerimiz var ise bunlara yine Wsus üzerinden güncelleme dağıtma imkanına sahibiz.

Bu işlem için Workgroup olarak çalışan sistemlerimiz üzerinde bulunan local policy özelliğini kullanabiliriz. Bunun için yine local policy aracı olan gpedit.msc aracını kullanmamız gerekir.

Yine aynı ayar konsolumuz gelecektir. Burada yukarıdaki GPO üzerindeki ayarları uygulayarak Workgroup sistemlerin güncelleme almasını sağlayabiliriz.

Yukarıdaki durum haricinde kullanıcılar bazen güncelleme çekmeyebilir veya manuel tetiklememiz yapmamız gerekebilir. Bu durumda aşağıdaki komutu kullanmamız gerekir.

Wuauclt /detectnow

Bazı durumlarda güncelleme alan kullanıcı durumu konsola yansımaz. Alınan güncelleme sayıları veya tüm güncelleme alması durumunda yeşil ikona dönüşüm olmayabilir. Bu durumda aşağıdaki komutu çalıştırmamız gerekir.

Wuauclt /reportnow

Bu makalemizin de sonuna geldik. Bir başka makalemizde buluşmak dileğiyle.

New-Cı Policy uygulamasını oluşturduğumuz zaman Golden imajımız üzerinde yüklü bulunan uygulamalar güvenilir ve bilinir uygulamalar olarak Device Guard politikalarına eklendi ve Device Guard yaygınlaştırma işlemleri tamamlandı. Aradan belirli bir zaman geçti ve bizim imzalamış olduğumuz X yazılımının 1.2.3 versiyonu 1.2.4 olarak güncellendi.

Bu güncelleştirme sonrası Device Guard Politikaları nasıl davranacak. Device Guard, 1.2.3 olarak imzalanmış olduğumuz uygulamaya güvenmeye devam edecek ama güncellenen uygulamanın 1.2.4 versiyonuna güvenmeyecektir. Bizler 1.2.4 uygulaması için ayrı bir policy oluşturmamız gerekmektedir. Device Guard’ a göre güncelleştirme alınan uygulama başka bir yazılımdır.

Bir diğer senaryo, policy i oluşturmuş olduğumuz zaman Y yazılımını golden imaja yüklemeyi unuttuk ve Device Guard deployment işlemini gerçekleştirdik. Bu senaryo içinde aynı eylem geçerli olacak ve Y yazılımı policy içinde güvenilir olarak imzalanmadığı için Device Guard eklemediğimiz, unuttuğumuz her bir yazılıma güvenilmeyecektir.

Yapacak olduğumuz işlem yeni bir Policy daha oluşturup her iki policy  Merge-CIPolicy Power Shell komutlarıyla birleştirmek olacaktır.

Merge-CIPolicy işlemlerini yapabilmek için ben aynı referans makinemi kullanıyorum. Fakat aradan zaman geçti ve mevcut referans makinenize ulaşamıyorsunuz. Problem değil. New-CIPolicy uygulamış olduğumuz makinenin gereksinimlerinde bir tane Windows 10 ENT işletim sistemi kurmamız ve daha önce oluşturmuş olduğumuz Policy’e sahip olmamız yeterlidir.  Policy mizin dönüşüme uğramamış ham hali varsa aynı uygulamaları tekrardan Golden bilgisayarımıza yüklememize gerek bulunmamaktadır. Bu sebepten ötürü Merge işlemlerine başlamadan önce daha önce oluşturmuş olduğumuz Policy’ nin yedeğini almanızı önermekteyim.

Referans bilgisayarımız Audit Mode içinde ve imzalamak istediğimiz uygulamalarımızı yüklüyoruz ve varsa eğer yapılandırmalarını gerçekleştiriyoruz. İmzalanacak olan uygulamanın kurulum dosyası referans bilgisayarımız üzerinde olması gerekmektedir.

Örneğimiz içinde 7-Zip uygulaması Policy miz içinde bulunmamakta. Senaryomuz içinde 7-zip uygulaması için izin vereceğiz. Golden bilgisayarımız Audit mode içindeyken 7-zip uygulamasını kurdum ve kurulum dosyasını ise Downloads pathi altında bıraktım.

New-CIPolicy -Audit -Level Hash -FilePath c:\Policy2.xml -Userpes

Yukarıda çalıştırmış olduğum komutlar sonrası 7-Zip uygulaması imzalandı.

Aşağıdaki komut ile Poliy1 ve Policy2 dosyaları birleştirildi ve yeni oluşturmuş olduğumuz MergePolicy.xml dosyamız içinde yeni imzaladığımız 7zip dosyasının kurulum dosyasının da imzalandığını görebilmekteyiz.

Merge-CIPolicy -PolicyPaths C:\Policy1.xml,c:\Policy2.xml -OutputFilePath c:\MergePolicy.xml

Aşağıdaki komut ile oluşturmuş olduğumuz Merge.xml dosyasını bin formatına çeviriyoruz.

ConvertFrom-CIPolicy C:\MergePolicy.xml C:\MergePolicy.bin

Ve son olarak aşağıdaki komut ile birleştirilmiş olan merge edilmiş policymizi dağıtılacak olan SIPolicy.p7b dosya türüne dönüştürüyoruz.

cp C:\MergePolicy.bin c:\Windows\System32\CodeIntegrity\SIPolicy.p7b

Bu işlemlerden sonra artık 7zip uygulamamızda güvenilir uygulamalar içine dahil edilmiş oldu. Mevcut yeni sertifikamız içinde ilk imzaladığımız uygulamalarımız ve bu makale ile birlikte imzaladığımız 7-zip uygulamamız güvenilir, imzalı uygulamalar içinde.

CodeIntegrity olay günlüklerini sıfırlıyorum ve güvenilen uygulamalarımız olan 7zip (merge policy ile birlikte imzalanan uygulama) ve WordViewerSkus (ilk policy oluşturulduğu zaman imzalanan uygulama) uygulamalarını çalıştırıyorum ve hiçbir olay günlüğü oluşturulmuyor.

İmzalanmayan winrar dosyasını henüz yüklemedim sadece exe dosyasını açtım.

CodeIntegrity Policy sine hemen bir olay günlüğü düştü.

Olay günlüğünün detaylarına baktığım zaman imzalanmayan winrar uygulaması için olay günlüğünün oluştuğunu görebilmekteyiz.

Device Guard teknolojisini Code Integrety politikaları sayesinde birleştirilmiş bir koruma kalkanı oluşturmakta ve korumuş olduğu Windows 10 bilgisayar üzerinde Kernel Mode ve User Mode olmak üzere iki farklı platform üzerinee korumasını gerçekleştirebilmektedir. User mode platformu üzerinde gerçekleştirmiş olduğu koruma özelliklerini Audit Mode makalesi içinde inceledik. Bu makalemiz içinde User Mode içinde Enforced Mode yapılandırmasını ve Kernel Mode yapılandırması için temel gereksinimleri paylaşacağız.

Device Guard teknolojisini Kernel Mode yani işletim sisteminin çekirdeğini ve bunun ötesinde çalışmış olduğu bilgisayarın donanımının sahip olduğu firmware ve ilk açılış bölümü olan boot bölümünü koruyabilmektedir. Bu korumayı gerçekleştirebilmemiz için bir takım donanımsal gereksinimlere ihtiyacımız bulunmaktadır ve PC OEM requirements for Device Guard and Credential Guard makalesi içinde paylaşılmaktadır.

Device Guard requirements for baseline protections inceleyeceğiz.

64-bit CPU.
Device Guard teknolojisi VBS yani vitulization base securty kullanmakta ve Windows Hypervisor un temel gereksinimi olan 64 bit CPU zorunlu koşmaktadır. Günümüz bilgisayarları neredeyse bu gereksinimi karşılamaktadır.

CPU virtualization extensions Plus extended page tables
Virtulization extension özelliği VT-x (Intel) ve AMD-V olarak bilinir ve Second Level Address Translation (SLAT) olarak adlandırılırlar. Bu özellik yapılandırıldığı zaman kazanacak olduğumuz güvenlik daha önce belirttiğimiz gibi Kernel Mode ile İşletim sistemi bir-birlerinden izole esilmiş bir şekilde çalışacaktır ve vaat edilen sıfır gün koruması bu izolasyon ile birlikte sağlanacaktır.

UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot

Device Guard yapılandırılmış olan cihazının ilk açılması sırasında yetkilendirilmiş kodlar ile açılmasını kontrol etmektedir. Bu özellik aktif edildiği zaman Rootkitler i engelleyebilmektedir. Device Guard yeni bir teknoloji ve bu özelliğe sahip atakları engellemek pek mümkün olmadığı veya zor olduğu düşünülebilir.

Özgür ansiklopediden almış olduğumuz bilgiler şunu söylemekte;

“Rootkit’in gerçekte hangi dosyaları değiştirdiği, Kernel’a hangi modülü yüklediği, dosya sisteminin neresinde kayıtlı olduğu, hangi ağ servisiüzerinde dinleme yaparak uygun komutla harekete geçeceğini tespit etmek güçtür.”

Ama artık Windows işletim sistemlerinde mümkün olduğunu görebilmekteyiz. Bu özelliği aktif duruma getirebilmemiz için Hardware Compatibility Specification for Systems for Windows 10, version 1607 makalesi içinde belirtilen donanım gereksinimlerini tamamlamış olmamız gerekmektedir.

Secure firmware update process

UEDI Firmware deki gibi firmware (aygıtın yazılımı zaten) kısıtlı olsa bile bir işletim sistemine sahip ve patch güncelleştirilmesi, yükseltme işlemlerinde aynı UEFI Secure Booy özelliğindeki gibi sistemi Rootkitler den koruyabilmektedir. Donanım gereksinimi UEFI Secure Boot ile aynıdır.

HVCI Compatible Drivers

Hypervisor Code Integrity özelliği ile sürücülerin kod bütünlüğünü sağlamış olabiliyoruz. Kernel mode içinde sadece kod bütünlüğü sağlanmış sürücüler çalışabilecektir. Kernel içinde herhangi bir malware çalışmayacağı gibi koruma bütünlüğünü, direncini arttıracaktır.

Risk altında bulunan potansiyel API lerin listesine Driver compatibility with Device Guard in Windows 10 adresindenöğrenebilirsiniz.

Windows Operating System

Bu özellikleri kullanabileceğimiz işletim sistemleri Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server ve Windows Enterprise IoT sürümleridir.

İsmi ve özellikleri donanımsal gereksinimleri işaret etmiş olsa bile Device Guard teknolojisini sanal platform içinde kullanabilmekteyiz. Sanal platform gereksinimi Hyper-V Platformları için Gen2 sanal makine olması temel şarttır.

Baseline protections başlığı altında paylaşmış olduğumuz seçenekleri Device Guard için geliştirilen Set-RuleOption Power Shell komutları ile aktif ve pasif duruma getirebiliyoruz

Makalenin bundan önceki bölümlerinde yapmış olduğumuz işlemler sadece Audit Mode ile ilgiliydi ve Device Guard sadece olayları izliyor ve olaylara karşı günlük tutuyordur. Bizler artık Enforce Mode ile eylem yapmasını istiyoruz.

Eyleme geçmeden önce oluşturmuş olduğumuz Merge Policy’ sini kontrol ediyoruz. Baseline protections bölümünde bahsettiğimiz ve Set-Ruleoption içinde aktif ve pasif duruma getirebileceğimiz rule seçenekleri xml içinde bulunmakta.

Yukarıdaki komut ile Option 3 siliyoruz. Bir önceki ekran görüntüsüne dikkatli bakarsanız bu option 3 ün Audit mode olduğunu görebileceksiniz ve Enable durumda.

Set-RuleOption –option 3 –FilePath C:\MergePolicy.xml  -delete

Yukarıdaki komut ile oluşturmuş olduğumuz MergePolicy.xml datası içinde option3 siliyoruz yani audit modu ve policy içinde otomatik olarak Enforce mod devreye girmiş olacaktır.

Komut sadece xml içindeki veriyi değiştiriyor. Xml değiştirmemekte. Sonrasında daha önce yaptığımız gibi merge policy dosyasını bin dosya formatina ve bin formatinida yeni sertifika almak üzere komutlarımızı çalıştırıyoruz.

Device Guard uygulanmış bilgisayarlarımız yeni sertifikamızı aldıktan sonra Enforced mod altında çalışacaktır.

CodeIntegrity politikalarımızı sıfırlıyoruz ve testlerimize başlıyoruz.

Bilgisayarımız daha önce imzaladığımız 7zip uygulamasını başarılı bir şekilde yüklerken imzalamadığımız winrar uygulaması için hata verdi ve yükleme yapmamıza müsaade etmedi.

Audit Moda sadece izleme ve olay günlüğüne kayıt alırken Enforce Mode kuralları uyguluyor.

Code Integrety olay günlüklerine baktığımız zaman Event ID 3077 olay günlüğünü görebilmekteyiz.

option 3 parametresini Set-RuleOption –option 3 –FilePath C:\MergePolicy.xml olarak değiştirdiğimiz zaman ve sonrasında tekrardan bin ve sertifikanın baştan oluşturma komutları sonrasında Enfoced Mode türünden Audit Mode geri dönüş yapabilmekteyiz.

Önceki makale serilerimizde Windows Server 2016, Domain rolünün kurulumu, Additional Domain Controller kurulumu, FSMO rollerinin aktarımı gibi noktalarda bilgiler vermiştik. Bu makalemizde ise Windows Server 2016 ADC sunucuyu kaldırma adımlarını ele alıyor olacağız.

Öncelikle ADC sunucu neden ortamdan kaldırılır bunlara ele alalım. Ortamda ADC ye gerek olmadığı düşünülür ise, Ortamda tek DC bırakarak Sistem uptade işlemi yapılması durumunda sonradan güncel ADC’ler kurma gibi senaryolarda ADC ortamdan kaldırılabilir. Bunun haricinde ADC üzerinde bir sorun olması durumunda kısa yoldan kaldırıp tekrar kurmak gibi senaryolar düşünülebilir. Adımlarımıza başlayalım.

Öncelikle ortamımıza bakalım ortamımızda iki adet domain Controller Rolüne sahip sunucumuz var.

Domain Ortamında bulunan FSMO rollerinin tamamı ADC.COZUMPARK.LOKAL isimli sunucuda.

Kontrol amaçlı yine test ettiğimizde rollere sahip olan makinamızın ismi ADC. Biz bu durumda DC isimli sunucumuz üzerindeki Active Directory rolünü kaldırıyor olacağız.

DC sunucumuz üzerinden Server Manager’içalıştıralım.

Açılan ekranımızda Manage kısmına tıklayıp açılır menüden Remove Roles and Features kısmına tıklayalım.

Bilgilendirme sihirbazı ekranında Next butonuna tıklayarak sonraki adıma geçelim.

Lokal sunucumuzdan rol kaldıracağımız ve bir farm oluşturmadığımız için varsayılan seçimlere dokunmadan Next butonuna tıklayarak ilerleyelim.

Active Directory Domain Services rolümüz kurulu olarak görünüyor. Kenarındaki checkbox seçimini kaldıralım.

Bu rolün kalkması ile birlikte gerek duyulmayan özelliklerin kaldırılacağı noktasında bilgi verilmekte. Biz Remove Features butonuna tıklayalım.

Validation Result ekranında karşımıza gelen ekranda Demote this domain controller linkine tıklayalım.

Bu ekranımızda rolü kaldıracak kullanıcı değiştirme imkanımız var. Ancak biz Administrator kullanıcısı ile bu işlemi yaptığımız için kullanıcı seçimini olduğu gibi bırakıyoruz. Eğer domain sunucusu erişilemeyecek durumda ve iletişim sorunları var ise bu durumda Force the removal of this domain controller checkbox kutusunu işaretlememiz gerekecek. Bizim erişim ile ilgili olarak bir sorunumuz olmadığından Next ile ilerleyelim.

Sunucumuzun üzerinde DNS ve Global katalog rollerinin olduğu belirtilmekte.

Ancak biz sunucuyu ortamdan kaldıracağımız için bu uyarıyı göz ardı ederek Proced with removal checkbox kutusunu işaretliyoruz ve Next ile ilerliyoruz.

Domain rolü kaldırılacak olan sunucumuz için bir Local Admin Parolası belirledikten sonra Next ile sonraki ekrana ilerliyoruz.

Son adım aşamasına geldik. Buraya kadar olan adımları View Script script olarak görüp farklı durumlarda üzerinde oynamalar yaparak Powershell üzerinden kullanabiliriz. Demote butonuna tıklayarak işlemi başlatalım.

İşlemler sorunsuzca tamamlandı. Close butonuna tıklayarak sistemimizi yeniden başlatalım.

Sunucumuz yeniden başladı. AD rolleri disable duruma geldi.

İşlemimiz tamamlandı. Ancak domain rolümüz kaldırıldı.

Domain yönetim araçlarımız kaldırılmamış durumda. Bu araçlar yine sunucumuzda görünmeye devam edecektir.

Görüldüğü gibi Actice Directory Users and Computers konsolumuzda Domain Controllers kabında artık tek bir Domain sunucumuz kaldı. DC isimli sunucumuz üzerinden AD rolü kaldırıldı.

DC isimli üzerinden rol kaldırdığımız sunucu domaine üye olan bir sunucu olarak Computers kabında yerini aldı.

Bir makalemizin daha sonuna geldik. Bir başka makalede görüşmek dileğiyle.