BOfH_666

... kommt sogar noch besser: "Auch ein ausgewiesener Sicherheitsforscher klickt mal daneben .... " 36C3: Wenn der Ransomware-Support plötzlich Russisch spricht

Ich hab das Gefühl, dass Du irgendwie bei dem Begriff unsicher bist ... vielleicht also einfach mal als Begriffs-Erklärung: Ein Member-Server ist einfach ein Server, der in die Domäne "ge-joint" wurde. Also Member der Domäne ist.

's war eher als Tipp an didde1408 gedacht. Ich wollte damit nix implizieren.

Eventuell eine gute Gelegenheit, über einen automatisierten BUILD-Prozess nachzudenken. Dann kannst Du's ganz beruhigt wie bei einem Autoreifen angehen. Wenn einer "verschlissen" oder "platt" ist - einfach einen neuen aufziehen.

Eine weitere Möglichkeit wäre, zu akzeptieren, dass die IT-/Online-Welt englisch ist und man um den ein oder anderen englischen Begriff nicht herumkommt, bzw. lernen kann, mit ein paar englischen Begriffen zu leben.

Ohne großkotzig klingen zu wollen, aber eine 500GB-SSD kostet im Moment ca 60 €uro. Vielleicht kann man sich überlegen, die Austattung zu modernisieren und auf aktuelle Technik umzustellen. RAM-Disk ist irgendwie so 90-er!? ... oder so "letztes Jahrtausend" ...

Oh ... Du hast also ein Problem, nur ein ganz anderes, als Du uns hier beschrieben hast ... hmmmm

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?