BOfH_666

Supi. Eine Kleinigkeit noch. Beim Vergleich mit $NULL sollte $NULL auf der linken Seite des Vergleichsoperators stehen. Also ... if ($null -eq (Compare-Object -ReferenceObject $SourceACL -DifferenceObject $TargetACL -Property IdentityReference, FileSystemRights))

Du enthältst uns den entscheidenden teil Deines Scriptes vor. So können wir bestenfalls raten. Was steckt denn in $mb? Poste doch mal bitte den kompletten relevanten Teil und dazu auch die komplette Fehlermeldung. Sehr häufiig enthält der Fehler schon einen Hinweis aus die Lösung.

Ich vermute, dass Du ein Ergebnis erwartest, welches so nicht existiert. Du kannst die Ausgabe von Compare-Object nicht für eine einfache if-Bedingung benutzen. Wie Du siehst, hast Du 3 mögliche verschiedene Ergebnisse. Die kannst Du nicht mit einem einfachen if abfragen. Wenn Du das -IncludeEqual weglässt und nur darauf prüfst, ob von Compare-Object überhaupt Etwas ausgegeben wird, dann kannst Du eine einfache if-Bedingung benutzen - so wie es Jan oben empfohlen hatte. Das kommt darauf an, was Du im Anschluss mit dieser Information machen möchtest. Stell Dir vor, Du hast einen Obstkorb und darin Äpfel, Birnen und Pflaumen (Mehrzahl). Und dann kommt jemand und fragt "Ist der Inhalt des Korbes gleich einer Birne?" .... Nö. Es sind einfach zu viele Ergebnisse für einen einfachen Ja-Nein-Vergleich.

OK. Tust Du mir bitte einen Gefallen und führst mal bitte den folgenden Code aus ... so wie er ist - nur mit Deinen Variablen? $SourceACL = Get-Acl $Quelle | Select-Object -ExpandProperty Access $TargetACL = Get-Acl "\\$TargetServer\$Type\$Folder" | Select-Object -ExpandProperty Access Compare-Object -ReferenceObject $SourceACL -DifferenceObject $TargetACL -Property IdentityReference, FileSystemRights -IncludeEqual Was erhältst Du als Ausgabe? ... ich gehe davon aus, dass Du ein paar Zeilen mit den Titeln IdentityReference, FileSystemRights und SideIndicator erhältst, richtig? Du hast also MEHRERE Zeilen mit dem gleichen Ergebnis. Und das versuchst Du mittels -eq '==' zu vergleichen. Das kann nicht zuverlässig funktionieren. Und wenn es doch funktioniert, kannst Du dem Ergebnis nicht vertrauen. Wenn Du das -IncludeEqual weglässt, erhältst Du nur noch die Unterschiede - was Du ja möchtest. Und wenn es keine Unterschiede gibt, wird auch keine Ausgabe erzeugt.

Hmmm ... ich glaube, dass Du das ganze ein wenig (ganz schön) komplizierter angehst als nötig. Wenn ich Dich richtig verstanden habe, willst Du Quell- und Ziel-ACL vergleichen und nur die Unterschiede sehen. Dann macht es aber keinen Sinn, die einzelnen Elemente der ACLs einzeln zu vergleichen. Lass Powershell die Arbeit machen. So etwas wie das hier sollte genügen: $SourceACL = Get-Acl $Quelle | Select-Object -ExpandProperty Access $TargetACL = Get-Acl "\\$TargetServer\$Type\$Folder" | Select-Object -ExpandProperty Access Compare-Object -ReferenceObject $SourceACL -DifferenceObject $TargetACL -Property IdentityReference, FileSystemRights Damit vergleichst Du Quell- und Ziel-ACL und gibst ausschließlich die Unterschiede aus. Wenn es keine Unterschiede gibt - gibt es auch keine Ausgabe. Zur Kontrolle kannst Du ja einfach mal ein -IncludeEqual anhängen.

Wenn icacls den Job zufriedenstellend erledigt, gibt es meiner Meinung nach keinen Grund, das zwingend auf Powershell umzustellen. Die ein oder andere Aufgabe lässt sich mit einem dedizierten Spezial-Tool besser/zuverlässiger/einfacher/effizienter lösen, als mit Powershell. Auch wenn das inzwischen als das Schweizer Taschenmesser unter den Systemtools gilt.

... häufig auch als XY-Problem bekannt ...

Was Jan meint ist, dass Dein "Exclude-Muster" vielleicht ein bissl zu allgemein gehalten ist. Du würdest also nicht nur Dateien mit dem Format "20200720-blakeks.ods" aussortieren, sondern z.B. auch "0815-blasuelz.ods". Wenn das für Dich ok ist, kannst Du Jans Einwand einfach ignorieren. Falls nicht, solltest Du eventuell ein wenig mehr Aufwand treiben, um die gewünschten Dateien korrekt zu identifizieren.

Ich habe den Eindruck, dass genau das sehr häufig das eigentliche Grundproblem darstellt. Gefühlt gelingt vielen nicht, einen Sachverhalt oder eine Aufgabe klar und eindeutig zu beschreiben. Von den vorhandenen Voraussetzungen und Abhängigkeiten ganz zu schweigen. Dann ist natürlich schwer - ich glaube auch für den Fragenden selbst - die Aufgabe wirklich zu verstehen und eine Lösungsstrategie zu entwickeln.

Cool. Danke für's Teilen.

So was ähnliches hatte ich vor 'ner Weile auch mal .... dann hat sich rausgestellt, dass der Kollege sein altes Tablet an die Tochter weitergegeben hatte, ohne seine Daten vorher zu entfernen ....

Das halte ich auch für eine sehr gute Idee ... wenn Du ein bissl Zeit hast, kannst Du es Dir ja vom Erfinder erklären lassen. Getting Started with PowerShell 3.0 ... ist ein bissl älter, aber die Grundlagen sind immernoch die gleichen.

Wie ... "passiert nichts" ... nicht mal Fehlermeldungen?

Geht es dabei um eine externe HDD? Wohin soll gesichert werden? In den "Pro-Versionen" von Windows 10 gibt es die Shadow-Copies. Die helfen schon relativ häufig weiter. Dann wäre bestimmt sowieso ein automatisch gestartetes Backup besser als ein manuell per Doppelklick gestartetes, oder? Und bei einem eventuell nötigen Restore wirst Du vermutlich auch sowieso helfen müssen, richtig? Ich nutze für meine "Privat-Patienten" gern Duplicati2 und bin bisher sehr zufrieden damit. Man kann "lokale" Backup-Ziele benutzen oder auch viele Online-Speicher (natürlich verschlüsselt).

Da kann ich Martin nur zustimmen. Solltest Du nicht zwingend Cross-Plattform-Code produzieren müssen, fang doch einfach erstmal mit der "ganz normalen Windows Powershell" an. Die ist überall eingebaut, legt Dir am Anfang die wenigsten Hürden in den Weg und Du findest im Netz auch noch deutlich mehr Hilfe. Und die Grundlagen sind zu 99% die gleichen. Wenn Du's dann mal brauchst, ist der Umstieg dann nur noch ein kleiner Schritt.

Na wenigstens versuchen sie sprachlich doch schon einen Unterschied deutlich zu machen. Wenn's um die "legacy" Powershell bis Version 5.1 geht, ist jetzt immer von "Windows Powershell" die Rede, während die neue einfach nur "Powershell" heißt.

Die Weiterentwicklung von Powershell geschieht unter der Schirmherrschaft von Microsoft als Open Source. Die aktuelle stabile Version ist die Version 7.0.2 7.0.3, die heute released wurde. Bis Powershell Version 5.1 basiert das Ganze auf dotNet für Windows. Ab Version 6 auf dotNet-Core, welches plattformübergreifend für Windows, Mac und Linux zur Verfügung steht. Die Version 6 und folgende ist keine Nachfolge-Version im klassischen Sinn, die die Vorversion ersetzt. Windows wird auf absehbare Zeit weiter mit Version 5.1 ausgeliefert und auch weiter supportet - nur eben nicht mehr weiterentwickelt. Das heißt, neue Features landen ausschließlich in Versionen 6 und höher. Wenn Du z.B. Powershell 7 nachinstallierst, hast Du 2 unterschiedliche, voneinander unabhängige Powershells auf dem Rechner.

Cool. Danke für den Link.

Jeder, der keine Abhängigkeiten zu alten legacy 32-Bit Plugins/AddOns hat, oder? Was spräche noch dagegen?

