BOfH_666

Das ist eine hervorragende Idee. Ich. VSCode und Git. Was ist die eigentliche Frage?

Jon, bitte Code als Code formatieren. Hier nochmal Deine ersten Zielen Code. Vielleicht kommst Du selber drauf: $computerlist = Get-Content c:\Temp\Test.csv $a = Import-Csv -Path 'C:\Temp\test.csv' -Header "ComputerName" $Result = foreach ($Computername in $computerlist.ComputerName) { ... wenn nicht, gib Bescheid, dann helfen wir. EDIT: ... noch ein Tipp: Wenn Du zum Powershell-Scripte schreiben VSCode benutzt, wirst Du auf solche Fehler hingewiesen.

Vielleicht ja eben doch. Das könnte in diesem Fall aber genau das Problem sein. Es gibt Programme, die geben die Kontrolle direkt nach dem Start wieder an den aufrufenden Prozess zurück und laufen dann unabhängig weiter. Dann gibt es wieder Programm, die weitere Prozesse starten und dann die Kontrolle abgeben, während die "Kind-Prozesse" aber weiterlaufen. Wenn ich folgenden Code auf rufe: Echo "Start des Super CMD scripts" Notepad.exe Echo "Notepad beendet" Echo "Jetzt kommt Calc" calc.exe Dann erhalte ich genau das erwartete Verhalten. So sieht der output dann aus: C:\>c:\sample\test.cmd C:\>Echo "Start des Super CMD scripts" "Start des Super CMD scripts" C:\>Notepad.exe C:\>Echo "Notepad beendet" "Notepad beendet" C:\>Echo "Jetzt kommt Calc" "Jetzt kommt Calc" C:\>calc.exe C:\> Und der Rechner geht erst auf, wenn ich Notepad beendet habe.

Einfach mal ne Rückmeldung zu geben, hätte ja auch schon gereicht. Kein Grund beleidigt zu reagieren. Darf ich fragen, was das für Programme sind? Starten die Programme vielleicht weitere Prozesse? Wäre Powershell ne Option?

OK, aber Du hattest ja auch nicht danach gefragt und noobi hatte explizit erwähnt, dass sie W10 bereits nutzen und er bisher keine Erfahrung mit ThinClients hat. So ...

Stimmt natürlich. Je nach Anzahl der Dateien ist das dann nur etwas langsamer. .... und das zusammenbasteln der UNC-Pfade sieht immer unelegant aus ... finde ich ...

Jon, das wird so nix ... Wenn Du auf einem remote Computer etwas ausführen möchtest, must Du ihm das auch mitteilen. Ich gehe mal davon aus, dass Deine CSV-Datei einen Header enthält und in der Spalte, die "ComputerName" heißt, die Computernamen enthält. $computerlist = Get-Content c:\Temp\Server.csv $Result = foreach ($Computername in $computerlist.ComputerName) { if (Test-Connection -ComputerName $Computername) { Invoke-Command -ComputerName $Computername { Stop-Service -Name OssecSvc $FileList = Get-ChildItem -Path 'C:\Program Files (x86)\ossec-agent\rids'-Recurse $FileList | Select-Object -Property Parent, Name, @{Name = 'ComputerName'; Expression = { $ENV:ComputerName } } $FileList | Remove-Item Start-Service -Name OssecSvc } } } $Result | Export-Csv -Path c:\Temp\ossec.csv -NoTypeInformation Der Code ist von mir natürlich ungetestet ... also bitte mit einem Test-Computer und Test-Daten testen, bevor Du das auf Deine produktive Umgebung loslässt.

Schau Dir mal die Hilfe für CMD an "CMD /?". Die Optionen /C oder /K sollten was für Dich sein, wenn ich Dich richtig verstanden habe. Warum willst Du denn aus CMD eine weitere starten? Oder möchtest Du eine Batch-Datei ausführen? Übrigens: Wenn Du die gleiche Frage gleichzeitig in verschiedenen Foren stellst, sei doch bitte so nett und poste jeweils einen Link zu den anderen Foren, damit die Leute, die Dir helfen wollen, sich ihre Mühe nicht umsonst mehrfach machen müssen! Danke schon mal. https://social.technet.microsoft.com/Forums/de-DE/bf93c7d8-9199-4e38-93af-c8ea5cd978cb/proze-erst-warten?forum=powershell_de

Wie Mark Minasi immer zu sagen pflegte "There's no silicon based solution for a carbon based problem".

Es gibt mehrere Möglichkeiten, so eine Authenticator App zu benutzen - z.B. kann man sich einen Zahlencode erzeugen lassen. Das ist dann das gleiche wie ein Hardware-Token ... nur eben in Software. Oder man lässt den Authentifizierungsprovider (MS) beim Smartphone anfragen, ob eine gerade anstehende Autorisierung genehmigt werden soll. Das ist etwas komfortabler, da man auf dem Phone nur noch - nach Entsperrung (gegebenenfalls mit Fingerabdruck) - bestätigen muss. Aber das Smartphone verbindet sich nicht mit dem Firmennetz. Aber wenn's sooo spezielle Anforderungen gibt, isses dann vielleicht nix für Euch.

Du kannst die MS Authenticator App (oder auch viele andere Authenticator Apps) verwenden. Da wäre dann - ein entsprechendes Smartphone vorausgesetzt - die Biometrie auch gleich dabei. ... funktioniert sehr gut. PS: Das Handy geben wohl noch die wenigsten einfach aus der Hand.

Geänderte Ausgangsbedingungen haben natürlich eine andere Bewertung zur Folge. Aber von mehr als einem Gerät war bisher in diesem Thread noch nicht die Rede.

... und ... funktioniert das gut? Ich würde erwarten, dass Anwender, die kein Problem damit haben, ihren Account weiterzugeben, auch kein Problem damit haben, diese Weitergabe aktuell zu halten - also das neue Passwort auch wieder weiterzugeben.

Parameter -SearchScope. Bitte die Hilfe benutzen! Get-Help Get-ADUser -Full Get-ADUser

Du präferierst also für ein einzelnes Gerät in Deiner Infrastruktur eine "Sonderlocke"? Obwohl Du es auch mit einem normalen W10-Client, z.B. ein Mini-PC wie ein NUC, machen könntest? Ich vermute mal, dass Du für die Windows-Geräte eine Strategie hast, sie auf dem Laufenden zu halten und zu pflegen und zu warten usw.. Du kennst Dich einigermaßen damit aus und kannst auch vermutlich Probleme beseitigen, die evtl. auftreten. Jetzt möchtest Du diese Vorteile über Bord werfen für eine OpenSource-Lösung, mit der Du keine Erfahrung hast, die Du separat patchen musst und bei der Du, falls es mal Probleme gibt, nicht auf Deine Erfahrung zurückgreifen kannst. Und Du kannst sie im Zweifel auch nicht mal schnell gegen ein Ersatzgerät austauschen, weil Du nur dieses eine hast. Und das im Zweifel in einer Situation, in der Kunden im Meeting-Raum sitzen und ein Kollege etwas präsentieren möchte - es also eilt. .... Du hast meinen Respekt - das finde ich eine sehr tapfere Einstellung.

Das hängt am Ende des Tages ja immer davon ab, wem Du damit Deine Befähigung nachweisen möchtest. Wenn derjenige es als Befähigungsnachweis akzeptiert, hast Du gewonnen.

Da gibt es noch eine weitere Option, die Du bisher offenbar nicht mal in Betracht ziehst. Welche bessere Gelegenheit kann es geben, ein System abzuschaffen, das die Aufgabe, für die es erdacht wurde, sowieso nicht zuverlässig erfüllt und dazu auch noch mehr Arbeit macht als es spart. Die Empfehlung, Passwörter regelmäßig zu wechseln, haben wir dem NIST zu verdanken. Und sie stammt aus der Computer-Steinzeit. Alle weiteren Empfehlung, incl. der des BSI, basierten im Prinzip darauf. ABER, und das ist ein riesen aber - angefangen mit dem NIST, haben alle relevanten Institutionen inzwischen diese Empfehlung widerrufen. Das NIST, BSI, die englische CESG, ja selbst Microsoft empfehlen inzwischen, die Passwort-Alterung zu deaktivieren, weil sie die Sicherheit nicht erhöht sondern verringert. Wenn Du dafür "Futter" für Deine Chefs oder die Administratoren oder den CSO oder CIO brauchst, brauchst Du nur danach zu suchen - Du wirst sehr schnell fündig werden. (Ich könnte auch nochmal auf die Suche gehen, wenn Dir das hilft. Also, statt wahnsinnig große Umstände zu veranstalten, die User dazu zu bewegen, ihr Passwort regelmäßig zu ändern, solltet ihr die User schulen, ein sicheres Passwort zu wählen, welches sie so lange behalten können, bis es den begründeten Verdacht gibt, dass dieses spezielle Passwort kompromittiert wurde.

So lange Dein Arbeitgeber keinen Wert drauf legt und Du Dich nicht verändern möchtest, geht's wohl auch ohne. Wenn aber z.B. firmenintern ein Benefit daran hängt, oder Du für einen zukünftigen Arbeitgeber nachweisen möchtest, dass Du entsprechende Kenntnisse erworben hast, macht's wohl Sinn, denke ich.

Bei uns heisst die Powershell Property mobile bzw. mobilePhone. Pick Dir doch einfach einen User raus und lass Dir ALLE Properties anzeigen. So bekommst Du den richtigen Namen raus. Also Get-ADUser -Identity <sAMAccountName des einzelnen Users> -Properties * In der produktiven Abfrage solltest Du übrigens nicht -Properties * benutzen, sondern -Properties cn,otherMobile,mobile,telephoneNumber. Also nur die Attribute, die Du brauchst. Die Properties in Powershell heißen nicht zwingend genau so wie die Attribute im AD. Teilweise gibt es nicht mal entsprechende Attribute im AD, sondern das cmdlet Get-ADUser baut im Hintergrund noch was für Dich zusammen.

Kann sein, dass ich jetzt Unsinn rede, aber wenn Du noch ausrangierte PCs hast, die Du dafür verwenden könntest, würden die denn so intensiv genutzt werden, dass sich der Energie-Mehrverbrauch gegenüber einem Thin-Client so stark auswirkt, dass dabei die Kosten für einen extra Thin-Client rausspringen? Nimm doch einfach den alten Windows-PC. Der braucht ja nicht wirklich viel zu leisten.

Powershell 7 ist noch nicht wirklich "production ready", auch wenn Microsoft das gern anders darstellt. PSSnapins sind eigentlich schon seit v3.0 deprecated, werden aber noch als Legacy Support bis v5.1 unterstützt. v5.1 wird auch nach bisherigen Stand zwar nicht weiterentwickelt, aber bis auf unbestimmte Zeit von MS weiter unterstützt werden. Für aktuelle Versionen von Exchange gibt es die Erweiterung als Modul. Wenn Du aber z.B. aufwändige Skripte erstellt hast, die auf die Snapins angewiesen sind, spricht nichts dagegen, die Windows Powershell und die Snapins weiterzubenutzen. Legacy Support. Mehr braucht's doch nicht. MS supported ja gern mal die ein oder andere Technologie länger als man sich's wünschen mag.

Nee, siehste, das is mir glatt durchgerutscht. Gut, dass Du nochma rübergeguckt hast.

Cool. Ein Fehler weniger. Du erzeugst Dein "Menü" mit Write-Host. Damit ist das Menü vom eigentlichen Code völlig unabhängig. Das sind nur Pixel auf Deinem Bildschirm ohne weitere Funktion. Wichtig ist der Code, den Du benutzt, um die Eingabe des Benutzers auszuwerten. Davon hast Du aber bisher nur ein paar lose miteinander verbundene Schnipsel gezeigt. Damit kann ich leider nicht wirklich sehen, was Du in Deinem Code machst. Aber nicht, wenn Du das switch-Statement bereits einmal erfolgreich durchlaufen hast. Dafür müsstest Du die Auswahl erneut erhalten - also das switch-Statement erneut ausführen - mit einer Schleife zum Beispiel. ... es sei denn, ich habe Dich falsch verstanden. ... kommt immer mal wieder vor ... Vielleicht machst Du Dir einfach mal ein MockUp. Also ein Script-Gerüst, welches den Script-Ablauf zeigt, ohne die eigentlichen Funktionen auszuführen. So könntest Du die Menü-Struktur testen, ohne den Balast des Codes der Funktionen mitzuschleppen. Das macht es manchmal einfacher. Dann hast Du in Deinen externen Scripten irgendwo einen logischen Fehler. Hast Du eventuell im der Script-Datei mit der Funktionsdefinition für MyBenutzer, die Funktion MyBenutzer direkt aufgerufen? Edit: Hier mal ne kleine Demo: $Menu = @' Hauptmenue ================================================== 1 : Benutzerverwaltung 2 : Gruppenverwaltung -------------------------------------------------- 0 : zurück ================================================== '@ Clear-Host Write-Host $Menu function show-input { param ( $BenutzerEingabe ) "`n `t$BenutzerEingabe`n " } $Eingabe = Read-Host -Prompt "Bitte Zahl zwischen 1 und 5 eingeben " switch ($Eingabe) { 1 { show-input -BenutzerEingabe "Du hast wohl ne '1' eingegeben " } 2 { show-input -BenutzerEingabe "Du hast wohl ne '2' eingegeben " } 3 { show-input -BenutzerEingabe "Du hast wohl ne '3' eingegeben " } 4 { show-input -BenutzerEingabe "Du hast wohl ne '4' eingegeben " } 5 { show-input -BenutzerEingabe "Du hast wohl ne '5' eingegeben " } Default { show-input -BenutzerEingabe "Das muss irgendwas Anderes als 1 bis 5 gewesen sein!" } } } Nachdem Du etwas Beliebiges an der Eingabeaufforderung eingegeben hast, wird das switch-Statement genau 1 mal durchlaufen und dann beendet.

... und es sollte natürlich auch nicht heißen, dass Du hier nicht mehr fragen darfst ... auch zu diesem Thema/Script - jederzeit - dafür sind wir alle hier. Es macht uns ja auch selber Spaß

OK. Als erstes hast Du ihn Deinem MyMain einen Klammerfehler im switch-Statement. Das sollte so aussehen: Function MyMain { #Hauptmenue cls Write-Host Write-Host "Hauptmenue" Write-Host "==================================================" Write-Host "1":" Benutzerverwaltung" Write-Host "2":" Gruppenverwaltung" Write-Host "--------------------------------------------------" Write-Host "0":" EXIT" Write-Host "==================================================" $input = Read-Host "Auswahl" Switch ($input) { 0 { exit } 1 { . $m_benutzer MyBenutzer } 2 { . $m_gruppen MyGruppen } 3 { MyMain } DEFAULT { exit } } } MyMain Darf ich fragen, welchen Code-Editor Du benutzt? Sowohl die Powershell_ISE als auch VSCode würden diesen Syntaxfehler entsprechend markieren. ... oder ist das nur ein Copy-&-Paste-Fehler hier im Forum? Jetzt wo die Klammern stimmen, solltest Du, auch wenn es vielleicht im Moment funktioniert, dringend die Variable $Input ändern. $Input ist eine für Powershell reservierte Variable, die nicht für eigene Zwecke benutzt/missbraucht werden sollte, Hmm ... das switch-Statement wird von oben nach unten abgearbeitet. Wenn Du die Option 1 wählst, bist Du über die 0 schon drüber. Das kann also nicht funktionieren. ... und der Default-Zweig wird nur ausgeführt, wenn keine der zur Verfügung stehenden Optionen passt. Wenn Du immer wieder in Dein Hauptmenü zurück möchtest, wirst Du eine while oder do Schleife benutzen müssen. Es macht übrigens nicht wirklich viel Sinn, die "extenen" Scripte erst mittels dot-Sourcing in Dein Hauptscript einzubinden, wenn der entsprechende Menüeintrag gewählt wird. Einfacher wäre es, wenn Du am Anfang Deines Scriptes einfach mittels: Get-ChildItem $PSScriptRoot -Filter *.ps1 | ForEach-Object { . $_.FullName } alle weiteren Funktionen in den Scope Deines Hauptscriptes importiertest. Somit brauchst Du im Code nur noch mit den Funktionsnamen zu arbeiten. Damit wären wir beim nächsten Thema: Funktionsnamen. Wenn Du irgendwann mal Deine Scripte in Module umwandelst und diese vielleicht auch an Kollegen weitergeben möchtest, empfiehlt es sich, besonders für Funktionen, die direkt aufgerufen werden sollen, die gleiche Schreibweise zu benutzen, wie bei den eingebauten cmdlets - also <Verb>-<Nomen>. Das macht im Zweifel ihre Funktion direkt erkennbar und erleichtert das Verstehen und Debuggen. Empfehlenswerte Lektüre dazu ist The Unofficial PowerShell Best Practices and Style Guide.