~/yazilar/windows-server-core-ile-calismak

Windows Server'ı masaüstü olmadan yönetmek

8 dk okuma

içindekiler
sconfig
================================================================================
                         Welcome to Windows Server
================================================================================

  1)  Domain/workgroup:                   Workgroup:  WORKGROUP
  2)  Computer name:                      WIN-3H8K2Q1LM0P
  3)  Add local administrator
  4)  Remote management:                  Enabled

  5)  Update setting:                     Download only
  6)  Install updates
  7)  Remote desktop:                     Disabled

  8)  Network settings
  9)  Date and time
  10) Telemetry setting:                  Required
  11) Windows activation

  12) Log off user
  13) Restart server
  14) Shut down server
  15) Exit to command line (PowerShell)

Enter number to select an option:

Core kurulumunda oturum açınca karşına masaüstü yerine bu menü geliyor. Güncel sürümde sconfig oturum açılır açılmaz kendiliğinden başlıyor, 15 ile çıkınca PowerShell'e düşüyorsun, geri dönmek için yine sconfig yazıyorsun. İlk bakışta fazla çıplak görünüyor. Ama bir sunucuyu ağa bağlayıp, adını verip, domain'e alacak kadar her şey bu ekranda.

Neden masaüstü olmadan

Kurulum sihirbazında iki seçenek çıkıyor: Server Core ve Desktop Experience. Core'da Explorer, tarayıcı ve grafik kabuğun büyük kısmı yok. Bunun pratik karşılığı şu: o bileşenlere gelen yamalar bu sunucuya gelmiyor, aylık güncellemeler daha küçük oluyor ve yeniden başlatma gerektiren güncelleme sayısı azalıyor. Disk ve bellek tüketimi de düşüyor, tek bir sunucuda fark etmez ama aynı host üzerinde yirmi VM varsa birikiyor.

Bir de alışkanlık tarafı var. Masaüstü olan sunucuya RDP ile girip bir şeyi elle düzeltmek çok kolay. Core'da bunu yapamadığın için değişiklikler komutla yapılıyor, komutlar da zamanla script'e dönüşüyor. Bir sonraki sunucuda aynı işi tekrar etmek kopyala yapıştır kadar kısa sürüyor.

Bedeli de var:

  • Bazı üçüncü parti yazılımlar (yedekleme ajanları, donanım üreticisinin araçları, eski iş uygulamaları) Desktop Experience istiyor. Kurmadan önce üreticinin dokümanına bak.
  • Core ile Desktop Experience arasında sonradan geçiş yok. Yanlış seçtiysen yeniden kurulum gerekiyor.
  • Sorun anında konsolda olay günlüğüne bakmak, grafik arayüze alışkın biri için daha yavaş.

Son madde için "App Compatibility" adlı Features on Demand paketi var, Core'a Event Viewer, Explorer ve bazı MMC konsollarını ekliyor. Bence ilk iş olarak kurulacak bir şey değil, gerçekten ihtiyaç olursa düşünülür.

Domain controller, DNS, DHCP, dosya sunucusu ve Hyper-V host'u Core'da sorunsuz çalışıyor. Bu serideki DC'ler de Hyper-V host'u da Core olacak.

Başlamadan önce elinde olması gerekenler: kurulumu bitmiş bir Core sunucu, ona konsoldan erişim (iLO, iDRAC, hipervizör konsolu ya da başında bir monitör) ve ağda yönetim için kullanacağın bir Windows makine. Konsol erişimi önemli, çünkü ağ ayarını yanlış yaparsan uzaktan geri dönemiyorsun.

İlk ayarlar, doğru sırayla

sconfig menüsü numaralı ama o sırayla gitmiyorum. Benim sıram ağ, isim, saat, güncellemeler ve en son domain. Domain'e alma DNS'e bağlı, DNS ayarı da ağ ayarının parçası. İsim değişikliği yeniden başlatma istiyor ve domain'e katılmadan önce düzgün bir isim olsun istiyorum, yoksa AD'de bir süre WIN-3H8K2Q1LM0P diye bir bilgisayar nesnesi dolaşıyor.