Weil's mich selber interessiert hat ... Hier mal eine Version, die statt des Outlook-Com-Objekts Send-MailMessage benutzt und deshalb auch ohne installiertes Outlook funktionieren würde. ... z.B. vom Server Ich würde auch eher UNC-Pfade als Laufwerksbuchstaben empfehlen. Also \\Servername\Freigabe anstatt x:\. $maxAttachmentSize = 20MB $directory = 'x:\TIFF zum einlesen Scanntool' $Filter = '*GEKO*.tif' $mailText = Get-Content -Path 'X:\Textvorlagen\skoda-sekretariat.txt' $fileList = [System.Collections.ArrayList](Get-ChildItem -Path $directory -Filter $Filter | Sort-Object -Property Length -Descending ) $attachmentListList = [System.Collections.ArrayList]@() while ($fileList.count -gt 0) { $attachmentList = [System.Collections.ArrayList]@() while (($attachmentList.Length + $fileList[0].Length | Measure-Object -Sum).Sum -lt $maxAttachmentSize -and $fileList.count -gt 0) { [VOID]$attachmentList.add($fileList[0]) [VOID]$fileList.RemoveAt(0) } $index = 1 while ($fileList.count -gt $index ) { if (($attachmentList.Length + $fileList[$index].Length | Measure-Object -Sum).Sum -le $maxAttachmentSize ) { [VOID]$attachmentList.add($fileList[$index]) [VOID]$fileList.RemoveAt($index) } $index ++ } [VOID]$attachmentListList.Add($attachmentList) } foreach ($list in $attachmentListList) { $SendMailMessageParams = @{ From = 'absender@absender.de' To = 'empfaenger@empfaenger.de' Subject = 'Scan Antraege fuer Archiv' Body = $mailText Attachments = $list.FullName SmtpServer = 'smtp.absender.de' } Send-MailMessage @SendMailMessageParams } Bei der maximalen Attachment-Größe musst Du Dich evtl. herantasten weil die Gesamtgröße der Dateien für eine Mail immer ein bissl über der eingestellten Größe liegt (je nach Größe der zuletzt hinzugefügten Datei). Achja ... die "Verschiebe-Aktion" der Dateien in das Archiv-Verzeichnis kannst Du dann hinterher natürlich immernoch machen wenn gewünscht. EDIT: Ich hab die innere While-Schleife nochmal geändert. Die Summe der Dateigrößen in einer einzelnen "$attachmentList" ist jetzt auf jeden Fall kleiner oder gleich der eingestellten Maximalgröße. EDIT 2: Ich hab den Code nochmal ein bissl gepimpt. Jetzt wird die angegebene Maximalgröße optimal ausgenutzt. Das kann - je nach Datei-Anzahl- und Größe - die Anzahl der versendeten Mails reduzieren.

Nicht jeder ist in globalen verteilten AD-Strukturen mit 10.000-den von User-Objekten unterwegs oder so. Und wenn der Code nicht alle 30 Sekunden laufen soll, dann ist es meiner Meinung auch mal egal, ob das dann der effizienteste Code der Welt ist oder nicht. Für einen LDAP-Filter müsste ich "nachschlagen" - das fließt mir nicht aus den Fingern. Die Syntax von ober klimper ich einfach runter und das Ergebnis ist am Ende des Tages das gleiche. Der Aufwand wäre für mich also deutlich höher, ohne mir einen spürbaren Mehrwert zu liefern.

Wäre es. Definitiv. Da man aber dem Parameter -Filter keine komplexen Script-Blöcke, sondern nur einen "Filter-String" mitgeben kann, kenne ich keine funktionierende Syntax, wie man auf ein leeres Attribut filtern kann. Und meine LDAP-Kenntnisse sind leider auch quasi nicht vorhanden.

Ich würd' eher eine CSV-Datei empfehlen. Die eignet sich besser für strukturierte Daten: Get-ADUser -Filter "enabled -eq '$true'" -Properties Mail -SearchBase 'OU=Verwaltung,OU=Anwender,DC=contoso,DC=com' | Where-Object {$null -eq $_.Mail} | Select-Object -Property *Name*,Mail | Export-Csv -Path 'Pfad zur CSV-Datei.csv' -NoTypeInformation Wenn Du unbedingt eine Text-Datei haben möchtest, pickst Du Dir einfach mit dem Select-Object den Namen raus, den Du exportieren möchtest und nimmst Out-File anstatt Export-CSV. (Ich habe hier das Attribut "Mail" nochmal mit in die Ausgabe eingeschlossen, um eine "visuelle Bestätigung des Fehlens" zu erhalten)

Hmmm ... ich bin ein bissl verwirrt. Du sammelst tif-Dateien ein, nennst die Variable aber $pdfs!? In Deiner foreach-Schleife benutzt Du eine Variable $tifBaseName, die aber vorher nicht definiert wird. Erst benutzt Du einmal Join-Path, um einen korrekten Pfad zu erstellen und dann wieder bastelst Du mittels String-Verkettung Pfade zusammen. Wenn Du Fehlermeldungen erhältst, poste diese doch bitte komplett (auch als Code formatiert bitte).

Wenn Du schon automatisierst, dann richtig. Was ist das Maximum, was Du per Mail versenden darfst / der Empfänger empfangen darf? Wie unprofessionell ... .... na dann los ... wir helfen Dir. Ich vermute mal, dass Du wenigstens die Grundkenntnisse in Powershell bereits erworben hast - jedenfalls lässt das Deine früher hier gestellte Frage vermuten. Viele Sachen sind in Powershell deutlich einfacher als in VBS. Wie würdest Du anfangen?