Exchange 2013 uuenduste paigaldus

Sai hiljuti just läbi tehtud Exchange 2013 serverile uuenduste paigaldus.  Ja pärast seda olen veendunud, et ainuke õige viis Exchangele uuenduste pealepanekuks on olemasoleva serveri kõrvale uue paigaldamine ning rollide ületõstmine.  Sest nii hoiab kõvasti närve ja tõenäoliselt ka aega kokku.  Ning lisaks muudele eelistele saab uuendamist teha rahulikult keset päeva.

Exchange on juba pikka aega olnud selline keskkond, kus parandused lastakse välja ühe komplektina.  Ning Exchange 2013 puhul on seesama komplekt sobiv ka uue serveri paigalduseks.  Aga kui Sa järele proovid, siis tuleb välja, et testitud on ainult tühja masinasse Exchange paigaldust.

Mis siis valesti on?  Paigaldusprotsess on jagatud mitmeks sammuks.  Iga samm paigaldab/uuendab ühe komponendi.  Uuendamise puhul võetakse sammu alguses ports teenuseid (sealhulgas Exchange teenused), pannakse need seisma ja keelatakse nende käivitamine.  Kuskil paigalduse käigus aga läheb neid teenuseid järsku vaja ning teenused käivitatakse uuesti.  Windowsi teenustega on tavaliselt kõik hästi, ent Exchange enda teenuste puhul on paigaldusprotsess unustanud, et teenused keelati ära.  Ja tulemuseks on veateade ning poolik paigaldus.

Mis halvasti, see uuesti.  Aga tulemuseks on sama probleem, kuna paigalduse sammu alguses keelatakse teenused ning töö käigus püütakse neid uuesti käivitada.  Ja seda hoolimata sellest, et antud sammu on juba korduvalt jooksutatud…

See probleem pole Exchange 2013 Cumulative Update 10 juures unikaalne, vaid eksisteerib juba mitu aastat.  Ning kuskilt otsast pole näha, et midagi muutuks.

Kui ülaltoodud jutt pole Sind veel piisavalt ära hirmutanud ja Sa siiski proovid, siis varu kannatust ning ära mine arvutist kaugele, sest paigaldusprotsessi tuleb pidevalt järele aidata.

Enne alustamist tasuks salvestada hetke teenuste häälestus.  Seda saab teha näiteks Powershelliga:

Get-CimInstance -ClassName Win32_Service |
  Select-Object Name, StartMode , State |
  Export-Csv -Path .\teenused.csv -UseCulture -Encoding Default

Kui jooksva sammu progress on jõudnud ~3% peale, siis tuleks (tavalises) Powershellis käivitada järgmised käsud:

Get-Service -Name msexchange*, fsm |
  Set-Service -StartupType Manual

Ja sedasi iga kord, kui paigaldus uue sammu peale läheb.  Seetõttu ei tohigi masinast kaugele minna, sest teenused tuleb uuesti käivituvaks teha, muidu jääb paigaldus pooleli. Ja tuleb jälle kõik sammud läbi käia…

Kui nüüd paigaldus on lõppenud, siis on kogu selle sebimise käigus läinud kaduma teenuste varasem staatus.  Seetõttu tuleb see ise taastada:

$teenused = Import-Csv .\teenused.csv -UseCulture

$teenused | Where-Object StartMode -Like "Auto" |
  ForEach-Object {
    Set-Service -Name $_.name -StartupType $_.StartMode
  }

$teenused | Where-Object State -Like "Running" |
  Start-Service

Tegelikult salvestab Exchange paigaldus samuti teenuste häälestuse.  Ent miskipärast häälestuse taastamisega paigalduse lõpus enam hakkama ei saadud.

Advertisements

Powershell DSC for Linux

Linuxi kaughaldus Powershelli abiga on juba mõnda aega võimalik olnud.  Selleks oli vaja kas SSH tuge Powershellile või siis CIM/OMI serverit Linuxi masinasse.  Esimesel puhul vastas Linuxist shell, teisel juhul suhtles Powershell CIM-liidese abil.

Nüüd on (tegelikult juba 4 kuud) olemas Powershell Desired State Configuration (DSC) liides Linuxi jaoks.  See tähendab, et nüüd saab DSC abil kirjeldada Linuxi masina häälestust ja see siis kehtestada.  Või siis salvestada DSC Pull serverisse ja Linux tuleb tõmbab omale ise häälestuse.

Värskelt välja lastud versioon 1.1 toetab Azure Automation DSC-d ja sealset Pull Serverit.  Seega saab seda kõike juba Azure’is jooksvate Linux masinate peal kasutada.

Powershell 5 – Production Preview

koduleht