Menü arka planda PowerShell cmdlet'lerini çağırıyor. Her adımda karşılığını da yazıyorum, çünkü on sunucuyu aynı anda kuruyorsan menüde gezinmek yerine bunları bir script'e koymak daha mantıklı.

Ağ (8)

Menüde önce adaptörün index numarasını seçiyorsun, sonra statik adres, maske, gateway ve DNS soruluyor. PowerShell'de aynı iş:

Get-NetAdapter
Name      InterfaceDescription                ifIndex Status MacAddress         LinkSpeed
----      --------------------                ------- ------ ----------         ---------
Ethernet  Microsoft Hyper-V Network Adapter         4 Up     00-15-5D-0A-14-15   10 Gbps
New-NetIPAddress -InterfaceAlias Ethernet -IPAddress 10.10.20.21 -PrefixLength 24 -DefaultGateway 10.10.20.1
Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 10.10.20.11, 10.10.20.12

Arayüz önceden DHCP'den adres ve gateway aldıysa ilk komut şu hatayla dönebiliyor:

New-NetIPAddress : Instance DefaultGateway already exists

Eski varsayılan rotayı ve DHCP'den gelen adresi temizleyip tekrar deniyorum:

Set-NetIPInterface -InterfaceAlias Ethernet -Dhcp Disabled
Remove-NetRoute -InterfaceAlias Ethernet -DestinationPrefix 0.0.0.0/0 -Confirm:$false

DNS sunucusu olarak ne verdiğin burada önemli. Domain'e alınacak her makine DNS olarak sadece domain controller'ları göstermeli, kurumun genel resolver'ını ya da modemi değil. Örnekteki 10.10.20.11 ve 10.10.20.12 serinin ikinci yazısında kuracağım DC'ler. Henüz yoklarsa geçici bir DNS ver, DC'ler kurulunca buraya dön.

İsim (2)

Rename-Computer -NewName srv01 -Restart

NetBIOS tarafında 15 karakter sınırı var. Daha uzun bir isim verirsen Rename-Computer uyarı veriyor ve NetBIOS adı kırpılıyor. Kısa ve kurumun isimlendirme düzenine uyan bir şey seç.

Saat (9)

Set-TimeZone -Id "Turkey Standard Time"
w32tm /query /status

Sunucu domain'e katıldıktan sonra saatini domain hiyerarşisinden alıyor, o yüzden burada sadece saat dilimini düzeltmek yetiyor. Workgroup'ta kalacak bir sunucuysa w32tm ile kurumun NTP sunucusunu göstermek gerekiyor.

Güncellemeler (5 ve 6)

Güncelleme ayarında genelde üç seçenek var: otomatik, sadece indir ve manuel. Ben "sadece indir" seçip kurulumu bakım penceresinde 6 numarayla yapıyorum. Kurumda WSUS ya da başka bir yama yönetim aracı varsa bu ayarı zaten grup ilkesi belirliyor, sconfig sadece mevcut durumu gösteriyor.

Uzak masaüstü (7)

Kapalı bırakıyorum. Core'a RDP ile bağlandığında masaüstü gelmiyor, aynı konsol penceresini görüyorsun. Uzaktan yönetimin asıl yolu aşağıdaki PowerShell Remoting. RDP'yi açman gerekirse Network Level Authentication zorunlu olan seçeneği seç.

Domain (1)

Add-Computer -DomainName ad.example.com `
    -OUPath "OU=Sunucular,DC=ad,DC=example,DC=com" `
    -Credential (Get-Credential ORNEK\yonetici) `
    -Restart

Domain henüz kurulu değilse bu adımı Active Directory yazısından sonraya bırak. yonetici hesabını da orada açıyorum.

-OUPath vermezsen bilgisayar nesnesi varsayılan Computers container'ına düşüyor. Oraya grup ilkesi bağlanamıyor, sonradan taşımak da unutuluyor. Sunucular için ayrı bir OU açıp en baştan oraya almak daha temiz. Get-Credential parolayı ekrandan güvenli şekilde alıyor, script'e ya da komut geçmişine düşmüyor.

Domain henüz yoksa bu adımı şimdilik atla. Active Directory'yi bir sonraki yazıda kuruyorum.

Konsolu yanlışlıkla kapatırsan

Core'da PowerShell penceresini kapatınca siyah bir ekranla baş başa kalıyorsun. Panik yok: Ctrl+Alt+Del ile Task Manager'ı aç, "Run new task" ile powershell yaz. Ya da oturumu kapatıp tekrar aç, sconfig yeniden geliyor.

PowerShell Remoting

Windows Server'da WinRM varsayılan olarak açık geliyor, sconfig menüsünde 4 numaranın yanında "Enabled" yazmasının anlamı bu. Yönetim makinen ve sunucu aynı domain'deyse Kerberos devrede ve ekstra ayar gerekmiyor:

Enter-PSSession -ComputerName srv01
[srv01]: PS C:\Users\yonetici\Documents>

Tek tek bağlanmak yerine aynı komutu birkaç sunucuda çalıştırmak çoğu zaman daha işe yarıyor:

Invoke-Command -ComputerName srv01, srv02, dc01 -ScriptBlock {
    Get-Service W32Time | Select-Object Status, Name
}
Status  Name    PSComputerName
------  ----    --------------
Running W32Time srv01
Running W32Time dc01
Running W32Time srv02

Komutlar paralel çalıştığı için sonuçlar karışık sırayla geliyor. PSComputerName sütunu hangisinin nereden geldiğini söylüyor.

Sunucuya dosya kopyalamak için ayrıca paylaşım açmana gerek yok, açık bir oturum üzerinden gönderebiliyorsun:

$s = New-PSSession -ComputerName srv01
Invoke-Command -Session $s -ScriptBlock { New-Item -ItemType Directory -Path C:\Scripts -Force | Out-Null }
Copy-Item -Path .\kontrol.ps1 -Destination C:\Scripts\ -ToSession $s
Invoke-Command -Session $s -ScriptBlock { & C:\Scripts\kontrol.ps1 }
Remove-PSSession $s

Ping'e cevap vermemesi seni yanıltmasın. Core'da ICMP echo kuralı varsayılan olarak kapalı, Remoting çalışırken ping çalışmayabiliyor. İzleme sistemin ping ile kontrol ediyorsa kuralı açıyorum:

Enable-NetFirewallRule -Name FPS-ICMP4-ERQ-In

Domain dışındaki sunucular

Sunucu workgroup'taysa ya da yönetim makinen domain'de değilse ilk deneme genelde şununla bitiyor:

Enter-PSSession : Connecting to remote server srv01 failed with the following error message : The WinRM client
cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is
not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the
TrustedHosts configuration setting. ...

Hata mesajı iki çözümü de söylüyor. Kısa yol TrustedHosts:

# Yönetim makinesinde, yönetici olarak
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'srv01' -Concatenate
$cred = Get-Credential srv01\Administrator
Enter-PSSession -ComputerName srv01 -Credential $cred

Bunu laboratuvar ve geçici kurulumlar için kullanıyorum. TrustedHosts'a eklenen makinede istemci karşısındakinin gerçekten o sunucu olduğunu doğrulamıyor, NTLM ile kimlik bilgisi gönderiyor. İnternette sıkça görülen -Value '*' örneği de bu kontrolü bütün makineler için kapatıyor, onu hiç kullanma.

Kalıcı çözüm HTTPS. Sunucuya kurum CA'sından, adı sunucunun FQDN'iyle eşleşen bir sertifika alıp WinRM'e HTTPS listener ekliyorsun:

# Sunucuda
$thumb = (Get-ChildItem Cert:\LocalMachine\My |
    Where-Object Subject -eq 'CN=srv01.ad.example.com').Thumbprint
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $thumb -Force
# Sadece yönetim ağından
New-NetFirewallRule -DisplayName 'WinRM HTTPS' -Direction Inbound -Protocol TCP -LocalPort 5986 `
    -RemoteAddress 10.10.20.0/24 -Action Allow
# Yönetim makinesinde
Enter-PSSession -ComputerName srv01.ad.example.com -UseSSL -Credential $cred

