Windows Server 2019

Hiljuti kuulutas Microsoft, et selle aasta teises pooles tuleb välja Windows Server 2019.  Juba praegu saavad Windows Insider programmiga liitunud alla laadida Server 2019 eelvaate versioone.

Windows Server 2019 on järgmine Long-Term Servicing Channel väljalase.  See tähendab et see sobib muuhulgas Exchange, Sharepointi või SQL Serveri jooksutamiseks ning kaugtöölaua serveriks.

Muuhulgas on lubatud, et Server Core paigaldus peaks kuni 3 korda väiksemaks minema.  Siis on hea hulgi konteinereid luua.

Lubatud on veel mitmeid asju, nagu näiteks Windows Subsystem on Linux ja Windows Admin Center (endine Project Honolulu), samuti nagu juba Windows 10 peal olemasolevad Windows Defender Advanced Threat Protection ning Windows Defender ATP Exploit Guard.

Võta endale aega, tõmba eelvaated alla, paigalda ning proovi.  Ja kui leiad midagi parandada, siis saada kindlasti tagasisidet.

Advertisements

Powershell Direct

Windows 10 ja Server 2016 võimaldavad luua PowerShelli sessiooni Hyper-V host masina pealt otse virtuaalmasinasse.  See funktsionaalsus kannab nime PowerShell Direct ja on isegi dokumenteeritud.

Dokumentatsioonist on välja kukkunud see pisiasi, et virtuaalmasina häälestuse versioon peab olema 8.0 või värskem.  Ilma selleta ei õnnestu virtuaalmasinaga ühendust saada.  Selle asemel tuleb veateade:

An Error has occured which Windows PowerShell cannot handle. A remote session might have ended.

Põnev on see, et nii saab ühendust isegi Windows 10 virtuaalmasinaga, milles on Powershell Remoting ikka veel välja lülitatud.

 

Powershelli tulevikust

Eelmine kord rääkisime sellest, kuidas tuvastada keskkonda, milles skript jookseb.  Sealt jäi välja üks pisiasi: kuidas tuvastada Nano Server või Server Core keskkonda.

Server Core keskkonnaga on lihtne, seal on meil tavaline Powerhsell keskkond ja OS funktsioonidega kaasatulevad haldusmoodulid.  Vajadusel saab seda kontrollida:

$regPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels\'

Get-ItemProperty -Path $regPath -Name ServerCore

if (Get-ItemProperty -Path $regPath -Name Server-Gui-Shell -ea SilentlyContinue) {
  "Server with Desktop Experience"
} elseif (Get-ItemProperty -Path $regPath -Name ServerCore -ea SilentlyContinue) {
  "Server Core"
} elseif (Get-ItemProperty -Path $regPath -Name NanoServer -ea SilentlyContinue) {
  "Nano Server"
} else {
  "Not a Server OS"
}

Nano Server keskkonnaga on natuke raskem.  Nimelt on seal ruumi kokkuhoiuks OS funktsionaalsust vähendatud, sealhulgas .Net Framework on seal .Net Core, mitte täielik .Net Framework.  Ja kuna Powershell sõltub .Net keskkonnast, siis on ka Powershelli funktsionaalsus vähendatud.  Lisaks on puudu terve hunnik haldusmooduleid, mis tavaliselt olemas on.  Vähendatud funktsionaalsusega keskkond on tuntud kui Powershell Core edition:

$PSVersionTable.PSEdition

if ($PSVersionTable.PSEdition -like 'Core') {
  Write-Verbose 'Powershell Core'
} else {
  Write-Verbose 'Windows Powershell'
}

Skriptile võib lisada kontrolli, et vältida skripti käivitumist vales keskkonnas:

#Requires -Version 5.1
#Requires -PSEdition Core

Samuti on võimalik mooduli lisamisel/kasutamisel kontrollida, et see toetab keskkonda, kus teda kavatsetakse kasutada:

Find-Module -Tag PSEdition_Core

Get-Module -ListAvailable |
  Where-Object CompatiblePSEditions -Contains "Core"

Get-Module -ListAvailable | Where-Object {$_.CompatiblePSEditions}

Esialgu on moodulid ilma vajaliku infota manifestis, ent tulevikus peaksid moodulid seda infot sisaldama.  Samas on Powershell Gallery moodulid juba sildistatud.

Arvestades, et Powershell 6 on juba olemas, tasub tähele panna:

  • Windows Powershell 5.1 on viimane omast klassist ja seda edasi ei arendata.
    • Kõik Windows Powershelliga seotud probleemid/ettepanekud tuleb raporteerida UserVoice saidis.  Vigade parandusi väidetavasti veel tehakse.
  • Powershell v6 on täielikult Powershell Core.  Seda ei panda Windowsiga kaasa, kuna seda arendatakse korraga mitmele platvormile: Windows, Linux, macOS.
  • Powershell Core paigaldatakse Windows Powershelli kõrvale ja see tuleb käivitada kui pwsh.exe
  • kogu tulevane arendus toimub Powershell Core peal.
    • kõik Powershell Core-ga seotud probeemid/ettepanekud tuleb esitada Github saidis.
  • Powershell Core ei sisalda enam järgmiseid asju:
    • Powershell ISE liides.  Arendustiim pakub alternatiivina kasutada Visual Studio Code redaktorit, mille Powershelli plugin on suht tasemel.
    • Töövoogude (workflow) mootor.
  • Desired State Configuration saab samuti ümber kirjutatud .Net Core baasil.
  • Powershell 2.0 režiimist on kavas lahti saada.

Powershell Core kasutamisel on vaja tuvastada ka OS, mille peal joostakse.  Kuna CimCmdlets moodul pole veel Powershell Core osa, kui OS ei ole Windows, siis tuleb OS tuvastada teist moodi:

$PSVersionTable.PSEdition

#Requires -PSEdition Core
$PSVersionTable.OS

if ($PSVersionTable.PSEdition -like "core" ) {
  "Powershell core, OS: {0}" -f $PSVersionTable.OS
} else {
  "Windows Powershell"
}

#Requires -Version 6
$IsWindows
$IsMacOs
$IsLinux

Praegu veel ei ole, aga tulevikus peaks moodulite manifesti ilmuma ka toetatud OS-i näitamine.

Kokkuvõtteks võib öelda, et juba praegu tasub vähehaaval oma skripte/mooduleid üle vaadata ning lisada vajalikud kontrollid, et vales keskkonnas mitte tundmatuid veateateid saada.

Mis keskkonnas mu skript jookseb

Iga Windowsi süsteemiülem peab oskama PowerShelli kasutada.  Kui ta seda ei oska, siis ei saa ta ennast Windowsi süsteemiülemaks nimetada.  Ja vähehaaval nad seda ka õpivad (kui nad juba ei oska).

Kõik on väga tore, kuni me teame, millises masinas me oma asju jooksutame.  Aga kui me oleme jõudnud juba sinnamaale, et koodi jooksutatakse automaatselt, siis läheb elu keerulisemaks.  Nimelt tuleb siis hakata tuvastama, et mis keskkonnas kood parasjagu jookseb.  Sest kui seda mitte teha, siis võib kood mitte töötada.

Vanasti oli lihtne, tuli vaid tuvastada Powershelli versioon.  Selleks oli kaks meetodit:

if ($PSVersionTable.PSVersion -lt "5.0") {
    throw "see on vale PowerShelli versioon"
}

#Requires -Version 5.0

Neist esimese puhul ei pea tingimata skripti tööd katkestama.

Windows 8-st alates hakkasid Powershelli moodulid kaasa tulema ka opsüsteemiga.  Samuti on vaja moodulite olemasolu kontrollida juhul, kui kasutada mõnd iselisatud funktsionaalsust.  Ka seda saab kahte moodi teha:

