BOfH_666

Eine kleine Beschleunigung ohne großen Aufwand könntest Du bereits dadurch erreichen, jeden Server nicht 2 mal anzupingen, sondern nur einmal. $Result = Foreach ($VMName in $BI_VMs.Name) { [PSCustomObject]@{ Name = $VMName Online = Test-Connection -Quiet -Count 1 -ComputerName $VMName } } $Result

hhhmmm .... nur aus Neugier: Warum?

Du markierst den Code den Du in einen Beitrag eingefügt hast und klickst dann einfach in der Formatierungsleiste auf </> . AWK? Dieses AWK -> https://de.wikipedia.org/wiki/Awk ??

Hmmm ... ich empfehle Dir dringeds, DIr die Grundlagen von Powershell anzueignen. Solltest Du vorhaben, beruflich noch ne Weile in Windows-Umgebungen unterwegs zu sein, lohnt sich das für die Zukunft auf jeden Fall für Dich. Hier im Forum bitte Code als Code formatieren. Und bitte in Skripten und in Foren keine Aliasse verwenden. Hier also die nächste Literaturempfehlung: The Unofficial PowerShell Best Practices and Style Guide. Wenn Du die Hilfe für Export-Csv gelesen hättest, hättest Du gewusst, dass dieses cmdlet keinen Parameter -Skip hat. $in_file = "D:\Daten\qsys\Powershell\NC_PM\NC_PM.csv" $out_file = "D:\Daten\qsys\Powershell\NC_PM\NC_PM_OUT.csv" $Header = @( 'szIdentNr', 'szGeraeteNr', 'sGrpNr', 'szBezeichnung', 'sKlassifizierung', 'sPruefOrtBez', 'dtPruefTermin', 'dtLastPruefTermin', 'dwMaxMessungen' ) Import-Csv $in_file -Delimiter ';' -Header $Header | Select-Object -Property 'szIdentNr', 'szGeraeteNr', 'sGrpNr', 'szBezeichnung', 'sKlassifizierung', 'sPruefOrtBez', @{ Name = 'dtPruefTermin'; Expression = { (Get-Date $_.dtPruefTermin -Format 'yyyyMMdd') } }, 'dtLastPruefTermin', @{ Name = 'dwMaxMessungen'; Expression = { 'DefaultWert' } } | ConvertTo-Csv -NoTypeInformation -Delimiter ';' | ForEach-Object { $_ -replace '"' } | Select-Object -Skip 1 | Out-File $out_file

Super. Wie hast Du's gemacht? Aha. Hmmm ... das ist ja nicht gerade sehr robust. Ich würd mich wohl mit dem Anbieter der Schnittstelle auseinandersetzen wollen. Warum toleriert man denn so eine Gängelei? Wo? Da ich Deinen Bildschirm nicht sehen und nicht weiß, was und wie Du's gemacht hast, musst Du jetzt mir helfen, Dir zu helfen. Und Du hilfst damit vielleicht auch anderen, die ein ähnliches Problem haben. Also zeig mal Deinen Code, wie Du ihn jetzt hast.

Das mit dem "Trenner" ist einfach und das bekommst Du allein raus, wenn Du Dir einfach die Hilfe für Export-Csv anguckst. Wenn Du die Header weglassen willst und auch noch die Anführungszeichen, musst Du halt tricksen. standardkonformes CSV enthält nun mal beides und alle Tools, die standardkonformes CSV korrekt verarbeiten, können damit umgehen. Wofür brauchst Du die Daten denn so komisch? Ja, aber dann musst Du Dich eben um die entsprechende Formatierung selbst kümmern. Ich würde empfehlen, so standardkonform zu arbeiten wie es irgend geht. Alles andere ist üblicherweise aufwändiger, fehlerträchtiger und schwerer zu warten und anzupassen, falls mal nötig. Wenn Du's doch unbedingt so machen willst, schau Dir mal ConvertTo-Csv an.

Ich finde, Du hast ein Talent zu verwirren ... was soll das mit dem "Get-Process | Select ..." und so weiter? Hast Du da versehentlich beim Kopieren das Falsche markiert? Hier ... so sollte's klappen $in_file = "D:\Daten\qsys\Powershell\NC_PM\NC_PM.csv" $out_file = "D:\Daten\qsys\Powershell\NC_PM\NC_PM_OUT.csv" $Header = @( 'szIdentNr', 'szGeraeteNr', 'sGrpNr', 'szBezeichnung', 'sKlassifizierung', 'sPruefOrtBez', 'dtPruefTermin', 'dtLastPruefTermin', 'dwMaxMessungen' ) Import-Csv $in_file -Delimiter ';' -Header $Header | Select-Object -Property 'szIdentNr', 'szGeraeteNr', 'sGrpNr', 'szBezeichnung', 'sKlassifizierung', 'sPruefOrtBez', @{ Name = 'dtPruefTermin'; Expression = { (Get-Date $_.dtPruefTermin -Format 'yyyyMMdd')} }, 'dtLastPruefTermin', @{ Name = 'dwMaxMessungen'; Expression = {'DefaultWert'} }| Export-CSV -Path $out_file -NoTypeInformation Ergänzung: Du solltest jeweils für die cmdlets, die Du benutzt, die Hilfe lesen - komplett und inklusive der Beispiele. Die Technik, die in diesem Code-Snippet benutzt wird nennt sich "calculated Properties". Einen ersten kleinen Hinweis darauf findest Du in der Hilfe für das cmdlet Select-Object im Beispiel #10. Dabei übergibst Du statt eines einfachen Strings, eine Hash-Table mit einem Stück Code, der die Property errechnet.

... wenn ich das etwas korrigieren/präzisieren darf ... Understanding the Six PowerShell Profiles ... (mit VSCode kommt quasi noch eins dazu )

... und vielleicht beschreibst Du auch gleich mit, warum Du diese Frage im Scripting-Forum stellst.

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.