Bağlanırken sunucu adını sertifikadaki adla aynı yazmazsan sertifika hatası alıyorsun. Kendinden imzalı sertifika da teknik olarak çalışır ama istemcide doğrulamayı kapatmanı gerektiriyor, o da TrustedHosts'tan farksız hale geliyor.

İkinci atlama sorunu

Remoting'de herkesin bir kez takıldığı yer: srv01 üzerinde açtığın oturumdan bir dosya paylaşımına erişmeye çalışınca "Access is denied" alıyorsun. Kimlik bilgilerin varsayılan olarak ikinci makineye taşınmıyor. Buna "double hop" deniyor. CredSSP'yi açmak işi çözüyor ama kimlik bilgini uzaktaki makineye bırakıyor, o yüzden önermiyorum. Çoğu durumda dosyayı önce -ToSession ile kopyalamak ya da komutu doğrudan dosyanın olduğu sunucuda çalıştırmak yetiyor. Gerçekten gerekiyorsa resource-based Kerberos constrained delegation daha güvenli bir yol.

Windows Admin Center

Her şey PowerShell ile yapılabiliyor ama olay günlüklerine, performans sayaçlarına ya da sertifika deposuna bakmak için tarayıcıdan açılan bir arayüz işleri hızlandırıyor. Windows Admin Center (WAC) tam olarak bu. Sunucu lisansıyla birlikte ücretsiz geliyor ve hedef sunucuya ajan kurmuyor, altta yine PowerShell Remoting ve WMI kullanıyor. Yani Remoting çalışıyorsa WAC'ın da büyük kısmı çalışıyor.

Birkaç kurulum kararı var:

Önce nereye kurulacağı. WAC'ı ayrı bir yönetim sunucusuna gateway olarak kuruyorum (wac01 diyelim). Domain controller'a kurma. Gateway, yönettiği her sunucuya erişebilen bir makine, kendisi iyi korunmalı.

Kurulum, test için kendinden imzalı bir sertifika üretmeyi teklif ediyor. Kalıcı kullanımda kurum CA'sından wac01.ad.example.com adına bir sertifika al, yoksa herkes tarayıcı uyarısını geçmeye alışıyor.

WAC'ın kendi erişim ayarlarında gateway kullanıcılarını ve yöneticilerini bir AD grubuyla sınırla. Gateway'e erişebilen herkes, kendi yetkisi neyse onunla hedef sunuculara bağlanabiliyor. WAC yetki vermiyor, ama kapıyı kimin çaldığını da sen belirliyorsun.

WAC'ta bir de uzantı kataloğu var. Uzantılar gateway üzerinde kod çalıştırıyor, sadece ihtiyacın olanları ve tanıdığın yayıncılardan kur.

Her bağlantıda parola sormasın

Gateway modunda WAC, senin adına hedef sunucuya bağlanıyor. Delegasyon tanımlı değilse her sunucuya geçişte kimlik bilgisi soruyor ya da bazı araçlar hata veriyor. Hedef sunucularda gateway'e resource-based constrained delegation izni veriyorum:

$wac = Get-ADComputer wac01
Get-ADComputer -Filter * -SearchBase "OU=Sunucular,DC=ad,DC=example,DC=com" |
    Set-ADComputer -PrincipalsAllowedToDelegateToAccount $wac

Bu komut her sunucudaki mevcut değerin üzerine yazıyor. Daha önce başka bir hesaba delegasyon verdiysen onu da listeye eklemen gerekiyor, yoksa o bağlantı bozuluyor.

WAC'ta bir sunucuyu ekleyip açtığında soldaki araç listesinde olaylar, servisler, dosyalar, sertifikalar, güncellemeler, Hyper-V ve PowerShell konsolu gibi bölümler çıkıyor. Bir sorun anında olay günlüğüne bakmak ya da bir servisi yeniden başlatmak için RDP'ye ihtiyaç kalmıyor.

Konsola artık sadece ağ koparsa gidiyorum.

Sıradaki yazı: Active Directory kurulumu ve ikinci domain controller