Återlämna värdet från PowerShell invoke-command till SQL Server-agent

När jag skapade min egen metod för att hantera säkerhetskopior på flera MS-SQL-servrar spenderade jag mycket tid på att studera mekanismen för överföring av värden i PowerShell vid fjärranrop, så jag skriver en påminnelse till mig själv, ifall den kan vara till nytta för någon annan.

Så, låt oss börja med ett enkelt skript och köra det lokalt:

$exitcode = $args[0]
Write-Host 'Ut till värden.'
Write-Output 'Ut till utdata.'
Write-Host ('ExitCode: ' + $exitcode)
Write-Output $exitcode
$host.SetShouldExit($exitcode)

För att köra skripten kommer jag att använda följande CMD-fil, jag kommer inte att återge den varje gång:

@Echo OFF
PowerShell .TestOutput1.ps1 1
ECHO ERRORLEVEL=%ERRORLEVEL%

På skärmen kommer vi att se följande:

Ut till värden.
Ut till utdata.
ExitCode: 1
1
ERRORLEVEL=1

Nu kör vi samma skript via WSMAN (fjärråtkomst):

Invoke-Command -ComputerName . -ScriptBlock { &'D:sqlagentTestOutput1.ps1' $args[0] } -ArgumentList $args[0]

Och här är resultatet:

Ut till värden.
Ut till utdata.
ExitCode: 2
2
ERRORLEVEL=0

Utmärkt, Errorlevel har försvunnit någonstans, men vi behöver ändå få värdet från skriptet! Vi provar nästa konstruktion:

$res=Invoke-Command -ComputerName . -ScriptBlock { &'D:sqlagentTestOutput1.ps1' $args[0] } -ArgumentList $args[0]

Här blir det intressantare. All utskrift till utdata har på något sätt försvunnit:

Ut till värden.
ExitCode: 2
ERRORLEVEL=0

Nu som en lyrisk avstickare, noterar jag att om du inom en PowerShell-funktion skriver Write-Output eller helt enkelt uttrycket utan att tilldela det till någon variabel (vilket implicit innebär att det skrivs ut till utdata), så kommer inget att skrivas ut på skärmen, även vid lokal körning! Detta är en följd av PowerShells rörledningsarkitektur - varje funktion har sin egen utdata-pipeline, där ett array skapas, och allt som hamnar där räknas som resultatet av funktionskörningen. Return-operatören lägger till det returnerade värdet som sista element i denna pipeline och överför kontrollen till den anropande funktionen. För att illustrera kommer vi att köra följande skript lokalt:

Function Write-Log {
  Param( [Parameter(Mandatory=$false, ValueFromPipeline=$true)] [String[]] $OutString = "`r`n" )
  Write-Output ("Funktion: "+$OutString)
  Return "ReturnValue"
}
Write-Output ("Huvud: "+"ParameterValue")
$res = Write-Log "ParameterValue"
$res.GetType()
$res.Length
$res | Foreach-Object { Write-Host ("Huvud: "+$_) }

Och här är dess resultat:

Huvud: ParameterValue

IsPublic IsSerial Namn                                     BasType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array
2
Huvud: Funktion: ParameterValue
Huvud: ReturnValue

Huvudfunktionen (kroppen av skriptet) har också sin egen utdata-pipeline, och om vi kör det första skriptet från CMD och omdirigerar utdata till en fil,

PowerShell .TestOutput1.ps1 1 > TestOutput1.txt

Det vi ser på skärmen

ERRORLEVEL=1

och i filen

Ut till värden.
Ut till utdata.
ExitCode: 1
1

om vi gör ett liknande anrop från powershell

PS D:sqlagent> .TestOutput1.ps1 1 > TestOutput1.txt

så kommer det att visas på skärmen

Ut till värden.
ExitCode: 1

och i filen

Ut till utdata.
1

