Powershell .vbs’i sees

Kuigi SCOM on väga-väga Powershellili orienteeritud lahendus on vähemalt 1 koht, kus saab kasutada (minule teadaolevalt) ainult Visualbasic scriptimist. Väidetavalt on eesmärk 2 suunaline.  Ja see koht on Agent Tasks.

image

Esmalt tagada ühilduvus hallatavate süsteemidega (cscript on neis kõigis) ja jõudlusteemad. Minu hinnagul on mõlemad tänapäeval ajalugu ja võiks loota, et lähiajal saab seal kasutada ka PS.

Seniks aga üks väike workaround.

Ehk siis manustame oma PS scripti vbs’i sisse.

Sellel on meetodil on mõned puudused: esmalt ei näe me mõistliku väljundit Taski käivitumise aknas ja Scripti sisu muutmine on natuke kohmakas ja ebamugav. Samuti ei saa kasutada argumente ja mingile konkreetsele objektile suunamist.

Samm 1 – kirjutame ja testime oma PS scripti. Sisend ja väljund argumente pole.

Samm 2 – kodeerime oma PS Base-64’ja.

Selleks võib kasutada allolevat PS’i, mille tagajärjel on skripti sisu lõikepuhvris.

$script = Get-Content C:\temp\minuskript.ps1 -Raw 
$bytes = [System.Text.Encoding]::Unicode.GetBytes($script) 
$encoded = [Convert]::ToBase64String($bytes) 
$encoded | clip

Samm 3 – tekitame nüüd vbs ümbrise.

Set objShell = CreateObject("Wscript.Shell") 
objShell.Run("powershell.exe –EncodedCommand  XXX”)

kus XXX asemele kleebi lõikepuhvri sisu.

Samm 4 – on juba SCOM’is vastava Taski loomine. Kus siis faili nimeks võid panna misiganes.vbs ja Script aknasse kleebi samm3 tulemus. Tehtud.

Märkmeid SCOM’i poolt kogutud jõudlusandmete kohta.

Teatavasti talletab SCOM endasse (okei SQL baasi) monitooritavate objektide jõudlusandmeid. Mida ja kui sageli kogutakse on määratud halduspakkide ( ja admini poolt määratud override) reeglitega.

Jõudlustulemusi numbrilisel kujul tegelikult kusagilt ei näe – põhimõtteliselt on graafiliseks nägemiseks 3 võimalust:

* Perfromance View

* Performance Widget

* Raport

Võib tekida vajadus otsa vaadata puhastele numbritele ja selelks tuleb sukelduda baasi maailma.

Performance/Event/alert jne andmeid hoitakse 2’s baasis – põhibaasis ja DW baasis.  Põhibaasis on ainult viimase aja andmed ja määratud ajaga agregeeritakse need ja kustutatakse sealt. Alles jäävad ainult DW’s asuvad andmed, kus neid samuti agregeeritakse ja kustutatakse pikaajaliselt.

Teoorias peaks Performance View andmed tulema operational DB. Widgeti ja Raporti omad tulevad DW’st.

Nüüd tekis mul vajadus RAW data järgi ja selleks läks tsipa aega ja SQL’ querysid. Panen siia sammhaaval kirja, eks lõptulemust saab igaüks ise ilusamaks ajada.

 

Alustuseks on kasulik lugeda näiteks – https://capacitas.wordpress.com/2012/12/05/retrieving-data-from-the-scom-database/

Kasutades vaateid:

OperationsManagerDW.Perf.vPerfHourly

OperationsManagerDW.Perf.vPerfDaily

OperationsManagerDW.Perf.vPerfRaw

saad erineva agregeeritusega andmeid.

Näiteks:

SELECT FullName, InstanceName, DateTime, SampleValue

FROM OperationsManagerDW.dbo.vManagedEntity,

OperationsManagerDW.dbo.vPerformanceRule,

OperationsManagerDW.dbo.vPerformanceRuleInstance,

OperationsManagerDW.Perf.vPerfRaw

WHERE vPerfRaw.ManagedEntityRowId = vManagedEntity.ManagedEntityRowId

AND vPerfRaw.PerformanceRuleInstanceRowId = vPerformanceRuleInstance.PerformanceRuleInstanceRowId

AND vPerformanceRuleInstance.RuleRowId = vPerformanceRule.RuleRowId

AND vPerformanceRule.ObjectName = ‘LogicalDisk’

AND vPerformanceRule.CounterName = ‘Avg. Disk sec/Transfer’

AND DateTime > ‘2015-06-24’

AND DateTime < ‘2015-06-27’

AND FullName like ‘%SERVER1%’

ORDER BY FullName, InstanceName, DateTime

Saad vastuseks agregeerimata loogiliste ketaste andmed SERVER1 kohta.

KUID – need on siiski juba agregeeritud andmed DW baasist. Mõnikord võib olla vajadus leida sama objekti kohta andmeid operational baasist.

 

Operational baasis pole kahjuks vajalikke SQL vaateid defineeritud ja seega kasutame erinevaid päringuid erinevate tabelite vastu.

Esmalt – leiame monitooritava objekti ID (mis on seotud serveriga SERVER1)

SELECT *  FROM [OperationsManager].[dbo].[BaseManagedEntity] where FullName like ‘%SERVER1%’

Otsime üles meid huvitava objekti kohta käiva  BaseManagedEntityID  ja jätame selle meelde  näiteks 9AEBE075-10D8-1B76-2175-DD29CDF9777B

Samuti otsime FullName alt sobiva objekti nime ja jätame sealt meelde sobiva substringi – näiteks LogicalDisk mille kohta me andmeid tahame.

Teiseks – leiame Perfomance Counter ID

SELECT *  FROM [OperationsManager].[dbo].[PerformanceCounter] where ObjectName like ‘%logicaldisk%’

Jätame meelde näiteks:( kui meid huvitab Avg Disk sec/ Transfer)

6B85C704-8122-4317-8E73-F42E279DFC10    LogicalDisk    Avg. Disk sec/Transfer

Kolmandaks – leiame selle objekti ID kohta käiva sisemiseID (kasutades eelmites sammudes leitud andmeid)

SELECT *  FROM [OperationsManager].[dbo].[PerformanceSource] where PerformanceCounterId = ‘6B85C704-8122-4317-8E73-F42E279DFC10’ and BaseManagedEntityId = ‘9AEBE075-10D8-1B76-2175-DD29CDF9777B’

Siit saame PerformanceSourceInternalID – jätame meelde 272221

 

Reaalsed Perf data andmed on laiali umbes 60’s PerformanceData_xx nimelises tabelis, kuid õnneks on olemas siiski vaade, mis need kokku tõmbab (UNION’iga).

Lõpuks

SELECT *  FROM [OperationsManager].[dbo].[PerformanceDataAllView] where PerformanceSourceInternalId = ‘272221’ order by TimeSampled

Voilaa.

Meeles peab pidama veel paari nüanssi:

1- Ajad on GMT.

2- Kui sample value ei muutu, siis uusi kirjeid ei lisata. Ehk-  kuigi jälgitakse a la iga  minuti tagant, siis reaalne lisamine baasi toimub alles siis kui muudatus toimub ( mis võib olla vabalt miinimum tund)

2 uudist OpsManageri suunalt.

MS press on avaldanud tasuta e-raamtu OpsManageri kohta  – “kogemusi põllult”🙂

Kõigile Opsmanageri adminnidele kohustuslik lugemisvara.

 http://blogs.msdn.com/b/microsoft_press/archive/2015/04/21/free-ebook-microsoft-system-center-operations-manager-field-experience.aspx

 

Ühtlasi juhin tähelepanu asjaolule, et KB 3032946  on  uuendatud 14 aprillil.

https://support.microsoft.com/en-us/kb/3032946 ( kui sul on binaar varem alla laaditud ja installitud siis võivad sellga olla probleemid). Kui kasutda WSUS’i/SCCMI siis on esialgne versioon Expired ja deployma pead uuema.

Ja veel mõned viited veakoodidele

Kergema hilisema ülesleidmise huvides olgu siin veel mõned vanad kohad kus veakoode kirjas:

NT Status Codes – https://msdn.microsoft.com/en-us/library/cc231200.aspx

Üleüldse on https://msdn.microsoft.com/en-us/library/cc231196.aspx päris asjalik.

Samuti võib kiigata Dev Centris olevasse https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

, kuigi see on mõne koha pealt hõredavõitu.

Kuidas kiirelt tõlgendada veakoode.

Vana, aga meenutuseks.

Mõnikord esitatakse veakoodid numbriliselt ja suhteliselt loetamatult. Ok, kogenud admin mäletab peotäit koode peast ja une pealt. Aga mõnikord läheb ikka väikest värskendust vaja. Tehtav lokaalis võrguühenduseta (ei pea guugeldama)

Error 2147943785 – see teisenda Hexi 0x80070569 ( Windowsi kalkulaatoriga või kuidas mugavam on)

0x8007 = win_32

0x 0569 teisenda dec = 1385

Ja nüüd cmd/PS promptist

net helpmsg 1385

mis annab tulemuseks

Logon failure: the user has not been granted the requested logon type at this computer.

Windows Update ja server CORE

Windows Server Core on paljuski kasulik valik – väiksem installatsiooni jälg, vähem komponente, vähem auke, vähem paikasid, vähem muret.

Aga – kui midagi ei toimi just päris nii nagu tahaks, siis on natuke keerukam. Windows GUI peal on võimalik rohkem vähem mugavalt kasutada Control Paneli appi Windows Updates. Corel seda pole.

Alljärgnevalt vaatame, kuidas opereerida Updatedega Core keskkonnas.

 

A – Mul on täiesti iseseisev CORE

( pole domeeni, WSUS’i ega midagi).

Põhimõtteliselt on siin 2 varianti – täiesti automaatne paikamine või korra (või kaks) kuus käsitsi.

Automaatsekscscript scregedit.wsf /AU 4

Sellega häälestatakse server ise kõiki patche MIcrosofti serverites alla tõmbama ja installima ja buutima.

Tagasi manuaalseks cscript scregedit.wsf /AU 1

Natuke paindlikum ( kuid kindlasti ajamahukam) on sconfig abil ise patche scannida, alla laadida ja installida.

Loomulikult ei keela keegi ka mingit iseseisvat scripti ehitada mis patche kuskilt kohalikust failisüsteemist installeerib.

B – Mul on domeeni kuuluv CORE

Võid kasutada kõike eelnevat, kuid mugavam on Group Policyga paika panna millisel serveril kuidas ja millal. Vaikimisi on Update source serveriks jätkuvalt MS serverid. Koheseks patchimiseks ikka ja jälle sconfig.

C – Mul on domeen ja oma WSUS/SCCM

Esimesel juhul tuleks ise GP’ga määrata lisaks käitumisele ka WSUS serveri nimi. SCCM’i korral teeb kogu musta maagia SCCM’i klient ja GPOga midagi üle käia on ebavajalik võib-olla ilmselt isegi ebasoovitav.

Kui Sinu WSUS/SCCM töötab perfektselt siis peaks elu olema “lill”. Mõnikord aga juhtub, et seal või kuskil mujal on väiksed bugid. Siis on vaja uudrida, mis ja kus katki on.

Kui sconfig väidab, et siin ei ole ühtegi pachi installida, kuid me teame ( või keegi teeb pentesti ja ütleb meile, et ikka  on küll) võime eeldada, et midagi on katki meie WSUS/SCCM serveri või ühendusega sinna.

Kuidas teha patch scanni MS serverite vastu (eeldusel, et võrgu tasemel on sinna juurdepääs olemas) ?

  1. Regedit (jah, see on core peal olemas!), otsi üles [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] UseWUServer ja muuda väärtus 0’ks. Sulge regedit.

  2. taaskäivita Windows Update service ( net stop “windows update” ja seejärel  net start “windows update”)

  3. sconfig ja kontrolli updatesid

  4. pärast tagasimuutmiseks muud aregistry väärtus taas 1’ks ja teenusele restart.

SCCM poolelt on CORE’sse installeritud nii SCCM Control Panel aplett (c:\windows\ccm\smscfgrc.cpl) kui ka Software Center (C:\windows\ccm\scclient.exe). Ka nendega saad algatada kliendi poolsed tegevusi.

Keywords: Windows update, Core, Online, check