ma solution à cela a été d'écrire le bloc de script dynamiquement avec [scriptblock]:Create :

# Or build a complex local script with MARKERS here, and do substitutions
# I was sending install scripts to the remote along with MSI packages
# ...for things like Backup and AV protection etc.

$p1 = "good stuff"; $p2 = "better stuff"; $p3 = "best stuff"; $etc = "!"
$script = [scriptblock]::Create("MyScriptOnRemoteServer.ps1 $p1 $p2 $etc")
#strings get interpolated/expanded while a direct scriptblock does not

# the $parms are now expanded in the script block itself
# ...so just call it:
$result = invoke-command $computer -script $script

passer des arguments était très frustrant, en essayant diverses méthodes, par exemple,

-arguments , $using:p1 , etc. et cela a fonctionné comme souhaité sans aucun problème.

puisque je contrôle le contenu et l'expansion variable de la chaîne qui crée le [scriptblock] (ou fichier script) de cette façon, il n'y a pas de problème réel avec l'incantation "invoke-command".

(ça ne devrait pas être si dur. :))

j'avais besoin de quelque chose pour appeler des scripts avec des paramètres nommés. Nous avons pour Politique de ne pas utiliser le positionnement ordinal des paramètres et d'exiger le nom du paramètre.

Mon approche est similaire à celles ci-dessus, mais obtient le contenu du fichier de script que vous souhaitez appeler et envoie un bloc de paramètres contenant les paramètres et les valeurs.

l'Un des avantages de ceci est que vous pouvez éventuellement choisir les paramètres à envoyer au script fichier permettant des paramètres non-obligatoires avec des valeurs par défaut.

en supposant qu'il y ait un script appelé "MyScript.ps1" dans le chemin temporaire qui a le bloc de paramètres suivant:

[CmdletBinding(PositionalBinding = $False)]
param
(
    [Parameter(Mandatory = $True)] [String] $MyNamedParameter1,
    [Parameter(Mandatory = $True)] [String] $MyNamedParameter2,
    [Parameter(Mandatory = $False)] [String] $MyNamedParameter3 = "some default value"
)

C'est comme ça que j'appellerais ce script à partir d'un autre script:

$params = @{
    MyNamedParameter1 = $SomeValue
    MyNamedParameter2 = $SomeOtherValue
}

If ($SomeCondition)
{
    $params['MyNamedParameter3'] = $YetAnotherValue
}

$pathToScript = Join-Path -Path $env:Temp -ChildPath MyScript.ps1

$sb = [scriptblock]::create(".{$(Get-Content -Path $pathToScript -Raw)} $(&{
        $args
} @params)")
Invoke-Command -ScriptBlock $sb

j'ai utilisé ceci dans beaucoup de scénarios et cela fonctionne vraiment bien. Une chose que vous avez parfois besoin de faire est de mettre des guillemets autour de l'assignation de valeur du paramètre bloc. C'est toujours le cas quand il y a des espaces dans la valeur.

p.ex. ce bloc param est utilisé pour appeler un script qui copie divers modules dans l'emplacement standard utilisé par PowerShell C:\Program Files\WindowsPowerShell\Modules qui contient un caractère d'espace.

$params = @{
        SourcePath      = "$WorkingDirectory\Modules"
        DestinationPath = "'$(Join-Path -Path $([System.Environment]::GetFolderPath('ProgramFiles')) -ChildPath 'WindowsPowershell\Modules')'"
    }

Espérons que cette aide!

j'imagine que c'est une nouvelle fonctionnalité puisque ce post a été créé - passer les paramètres au bloc script en utilisant $Using:var. Puis c'est un simple mater pour passer les paramètres à condition que le script soit déjà sur la machine ou dans un emplacement réseau connu par rapport à la machine

en prenant l'exemple principal, il serait:

icm -cn $Env:ComputerName { 
    C:\Scripts\ArchiveEventLogs\ver5\ArchiveEventLogs.ps1 -one "uno" -two "dos" -Debug -Clear $Using:Clear
}