Russische Volkslieder von einer Straßencombo.
Georgische Volkslieder Trio Mandili
Irisches Folk: The Dubliners
Archiv für den Monat: Juli 2017
PowerShell für die Steuerung anderer Computer nutzen
Powershell Remoting einrichten
- PowerShell als Admin starten
- Enable-PSRemoting -Force ausführen
- Bei meinem Laptop kam als Fehlermeldung: Set-WSManQuickConfig : Die WinRM-Firewallausnahme funktioniert nicht, da einer der Netzwerkverbindungstypen auf diesem Computer auf „Öffentlich“ festgelegt ist. Ändern Sie den Netzwerkverbindungstyp entweder in „Domäne“ oder in „Privat“, und wiederholen Sie den Vorgang. -> Lösung: also habe ich meine LAN-Verbindung, die auf Öffentliches Netzwerk gestellt war, deaktiviert. Danach führte der Befehl erfolgreich aus.
- anschließend habe ich die Verbindung getestet: Test-WsMan <REMOTE COMPUTERNAME>
- und bekam folgende Fehlermeldung: Test-WSMan : Der Client kann keine Verbindung mit dem in der Anforderung angegebenen Ziel herstellen. Stellen Sie sicher, dass der Dienst auf dem Ziel ausgeführt wird und die Anforderungen akzeptiert. Lesen Sie die Protokolle und die Dokumentation für den WS-Verwaltungsdienst, der auf dem Ziel ausgeführt wird. Hierbei handelt es sich meistens um IIS oder WinRM. Wenn das Ziel der WinRM-Dienst ist, führen Sie den folgenden Befehl auf dem Ziel aus, um den WinRM-Dienst zu analysieren und zu konfigurieren: „winrm quickconfig“. -> Lösung: auf dem Zielrechner habe ich dann winrm quickconfig durchgeführt und im weiteren Dialog dann winrm aktiviert.
- anschließend habe ich die Verbindung noch einmal getestet: Test-WsMan <REMOTE COMPUTERNAME> – dieses Mal war’s erfolgreich:
Verschiedene Dinge auf dem remote-Rechner tun
#fill you credential in the pop-up window once
$myCredential = get-credential
# Gibt den Ordnerinhalt von C:\Temp zurück
Invoke-Command -ComputerName <COMPUTERNAME> -ScriptBlock { Get-ChildItem C:\Temp } -credential $myCredential
# Startet einen calc-Prozess, der lediglich im Task Manager zu sehen ist (ein sichtbarer Taschenrechner wird nicht gestartet). Eine Taschenrechner-UI wird, wie zu erwarten, nicht gestartet, weil der remote powershell eine UI-session fehlt.
# Aus irgendeinem Grunde startet der Prozess nicht, wenn kein -Wait angegeben ist.
Invoke-Command -ComputerName <COMPUTERNAME> -ScriptBlock { Start-Process calc -Wait} -credential $myCredential
# Erzeugt ein leeres Text-File
Invoke-Command -ComputerName <COMPUTERNAME> -ScriptBlock { New-Item c:\temp\AnEmptyFile.txt -ItemType file -Wait} -credential $myCredential
# Zeigt, in welcher Session man sich gerade befindet
Write-Host "This PowerShell command is running under the current users context: $env:userdomain\$env:username" -f magenta
Invoke-Command -ComputerName -ScriptBlock { Write-Host "Hello, this script block is running under the security context of the inner account: $env:userdomain\$env:username" -f Green; } -credential $myCredential
Write-Host "And now we return to the current users context: $env:userdomain\$env:username" -f magenta
# Ungelöst: den Ordnerinhalt eines Netzwerkordners zurückgeben
Wenn ich den Befehl
Get-ChildItem „\\<NAME OF COMPUTER WHICH HOSTS THE NETWORK SHARE>\ourNetworkShare“
auf dem Remote-Computer in einer Powershell (die ich nicht als admin gestartet habe) ausführe, bekomme ich ein korrektes Ergebnis. Führe ich jedoch auf einem anderen Computer Folgendes aus:
Invoke-Command -ComputerName <REMOTE COMPUTERNAME> -ScriptBlock { Get-ChildItem ‚\\<NAME OF COMPUTER WHICH HOSTS THE NETWORK SHARE>\ourNetworkShare‘ } -credential $myCredential
… scheiterte bei mir jedoch immer mit
Cannot find path ‚\\<NAME OF COMPUTER WHICH HOSTS THE NETWORK SHARE>\ourNetworkShare‘ because it does not exist. + CategoryInfo: ObjectNotFound: (\\<NAME OF COMPUTER WHICH HOSTS THE NETWORK SHARE>….ourNetworkShare:String) [Get-ChildItem], ItemNotFound Exception + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
Also habe ich diese Frage an Stackoberflow gestellt: Zur Frage
Autologon im Zusammenhang mit VMs nutzen
Man kann sich bei Windows anmelden, ohne Benutzer&Passwort einzugeben: Sysinternals Autologon.
Im Zusammenhang mit der Verwendung von VMs ergibt sich der praktische Nutzen daraus, dass eine Session mit (virtuellem) Bildschirm beim Rechnerneustart automatisch mitstartet, die für das Funktionieren von Ranorex-Tests notwendig ist.
Es scheint so zu sein, dass ein Zugriff per RDP trotzdem noch die Eingabe eines Passworts erforderlich macht, was für den Schutz des Computers ausreichen dürfte. Jedenfalls bekam ich bei einem RDP-Verbindungsversuche folgenden Hinweis: To log on to this remote computer, you must be granted the Allow logon through Terminal Services right. Ich glaube, wer Mitglied in der Usergroup Remote Desktop Users ist, der hat dieses Recht automatisch. Das Pendant zum Vor-dem-Computer-Sitzen ist bei VMs der Zugriff via Console, der tatsächlich dann auch ohne die Eingabe eines Passworts auskommt. Bei einem physischen Computer erscheint trotz enableten Autologon natürlich noch eine möglicherweise eingerichtete McAfee Endpoint Encryption Passworteingabe.
Der batch-mode vom Autologon.exe funktioniert zwar grundsätzlich – ist aber irgendwie nicht ganz zuverlässig. So konnte ich das autologon im batch-mode erfolgreich laufen lassen, als es bei mir auf dem Computer lag. Es wurde jedoch keine Erfolgsmeldung ausgegeben und so habe ich erst durch einen Restart herausgefunden, dass es wirklich geklappt hat. Von einem Netzwerkordner konnte ich das autologon nicht im batch-mode ausführen (was an den Sicherheitseinstellungen lag). Der entsprechende Versuch wurde jedoch mit der unpassenden und irreführenden Fehlermeldung Login failure: unknown user name or bad password. quittiert – die Credentials waren nachweislich korrekt – ich hatte sie vom vorigen „lokalen“ Versuch einfach rüberkopiert. So richtig dokumentiert ist der batch-mode leider auch nicht.
Auf vielen Computern Autologon aktivieren
Eine bulk-action mit PowerShell konnte ich noch nicht realisieren, weil ich es noch nicht geschafft habe, Dateien von einem Netzwerk-share zu kopieren – siehe.
Am effektivsten ist also noch Folgendes: autologon auf share ablegen und dann folgendes script auf jedem Rechner per cmd ausführen:
mkdir C:\temp
copy "\\<NETWORK-SERVER>\<NETWORK-SHARE>\<PATH>\autologon.exe" C:\temp
C:\temp\autologon <USER> <DOMAIN> <PASSWORD>
#gg.falls restart windows
#cmd: whoami