BOfH_666

Ich weiß, es klingt ketzerisch, aber bist Du denn mal der Empfehlung in der Fehlermeldung gefolgt? https://support.microsoft.com/de-de/help/2983588/event-id-158-is-logged-for-identical-disk-guids

Du führst das Script aus, aber versorgst es quasi nicht mit den nötigen Eingaben. Das kann so nicht funktionieren. Bitte - das hier führt zu nix, wenn Du nicht VORHER die Grundlagen von Scripting/Programmierung im Allgemeinen und von Powershell im Speziellen gelernt hast. Wir können Dir hier nicht Schritt für Schritt beibringen, wie man Scripte programmiert. Du hast offensichtlich noch nicht verstanden, was Variablen sind und wofür und wie man sie benutzt. Bitte jetzt erstmal ein Buch lesen oder einen Video-Kurs anschauen oder sowas.

Jetzt weiß ich nicht, wovon Du genau sprichst. Ich meinte weiter oben, dass Du, wenn hier im Forum Code postest, diesen als Code formatieren solltest. Dadurch wird der Code so angezeigt, wie er auch in einer Entwicklungsumgebung oder in Notepad angezeigt werden würde. Also im Prinzip ohne jegliche Formatierung und ohne Zeilenumbrüche und so weiter. Das ist für Powershell völlig egal. Du kannst sowohl beim Export als auch beim Import das Trennzeichen mit dem Parameter -Delimiter angeben. ... und hier solltest Du jetzt den Code zeigen, den Du benutzt hast. Die Zeile, die ich jetzt im Hinterkopf habe, die mit der Variablen $ComputerList zu tun hat, würde eine CSV-Datei einlesen - nicht schreiben. Ich empfehle Dir dringendst, Dir als Erstes die Grundlagen der Powershell anzueignen. Sonst wird es Dir schwer fallen, die Hilfen zu verstehen, die Du hier bekommst. Du hast offenbar die Grundprinzipien noch nicht verstanden. Wenn Du mit gefährlichem Halbwissen an produktiven Server operierst, kannst Du ne Menge kaputt machen. Also wenn Du testest, solltest Du das ausschließlich in einer Test-Umgebung tun. Du solltest niemals Code ausführen, den Du nicht verstehst. Mir ist grad aufgefallen, dass ich oben im Code einen bösen Schnitzer eingebaut habe, sorry ... passiert auch erfahrenen Leuten mal ... hier also nochmal der korrigierte Code: $computerlist = Import-Csv -Path 'c:\Temp\Server.csv' -Header 'ComputerName' $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

Hmmm ... dann ist die Aufgabe hier wohl Deine Hausaufgabe, oder? Die Variablennamen haben eine Bedeutung. Die Variable, die ich im Code mit der ersten Zeile definiere, benutze ich in der nächsten Zeile gleich wieder sozusagen als Input. Du erzeugst eine Variable - zwar mit der richtigen Befehllszeile - aber Du benutzt sie dann nicht. Ergänze einfach den Parameter -Header mit dem Wert "ComputerName" bei meiner Variablenzuweisung für $Computerlist lass Deine zusätzliche Zeile weg. Dann läuft's. Du könntest auch einfach die Header-Zeile in Deiner CSV-Datei ergänzen - das kommt dann auf's Gleiche raus. Und Du solltest Dir die Grundlagen von Powershell aneignen. Wenn Du vorhast noch ne Weile in Windows-System-Umgebungen unterwegs zu sein, wird sich das mit Sicherheit für Dich lohnen. So'n Quatsch. Wir haben 2020!! Solche Dinosaurier-Ressentiments gehören ins letzte Jahrtausend!! Geeks und Nerds benutzen einfach das, was sie ihnen am besten gefällt. So!

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.