Windows 10 on juba üle kuu aja väljas, ent varasematele Windowsi versioonidele pole senimaani uut Powershelli versiooni.  Nüüd siis lasti välja Windows Management Framework (WMF) 5.0 Production Preview, mis ei ole küll veel valmis versioon, aga on Microsofti poolt toetatud ning töökeskkonnas kasutuskõlblik.

WMF 5 töötab Windows 7 SP1 või värskema operatsioonisüsteemi peal ning vajab töötamiseks .NET Framework 4.5.

Muuseas tasub ka ära märkida, et Powershellil on nüüd juba mõnda aega oma koduleht, mis teeb info leidmise mõnejagu lihtsamaks.

Veel kord kasutajaprofiilidest

Sai kunagi kirjutatud, kuidas Powershelli abiga kasutajaprofiile üles leida ja kustutada.  Vahepeal on aeg edasi läinud ja uued Powershelli versioonid oskavad samu asju natuke paremini teha.  Sellega seoses sai kirjutatud moodul, mis võimaldab kasutajaprofiilide haldust automatiseerida.  Mooduli leiab Technet Script Gallery’st ja Powershell 5.0 omanikud võivad selle alla tõmmata Powershell Gallery‘st.  Viimaste jaoks on see käsurealt ülilihtsalt teostatav:

#otsi
Find-Module -Name UserProfile

#paigalda
Install-Module -Name UserProfile

Mooduli kasutamine käib järgnevalt:

#Find all user profiles except special system profiles.
Get-UserProfile -Special $false

#Delete all roaming profiles that are not used for 3 months.
$myDate = (Get-Date).AddDays(-90)
Get-UserProfile -Before $myDate -Roaming $true -Loaded $false |
  Remove-UserProfile

#Find user profile of specific user.
Get-AdUser John |
  Select-Object @{n="sid";e={[string]$_.sid}} |
  Get-UserProfile

#Find all roaming profiles from specific computers.
$session = new-cimsession -ComputerName srv1,srv2 -credential domain\user
Get-UserProfile -CimSession $session -Roaming $true

#Migrate local user account profile into domain user account profile.
$oldAccount = Get-CimInstance Win32_UserAccount -filter "caption='PC\\user'"
$newAccount = Get-AdUser Mati
Get-UserProfile -Sid $oldAccount | Set-ProfileOwner -SID $newAccount.SID

#discover user profile owner by folder name
Get-Item c:\users\kasutaja |
  Select-Object -ExpandProperty FullName |
  Get-UserProfile |
  Get-ProfileOwner

Ülalmainitud moodul töötab ilusti ka Windows 7 ja Server 2008 R2 peal ning võib-olla et isegi Vista/Server 2008 peal, kui sinna Powershell 3.0 paigaldada.  Pole hetkel Vista masinat kuskilt võtta, seega ei saa proovida.

Loodetavasti on antud moodul mugavam kasutada, kui kunagi pakutud skriptinäide.

SSH tugi Powershellis

Powershelli tootetiim andis teada, et nad alustasid SSH protokolli toe planeerimist Powershellile.  Seda siis muuseas ka sedapidi, et eemalt masinast saab teha SSH ühenduse ja sihtpunktis kasutada Powershelli.

Teistpidi lahendusi (Powershell teeb SSH sessiooni teise masinasse) on juba mõnejagu olemas.  Näiteks võiks mainida moodulit Posh-SSH.  Kommertstoodetest võiks mainida PowershellServerit, millest on tasuta personaalne versioon olemas.  Samuti võib võtta suvalise Windowsi peal töötava SSH serveri ja kasutada selle sees käsurea interpretaatoriks Powershelli.

Nimetatud funktsionaalsust on korduvalt Powershelli tagasiside veebis küsitud.

Seisuga Oktoober 2015 on valmis saadud OpenSSH for Windows, mis on esialgu veel arendamisel, ent tulemus lubatakse valmis saada järgmise aasta esimeses pooles.

Powershell 5 Preview April 2015

Järjekordne versioon Windows Management Framework 5.0 eelvaatest.  On möödunud aasta esimesest eelvaatest ja seekord saab seda paigaldada ka Windows 7/Server 2008 R2 ja Server 2012 peale.

Uusi asju on juurde tulnud päris palju.  Muudatusi on nii väikeseid kui suuri.  Peamised suured asjad on ikka Desired State Configuration ja moodul PowershellGet.  Aga on ka pisikesi asju, nagu näiteks Get-Clipboard, Set-Clipboard ja New-TemporaryFile.

Nagu eelvaatega ikka, kui leiad midagi, mida tahad muuta, siis kirjuta aadressil https://windowsserver.uservoice.com/forums/301869-powershell, või siis vähemalt hääleta juba kirjutatud asjade seas neid, mis ka Sinu arust vajalikud on.