if (-not (get-module Hyper-V -ListAvailable)) {
    throw "Vajalik funktsioon puudu, katkestan"
}

#Requires -Modules Hyper-V

Vajadusel saab kontrollida ka mooduli versiooni:

if (-not (
    Get-Module Hyper-V -ListAvailable |
      Where-Object Version -EQ "2.0.0.0"
    )) {
      throw "Vajalik moodul puudu, katkestan"
    }

#Requires -Modules @{ModuleName="Hyper-V";ModuleVersion="2.0.0.0"}

Tasub tähele panna, et #Requires kontrollid töötavad ainult salvestatud skripti sees ning neid kontrollitakse juba skripti laadimisel.  See seab nende kasutamisele mõningad piirid.

Kui moodulite halduseks on oma koodihoidla, siis saab muidugi lihtsamalt:

#Requires -RunAsAdministrator
#Requires -Modules PowerShellGet
Find-Module userprofile -MinimumVersion 1.0 -Repository PSGallery |
    Install-Module -Force -Scope AllUsers

Get-InstalledModule | Update-Module

Aga vahel ei piisa ka mooduli olemasolu/versiooni kontrollist.  Näiteks on Windows 8.1-ga kaasas olevas moodulis (NetTCPIP) olemas käsk Test-NetConnection, mida Windows 8-ga kaasas olevas moodulis pole.  Aga mooduli versiooninumber on mõlemal sama.  Siis tuleb kontrollida konkreetse käsu olemasolu:

if (Get-Command Test-NetConnection -ErrorAction SilentlyContinue) {
    #olemas, võib tegutseda
} else {
    Write-Error "käsk puudu"
}

Get-Command telnet

Vahel oleks vaja hoopis teada, kas mõni opsüsteemi funktsioon on antud masinas olemas või puudu.  Windows Serveri haldusliidesed on funktsionaalsustest eraldi paigaldatavad ning võivad paikneda hoopis teises masinas.  Serveriga on asi lihtne.  Kui skripti jooksutavas masinas on ServerManager moodul (seda saab ka klient-OSile paigaldada, kui tõmmata omale RSAT)

if (-not (Get-WindowsFeature -Name RSAT-DNS-Server).Installed) {
    Install-WindowsFeature -Name RSAT-DNS-Server
}
#olemas, võib tegutseda

Klient-OSi puhul on see natuke keerulisem:

#Requires -Modules Dism
#Requires -RunAsAdministrator
if ((Get-WindowsOptionalFeature -Online -FeatureName telnet*).state -eq
    [Microsoft.Dism.Commands.FeatureState]::Disabled) {
      Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient
    }

Nüüd jääb veel vaid üle kontrollida, et kas meil on käes server-OS või midagi muud:

#Requires -Modules CimCmdlets
if ((Get-CimInstance Win32_OperatingSystem).ProductType -eq 1) {
    "Workstation"
} else {
    "DC or Server"
}

#Requires -Modules Dism
#Requires -RunAsAdministrator
if ((Get-WindowsEdition -Online).Edition -like 'Server*') {
    "on server"
} else {
    "klient, vist"
}

Olen seni teadlikult vältinud OS versiooni kontrolli.  nagu ülaltpoolt näha, pole seda enamasti vaja.  Ent arvestades Windows 10 (ja nüüd kohe varsti ka Server 2016) väljalaske tsükliga, võib seda vaja minna:

if ([environment]::OSVersion.Version -ge "6.3") {
    "Windows 8.1 või värskem"
}

Õnnetuseks otsustas Microsoft antud viisile panna peale kontrolli: kui rakendus ise ei deklareeri, et ta tunneb uuemaid OS versioone, siis valetatakse talle versiooniks alati “6.2.9200” ehk siis Windows 8/Server 2012.  Lisaks on Windows 10 versiooninumbri algus kõigil väljalasetel sama, muutub ainult BuildNumber.  Seda aga saab kontrollida:

switch ((Get-CimInstance Win32_OperatingSystem).BuildNumber) {
    10240 {"Win10 RTM"}
    10586 {"Win10 1511"}
    14393 {"Win10/Svr16 1607"}
    15063 {"Win10 1703"}
    16299 {"Win10/Svr16 1709"}
default {"Insider build"}
}

Get-CimInstance kasutamine võimaldab teha kontrolli ka eemalt.  Samamoodi saab ka versiooninumbri kätte.  Tuleb lihtsalt arvestada, et CIM tagastab versiooninumbri kui stringi ja see tuleb ise versiooninumbriks teisendada, kui seda vaja peaks olema:

(Get-CimInstance Win32_OperatingSystem).Version -as [version]

Microsofti eksamite kordamisest

Siiamaani on olnud sedapidi, et kui Microsofti eksam on sooritatud, siis seda enam uuesti teha ei saa.  Samas on tehnoloogia areng läinud nii kiireks, et paar aastat tagasi tehtud eksam ei näita enam oskusi kasutada praegust tehnoloogiat.

Nüüd on olukord juba mõned päevad teistsugune.  Kiirema arenguga tehnoloogiate eksameid on võimalik aasta möödudes uuesti sooritada.  Ehk siis kui eelmisest eksami sooritamisest on möödunud 365 päeva, saab samale eksamile uuesti registreeruda.

Esialgu on korduvaks sooritamiseks valmis kiiremini muutuvate tehnoloogiatega seotud eksamid.  Näiteks kõik MCSA: Cloud Platform ja MCSA: Office 365 tiitlite jaoks sobivad eksamid.  Lisaks veel ka osad MCSA: Windows Server 2016 eksamid.  MCSE tasemetest on uuesti sooritamiseks valmis MCSE: Cloud Platform and Infrastructure uuemad eksamid, ent suurem osa neist on muuhulgas ka juba mainitud MCSA taseme tiitlitega seotud.

Microsofti sertifitseerimisest ja tiitlitest

Seoses oma sisemiste ümberkorraldustega on Microsoft ühtlasi otsustanud muuta ka oma sertifitseerimisprogrammi ja tiitleid.  Seni kasutatud tiitlid kehtivad kuni 31.03.2017 ja pärast seda muutuvad aegunuteks.  Nende asemel said septembris välja kuulutatud uued tiitlid, mis on “paremini” seotud Microsofti tegevusvaldkondadega:

MCSA taseme tiitlid ei muutu.

Muuhulgas muudeti nüüd jälle ära tiitlite aegumine: uued tiitlid enam ei aegu.  Küll aga muutub nüüd võimalikuks uute tiitlitega seotud valikeksameid korra aastas uuesti teha, et tõestada endale/maailmale oma teadmiste olemasolu ja ajaga kaasas käimist.

PowerShell Linuxile

Ja ongi saanud tõeks see, mida juba mõnda aega oodatud on.  Powershell on kättesaadav Linuxi ja Mac OS X platvormile.  Koos sellega on Powershelli lähtekood tehtud avalikuks ning on saadaval GitHubis Powershelli projekti saidis.

Hetkel on saadaval veel alfa-staatuses kood (v6.0.0-alpha.9), ent kuna tegemist on avatud koodiga arendusprojektiga, siis iga hetkega areneb see edasi.

Vastav info on väljas ka Powershelli kodulehel .

Muuhulgas tasub mainida, et koos Windows 10 aastapäeva väljalaskega tuli välja ka Windows Management Framework (WMF) 5.1 .  Varasematele platvormidele on praegu saadaval vaid eelvaate versioon.  Ning Windows 7 ja Server 2008-le paigaldamisel eeldatakse, et WMF 4.0 on masinas juba olemas…

Nagu ka varasemate versioonidega, ei tasu seda installida Exchange või Sharepoint serverisse.