BOfH_666

Du hast die Funktionsdefinition in das Profil für die Powershell_ISE eingefügt. Führst Du das Script denn in der ISE aus? Wenn nicht, dann ist die Funktionsdefinition dort überflüssig. Wenn Du die Funktion nicht noch irgendwo anders brauchst, ist es vermutlich direkt im Skript am Besten aufgehoben. Oder Du speicherst den Code in einem separaten Skript. Nehmen wir mal an, Du nennst die Datei mit der Funktionsdefinition genauso wie die Funktion und speicherst sie im gleichen Verzeichnis wie das eigentliche Skript. Dann kannst Du am Anfang des eigentlichen Skriptes, das Skript mit der Funktionsdefinition mittels "dot-Sourcing" importieren - also so ungefähr: . .\Start-ProcessWithTimeout.ps1 $ToolPath = 'C:\Users\Alex\Desktop\Tools\pdftest\pdfinfo.exe' $DefectFilesPath = 'N:\CutFolders' Get-ChildItem -Path 'N:\rec\Verloren\Dokumente\pdf' -Filter *.pdf | ForEach-Object{ $PDFFilePath = $PSItem.FullName # hier wird der komplette Pfad zur PDF-Datei innerhalb der switch-Anweisung nutzbar gemacht $Result = Start-ProcessWithTimeout -FilePath $ToolPath -ArgumentList $PSItem.FullName # -Timeout 20 # anpassen falls nötig If($Result.State -eq 'Completed' -and $Result.HasMoreData){ switch ($Result.Result) { {$Result.Result -match 'Usage:\s+pdfinfo'} { "PDF-Tool SyntaxError - $PDFFilePath"; break } {$Result.Result -match 'find\s+trailer\s+dictionary'} { Move-Item -Path $PDFFilePath -Destination $DefectFilesPath; break } {$Result.Result -match 'PDF\s+version:'} { "PDF file is valid - $PDFFilePath"; break } } } Else{ "PDF-Tool stuck ... - $PDFFilePath" } } Wenn Du das Skript mit der Funktionsdefinition irgendwo anders speicherst, solltest Du den kompletten Pfad zu diesem Skript angeben, statt nur ".\". Hier die Hilfe für about_Scripts. Lies Dir das am Besten mal alles durch und achte besonders auf das Kapitel "SCRIPT SCOPE AND DOT SOURCING".

Hmmm ... also ich bin unschlüssig, ob und wie ich Dir antworten kann, weil ich nicht weiß, worauf sich Deine Antwort bezieht und was Du genau meinst. Meinst Du Send-MailMessage? Wenn "ja", kann ich Dir nur zustimmen. Ich gehe jetzt im Weiteren einfach mal davon aus, dass Du Send-MailMessage meintest ... Du kannst mehrere Empfänger einfach als Komma-separierte Liste übergeben, so wie das in Beispiel 2 der Online-Hilfe zu sehen ist. Send-MailMessage ist nicht für Massenmailings gemacht. Wenn Du Mails an hunderte Empfänger gleichzeitig schicken möchtest, gibt es vermutlich geeignetere Tools. Um wieviele Empfänger geht es denn? Um Deinen Code übersichtlicher zu gestallten, gibt es zahlreiche Möglichkeiten der Formatierung. Eine davon ist z.B. Splatting. Klar ... mit Import-Csv kannst Du die Daten einlesen und dann nach Belieben weiterverarbeiten. Der Code-Schnipsel, den Du gepostest hast ... hast Du dazu ne Frage? ... oder wofür ist der da?

Gibt es einen bestimmten Grund, warum Du nicht einfach Send-MailMessage benutzt?

Das mit den Laufwerksbuchstaben ist immer so eine Geschichte ... gerade für USB-Sticks oder externe Festplatten wechseln die Buchstaben gern mal, wenn man mehr als einen benutzt. Man kann (schon seit Windows XP, wenn ich mich nicht irre) externe/Wechsel-Laufwerke in einem leeren NTFS-Ordner bereitstellen. Ich hab mir z.B. ein Verzeichnis C:\USB erstellt, und darin dann jeweils für jeden USB-Stick oder jede externe USB-Festplatte ein eigenes Verzeichnis mit "sprechendem" Namen. Dann kann man sich die Ermittlung des Laufwerksbuchstabens sparen. Wenn der Stick angeschlossen ist, ist er immer unter dem gleichen Namen erreichbar. Dann würde z.B. eine Kommandozeile wie diese hier ausreichen: robocopy <Quell-Verzeichnis> C:\USB\IntensoGruen8GB *.txt /E Dann könnten sogar mehrere USB-Sticks oder Festplatten gleichzeitig angeschlossen sein, ohne dass sie sich in die Quere kommen.

Ja ... das solltest Du für Dich anpassen, wie es am besten passt. Ich hatte nur einen sehr kleinen Pool an PDF-Dateien zum Testen und hatte mir nur 2 defekte PDFs gebastelt. Ich kann's im Moment nicht verifizieren, aber innerhalb des switch - Blocks verweist $PSItem auf das zu testende "switch-Element" ... deshalb die extra Variable. Das kannst Du machen, wie Du möchtest. Die Funktion muss eben spätestens wenn Du sie aufrufen möchtest definiert sein. Du könntest sie in einer extra Datei speichern, die Du am Anfang Deines Scriptes mittels Dot-Sourcing einbindest. Oder Du packst die Funktion direkt mit in die Script-Datei. Oder Du packst sie mit ins Profil des Users oder PCs, wo das Script ausgeführt werden soll. Oder, oder, oder ...

So ... jetzt ich nochmal. Ich hab nochmal gründlich über die Aufgabenstellung und die von Dir geschilderten Probleme nachgedacht und hab versucht, das Ganze in kleinere Teile zu zerlegen. Da das PDFInfo-Tool bei Dir offenbar ziemlich instabil läuft - ich kann das auf meinem Computer nicht nachstellen - bräuchtest Du wohl als erstes eine Funktion, die das Tool starten kann, deren Ausführung überwachen und, wenn sich das Tool dann eben doch aufgehängt hat, das Tool beendet und Dir die Möglichkeit bietet, diesen Status zu erkennen und trotzdem weiterzumachen. Danach musst Du die Ausgabe des Tools auswerten. Wenn die Ausgabe einen entsprechenden Fehler enthält, wird die gerade verarbeitete Datei ignoriert. Wenn die Ausgabe die erwartete Information enthält, wird die Datei kopiert. Also hier meine Idee zur Funktion, die das Tool in einem Hintergrund-Job startet und dann eine einstellbare Zeit wartet, dass das Tool sich von selbst beendet und eine Ausgabe liefert: function Start-ProcessWithTimeout { [CmdletBinding()] [OutputType([System.String])] param( [Parameter(Position = 0, Mandatory = $true)] [ValidateNotNullOrEmpty()] [System.String] $FilePath, [Parameter(Position = 1)] [ValidateNotNull()] [System.String[]] $ArgumentList, [Parameter(Position = 2)] [ValidateNotNull()] [System.Int32] $Timeout = 10 ) $SBFilePath = $FilePath $SBArgumentList = $ArgumentList $ScriptBlock = { param( $SBFilePath, $SBArgumentList ) $TmpStdOut = New-TemporaryFile $TmpStdErr = New-TemporaryFile Start-Process -FilePath $SBFilePath -ArgumentList $SBArgumentList -NoNewWindow -RedirectStandardError $TmpStdErr -RedirectStandardOutput $TmpStdOut -Wait $StdErr = Get-Content -Path $TmpStdErr.FullName $StdOut = Get-Content -Path $TmpStdOut.FullName Remove-Item -Path $TmpStdErr -Force Remove-Item -Path $TmpStdOut -Force $StdErr $StdOut } $JobProps = @{ Name = 'BackGroundJob' ScriptBlock = $ScriptBlock } [VOID](Start-Job @JobProps -ArgumentList $SBFilePath, $SBArgumentList ) $StartTime = Get-Date do { $JobState = Get-Job -Name BackGroundJob Write-Debug "JobState: $($JobState.State) - HasMOreData: $($JobState.HasMoreData)" if ($JobState.State -eq 'Completed') { $HasMoreData = $JobState.HasMoreData if ($JobState.HasMoreData) { $Result = Receive-Job -Name BackGroundJob Remove-Job -Name BackGroundJob break } } else { Start-Sleep -Milliseconds 50 } } while ((Get-Date) -lt $StartTime.AddSeconds($Timeout)) if (Get-Job -Name BackGroundJob -ErrorAction SilentlyContinue) { Stop-Job -Name BackGroundJob Remove-Job -Name BackGroundJob -Force } [PSCustomObject]@{ State = $JobState.State HasMoreData = $HasMoreData Runtime = New-TimeSpan -Start $JobState.PSBeginTime -End $JobState.PSEndTime Result = $Result } } Leider gibt es noch ein Problem, wenn die Datei oder der Pfad ein Leerzeichen enthält. Das hab ich noch nicht lösen können. Wenn Du solche Datei hast, könntest Du die ja vielleicht vorher entsprechend umbenennen ... z.B. Leerzeichen durch Unterstriche ersetzen oder so. Oder Du ersetzt die Leerzeichen temporär durch ein einigermaßen exotisches Zeichen. Dann kannst Du sie später wieder relativ einfach zurück-umbenennen. In der Voreinstellung wartet die Funktion 10 Sekunden darauf, dass das Tool sich wieder beendet. Das war für meine Tests mehr als genug. Wenn das bei Dir anders ist, kannst Du den Timeout beim Aufrufen der Funktion entsprechend anpassen. Jetzt könntest Du diese Funktion ungefähr so benutzen: $ToolPath = '<kompletter Pfad zum PDFInfo-Tool>\bin64\pdfinfo.exe' Get-ChildItem -Path <Pfad zu den zu verarbeitenden PDF-Dateien> -Filter *.pdf | ForEach-Object{ $PDFFilePath = $PSItem.FullName # hier wird der komplette Pfad zur PDF-Datei innerhalb der switch-Anweisung nutzbar gemacht $Result = Start-ProcessWithTimeout -FilePath $ToolPath -ArgumentList $PSItem.FullName # -Timeout 20 # anpassen falls nötig If($Result.State -eq 'Completed' -and $Result.HasMoreData){ switch ($Result.Result) { {$Result.Result -match 'Usage:\s+pdfinfo'} { "PDF-Tool SyntaxError - $PDFFilePath"; break } {$Result.Result -match 'PDF\s+file\s+is\s+damaged'} { "PDF file is damaged - $PDFFilePath"; break } {$Result.Result -match 'PDF\s+version:'} { "PDF file is valid - $PDFFilePath"; break } } } Else{ "PDF-Tool stuck ... - $PDFFilePath" } } Dieses Beispiel gibt nur Strings auf der Console aus. Die eigentlichen Aktionen musst Du dann entsprechend Deiner Anforderungen einbauen. Natürlich kann man den switch block noch beliebig erweitern, z.B. je nach Author die PDFs in verschiedene Ordner verschieben oder, oder , oder ... Ich hoffe, es hilft. (... und es funktioniert wie erhofft ... wie gesagt, bei mir stürzt das Tool leider nicht ab)

Es gibt quasi keine eindeutige Zuordnung eines Computers zu einem User. Wie Du schon treffend bemerkt hast, gibt es nur den aktuell angemeldeten Benutzer oder den von Windows oder einigen Services wie SCCM "errechneten" Hauptbenutzer, was aber nicht wirklich zuverlässig ist. Was willst Du denn eigentlich erreichen?

Nur so'ne Idee ... Du benutzt als Bezeichner des VMNetworkAdapters beim Umbenennen $VM[0], welches Du mit Get-VMNetworkAdapterVlan ermittelst ... sollte das nicht eher mit Get-VMNetworkAdapter ermittelt werden?

Ja, wenn's um viele Dateien geht, lohnt es doch meistens externe tools einzuspannen ... im einfachsten Fall robocopy ... könnte ja hier theoretisch auch klappen ... robocopy kann ja schließlich auch löschen.

... dass Du mich immer so schonungslos desillusionieren musst ...

Wow ... es ist mir eine Ehre, mit einem Bekannten von Henoch zu chatten.

also das liegt vor meiner Zeit ... da muss ich dann auf Dein Methusalem-Wissen vertrauen ...

Wie schon mehrfach erwähnt - cmd geht in seinen Wurzeln noch auf MS DOS aus den 80-ern zurück und ist in seinen Möglichkeiten sehr stark begrenzt. Deshalb gibt es inzwischen Powershell, die alles kann, was cmd früher konnte und eben noch viel viel viel viel mehr. Mit Powershell wäre die Aufgabe, so wie Du sie hier beschrieben hast, in wenigen Minuten lösbar. Wenn Du beruflich in Windows-Umgebungen unterwegs bist, lohnt es sich auf jeden Fall, sich die Grundlagen von Powershell anzueignen.

Ich glaube ja, wenn der Kollege Adenium erstmal merkt, wie aufwändig das wird, so eine Anzeige hinzubekommen, dass ihm dann die existierende robocopy Fortschritts-Anzeige gleich viel besser gefällt. Vielleicht bringt's ja auch sowas hier ... da bekommt man dann wenigstens die aktuelle Zeit immer in der Konsole angezeigt und auch wie lange der letzte Befehl zur Ausführung brauchte ... und es sieht cool aus

Wir (Powershell)-Scripter schreiben nicht so gern code doppelt und dreifach. Dafür gibt es Arrays und Schleifen. Hier mal ein Beispiel, der von Deinem Code "inspiriert" wurde. Der Muss selbstverständlich noch angepasst werden. $ComputerNameList = (Get-ADComputer -Filter Name -like 'COMPUTER').Name $DirectoryList = @( 'C:\xxx\xxx1' 'C:\xxx\xxx2' 'C:\xxx\xxx3' ) $10DaysBefore = (Get-Date).AddDays(-10) $30DaysBefore = (Get-Date).AddDays(-30) foreach ($ComputerName in $ComputerNameList) { if (Test-Connection -ComputerName $ComputerName -Quiet -Count 1) { Invoke-Command -ComputerName $ComputerName { foreach ($Directory in $DirectoryList) { Get-ChildItem -Path $DirectoryList -Include *.bat, *.cat, *.txt, *.ini, *.zip, *.pdf, *.log -Recurse -Force -File | Where-Object { $_.LastWriteTime -lt $10DaysBefore } | Remove-Item -Force } } } } Wie Du siehst, ist keine CodeZeile doppelt vorhanden. Das macht den Code deutlich leichter zu lesen, zu debuggen falls nötig und auch leichter zu erweitern, falls gewünscht. Wenn Du z.B. ein weiteres Verzeichnis behandeln möchtest, fügst Du einfach ein weiteres Verzeichnis dem Array $DirectoryList hinzu. Fragen? Fragen! Edit: Achja ... noch vergessen ... der Code dürfte auch so deutlich schneller laufen, da Du die Dateien nicht über die administrativen Freigaben löschen musst, sondern quasi lokal unterwegs bist.

Hmmm ... es ist nicht so richtig der Focus dieses Forums, Dir iterativ das Scripten beizubringen. Das sind alles Anfängerfragen, die Dir ein gutes Buch, ein Anfänger-Online-Tutorial oder ein Video-Kurs in den ersten Kapiteln beibringt. Ich empfehle immer gern den hier: Getting Started with PowerShell 3.0. Da werden Dir die Grundlagen vom Erfinder beigebracht. Ein guter Startpunkt ist auch hier: Getting Started with Windows PowerShell Powershell ist neuer. Daher ist es einfacher "alte" cmd-Befehle in Powershell zu benutzen als andersrum. Die meisten laufen ohne jegliche Anpassung auch unter Powershell. Es gibt verschiedene Methoden "externe" Programme aus der Powershell heraus zu starten. Und man kann beeinflussen, ob das Script auf die Beendigung des externen Programms wartet, oder einfach asynchron (parallel) weiter läuft. Am Besten, Du fängst erstmal an ein bissl zu basteln und wenn Du dann mit einem konkreten Stück Code nicht weiterkommst, kannst Du hier wieder fragen. Wir können üblicherweise viele besser helfen, wenn wir etwas zum "Handanlegen" haben.

Oooops ... ich hatte angenommen, dass es hier um Powershell ginge, sorry. Naja, Nils hat Dich ja schon in die richtige Richtung geschubst. ... und wenn Du's doch mal mit etwas Modernerem und vor Allem einfacher zu Schreibenden versuchen willst, schaust Du Dir mal das Powershell cmdlet Write-Progress an. Das sieht dann ungefähr so aus, wie in diesem Video: ... was dort ausgegeben wird, kannst Du selbst festlegen. Es muss also keine Prozentzahl sein. Schau Dir einfach mal die Hilfe an und spiel ein bissl mit den Beispielen. Viel Spaß

Was für eine Zeitverschwendung. ... aber als Fingerübung vielleicht ganz nett. Du könntest robocopy in ein Log schreiben lassen und dieses periodisch lesen/parsen und Dir die Informationen entsprechend Deiner Vorlieben aufbereiten. Du kannst z.B. Write-Host anweisen, keine neue Zeile anzufangen. In einer Schleife steht das dann immer in der gleichen Zeile wenn Du manuell einen "Cariage Return" nach jeder Zeile einfügst. Oder Du kannst mittels Escape-Sequenzen die Ausgabe Zeilen- und Spalten-genau ausgeben. Oder Du könntest Write-Progress verwenden - das wird automatisch oben am Konsolen-Fenster positioniert - da brauchst Du nix tricksen. ... siehe oben ... Du liest die gewünschten Informationen aus dem Log und bereitest sie entsprechend Deiner Vorlieben auf. Ist das nicht nur dazu da, die zahlreichen und zum Teil cryptischen Optionen zusammenzuklicken? robocopy GUI Eine andere Alternative wäre noch RichCopy ... https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dd547088(v=msdn.10)?redirectedfrom=MSDN

Klingt, als wolltest Du ein kleines Rad neu erfinden. Hast Du schon mal über robocopy nochgedacht? Das zeigt Dir bei großen Dateien den Kopier-Fortschritt in Prozent und am Ende eine Zusammenfassung inklusive verstrichener Zeit.

Wenn Du einmal die Grundlagen drauf hast, kommt der Rest quasi mit der Zeit von alleine ... es gibt gute Bücher dafür, Online-Tutorials oder sogar kostenlose Video-Kurse ... wenn Du der englishen Sprache einigermaßen mächtig bist, nimm Dir die Zeit und lass Dir vom Erfinder die Grundlagen näher bringen ... https://channel9.msdn.com/Series/GetStartedPowerShell3 ... und keine Angst - es geht dabei zwar um Powershell in Version 3, aber die Grundlagen sind immernoch die Gleichen. Vielleicht versuchst Du mal mit dem finanziellen Zaunpfahl zu winken. Schreib doch einfach mal auf, wieviel Zeit Du pro Monat für Tätigkeiten aufwendest, die mittels Powershell automatisiert werden könnten. Wenn Du das Deinem Chef vorrechnest, bleibt mit Sicherheit genug übrig, Dir einen Präsenz-Training zu bezahlen.

OK, dann jetzt noch eine weitere dringende Empfehlung. Wenn Du Powershell-Code schreibst, tu Dir selbst, Deinen Kollegen und speziell den Menschen in Foren, die Dir helfen sollen, einen Gefallen und schreib Deinen Code so ausführlich, wie es irgendwie geht. Aliasse und z.B. Variablennamen mit einem Buchstaben sind wenig hilfreich. Wenn sich jemand anders Deinen Code ansehen soll, soll er den Code doch so schnell und leicht wie möglich verstehen können. ... und in einem halben Jahr bist dann auch Du ein Anderer und überlegst, "... was hab ich da nur geschrieben?". So - jetzt zum Code ... so sieht das deutlich besser aus und wenn Du das brauchst, kannst Du mehrere Bedingungen in einem Where-Object-Scriptblock kombinieren ... so ungefähr: $Gestern = (Get-Date).AddDays(-1) Get-ChildItem -Path \\xxx\xxx -Recurse | Sort-Object -Descending -Property CreationTime | Where-Object { $PSItem.length -gt 1MB -and $PSItem.CreationTime -gt $Gestern } | Select-Object -Property name, @{Name = "Megabytes"; Expression = { [Math]::round($PSItem.length / 1MB, 2)}} Und noch mal aus Neugier: Dateien größer 1 MB gelten bereits als groß?

... n' bissl von hinten durch die Brust ins Auge, aber Du könntest den Aufruf des Tools in einen Job oder einen Runspace oder einfach in eine zweite, unabhängige Konsolen-Session auslagern und diese überwachen. Wenn das länger dauert als "erlaubt", schießt Du's ab und gehst davon aus, dass das Tool gecrashed ist oder das PDF korrupt ist oder beides. ooops ... steht ja schon da oben ... sorry, einfach ignorieren ...

Wenn Du mit Get-ChildItem ein DateiSystemInfoObject erzeugst, hat dieses auch Eigenschaften wie CreationTime, LastAccessTime und LastWriteTime. Die müsstest Du auswerten, um an die gewünschten Informationen zu kommen. Ich würde mit der CreationTime beginnen. Unabhängig davon möchte ich Dir empfehlen, Dir die Grundlagen von Powershell anzueignen. Es gibt gute Bücher oder Online-Tutorials oder sogar kostenlose Video-Kurse wie der vom Erfinder auf Channel9. https://channel9.msdn.com/Series/GetStartedPowerShell3

Wie Mark Minasi zu sagen pflegte: "There's no silicon-based solution to a carbon-based problem."

... und das siehst Du an den neu angelegten bzw. angewachsenen Dateien? Wie so häufig hier im Scripting Forum, ist das eigentliche Problem nicht ein Script oder ein Befehl, der nicht wie gewünscht, bzw. wie erwartet funktioniert. Das Problem ist das Unverständnis bzw. die Unkenntnis der gemanagten Systeme. Was ist denn Deine eigentliche Aufgabenstellung? Was machst Du denn mit der Information, wer das Fileshare gefüllt hat? Wird derjenige entlassen? Werden seine Daten wieder gelöscht? Ist diese Datenerhebung mit dem Betriebsrat abgestimmt?