althalus
Goto Top

Remote-PowerShell Script gibt Probleme bei einigen Testrechnern

Hallo zusammen,

ich habe gerade ein Problem mit der Ausführung eines Powershell Scripts. Was nur bei einigen Testrechnern nicht Funktioniert ist die Laufwerksverknüpfung. Bei anderen geht es wieder.
Technischer Setup ist auf den Testrechnern Identisch (es sidn physische Rechner die gleich Ausgestattet sind). Das Script führe ich von meiner Arbeitsstation als Administrator (RunAs) aus.

Bei den Testdurchläufen sind folgende Sachen herausgekommen.
1. Testdurchlauf bei nur einem PC in der Textdatei, läuft Problemlos.
2. Testdurchlauf mit zwei PCs lief beim ersten Problemlos, beim Zweiten nicht.
2.a Was nicht lief beim zweiten Rechner war die Verbindung des Netzlaufwerks. Deinstallieren und den ganzen Rest hat er ohne zu Klagen und Nachvollziehbar getan.
3. Testdurchlauf nur Remote mit dem zweiten Rechner lief auch Einwandfrei bis zur verbindung des Netzlaufwerks.

Da dies anscheinend das einzige Problem ist habe ich die Verbindung des Netzlaufwerks mehrfach Versucht, auch mit NEW-PSDrive und der WMI Methode, jedoch scheitern sie alle. Eine Fehlermeldung finde ich weder im Ereignisprotokoll noch in der Ausgabe der Powershell ISE. Es ist auch Uninteressant ob ich für den Share eine IP-Adresse nutze oder den Namen.

Net Use gibt mir an das die Laufwerksverbindung Erfolgreich war.
New-PSDrive gibt mir das Laufwerk X an, jedoch sieht man keine Belegeung (Benutzer Festplattenspeicher, Verfügbarer Festplattenspeicher).
New-PSDrive -Name X -PSProvider FileSystem -Root \\Server\Share\Unterordner 

Wenn man jedoch nach dem Verbinden des Laufwerks ein Get-PSDrive eingibt und ausführt wird das Laufwerk X jedoch nicht angezeigt.

Mit meinem Latein bin ich am Ende, überlege ob ich das Script nicht so umschreibe das er die aktuelle Installation prüft und nur falls per Update eine neuere Version verfügbar ist diese dann Installiert... was aber auch wieder über ein Share laufen wird.

Wenn das Script komplett auf dem Rechner, wo das Laufwerksverbinden nicht klappt, ausführt funktioniert alles Einwandfrei. (Natürlich das Script so umgeschrieben das es Lokal läuft.)

Hier einmal der Code des gesamten Scripts.

# Deklarieren der lokalen Variablen und Scripte
$username = "<Domain\Administrator>"  
$password = "<Passwort>"  
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr
$PCLIST = Get-Content 'D:\Powershell\PCs_für_Deploy.txt'  
$ScriptDeinstall1 = {
 $app = Get-WmiObject -Class Win32_Product |where { $_.name -EQ 'AAFClientPackages' }  
 $app.uninstall()
}
$ScriptDeinstall2 = {
 $app = Get-WmiObject -Class Win32_Product |where { $_.name -EQ 'AAFOutlookCTI' }  
 $app.uninstall()
}
$ScriptInstall1 = {
    $args = "-i C:\Temp\ARGOPatch\AAFClientPackages.msi /qn /norestart ALLUSERS=1"  
    [diagnostics.process]::start("msiexec.exe", $args).WaitForExit()  
}
$ScriptInstall2 = {
    $args = "-i C:\Temp\ARGOPatch\AAFOutlookCTISetup.msi /qn /norestart ALLUSERS=1"  
    [diagnostics.process]::start("msiexec.exe", $args).WaitForExit()  
}
$Textmassage = {
    $CmdMessage = { C:\windows\system32\msg.exe * 'Die Installation des Updates ist beendet, es kann wieder gearbeitet werden.' }  
    $CmdMessage | Invoke-Expression
}

