BOfH_666

Das wird häufiger gefragt. Die Office-Programme wie Word oder Excel setzen eine interaktive Session voraus. Das wirst Du so nicht zuverlässig automatisiert bekommen.

... sonderlich effizient ist das aber nicht. Du suchst für jede einzelne Zeile in der Eingabe-Datei wieder und wieder das gesamte Verzeichnis ab. Wenn die Datei und auch das abzusuchende Verzeichnis deutlich größer werden, sollte man sich eine effizientere Strategie überlegen. z.B. könntest Du mit Get-ChildItem die komplette Liste der Dateien im Verzeichnis erstellen und diese dann mit der Liste an Dateinamen vergleichen.

Versuch ma das hier: $dateiInhalt = Get-content $env:USERPROFILE\Desktop\such_nach.txt $Result = foreach ($DateiName in $dateiInhalt) { Get-ChildItem -Path "D:\daten\*" -Recurse | Where-Object { $_.Name -like "$DateiName*" } | Select-Object FullName } $Result | Export-Csv -Path $home\desktop\ergebnis.csv -NoTypeInformation

Was ist denn der Inhalt der Datei "such_nach.txt"? Sollten es mehrere Zeilen mit jeweils einem Dateinamen sein, dann brauchst Du eine Schleife.

Es ist möglich (wahrscheinlich), dass Du in der Variable $datei etwas mehr drin hast, als Du denkst ... z.B. mehrere Zeilen oder wenigstens einen Zeilenumbruch. Was bekommst Du denn angezeigt, wenn Du Dir $datei.count ausgeben läßt?

Hast Du schon mal danach gesucht? Ich hab mal für Dich gesucht .... Monitoring Folders for File Changes. Wenn ich Dich nicht falsch verstanden habe, solltest Du damit ziemlich weit kommen.

Das ist mit der letzten Kommandozeile, die ich gepostet habe - die mit dem "$a=foreach..." vorne dran, technisch unmöglich. Natürlich macht es nur Sinn, wenn Du die Grundlagen von Powershell verstanden hast und nicht bei jeder Kleinigkeit andere fragen musst. Das ist genau wie bei anderen komplexen Technologien. Sie erschließen sich nicht, nachdem man ein paar Zeilen Code von anderen Leute kopiert und ausprobiert hat. Ein bissl mehr gehört eben schon dazu. stimmt ... na das Prinzip hab ich ja dann auch schon erklärt. Wenn das funktioniert, können wir ja nochmal über die genaue "Form" sprechen. Oder vielleicht kommst Du ja schon selber drauf. Ich hatte ja schon erklärt, welche Ausgabe bei welchen Bedingungen erzeugt werden. Das kann man natürlich den eigenen Anforderungen anpassen. Wie schon mehrfach erklärt ... den richtigen Code nehmen, dann klappt das.

Wieso einfügen? Entweder Du nimmst das ausführliche Script, oder die komplette Zeile, die ich zuletzt gepostet hatte. Das hast Du wohl vergessen zu erwähnen. Das macht mich dann aber schon ein wenig stutzig. Welche Entscheidung wird denn von wem auf Grund dieser Information getroffen? Der letzte Einzeiler, den ich gepostet hatte, erzeugt eine Variable "$a", die Liste mit den Informationen enthält, welche Rechner erreichbar waren und welche dann auch noch die Datei hatten. Mit $a | Where-Object -Property File -EQ -Value $true filterst Du alle Rechner aus, die nicht erreichbar waren oder die Datei nicht hatten. Mit $a | Where-Object -Property File -EQ -Value $false könntest Du alles rausfiltern, was nicht erreichbar war und was die Datei hatte und mit $a | Where-Object -Property File -EQ -Value 'n/a' gibst Du nur noch die Adressen aus, die nicht erreichbar waren. Wenn Du unbedingt willst, kannst Du die Ausgabe aber natürlich noch mit jeder Menge Prosa anreichern, was den Informationsgehalt aber auch nicht wirklich erhöht. Edit: Achja ... ganz vergessen ... mit $a | Export-Csv -Path D:\sample\liste.csv -Delimiter ';' -NoTypeInformation exportierst Du die Liste in eine CSV-Datei mit dem Trennzeichen "Semikolon". Ein deutsches Excel erkennt diese also auch als CSV und zeigt sie ansatzweise vernünftig an.

Die Faszination für Einzeiler hab ich irgendwie noch nie verstanden. hmmmm ... Du meinst also, dass sowas hier eingängiger und leichter verständlich ist? ping -n 1 %NET%.%%f | findstr /i "TTL" >nul 2>&1 && ( Hmmm .... da werden wir wohl unterschiedlicher Meinung bleiben. Aber CMD/Batch musstest Du doch auch irgendwann mal gelernt haben ... oder konntest Du das einfach irgendwann einfach so? Das kommt auf Deine Aufgabe drauf an. Wenn Du z.B. ein AD abfragen möchtest, ist es mit einem entsprechenden Modul einfacher. Dafür gibt es aber auch Lösungen. Hmmm ... Du kannst mit dem Ergebnis nix anfangen. ... Wenn man CMD/Batch gewöhnt ist - quasi eine Hohepriesterin der kryptischen Eigenheiten - wird man wohl Powershell auch die ein oder andere kleine Schrulligkeit durchgehen lassen müssen, oder? Um die Kommandozeile zu verkürzen, habe ich die Eigenschaftsnamen (IP, File) sehr kurz gewählt. Und Powershell ist immer bemüht Platz zu sparen, also schneidet es ab einer gewissen Länge, die ausgegebenen Werte auf der Konsole ab. Aber eben auch nur auf der Konsole. Die eigentlichen Werte sind noch da. Und auch dagegen ist natürlich ein Kraut gewachsen. $a=foreach($i in (2..254)){[PSCustomObject]@{IP="192.168.178.$i";File=If(Test-Connection "192.168.178.$i" -Cou 1 -Q){Test-Path "\\192.168.178.$i\c$\Program Files (x86)\Prg\aktvers.txt"}else{'n/a'}}};$a|ft -a

... na da können wir doch auch helfen .... 2..254 | ForEach-Object { $IPAddress = "192.168.178.$_" $TargetPath = "\\$IPAddress\c$\Program Files (x86)\Prg\aktvers.txt" [PSCustomObject]@{ IPAddress = $IPAddress FileExists = If (Test-Connection -ComputerName $IPAddress -Count 1 -Quiet) { Test-Path -Path $TargetPath } else { 'n/a' } } } Es sind zwar keine Zeilennummern dran, aber bei 9 oder eigentlich nur 7 Zeilen Code, wählen wir einfach mal manuell ... In Zeile 1 wird eine Liste von Elementen erzeugt, die die Zahlen 2 bis 254 enthält. Danach wird mittels der pipe ein Element nach dem anderen an das nächste cmdlet weitergeleitet. In Zeile 2 wird eine Schleife erzeugt, die für jedes einzelne Element aus der Pipeline die gleichen Befehle abarbeitet. Also alle Befehle, die innerhalb der geschweiften Klammern stehen. In Zeile 3 wird aus einer Vorlage mit den ersten 3 Oktetts und der aus der pipe entnommenen Zahl eine IP-Adresse gebildet und diese in einer Variable gespeichert. In Zeile 4 wird mit dieser Variablen und dem Rest eines UNC-Pfades der Zielpfad der gewünschten Datei zusammengebaut und in einer Variablen gespeichert. (Zeile 3 und 4 sind prinzipiell zwar nicht nötig, dienen aber hier ein wenig der Lesbarkeit.) Zeile 5 enthält die Deklaration eines Ausgabe-Objects mit den in den folgenden Zeilen definierten Eigenschaften. Zeile 6 definiert die Eigenschaft "IPAddress" und weißt ihr den Wert der Variablen "$IPAddress" zu. Zeile 7 definiert die Eigenschaft "FileExist" und weißt ihr das Ergebnis einer geschachtelten Abfrage zu. Zeile 8 und 9 sind die schließenden Klammern für das Object und die Schleife. Die geschachtelte Abfrage in Zeile 7 testet innerhalb der Bedingung, die durch das "if"-Schlüsselwort definiert wird, ob der Zielcomputer erreichbar ist - also quasi ein Ping. Ist das der Fall prüft der nächste Befehl innerhalb des Scriptblocks, ob die Datei deren Pfad in der Variablen "$TargetPath" gespeichert ist, vorhanden ist. Ist sie das, wird ein "$True" zurückgegeben. Ist sie das nicht, kommt ein "$false". Sollte die Prüfung auf Erreichbarkeit der IP-Adresse fehlschlagen, wird der zweite kleine Scriptblock ausgeführt und einfach ein "n/a" ausgegeben. Wenn man ein wenig englisch spricht, könnte man sich den größten Teil dieser Erklärung eigentlich schon selbst zusammengereimt haben. Powershell-cmdlet sind meist deutlich "beschreibender" als die Befehle anderer Script-Sprachen. Test-Connection oder Test-Path sind ziemlich unzweideutig, wie ich finde. Wenn Du beruflich in Windows-System-Umgebungen unterwegs bist und das auch noch ne Weile tun möchtest, glaube ich, dass Du Dir mit dem Erlernen von Powershell auf jeden Fall das Leben ein wenig erleichtern würdest und dass es sich für Dich auszahlt. Das eigentlich clevere an Powershell ist, dass Du das Ergebnis des obigen Scriptes sehr einfach weiterverarbeiten kannst, da es sich um Objekte mit Eigenschaften handelt. Du kannst es z.B. filtern und nur noch die IP-Adressen ausgeben, die erreichbar waren, oder nur noch die, die erreichbar waren und die Datei nicht vorhanden war. Oder Du könntest das Ergebnis z.B. mit einem einzigen Befehl in eine CSV-Datei schreiben. Edit: ... und nur weils auch mal Spaß macht ... wenn man es unbedingt schlecht lesbar und ein bssil kryptisch haben möchte, weil das vielleicht die etwas unbedarften Kollegen mehr beeindruckt, kann man mit Powershell auch das machen: foreach($i in (2..254)){[PSCustomObject]@{IP="192.168.178.$i";File=If(Test-Connection "192.168.178.$i" -Cou 1 -Q){Test-Path "\\192.168.178.$i\c$\Program Files (x86)\Prg\aktvers.txt"}else{'n/a'}}} Diese eine Zeile tut im Wesentlichen das Gleiche.

... nur als Hinweis: für den Code-Schnipsel, den ich gepostet hatte, brauchst Du keine RSAT. Es wird auch nur das Netzsegment gescannt und geprüft, ob die Datei auf dem Zielcomputer verfügbar ist oder nicht.

Dann fehlen Dir wohl die AD-cmdlets, die mit den RSAT-Tools installiert werden. Entweder nachinstallieren oder andere cmdlets benutzen. Der Code von Jan ermittelt einfach die abzufragenden Computer mit einer AD-Abfrage. Ich hab zwar keine Ahnung von CMD/Batch aber wenn ich Deinen Code korrekt interpretiere, dann scannst Du ein ganzes Netzsegment. Wenn Deine Netzwerker da nicht Alarm schlagen, kannst Du sowas auch mit Powershell machen. Quick&Dirty könntest Du so ungefähr anfangen 1..255 | ForEach-Object{ $TargetPath = "\\192.168.178.$_\c$\Program Files (x86)\Prg\aktvers.txt" [PSCustomObject]@{ IPAddress = "192.168.178.$_" FileExists = Test-Path -Path $TargetPath } }

Nein. Wenn Du Dir Deine UNC-Pfade passend zusammenbaust, kannst Du auch direkt mit Test-Path prüfen, ob ein Pfad oder eine Datei vorhanden ist. Dann kannst Du sie mit Get-Content auslesen und den Inhalt entsprechend weiterverarbeiten. Selbst mit wenig Ahnung solltest Du Dir nach der Lektüre der Hilfe für die cmdlets und dem Studium der enthaltenen Beispiele, sehr leicht was Einfaches zusammenbauen können. Und wenn Du mit Powershell nicht weiterkommst, bekommst Du hier und überall ohne Probleme eine Menge Hilfe.

... nur so'ne Idee ... vielleicht schilderst Du den Fireboard-Machern Dein sehr spezielles Problem einfach mal. Ich könnte mir vorstellen, dass die mit ihrer Erfahrung sowas eventuell schneller und professioneller in ihr Produkt integrieren könnten als Du es "from scratch" hinbekommst. Und es wäre vielleicht ein Feature mehr, welches die Software wieder attraktiver macht. Es wäre also vielleicht eine Win-Win-Situation für beide Seiten.

... mal versucht, alle Netzwerkverbindungen während der Anmeldung zu trennen? ... also WLAN aus oder Stecker ziehen, falls mit Kabel ...

Man kann auch mehrere unzusammenhängende OUs in einer Liste kombinieren, wenn man möchte ... $SearchBaseList = 'OU=Germany,DC=contoso,DC=de', 'OU=Switzerland,DC=contoso,DC=de' $Properties = 'Name', 'IPv4Address', 'OperatingSystem', 'OperatingSystemVersion' $Result = foreach ($SearchBase in $SearchBaseList) { $GetADComputerParams = @{ Filter = "ObjectCategory -like 'CN=Computers'" SearchBase = $SearchBase Properties = $Properties } Get-ADComputer @GetADComputerParams | Select-Object -Property $Properties } $Result | Format-Table -AutoSize Dann hat man alle Computer in einer Liste und kann diese Liste ganz nach Belieben wieder filtern, wenn nötig.

... klingt doch gut. Wenn Du irgendwo stecken bleibst, meldest Du Dich einfach wieder und dann sehen wir weiter.

... ich hab grad kein SCCM zur Hand, aber normalerweise kann SCCM ja ganz gut mit Powershell z.B. ... oder wo liegen da Deine Bedenken?

Auch wenn ich die Frage nicht so ganz verstanden habe - wenn man die Neustarts mittels eines Skriptes auslöst, könnte man im Skript abfragen, wann der letzte Neustart war. Wenn das z.B. mindestens 6 Tage her ist, kann man den Neustart auslösen - sonst nicht. Somit wird nicht versehentlich am gleichen Tag mehrmals neu gestartet.

Das Powershell-Skript enthält 3 Zeilen Code - genau genommen eigentlich nur 2. Wie wär's wenn Du versuchst zu verstehen, was diese 2 Zeilen tun und wenn Du es verstanden hast, es einfach so anpasst, dass es für Dich passt?

.... würde es sehr schmerzen, es einfach mal zu probieren? Davon unabhängig: Sowohl Powershell v2.0 als auch die Quest-Cmdlets werden nicht mehr supported.

Ah .... ok ... da hatte ich die Ursprungsfrage mis-interpretiert ... alles klar.

Haben *.ps1-Dateien nicht sowieso im Standard den Kontext-Menü-Eintrag "Mit Powershell ausführen"? Bei mir ist das jedenfalls so.

... über den Schnipsel hatte ich glatt drübergelesen ... aber Du hast Recht ... das dürfte ein verkorster Powershell-Versuch sein.

Wie kommst Du auf Powershell? ... ich glaub mit Powershell hätten wir das Thema schon lange erfolgreich abgeschlossen.