cj_berlin

Folgendes funktioniert (mit Ausnahme der Zeile 2, aber das könnte Copy-/Paste-Artefakte sein): $ledger = [xml](Get-Content C:\Temp\ledger.xml) $ledger.LedgerImport.consolidate.accountsReceivableLedger.ForEach({$_.exchangeRate='H'}) $ledger.Save("c:\temp\ledger-processed.xml") Du hast vermutlich übersehen, dass es in einem consolidate-Element mehrere accountsReceivableLedger-Elemente gibt. Und der Umweg über die HashTable ist zwar interessant. aber nach Deiner Beschreibung brauchst Du ihn nicht - es ist ja entweder Payable oder Receivable, und dann weißt Du ja, was reinkommt.

Moin, XML kann man in PowerShell objektorientiert verarbeiten: https://www.educba.com/powershell-xml/ Dann wäre exchangeRate eine Property, der Du ein 'H' oder ein 'S' zuweisen kannst.

Moin, HP DeviceManager (https://h30670.www3.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPDEVMAN) oder Client Cloud Manager. Dass die Änderungen nach Neustart wieder zurückgerollt sind, liegt am Write Filter. Den musst Du ausstellen, wenn Du Änderungen vornimmst, die permanent bleiben müssen.

Wenn die Audit-Settings am DC auch fehlgeschlagene Logons protokollieren lassen, ja.

Moin, solange in der Umgebung NTLM und/oder RC4 in Kerberos aktiv sind, ist ein Kennwortwechsel nach wie vor das einzige wirksame Mittel gegen Pass-The-Hash (nicht zur Vorbeugung, wohlgemerkt, sondern nur zur Eingrenzung).

Ja.

Versuch's zuerst mit dem KMS Client Key und dann mit der ROK. Schlägt das fehl, musst Du mit Microsoft telefonieren und schauen, was sie dann sagen. Und bei Domain Controllern ist eine Umwandlung von Eval zu Prod grundsätzlich nicht möglich.

For-Schleife, da kannst Du auf das nächste Element gucken.

Absolut.

...also in den Eigenschaften des Postfachs, nicht als Regel im Postfach? Dann ist es klar, dass Journaling nicht feuert, denn die Weiterleitung per targetAddress erfolgt ja bereits im Routing - damit kommt die Mail mit der Postfachdatenbank nie in Berührung!

Ja, weil Proxies Authentifizierung unterstützen, hier geht es aber um Firewalls. Und ja, egal, für was Du oder ich das halten, es funktioniert so - SOPHOS mit STAS, PaloAlto mit UserID, usw. usw. Alternative dazu ist ein Agent auf jedem Endpoint, wie TMG einen hatte.

Moin, hast du Standard Journaling (ein Journal-Postfach pro Postfachdatenbank, in den Eigenschaften der Datenbank) oder Premium Journaling (mit Regeln, pro Postfach) aktiviert? Wie genau leitest Du die Mail für eine Mailbox an einen öffentlichen Ordner um?

Ohne das jetzt geprüft zu haben: Du hast das Logging für Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A} (Security) hochgedreht, Dein Problem liegt aber im Bereich "Audit". Das wäre die GUID {F3CCC681-B74C-4060-9F26-CD84525DCA2A} ...

...aber das ist es ja gerade NICHT, worauf Du dich im OP beziehst. Einzelne Updates freigeben, zurückhalten, zu einem definierten Zeitpunkt installieren - alles reale Anforderungen des Patch Delivery, die mit WSUS, GPOs und ein paar Skripten zuverlässig bedient werden können, das machen wir alle in Umgebungen groß und klein seit Jahrzehnten. Niemand rät davon ab, WSUS für Patch Delivery zu benutzen, denn es gibt ja nur sehr wenige Alternativen, zumindest was die zugrundeliegende Technologie angeht. Du hingegen wolltest in Deinem OP Reports haben, und zwar zu einem von Dir gewünschten Zeitpunkt, und mittels eines Features, das dafür zwar leider irgendwann gebaut worden, aber noch nie wirklich gedacht gewesen ist. Wenn es Dich interessiert, ob bestimmte Updates auf einem bestimmten System installiert sind, und es Dir möglich ist, auf diesem System remote mit Adminrechten ein Skript auszuführen, dann kannst Du doch mit genau diesen Mitteln gezielt abfragen, ob die gesuchten Updates dort installiert sind oder nicht. Weniger Aufwand, sofortiges Ergebnis. Und der Report kommt irgendwann, so wie es schon immer bei WSUS der Fall war. Hier ein ganz grobes Beispiel: $session = New-Object -ComObject 'Microsoft.Update.Session' $history = $session.QueryHistory("",0,5000) if ($history | Select-Object -ExpandProperty Title | Select-String "KB5016616") { "August CU installed" } else { "August CU not installed" } lässt sich auch ohne irgendwelche erhöhten Rechte mit normalen Adminrechten aufrufen.

