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)

Monitooritud Serveri eemaldamine SCOM’ist ja Specified cast is not Valid viga.

Oletame, et server mis on SCOM agendiga monitooringu all lõpetab oma eksitentsi ja ta lülitatakse välja või VM kustutatakse. Nüüd ( parem eelnevalt) tuleks SCOMis tegelikult teha ports tegevusi, mis sõltuvad kas jõudlus/event jms andmeid on tulevikus vaja või mitte.

Kõige lihtsam on Agent Delete, KUID siin tekivad järgmised probleemid:

* Server  või mõni tema objektidest võib olla osake Distributed Application’ist. Ehk – viisakas on üle käia ka seotud DA ja parandada disain.

* Palju suurem probleem ( mille kohta on ka MS Bugi ja mis pole ka veel 2012 R2 CU2’s ära parandatud) on siis kui eemaldad mõne SQL serveri ja Sul on kasutuses SQL Action accoundid ja need accoundid on levitatud AINULT valitud SQL serveritele (mille hulka kuulub siis kustutatud server).

Avaldub bugi sel hetkel,  kui soovid kontot muuta/vaadata. Specified Cast is not valid.

image

Edasi töötades näed, et levitusloend on tühi.

image

 

Olukorrast lahendamiseks hetkel head lahendust pole.

Tuleks:

1 – Nimetada SCOM konsoolis “vigane”  Run As Account ümber.

2- Luua uus SQL Action Account sama nimega nagu ennem oli  ja kasutada sama AD kasutajanime parooli.

3- Levitada see vajalikele SQL serveritele.

4- Asendada Run As Profiles  SQL’iga seotud profiilides (või kus see kasutuses oli) vana konto uuesti loodud kontoga.

5- Kustutada vana Run As Account konto.

 

Juhul, KUI SCOM’ist eemaldatud server on võimalik veel korraks tööle panna ja lasta ennast uuesti ära registreerida, siis on võimalik eemaldada ta viisakalt Run As Account’i levitamis listist.

TallPaulF on kirjutanud selliseks eeltööks mõnusa PS scripti:

param (
[parameter(mandatory=$true)]$TargetName,
[switch]$WhatIf
)
Import-Module -Name OperationsManager
Write-Host
$Accounts=0
Get-SCOMRunAsAccount |
%{
$Acct=$_
try {
$Dist = Get-SCOMRunAsDistribution -RunAsAccount $Acct
}
catch {
Write-Host -f yellow $('WARNING: RunAsAccount "{0}" has a corrupt RunAs Distribution!' -f $Acct.Name)
}
if ($Dist.Security -eq 'MoreSecure')
{
$FoundTarget = $false
$Dist.SecureDistribution = @($Dist.SecureDistribution | %{ if ($_.DisplayName -eq $TargetName) { $foundTarget = $true } else { $_ } } )
if ($foundTarget)
{
$Accounts++
$Dist | Set-SCOMRunAsDistribution -RunAsAccount $Acct -WhatIf:$WhatIf -Verbose
}
}
}
Write-Host
if ($Accounts -gt 0)
{
if ($WhatIf)
{
Write-Host -ForegroundColor green $("$TargetName would be removed from {0} RunAsAccount secure distribution lists" -f $Accounts)
} else {
Write-Host -ForegroundColor green $("$TargetName removed from {0} RunAsAccount secure distribution lists" -f $Accounts)
}
} else {
Write-Host -ForegroundColor cyan "$TargetName was not found in any RunAsAccount secure distribution lists"
}

R2 laine

Seekord pole tegemist Rahvusringhäälingu populaarse raadiokanali ja kunagise menuansambli ühisprojektiga.

Lihtsalt kümmekond päeva tagasi jõudis hulgilitsentsi omanikene Microsofti toodete järgmine põlvkond ja tuleb leida aega dokumentatsioonist läbinärimiseks ja uuendamisteks.

Windows 8.1

Windows Server 2012 R2

System Center 2012 R2

Eks nüüd tuleb siis igaühel vaadata üle ja otsustada kas, mida ja millal uuendada. Viimasel ajal tundub, et MS on minemas teed, kus väga oluline on hoida infras jooksmas toodete viimaseid versioone. SC toodete inplace upgrade ainuvõimalikud teed on RTM>SP1>R2.

Allpool olgu toodud mõned nupud  SCOM 2012 SP1 uuendamiseks R2 tasemele.

1- Loe dokki! – http://technet.microsoft.com/en-us/library/dn249707.aspx

2- Installeeri eelnevalt nõutud tarkvara – MS Report Viewer 2012 Runtime ja MS SQL Server System CLR Types for SQL 2012 ( reboot lõpuks) – Upgrading To SCOM 2012 R2 RTM- Report Viewer 2012 Runtime Error

3- Tee varukoopiad oma SCOM Serveritest ja OpsManager ja DataWarehouse andmebaasidest

4- Uuendamise loogika on sarnane eelmistele kordadele, esmalt (R )MS’id ja seejärel riburada teised rolliserverid (ACS, Gateway, Reporting) ja agendid. Jälgima peab, et esimene MS upgrade jookseks kenasti lõpuni. Tesite serverite uuendamine toimub oluliselt kiiremini, sest enam pole vaja uuendada andmebaase ja importida halduspakette.