# Starten der Schleife für die Abarbeitung der Installation
ForEach ($computer in $PCLIST) {
	# Aufbau einer neuen Remote-Session zum entfernten Computer und Setzen der Berechtigungen
    New-PSSession -ComputerName $computer -Credential $cred
    Invoke-Command -ComputerName $computer { Get-ExecutionPolicy } | Set-ExecutionPolicy -Force
    Invoke-Command -ComputerName $computer { Set-ExecutionPolicy Unrestricted }
    Invoke-Command -ComputerName $computer { Enable-PSRemoting -Force }
        
	# InternetExplorer schließen
    Write-Host "Internet Explorer wird geschlossen"  
    Invoke-Command -ComputerName $computer { Stop-Process -name iexplo* -Force }

	# Deinstallation der alten ARGO-Pakete
    Write-Host "AAFClientPackages werden Deinstalliert"  
    Invoke-Command -Computername $computer -ScriptBlock $ScriptDeinstall1 -Credential $cred -Verbose
    Write-Host "AAFOutlookCTI wird Deinstalliert"  
    Invoke-Command -Computername $computer -ScriptBlock $ScriptDeinstall2 -Credential $cred -Verbose

	# Verbinden des ARGO-Patchverzeichnisses
    Write-Host "Laufwerk X wird verbunden"  
    Invoke-Command -ComputerName $computer { Net Use X: \\Server\Share\Unterordner /USER:<Domäne>\Administrator <Passwort>}

	# Erstellen des Remoteverzeichnisses und Kopieren der Updatedateien
    Invoke-Command -ComputerName $computer { mkDir C:\Temp\ARGOPatch }
    Invoke-Command -ComputerName $computer { robocopy X: C:\Temp\ARGOPatch /MIR }

	# Installation des Updates
    Write-Host "Installation von AAFClientPackages"  
    Invoke-Command -ComputerName $computer -scriptblock $ScriptInstall1 -Credential $cred
    Write-Host "Installation von AAFOutlookCTI"  
    Invoke-Command -ComputerName $computer -scriptblock $ScriptInstall2 -Credential $cred

	# Entfernen des Remoteverzeichnisses und Löschen der Updatedateien
    Invoke-Command -ComputerName $computer { Net Use X: /delete }
    Invoke-Command -ComputerName $computer { rd C:\Temp\ARGOPatch -recurse }

	# Freischaltung der NetFramework Dateien
    Invoke-Command -ComputerName $computer { C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -q -machine -chggroup Trusted_Zone FullTrust }
    Invoke-Command -ComputerName $computer { C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\CasPol.exe -q -machine -chggroup Trusted_Zone FullTrust }

	#Nachricht für die Benutzer dass das Update fertig ist
    Invoke-Command -ComputerName $computer -Scriptblock $Textmassage

	#Verlassen der Remote-Session
    Exit-PSSession
}

Schon einmal vielen Dank für die Hilfe.

LG Althalus

Content-ID: 287137

Url: https://administrator.de/forum/remote-powershell-script-gibt-probleme-bei-einigen-testrechnern-287137.html

Ausgedruckt am: 26.12.2024 um 04:12 Uhr

122990
Lösung 122990 30.10.2015 aktualisiert um 16:00:43 Uhr
Goto Top
Moin,
ich würde mal vermuten das kommt daher das du hier für jeden einzelnen Befehl ein separaten Invoke-Command ausführst und nicht das Verbinden des LW zusammen mit den Befehlen die das LW nutzen, denn normalerweise wird bei jedem Invoke-Command eine separate Session zum Remote-System aufgebaut und deswegen das PSDrive vermutlich wieder getrennt ...
When you use -ComputerName,  PowerShell will create a temporary connection that is
used only to run the specified command and is then closed.
If you need a persistent connection, use -Session

-Command ist ein Skriptblock, also kannst du problemlos mehrere Befehle in einen Aufruf packen, das ist schon der Performance wegen zu empfehlen, da ansonsten jedes mal eine Authentifizierung und Session gestartet werden muss!

Gruß grexit
Althalus
Althalus 30.10.2015 um 14:05:06 Uhr
Goto Top
Hallo grexit,
Danke für die Information. Gleich mal Testen, wobei ich mich frage warum es dann auf den anderen Maschinen klappt.

Werde sobald der Test beendet ist Rückmeldung geben.
122990
122990 30.10.2015 aktualisiert um 14:09:10 Uhr
Goto Top
Zitat von @Althalus:

Hallo grexit,
wobei ich mich frage warum es dann auf den anderen Maschinen klappt.
Das kann Zufall sein, das z.B. die vorherige Session noch nicht wieder komplett beendet ist und der nächste Command dann mit Überschneidung ausgeführt wird.

Netzlaufwerke sind ja immer nur User und Session bezogen verfügbar ...außer man setzt den Registry-Eintrag "EnableLinkedConnections"
Althalus
Althalus 30.10.2015 um 14:33:12 Uhr
Goto Top
Das heißt ich sollte alle Programmbefehle am besten innerhalb einer Schleife haben? Hier mein Bleistift:
$LWuK ={ anfang der ForEach-Schleife und dann Ende der ForEach-Schleife }
Invoke-Command -Computername $computer -ScriptBlock $LWuK -Credential $cred
?

Wenn das dann alles gut läuft kann ich Anfangen den Code entsprechend zu Verschönern,
122990
122990 30.10.2015 aktualisiert um 14:36:26 Uhr
Goto Top
Zitat von @Althalus:

Das heißt ich sollte alle Programmbefehle am besten innerhalb einer Schleife haben? Hier mein Bleistift:
$LWuK ={ anfang der ForEach-Schleife und dann Ende der ForEach-Schleife }
> Invoke-Command -Computername $computer -ScriptBlock $LWuK -Credential $cred
?
Das ist keine Schleife sondern ein Skriptblock in dem du mehrere Befehle zusammenfasst ... Ist auf jeden Fall viel effizienter.
Althalus
Althalus 30.10.2015 um 14:43:03 Uhr
Goto Top
Ja, das stimmt natürlich.
Meinte in dem Fall jetzt auch, bezogen auf den ganzen Code in meinem ersten Post das ich es dann wohl so machen würde.

# Deklarieren der lokalen Variablen und Scripte
$username = "<Domain\Administrator"  
$password = "<Passwort>"  
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr

$ScriptDeinstall1 = {
 $app = Get-WmiObject -Class Win32_Product |where { $_.name -EQ 'AAFClientPackages' }  
 $app.uninstall()
}
$ScriptDeinstall2 = {
 $app = Get-WmiObject -Class Win32_Product |where { $_.name -EQ 'AAFOutlookCTI' }  
 $app.uninstall()
}
$ScriptInstall1 = {
    $args = "-i C:\Temp\ARGOPatch\AAFClientPackages.msi /qn /norestart ALLUSERS=1"  
    [diagnostics.process]::start("msiexec.exe", $args).WaitForExit()  
}
$ScriptInstall2 = {
    $args = "-i C:\Temp\ARGOPatch\AAFOutlookCTISetup.msi /qn /norestart ALLUSERS=1"  
    [diagnostics.process]::start("msiexec.exe", $args).WaitForExit()  
}
$Textmassage = {
    $CmdMessage = { C:\windows\system32\msg.exe * 'Die Installation des Updates ist beendet, es kann wieder gearbeitet werden.' }  
    $CmdMessage | Invoke-Expression
}
$ScriptCode = {Sessionaufbau
Berechtigungen setzen
Internetexplorer schließen
MSIs Deinstallieren
Laufwerkverbinden, kopieren und Laufwerksverbindung löschen
MSIs Installieren
Session schließen
}
ForEach ($computer in $PCLIST) { Invoke-Command -Computername $computer -ScriptBlock $ScriptCode -Credential $cred }
122990
122990 30.10.2015 um 14:46:29 Uhr
Goto Top
Ach so, na dann OK.