Powershell ja sündmuste logid

Aeg-ajalt on vaja otsida sündmuste logidest teatud kindlaid sündmusi.  Ja vahel oleks hea ka ise sündmusi logida.

Vaatame kõigepealt, kuidas sündmusi leida.  Selleks on Powershellis kaks käsku: Get-EventLog ja Get-WinEvent.  Esimest neist tuleks kasutada ainult juhul, kui on vaja otsida sündmusi Windows Server 2003 logidest.  Ja Server 2003 tugi lõpeb sel aastal ära.

Kõigi uuemate OS-ide puhul tuleks kasutada teist käsku.  See oskab otsida sündmusi ka Event Tracing for Windows logidest.  Ja neid logisid on tänapäeval palju.  Alustamegi siis sellest, et otsime meid huvitava logi üles:

Get-WinEvent -ListLog *
Get-WinEvent -ListLog Application

Nüüd teades logi nime, saame sealt otsida sündmusi.  Piirame selle otsimise mingi arvuga, et mitte liiga kaua oodata:

Get-WinEvent -LogName Application -MaxEvents 10
Get-WinEvent -LogName "Windows Powershell" -MaxEvents 10

# vanemad sündmused enne
Get-WinEvent -LogName Application -MaxEvents 10 -Oldest

Tavaliselt ei huvita meid kõik logisse kirjutatud sündmused, vaid ikka spetsiifilised.  Lisaks võivad huvipakkuvad sündmused olla kirjutatud ka mitmesse erinevasse logisse.  Seetõttu saab sündmusi otsida ka mitte logide, vaid hoopis sündmuse allika järgi.  Kõigepealt leiame olemasolevate sündmuste küljest allikad:

(Get-WinEvent -ListLog Application).ProviderNames

Get-WinEvent -ListProvider *
Get-WinEvent -ListProvider *PowerShell
Get-WinEvent -ListProvider Outlook

Nüüd teades allikat, on lihtne saada kätte sündmused:

Get-WinEvent -ProviderName Outlook -MaxEvents 10
Get-WinEvent -ProviderName Microsoft-Windows-PowerShell -MaxEvents 10

Teades täpsemalt mida otsime, saame ka sündmusi täpsemalt filtreerida.  Näiteks võime me vaadata ainult viimase 24 tunni jooksul toimunud sündmusi:

$eile = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{
  LogName = "Application"
  StartTime = $eile
}

Või siis otsime me kindlat sündmust, mille puhul on teada ka sündmuse number (EventID):

Get-WinEvent -MaxEvents 10 -FilterHashtable @{
  ProviderName = "Outlook"
  ID = 32
}

Get-WinEvent -FilterHashtable @{
  Logname="Application"
  ProviderName="Application Error"
  Data="iexplore.exe"
}

Kui me oleme eelnevalt rakenduses Event Viewer loonud sündmuste filtri, siis selle saab ette anda ka Powershellile.  Vaja see vaid salvestada XML failiks ja sealt võtta välja element QueryList.  Selle saab ka vaate filtrit muutes vahelehelt XML.

Get-WinEvent -MaxEvents 10 -FilterXml @"
<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">*[System[Provider[@Name='Application Error'] and (Level=2) and (EventID=1000)]]</Select>
  </Query>
</QueryList>
"@

Get-WinEvent -FilterXml ([xml](Get-Content .\filter.xml)) -MaxEvents 10

XML-dokumendiga tasub jännata ainult keerulisemate päringute puhul, mida varem näidatud viisidel ei saa kokku panna (näiteks, kui on vaja leida mitmele erinevale EventID-le vastavaid sündmusi vms.).

Logidesse kirjutamisega on asi natuke keerulisem.  Nimelt tuleks oma skripti jaoks luua uus logi või siis vähemalt uus sündmuste allikas.  Muidu on pärast raske oma skripti sündmusi üles leida.  Ja nii uute logide kui ka uute allikate loomiseks on vaja süsteemiülema õigusi:

$myProvider = "minuskript"

#Requires -RunAsAdministrator
New-EventLog -LogName Application -Source $myProvider
New-EventLog -Source TestApp -LogName TestLog

try {
  Get-WinEvent -ListProvider $myProvider | Out-Null
} catch {
  Start-Process -Verb runas powershell.exe -ArgumentList "New-EventLog -LogName Application -Source $myProvider"
}

Ülaltoodud tegevus tuleb sooritada ühekordselt.  Pärast seda on uus logi/allikas masinas defineeritud ja skript saab rahulikult kirjutada sündmusi:

$params = @{
  LogName = "Application"
  Source = $myProvider
  EventId = 1
  Message = "Minu kohandatud sündmus"
}
Write-EventLog @params

Get-WinEvent -ProviderName $myProvider