Uuendamise ajal toimub aktiivne logimine C:\Users\käivitav kasutaja \AppData\Local\SCOM\LOGS nii, et soovi korral võib seal olevatele logidele CMTrace abil pilku peal hoida. Iga uuendatava komponendi koha kirjutatakse eraldi logifail.

5- Võib juhtuda, et uuesti on vaja sisestada SC litsentsivõti. (SC PowerShell Set-SCOMLicense ) ja restardi Data Access teenust kõigis SCOM serverites (või restardi servereid).

 

Üldiselt, hea tervise juures oleva SCOM upgrade mis on sooritatud juhendeid järgides on kiire ja valutu tegevus.

 

Keywords: upgrade SCOM 2012 to 20012 R2

MP, MP, MP …

Halduspakid (Management Packs, MP) on SystemCenter’i tarkus ja oskus. MP abil toote funktsionaalsuse laindamist ja uute oskuste õpetamist kasutati OM’is juba mitmeid versioon, nüüdseks on see laienenud ka teistele SC 2012 perekonna liikmetele (Service manager, Orchestrator).

Alljärgnevalt natuke uuemaid viiteid, kust kohast vajalikke MP’sid leida:

1- http://www.systemcentercentral.com/pack-catalog-categories/mp-catalog-pack-catalog/

System Center Central on hea ja põhjatu infovaramu SC entusiastidelt.

2 – http://systemcenter.pinpoint.microsoft.com/en-US/home

MS Pinpoint, värskema URLiga

3 – http://technet.microsoft.com/en-us/library/dd347500.aspx

MP (vähemalt MS poolt pakutavate) juhised (Technet online formaadis)

 

MP’dega on tõsi küll paar häda ja põletavaim nendest võiks olla teadmatus, millal uus MP on välja tulnud. Kas siis päris uue toote jaoks (näiteks Lynx 2013) või juba installeeritud MP uuem ja funktsionaalsem verisoon.

Vajaduse korral saab vähemalt MS MP’sid kontrollida SCOM konsooli tagant, valides siis kas ”Updates available..” või “All ..”. Meeldetuletus – ära  laadi sealtkaudu ühtegi MP’d alla. Niimoodi jääd sa ilma dokumentatsioonist ja võimalik et ka vajalikest lisa failidest.

Või siis käia oma ISV’sid või blogisid pidi infot hankimas.

OM 2005 jaoks oli olemas vastav MP, mis genereeris alerdi, kui MS uuenduse välja lasi.

OM 2012 jaoks pole mina vastavat funktsionaalsust veel leidnud. Siin ja seal (näiteks –http://scom.dk/?p=92) on proovitud teha Powershelli scripti.

 

Keywords: update, managemet packs, download

Application error DC logis.

Mingi hetk hakkas üks domeenkontroller väga tihedalt kirjutama Application logisse veateateid numbriga 1000 – Application Error.

image

Kõikide vigade puhul tekitatakse ka Windows Error Reporting andmekogum ja saadetakse see kenasti kogumisserverisse ära.

Sündmuste sisu  sama ja pikemalt valgust põhjusele ei anna.

image

Käsitisi käivitatud vbs’id töötavad nagu peab. Midagi teadlikult muudetud süsteemis pole ja teistes DC’des mis on täpselt sama konfiga  viga ei esine.

Sellise sagedusega kutsub cscripti seal masinas välja SCOM Agent ja täidetakse erinevaid monitooringu ülesandeid.

Kaevates natuke WER tõmmisfailides võis näha milliste vbs skriptide jooksutamisel viga tekib. Samad skriptid jällegi käsitsi käivitades töötavad kenasti.

Ühe võimalusena kahtlustasin agendi Healt State kaustade riknemist – seda võib mõnikord ette tulla. Lahendus on lihtne – seiska System Center Management teenus, kustuta (või nimeta ümber ) C:\Program Files\System Center Operations Manager 2007\Health Service State ja stardi teenus uuesti. Vajalikud kaustad tekitatakse, uuesti laetakse  halduspaketid ja alustatakse tühja baasiga.

Paraku see ei aidanud.

Edasine tuulamine debugeriga  tõmmisfailides midagi peale teadmise, et toimub STACK_OVERFLOW Scripting hostis targemaks ei teinud.

PIkapeale tekis tunne et agendi endaga on midagi laht, kuigi andmed tulid ja kõik nagu töötas.  Agendile uninstall. Install ja voilaa- ei mingeid vigu enam. Nüüd tuleks veel silmapeal hoida et korduma ei hakkaks.

Case unexplained- resolved, but not explained.

 

Igasuguste DMP failide lugemiseks on väga hea vahend Debuging Tool’ komplekti kuuluv WinDbg. Selle kasutamisest on nii Technetis ( a la http://support.microsoft.com/kb/315263)  kui mujal päris palju häid juhendeid. Väga põhjalikult , kuid arusaadavalt ja mõnusate näidetega tutvustab igasuguseid debugimisvahendeid ja abiriistu oma blogis Mark – http://blogs.technet.com/b/markrussinovich/

 

Keywords: Appcrash, SCOM 2007,  Windows 2008 DC, Event 1000, cscript.exe, ntdll.dll