Detta händer eftersom CMD startar powershell, som utan andra instruktioner blandar de två strömmarna (Host och Output) och skickar dem till CMD, som skickar allt den fått till filen, medan i fallet med körning från powershell existerar de två strömmarna separat, och omdirigeringssymbolen påverkar endast Output.

Åter till huvudämnet, kom ihåg att objektmodellen .NET inom powershell fungerar fullt ut på en enda dator (ett operativsystem), vid fjärranrop av kod via WSMAN sker överföringen av objekt genom XML-serialisering, vilket tillför mycket extra intresse i våra forskningar. Vi fortsätter experimentera med att köra följande kod:

$res=Invoke-Command -ComputerName . -ScriptBlock { &'D:sqlagentTestOutput1.ps1' $args[0] } -ArgumentList $args[0]
$res.GetType()
$host.SetShouldExit($res)

Och här är vad vi ser på skärmen:

Ut till värden.

ExitCode: 3

IsPublic IsSerial Namn                                     BasType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array
Det går inte att konvertera argumentet "exitCode", med värdet: "System.Object[]", för "SetShouldExit" till typ "System.Int32": "Det går inte att konvertera värdet "System.Object[]" av typen "System.Object[]" till typ "System
.Int32"."
D:sqlagentTestOutput3.ps1:3 tecken:1
+ $host.SetShouldExit($res)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument

ERRORLEVEL=0

Ett utmärkt resultat! Det betyder att när vi anropar Invoke-Command behålls uppdelningen av rör till två strömmar (Host och Output), vilket ger oss hopp om framgång. Låt oss försöka hålla kvar endast ett värde i Output-strömmen, för vilket vi ändrar det allra första skriptet som vi kör på distans:

$exitcode = $args[0]
Write-Host 'Ut till värden.'
#Write-Output 'Ut till utdata.'
Write-Host ('ExitCode: ' + $exitcode)
Write-Output $exitcode
$host.SetShouldExit($exitcode)

Vi kör det så här:

$res=Invoke-Command -ComputerName . -ScriptBlock { &'D:sqlagentTestOutput1.ps1' $args[0] } -ArgumentList $args[0]
$host.SetShouldExit($res)

och… JA, det verkar vara en seger!

Ut till värden.
ExitCode: 4

IsPublic IsSerial Namn                                     BasType
-------- -------- ----                                     --------
True     True     Int32                                    System.ValueType


ERRORLEVEL=4

Låt oss försöka förstå vad som har hänt. Vi kallade lokalt på PowerShell, som å sin sida anropade PowerShell på den fjärrstyrda datorn och körde vårt skript där. Två strömmar (Host och Output) från den fjärrstyrda maskinen serialiserades och skickades tillbaka, där strömmen Output, om den innehöll ett enda numeriskt värde, omvandlades till Int32-typ och skickades i detta format till mottagande part, och mottagande part använde det som avslutningskod för den anropade PowerShell.

Och som sista kontroll skapar vi på servern SQL-jobb av ett steg med typen "Operativsystem (cmdexec)" med följande text:

PowerShell -NonInteractive -NoProfile "$res=Invoke-Command -ComputerName BACKUPSERVER -ConfigurationName SQLAgent -ScriptBlock {&'D:sqlagentTestOutput1.ps1' 6}; $host.SetShouldExit($res)"

JIPPI! Jobbet avslutades med ett fel, texten i loggen:

Utförs under namnet: DOMAINagentuser. Ut till värden. ExitCode: 6. Processens avslutningskod 6. Steget avslutades med ett fel.

Slutsatser:

• Undvik att använda Write-Output och att ange uttryck utan tilldelning. Kom ihåg att flytta denna kod till en annan plats i skriptet kan leda till oväntade resultat.
• I skript som inte är avsedda för manuell körning, utan för användning i dina automatiseringssystem, särskilt för fjärranrop via WINRM, gör manuell felhantering genom Try/Catch, och se till att detta skript skickar exakt ett värde av primärtyp till Output-strömmen oavsett utfall. Om du vill få den klassiska Errorlevel — detta värde måste vara numeriskt.

Källa: habr.com