BOfH_666

Das wär mir neu. Versuch mal Folgendes in einem beliebigen Verzeichnis: Get-ChildItem | ForEach-Object { try { Get-ItemProperty -Path 'bla keks' -ErrorAction stop } catch { 'bla keks' } } Du wirst so viele "Blakekse" sehen, wie es Dateien und Ordner in diesem Verzeichnis gibt.

... Angeber! Die Ursache für solche Fehler liegt nach meiner Erfahrung meistens in ungewöhnlichen, in der ISE nicht sichtbaren Zeichen, wenn man den Code aus z.B. Word oder manchmal auch aus einem Browserfenster kopiert. Deshalb wäre VSCode als IDE auch besser geeignet, weil dort die PowerShell-Erweiterung inzwischen solche Zeichen speziell markiert und auf potenzielle Fehler hinweist. Versuch mal bitte, Deinen Code einmal in ein Windows-Notepad-Fenster zu kopieren und dann von dort wieder zurück in eine neue frische PS1-Script-Datei. Das eliminiert meistens solche Zeichen.

Entweder Du ersetzt den "-" mit einem anderen Zeichen ... z.B. einem "_", oder ... Du setzt ALLE Schlüsselnamen (die Bezeichnungen links vom Gleichheitszeichen) in Anführungszeichen (einfache oder doppelte). Ich würde ja die Namen deutlich kürzer und weniger redundant gestallten ... z.B. "OfficeBerechtigt" für den ersten und bei allen weiteren den Teil "remotedesktop-user" einfach weglassen. Noch ein Hinweis: Der Index eines Arrays in PowerShell beginnt bei "0"!! Mit "$GroupList[1]" erhältst Du also bereits das zweite Element des Arrays. Und noch ein Hinweis: bitte keine Screenshots von Code oder Konsolen-Output posten. Anstatt dessen, den Text posten und als Code formatieren. Dann kannst Du sensible Informationen auch leichter aus-X-en.

Danke. OK, es geht also nicht um ALLE Gruppen eines ADs - dann hätte ich Deine Idee für untauglich gehalten, sondern nur einige wenige spezifische. ... und weil bald Weihnachten is, .... $SearchBase = 'OU=Users,DC=Contoso,DC=de' $GroupList = 'CN=Group1,OU=Groups,DC=Contoso,DC=de', 'CN=Group2,OU=Groups,DC=Contoso,DC=de', 'CN=Group3,OU=Groups,DC=Contoso,DC=de', 'CN=Group4,OU=Groups,DC=Contoso,DC=de' $UserList = Get-ADUser -Filter * -SearchBase $SearchBase -Properties MemberOf $Result = foreach ($UserName in $UserList) { [PSCustomObject]@{ UserName = $UserName.sAMAccountName Group1 = If($UserName.MemberOf -contains $GroupList[0]){'x'} Group2 = If($UserName.MemberOf -contains $GroupList[1]){'x'} Group3 = If($UserName.MemberOf -contains $GroupList[2]){'x'} Group4 = If($UserName.MemberOf -contains $GroupList[3]){'x'} } } $Result | Format-Table -AutoSize ... bei 800 Usern halte ich eine solche Ansicht immernoch für untauglich ... aber wenn Du Dir eine Pivot-Tabelle draus bastelst, kannst Du Dir die Daten ja nach den jeweils benötigten Kriterien anzeigen lassen. Ein Hinweis noch: Du musst hier tatsächlich mit den exakten "DistinguishedNames" der Gruppen arbeiten, sonst findet der "-contains" Operator keine Übereinstimmung.

Wozu soll diese Matrix denn dienen?

Ohne auf den Rest Deines Codes einzugehen ... Du könntest Dir den String/Wert für "-Identity" vorher zusammenbauen und dann als komplette Variable übergeben: $Identity = '{0}:\Posteingang' -f $element Get-MailboxFolderPermission -Identity $Identity

Ah ... ok ... dann war's das.

Klaus Dieter, Willkommen im MCSEboard. ... kein Denkfehler ... das ist leider unter bestimmten Voraussetzungen ein Feature by Design. Wenn Du den Befehl lokal auf einem OnPremisses-Exchange-Server ausführst, hast Du an der Property "DatabaseSize" noch die "Sub-Property" .Value. Bei einem Remote-Zugriff existiert diese Sub-Property leider nicht mehr. Da müsstest Du dann mit einer calculated Property die Bytes aus den Klammern extrahieren und danach sortieren. Übrigens ... wenn Du Code, Konsolen-Output oder Beispieldaten postest, formatier die bitte mal als Code. Danke schon mal im Voraus.

... und dabei ist die ganze Auswahl auch viel weniger umfangreich, als man uns das glauben machen will ...

Da alle aktuellen Browser mit dem Speicher alles andere als sparsam umgehen, könnte ein bissl mehr RAM eventuelle eine Entspannung bringen.

Bei mir sind im Moment 6 Tabs zu 16 Prozessen

Meiner Meinung nach wäre dann ein PowerShell-Modul die bessere Wahl. Das ist ist deutlich flexibler, leichter zu pflegen und weniger fehleranfällig, denke ich.

Dann zitiere ich mich mal selbst ...

Das hört sich ziemlich unwahrscheinlich an. Besteht die Möglichkeit, dass die Operatoren doch richtig funktionieren? ... also, dass es einfach keine Einträge gibt, die aktuell genug sind?

Nur mal aus Neugier .... warum? Wenn ich mich nicht irre, sind alle Betriebssysteme, die mit einer PowerShell-Version kleiner 3.0 ausgeliefert wurden, schon ne Weile aus dem Support, oder? ... und selbst, wenn nicht - man könnte z.B. per UNC-Pfad auf die gewünschte XML-Datei zugreifen. Davon unabhängig - vergucke ich mich, oder ist in der kompletten XML-Datei die Du gepostet hast, das gewünschte Muster gar nicht vorhanden? ... also jedenfalls nicht so, wie Du es in Deiner ursprünglichen Frage angegeben hattest!?

Ich glaub, das ist nur ein Fehler vom Hier-Her-Kopieren. Die Fehlermeldung lässt ja leider Raum für Interpretation. Vielleicht ist auch das "[datetime]::today" die Ursache. Versuch doch stattdessen mal "$((Get-Date).Date)". Wenn das auch nix bringt ... vielleicht baust Du Deinen Code ein bissl um, um das Error-Handling zu erleichtern. Statt des "Where-Object" eine Schleife benutzen und die jeweiligen Variablen-Inhalte und -Typen ausgeben. Vielleicht zeigst Du uns etwas mehr von Deinem Code ... 'ist manchmal leichter, wenn man ein bissl Kontext hat.

Georg, Willkommen im MCSEboard. Die leeren Anführungszeichen in der Fehlermeldung deuten darauf hin, dass die Eigenschaft, die Du benutzen möchtest, leer ist. (oder hast Du die nur hier für das Forum entfernt?)

Ich schrub doch extra, dass ich keine Ahnung habe. ... der Unterschied war mir tatsächlich nicht bewusst. Danke.

Ohne auch nur ansatzweise Ahnung von Office-Makros zu haben ... die Erweiterung ".dot" klingt irgendwie nicht nach aktueller Version - sollte das nicht .dotx oder so sein? Wie wär's wenn der Hersteller das 1. aktualisiert und 2. nicht in externe Dateien auslagert, sondern in die entsprechende Vorlage integriert?

Die benutzen nur den gleichen Stecker ... was es natürlich auch nicht weniger verwirrend macht ...

Also 20H2!? Es ging mir nur darum, dass es noch ein supportetes Windows ist. So ... 'hab nochmal bei uns nachgeguckt ... sieht da genauso aus. ¯\_(ツ)_/¯ Das "Release-Datum" für diese Updates ist der 20.09.2022. Ich gehe davon aus, dass das entweder ein Fehler von MSFT ist, oder MSFT einen Fehler in den Updates entdeckt hat, der erst noch gefixt werden muss, bevor es ein neues aktualisiertes Updates dafür gibt. Auf der anderen Seite ist - auch nachträglich am 20.09.2022 - also nach dem offiziellen Patch-Mittwoch - noch ein weiteres Update rausgekommen ... "2022-09 Dynamic Update for Windows 10 Version 20H2 for x64-based Systems (KB5017404)" ... ist ja nicht das erste mal, dass MSFT Probleme mit den Updates hat.

... darf ich fragen welches Windows 10?

Ich glaube, ich verstehe die Frage noch nicht ganz. Wenn ein Update von MSFT als abgelaufen deklariert wird, gibt es meistens ein neueres, welches das alte ersetzt oder integriert hat. Jedenfalls kannst Du abgelaufene Updates mit SCCM nicht mehr installieren. Bei den Vorschau-Versionen in Deinem Screenshot ist mit an Sicherheit grenzender Wahrscheinlichkeit die "fertige" Version des Updates erschienen. Und die sollte dann auch installiert werden.

... das Video kannte ich schon ... coole Sache ... Handwerkskunst.

Uii ... und wat ne mondäne Tür ... cooler Stil-Mix!