17
Script lässt sich nur teilweise remote ausführen
Hallo,
Ich habe ein Script erstellt, welches auf einem Citrix Server eine neue Softwareversion installiert, die alte Version löscht, die neue Version in Citrix published und ein Lizenzfile in das Installationsverzeichnis kopiert. Das funktioniert auf dem Server selbst auch super (Server 2).
Nun muss ich das Script aber von einem Anderen Server aus starten.
Aslo Server 1 startet ein Script, was das Citrix-Script auf Server 2 ausführt . Das mache ich mittels PSExec:
nun wird das Script auf Server 2 ausgeführt bis an die Stelle, wo per Powershell die WorkingDirectory der alten Version abgefragt wird:
Da bekomme ich dann auf Server 1 folgende Meldung angezeigt:
Nun bin ich ratlos. Ich führe das Script von Server 1 mit dem Domänen Admin aus. Das Citrix Powershell Modul wird iM Script auf Server 2 gealden.
Wie gesagt. Wenn ich das Script direkt lokal auf Server 2 ausführe , wird es ohne Fehler ausgeführt. Lediglich, wenn ich es in einem anderen Script auf Server 1 trigger, kommt dieser Fehler und die letzten 2 Steps werden nicht ausgeführt.
Ich habe ein Script erstellt, welches auf einem Citrix Server eine neue Softwareversion installiert, die alte Version löscht, die neue Version in Citrix published und ein Lizenzfile in das Installationsverzeichnis kopiert. Das funktioniert auf dem Server selbst auch super (Server 2).
Nun muss ich das Script aber von einem Anderen Server aus starten.
Aslo Server 1 startet ein Script, was das Citrix-Script auf Server 2 ausführt . Das mache ich mittels PSExec:
$adminUsername='domäne\Administrator'
$plaintextPassword='adminpwd'
$encryptedPassword=ConvertTo-securestring $plaintextPassword -AsPlainText -Force
$adminCredential=New-Object -TypeName System.Management.Automation.PSCredential -Args $adminUsername,$encryptedPassword
$computers = 'IP1','IP2'
$customer = 'Kunde1'
$stage = 'Test'
# Script auf Remote-PC ausführen (mit psexec)
foreach($computer in $computers) {
Write-host "Starte Skript auf PC $computer" -ForegroundColor Green
$command = "$PSScriptRoot\PsExec.exe"
$scriptpath ="D:\powershell_tools\update_wizard_Citrix_client_silent.ps1"
#$arguments = "-wait -ArgumentList"
& $command "\\$computer" -u "$adminUsername" -p $plaintextPassword -s -i "powershell" $scriptpath "-new__version $new_version -customer $customer -stage $stage"
}nun wird das Script auf Server 2 ausgeführt bis an die Stelle, wo per Powershell die WorkingDirectory der alten Version abgefragt wird:
$old_version = [regex]::match((Get-BrokerApplication -CommandLineExecutable "$install_path\$stage\*").WorkingDirectory,'\d+\.\d+\.\d+(\.\d+)?(\.\d+)?').Value Da bekomme ich dann auf Server 1 folgende Meldung angezeigt:
Get-BrokerApplication : Insufficient administrative privilege
In D:\powershell_tools\update_wizard_Citrix_client_silen
t.ps1:107 Zeichen:35
+ ... ex]::match((Get-BrokerApplication -CommandLineExecutable "$_install ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (:) [Get-BrokerApplication], S
start-process
dkOperationException
+ FullyQualifiedErrorId : Citrix.XDPowerShell.Broker.AccessDenied,Citrix.B
powershell
roker.Admin.SDK.GetBrokerApplicationCommandNun bin ich ratlos. Ich führe das Script von Server 1 mit dem Domänen Admin aus. Das Citrix Powershell Modul wird iM Script auf Server 2 gealden.
Wie gesagt. Wenn ich das Script direkt lokal auf Server 2 ausführe , wird es ohne Fehler ausgeführt. Lediglich, wenn ich es in einem anderen Script auf Server 1 trigger, kommt dieser Fehler und die letzten 2 Steps werden nicht ausgeführt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93672656656
Url: https://administrator.de/contentid/93672656656
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
17 Kommentare
Neuester Kommentar
Moin,
Direkt helfen kann ich dir (vermutlich) nicht, aber versuchst du, den Citrix-Client (= WorkspaceApp) zu aktualisieren?
Wenn das der Fall ist: da hat Citrix doch selbst eine BatchFile im Portfolio. Einfach den Citrix-Server Neustarten und die Installation via GPO erledigen lassen…
Am Rande:
Ich hoffe inständig, dass das oben genannte Script nirgends abgespeichert ist.
Wenn du wirklich den User und das Password im Klartext im Script hast, ist das für einen pöhsen Purschen gefundenes Fressen und er dreht dir das AD komplett auf links (nachdem er alle Daten unbemerkt abgezogen hat)…
Direkt helfen kann ich dir (vermutlich) nicht, aber versuchst du, den Citrix-Client (= WorkspaceApp) zu aktualisieren?
Wenn das der Fall ist: da hat Citrix doch selbst eine BatchFile im Portfolio. Einfach den Citrix-Server Neustarten und die Installation via GPO erledigen lassen…
Am Rande:
Ich hoffe inständig, dass das oben genannte Script nirgends abgespeichert ist.
Wenn du wirklich den User und das Password im Klartext im Script hast, ist das für einen pöhsen Purschen gefundenes Fressen und er dreht dir das AD komplett auf links (nachdem er alle Daten unbemerkt abgezogen hat)…
Zitat von @MarciMarc85:
Wie gesagt. Wenn ich das Script direkt lokal auf Server 2 ausführe , wird es ohne Fehler ausgeführt. Lediglich, wenn ich es in einem anderen Script auf Server 1 trigger, kommt dieser Fehler und die letzten 2 Steps werden nicht ausgeführt.
Das dürfte damit Zusammenhängen, wie der Befehl auf dem Remotesystem ausgeführt wird.
Dies ist recht anschaulich unter PsExec Explainer by Mark Russinovich dargelegt.
Zitat von @em-pie:
Direkt helfen kann ich dir (vermutlich) nicht, aber versuchst du, den Citrix-Client (= WorkspaceApp) zu aktualisieren?
Wenn das der Fall ist: da hat Citrix doch selbst eine BatchFile im Portfolio. Einfach den Citrix-Server Neustarten und die Installation via GPO erledigen lassen…
Wenn das der Fall ist: da hat Citrix doch selbst eine BatchFile im Portfolio. Einfach den Citrix-Server Neustarten und die Installation via GPO erledigen lassen…
Wenn tatsächlich kein Provisioning eingesetzt wird, sind diese Prozesse (manuell/automatisch) in der Dokumentation der Workspace app ausführlich beschrieben (Install and uninstall, Update).
Nein. Ich versuche nicht Citrix zu Updaten.
Ich versuche die durch Citrix freigegebenen Anwendungen zu updaten, Wockspace Directory, CommandLine Executable und ApplicationName zu ändern und ein Lizenzfile in die geupdatete Anwendung zu kopieren. Das klappt alles mit meinem Script, solange ich es lokal auf dem Citrix Server ausführe.
Der Client soll aber nur geupdated werden, wenn vorher der dazugehörige Server auch geupdated wurde. Daher soll der Server am Ende seines Scriptes, mit PSExec, das Script auf dem Citrix Server starten, was dann nur soweit funktioniert, bis auf dem Citrix System die Stelle "GetBrokerApplication..." kommt.
Nichmal. Ich will nicht Citrix updaten, sondern die Published Apllications durch Citrix.
Und wie gesagt: Grundsätzlich funktioniert mein Scripot auch, wenn ich es lokal auf dem Citrx Server starte. Ich brauche aber ein Trigger vom Application Server, der das Script remote startet, was mir aktuell Schwierigkeiten bereitet, da eben dieser Fehler auftritt, sobald es remote mit Adminrechenten gestartet wird.
Ich versuche die durch Citrix freigegebenen Anwendungen zu updaten, Wockspace Directory, CommandLine Executable und ApplicationName zu ändern und ein Lizenzfile in die geupdatete Anwendung zu kopieren. Das klappt alles mit meinem Script, solange ich es lokal auf dem Citrix Server ausführe.
Der Client soll aber nur geupdated werden, wenn vorher der dazugehörige Server auch geupdated wurde. Daher soll der Server am Ende seines Scriptes, mit PSExec, das Script auf dem Citrix Server starten, was dann nur soweit funktioniert, bis auf dem Citrix System die Stelle "GetBrokerApplication..." kommt.
Nichmal. Ich will nicht Citrix updaten, sondern die Published Apllications durch Citrix.
Und wie gesagt: Grundsätzlich funktioniert mein Scripot auch, wenn ich es lokal auf dem Citrx Server starte. Ich brauche aber ein Trigger vom Application Server, der das Script remote startet, was mir aktuell Schwierigkeiten bereitet, da eben dieser Fehler auftritt, sobald es remote mit Adminrechenten gestartet wird.
Ist das typische double hop Problem, kommt hier gefühlt jeden zweiten Tag
Usw.
p s. Powershell hat eingebautes Remoting, da braucht es auch kein psexec => Invoke-Command
Aber so ne Frickelei ... Habt ihr kein vernünftiges Patchmanagement?
- https://www.computerweekly.com/de/ratgeber/Mit-PowerShell-das-zweite-Hop ...
- https://www.techtarget.com/searchwindowsserver/tutorial/How-to-avoid-the ...
- https://learn.microsoft.com/de-de/powershell/scripting/learn/remoting/ps ...
Usw.
p s. Powershell hat eingebautes Remoting, da braucht es auch kein psexec => Invoke-Command
Ich brauche aber ein Trigger vom Application Server, der das Script remote startet
Für sowas nutzt man der Einfachheit halber einen Tasktrigger im Task-Scheduler der auf ein Event wartet und dann das Skript ausführt, dann brauchst du nur noch Write-Eventlog zum antriggern des Skriptes.Aber so ne Frickelei ... Habt ihr kein vernünftiges Patchmanagement?
1
Moin,
aktualisiert ihr den „dazugehörigen Server“ manuell oder geschieht dies auch (halb)automatisiert?
Falls ersteres, dann euer Script einfach per
https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
aktualisiert ihr den „dazugehörigen Server“ manuell oder geschieht dies auch (halb)automatisiert?
Falls ersteres, dann euer Script einfach per
Invoke-Command() ausführen.https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
Wieso machst Du das nicht direkt mittels Powershell eingebauter Funktionen New-PSSession und anschließend mit Invoke-Command?
Zitat von @em-pie:
Moin,
aktualisiert ihr den „dazugehörigen Server“ manuell oder geschieht dies auch (halb)automatisiert?
Falls ersteres, dann euer Script einfach per
https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
Moin,
aktualisiert ihr den „dazugehörigen Server“ manuell oder geschieht dies auch (halb)automatisiert?
Falls ersteres, dann euer Script einfach per
Invoke-Command() ausführen.https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
Also ich hab es mal so abgeändert:
param (
[Parameter(Mandatory=$true)][String]$new_version,
[Parameter(Mandatory=$true)][String]$customer,
[Parameter(Mandatory=$true)][String]$stage
)
$computers = '10.0.1.15'
# Script auf Remote-PC ausführen (mit psexec)
foreach($computer in $computers) {
Write-host "Starte Skript auf PC $computer" -ForegroundColor Green
$scriptpath ="D:\powershell_tools\update_wizard_Citrix_client_silent.ps1"
Invoke-Command -ComputerName $computer -Credential $adminCredential -ScriptBlock {start-process powershell -ArgumentList -File $scriptpath "-new_version $new_version -customer $customer -stage $stage" }
}Das Ergebnis:
Starte Skript auf PC 10.0.1.15
Fehler beim Ausführen des InitializeDefaultDrives-Vorgangs für den Anbieter "FileSystem".
Missing an argument for parameter 'ArgumentList'. Specify a parameter of type 'System.String[]' and try again.
+ CategoryInfo : InvalidArgument: (:) [Start-Process], ParameterBindingException
+ FullyQualifiedErrorId : MissingArgument,Microsoft.PowerShell.Commands.StartProcessCommand
+ PSComputerName : 10.0.1.15
steht ja schon in der fehlermeldung , du gibst dem "-Argumentlist" keine parameter mit. Das gehört aber auch nicht in den scriptblock sondern dahinter (ist ein argument für invoke-command).
Würd empfehlen dir das hier mal durchzulesen https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell ...
alternativ lass es dir einfach von chatgpt etc schreiben.
Abgesehen davon: domain-admin credentials benutzt man niemals für sowas und legt sie erst recht nicht ( siehe dein erstes script) plaintext (!) in irgend nem script ab.
Würd empfehlen dir das hier mal durchzulesen https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell ...
alternativ lass es dir einfach von chatgpt etc schreiben.
Abgesehen davon: domain-admin credentials benutzt man niemals für sowas und legt sie erst recht nicht ( siehe dein erstes script) plaintext (!) in irgend nem script ab.
Hi. Also ich habe jetzt nochmal ein wenig das Hauptscript bearbeitet und etwas vereinfacht. letztendlich schaut das jetzt so aus:
1. Auf Server 1 wird eine Software installiert (Silent per Powershell Script)
2. Am Ende des Scripts auf Server 1 (Datenbank Sever) wird per PSExec auf Server 2 (Citrix Server) das entsprechende Script zur Installation des dazugehörigen Clients ("Client_Update_Script") auf Server 2 angestoßen.
3. Dieses "Client_Update_Script" liegt auf Server2, deinstalliert auf Server 2 die vorherige Client-Version, installiert die neue und passende Client-Version zu Server 1 und kopiert eine Lizenzdatei in das neue Clientverzeichnis.
4. Nun muss die Citrix-Freigabe des Clients auf Server 2 noch angepasst werden. Das habe ich bisher immer mit einem eigenen Script auf Server 2 gemacht. Da muss ich dann einfach nur die neue Versionsnummer als Parameter mitgeben und das Script ersetzt die alte Citrix Freigabe, durch die neue ( Es sind mehrere Applikationen der Software, die freigegeben werden).
5. Nun habe ich ebenfall einen Trigger für diesen abschließenden Schritt an das Ende des "Client_Update_Script" gepackt:
Das funktioniert auch genauso, wie es soll. Danach ist die Citrix freigabe angepasst. Aber das funktioniert nur dann, wenn ich das start-process "powershell" -wait -ArgumentList "$apptausch_script -new_rs_version_exe "Client_Update_Script" auf dem Citrix Server direkt ausführe.
6. Wenn ich das wie in Schritt 2. anstoße (von Server 1) werden die Citrix Freigaben nicht angepasst. Sprich das letzte Script wird nicht gestartet. bzw. wird ohne Fehler übersprungen.
7. Ich hab dann mal den letzten Part aus dem "Client_Update_Script" auch per PSExec voN Server 1 gestartet und bekomme:
Jetzt hab ich gegoogelt und das hier fefunden:
"Pass AdminAddress parameter when you run in your local machine. Default it will consider value as “Localhost” "
Damit kann ich allerdings nichts anfangen. Es scheint so, als würde das Script auf Server 2 alle Befehle so behandeln, als würden sie von Server 1 ausgeführt und entsprechend das Citrix Apptausch Script am Ende nicht gesstartet, da die Berechtigungen nicht stimmen.
Das Apptausch Script besteht im Großen und Ganzen hauptsächlich aus Befehlen wie :
1. Auf Server 1 wird eine Software installiert (Silent per Powershell Script)
2. Am Ende des Scripts auf Server 1 (Datenbank Sever) wird per PSExec auf Server 2 (Citrix Server) das entsprechende Script zur Installation des dazugehörigen Clients ("Client_Update_Script") auf Server 2 angestoßen.
3. Dieses "Client_Update_Script" liegt auf Server2, deinstalliert auf Server 2 die vorherige Client-Version, installiert die neue und passende Client-Version zu Server 1 und kopiert eine Lizenzdatei in das neue Clientverzeichnis.
4. Nun muss die Citrix-Freigabe des Clients auf Server 2 noch angepasst werden. Das habe ich bisher immer mit einem eigenen Script auf Server 2 gemacht. Da muss ich dann einfach nur die neue Versionsnummer als Parameter mitgeben und das Script ersetzt die alte Citrix Freigabe, durch die neue ( Es sind mehrere Applikationen der Software, die freigegeben werden).
5. Nun habe ich ebenfall einen Trigger für diesen abschließenden Schritt an das Ende des "Client_Update_Script" gepackt:
start-process "powershell" -wait -ArgumentList "$apptausch_script -new_version_exe $new_version" 6. Wenn ich das wie in Schritt 2. anstoße (von Server 1) werden die Citrix Freigaben nicht angepasst. Sprich das letzte Script wird nicht gestartet. bzw. wird ohne Fehler übersprungen.
7. Ich hab dann mal den letzten Part aus dem "Client_Update_Script" auch per PSExec voN Server 1 gestartet und bekomme:
Get-BrokerApplication : Insufficient administrative privilege
In D:\tools\Apptausch.ps1:22
Zeichen:1
+ Get-BrokerApplication -AdminFoldername "Release_NEU\" -ApplicationName ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (:) [Get-BrokerApplication], S
dkOperationException
+ FullyQualifiedErrorId : Citrix.XDPowerShell.Broker.AccessDenied,Citrix.B
roker.Admin.SDK.GetBrokerApplicationCommandJetzt hab ich gegoogelt und das hier fefunden:
"Pass AdminAddress parameter when you run in your local machine. Default it will consider value as “Localhost” "
Damit kann ich allerdings nichts anfangen. Es scheint so, als würde das Script auf Server 2 alle Befehle so behandeln, als würden sie von Server 1 ausgeführt und entsprechend das Citrix Apptausch Script am Ende nicht gesstartet, da die Berechtigungen nicht stimmen.
Das Apptausch Script besteht im Großen und Ganzen hauptsächlich aus Befehlen wie :
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Get-BrokerApplication -AdminFoldername ... -ApplicationName ... | Set-BrokerApplication -CommandLineExecutable ...
Steht doch schon oben in meinem Post warum es zum Fehler kommt (Stichwort double hop), lesen hilft !
Zitat von @11078840001:
Steht doch schon oben in meinem Post warum es zum Fehler kommt (Stichwort double hop), lesen hilft !
Steht doch schon oben in meinem Post warum es zum Fehler kommt (Stichwort double hop), lesen hilft !
In dem Besipielen oben wird jedoch davon gesprochen, von Server 1 ein Script auf Server 2 auszuführen, was dann wiederum ein Script auf Server 3 startet.
ich führe aber von Server 1 ein Script auf Server 2 aus, welches ein weiteres Script auf Server 2 startet.
Bzw. Hatte ich vorher auch eine Get-BrokerApplication-Abfrage direkt im ersten Script auf Server 2 und es kam zu genau derselben Fehlermeldung.
ich führe aber von Server 1 ein Script auf Server 2 aus, welches ein weiteres Script auf Server 2 startet.
Nein der Aufruf des CMDLet Get-BrokerApplication ist bereits ein DoubleHop weil der eine Remote-Abfrage startet, und da die CredentialDelegation hier nicht zugelassen wird schlägt der Aufruf wegen zu wenig Rechten fehlt!!
Ich komme mit diesem Problem einfach nicht weiter. Ich bin jetzt nach https://www.techtarget.com/searchwindowsserver/tutorial/How-to-avoid-the ...
vorgegangen und wenn ich jetzt voN Server 1 das Script auf Server 2 mittels PSexc starte bekomme ich:
Ergebnis:
Langsam verliere ich da wirklich den Überblick
$PSDefaultParameterValues = @{'Invoke-Command:ConfigurationName'='Demo' } # Script auf Remote-PC ausführen (mit psexec)
foreach($computer in $computers) {
Write-host "Starte Skript auf PC $computer" -ForegroundColor Green
$command = "$PSScriptRoot\PsExec.exe"
$scriptpath ="D:\powershell_tools\test2.ps1"
#$arguments = "-wait -ArgumentList"
& $command "\\$computer" -u "$Username" -p $Password -h -i start-process "powershell" -wait -ArgumentList "$scriptpath $new_version"
}Ergebnis:
Starting PSEXESVC service on 10.0.0.1..
Copying authentication key to 10.0.0.1...
Connecting with PsExec service on 10.0.0.1...
Starting start-process on 10.0.0.1...
PsExec could not start start-process on 10.0.0.1:
The system cannot find the file specified.Langsam verliere ich da wirklich den Überblick
Ich verstehe immer noch nicht, wieso du mit PSEXEC etc. arbeitest, wo doch die Powershell selbst alles Remote ausführen kann.
Enter-PSSession ServerXX
oder
Invoke-Command -ComputerName ServerXX
Befasse dich doch besser damit.
https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
Enter-PSSession ServerXX
oder
Invoke-Command -ComputerName ServerXX
Befasse dich doch besser damit.
https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ru ...
Ich habe es jetzt hinbekommen mit Invoke-Command, allerdings nur mit einem Parameter, Wenn ich mehrere Paramter als AgrumentList mitgebe, bekomme ich immer ine Fehlermeldung:
Funktioniert:
Funktioniert nicht:
Funktioniert:
Invoke-Command -ScriptBlock {D:\tools\Apptausch_Citrix.ps1 $using:new_version } -ComputerName $Computer -Credential $adminCredential -ErrorAction StopFunktioniert nicht:
Invoke-Command -ScriptBlock {D:\tools\Apptausch_Citrix.ps1 -ArgumentList -new_version $using:new_version -customer $using:customer -stage $using:stage } -ComputerName $Computer -Credential $adminCredential -ErrorAction StopA parameter cannot be found that matches parameter name 'ArgumentList'.
At D:\powershell_tools\citrix_client_update_trigger.ps1:35 char:5
+ Invoke-Command -ScriptBlock {D:\tools\Apptausch ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Apptausch_Citrix.ps1], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Apptausch_Citrix.ps1
+ PSComputerName : 10.32.2.17
Tja du liest unsere Posts einfach nicht aufmerksam genug ....haben wir dir schon x mal gezeigt. Genau das steht nämlich in den Antworten zu deinem Beitrag hier ...
Mehrere Parameter an zweites Powershell Script übergeben
Aufmerksamkeitsspanne erhöhen!
Mehrere Parameter an zweites Powershell Script übergeben
Aufmerksamkeitsspanne erhöhen!