Und genau da liegt das Mißverständnis: WSUS hat nie versprochen, etwas zu sein, was besser oder mehr ist als Microsoft Update, nur halt lokal. Vor 20 Jahren war Bandbreite ins Internet, selbst in großen Umgebungen, noch wichtig. Dass jemand diese Reporting-Funktion da eingebaut hat, ist zwar nett, hilft aber - wie Beiträge wie der obige zeigen - nur bedingt, weil das einwandfreie Funktionieren dieser Funktion nicht Teil des Service-Versprechens ist. Und die Kleinumgebungen haben so viele Baustellen mehr, an die sie sich nicht trauen ( SMB1, NTLM, PKIs, die nach Weiter-Weiter-Finish ohne Sinn und Verstand eingerichtet wurden, Exchange per NAT ins Internet veröffentlicht, Adminkonten mit Mail-Postfächern, NT4- und SAMBA2-Maschienensteuerungen im gleichen Netz wie AD, SQL mit leerem SA-Kennwort und Service-Account in Builtin\Administrators, Azure AD Connect für alle User, Gruppen und Computer, Branchenanwendungen aus dem schwäbischen Hinterland, die nur bei ausgeschaltetem UAC funktionieren und pauschale Ausnahmen aus dem Virenscan für 1000 Ordner brauchen, und, und, und... ) Da muss ich meist wirklich schmunzeln, wenn die Menschen dann versuchen, jedes einzelne Update extra freizugeben und dann auch noch Reporting darüber erwarten, ob es denn auch sofort installiert wurde

...aber nur von Beiträgen wie diesem, nicht aus dem richtigen Leben. Und immer fehlt die Erklärung, warum es wichtig sein soll, dass die Reports zu einem bestimmten Zeitpunkt reinkommen. WSUS ist nicht Patch Management, sondern nur Patch Delivery. Und Patch Delivery funktioniert durchaus zuverlässig. In der Sache: 1. in dem Skript wird die Variable $criteria nicht gesetzt, sie ist aber wichtig! Da sollte stehen "IsInstalled=0 and Type='Software'" 2. warum sollte ein Skript, das ausschließlich REMOTE-Befehle enthält, LOKAL mit erhöhten Rechten ausgeführt werden? Es werden Adminrechte auf dem entfernten System benötigt, aber lokal kann es ganz normal gestartet werden.

Nö, das ist normal üblich. Eine herkömmliche Firewall kriegt ja keine Informationen zum Benutzer, der die Kommunikation auslöst, sondern nur die Quell-IP. Und um diese einem Benutzer zuzuordnen, überwacht sie Event 4624 auf sämtlichen DCs und nimmt die Zuordnung entsprechend vor. Gibt lustige Nebeneffekte, wenn man von einem Client RDP-Verbindungen mit anderen Accounts aufbaut und NLA aktiviert ist.

Naja, das Wandeln von Golf in Porsche geht ja auch: Golf weg, was dazu tun, Porsche ran. So ist es auch hier

Moin, nur aus Interesse: Wie stellst Du dir technisch das "Wandeln" eines Verteilers in ein Postfach vor? Was für Regeln sind das denn? Habt ihr das mal mit einer einzelnen einfachen Regel versucht? Werden die Regeln ausgeführt, wenn man sie aus Outlook heraus explizit startet?

Moin, dann braucht der Installer vermutlich Parameter für eine unbeaufsichtigte Installation. Sie musst Du ihm als Transform in der GPO mitgeben - oder Du installierst das Ding per Skript. Frag den Lieferanten nach der Parametrisierung für "silent install".

Wieso, ist doch nur des Angreifers. Und nicht registriert, ist also gespooft. Korrektur: Ist doch registriert, chinesisch. Anmeldetyp 3 ist Netzwerk-Anmeldung, kann also ein beliebiges authentifizierungspflichtiges Protokoll sein - RPC, SMB, HTTP, WinRM etc. Mach doch die Firewall komplett zu, wenn die Maschine ungefiltert im Internet steht.

Moin, wenn Du Archivmailboxen listen willst, musst Du es dem Cmdlet sagen: Get-Mailbox -Archive -Database <myarchdb>

Das hat aber keinerlei Funktion, reine - wenn auch in einer ordentlichen Umgebung notwendige - Kosmetik.

...und drei Wochen später ist sie auch drin:

Nein: