cj_berlin

Danke für das Vertrauen darauf, dass wir alle Event IDs von Exchange auswendig können. Aber mal anders gefragt: Nach einem Backup mit zwei Kopien, wird da der Backup-Zeitstempel auf der Datenbank gesetzt? Falls ja, hast Du kein Problem, und es sind in der Tat "zu wenige" Logs.

Moin, wenn Logs nicht gelöscht werden können, wird es im Application EventLog protokolliert. Auch wenn sie abgeschnitten werden, wird es dort protokolliert. Dass man nach dem Hinzufügen und Entfernen von Kopien den Information Store neu starten muss, hast Du berücksichtigt? Sicherst Du die aktive oder die passive Kopie? Falls die aktive Kopie klappt und die passive nicht, ist die Cluster-Kommunikation kaputt. Exchange schneidet die Logs nicht auf Null an, sondern behält einige. Vor Einführung der DAG waren das, meine ich, acht (á 5 MB), ab Exchange 2010 sind es mehr, allerdings á 1MB, 100 könnte hinkommen.

Nö, auch Verteilergruppen haben eine SID. Die kommt nur nicht in den Anmeldetoken der Mitglieder.

Ist bei euch irgendwas davon mit personenbezogenen Informationen verknüpft oder alles generisch? Sprich: Wenn eine Lisa Müller bei euch anfängt, kriegt sie dann muellerl2, obwohl aktuell keine L. Müller in dieser Domain beschäftigt ist, aber mal beschäftigt war?

Moin, das Stichwort lautet "Shared Activation".

SenderIPRange ist eine valide Bedingung für die Mailflow Rule. Und diese Rule könnte dann beispielsweise etwas in den Betreff reinschreiben, was die Mailbox Rule dann auswerten und daraufhin die Mail in "Sent Items" verschieben würde. Das wäre auch eine Server-Regel, unabhängig von Outlook...

Aber er schickt sie doch auch nur per SMTP weiter, da hast Du nichts gewonnen????

...und was würde damit erreicht werden?

Moin, AFAIK ist das nur bei Exchange Online möglich. On-prem werden Mails, die über SMTP mit Authentifizierung eingereicht werden, nirgends gespeichert (außer beim Empfänger, wenn er intern war). Hier Flashback: Auf diese Idee sind schon einige gekommen, und ich meine, es gibt auch ein Tool, welches das macht. Wenn es nur um den Nachweis geht, kannst Du das ja per Mailflow Rule kennzeichnen und zurück an die Mailbox schicken, und dort per Mailbox Rule anhand der Kennzeichnung in Sent Items verschieben. Oder so.

Moin, nein, der Wert im Attribut verleiht dem User keine Berechtigungen am Computer-Objekt - meistens wird der User aber auch Owner sein, und daraus leiten sich die Rechte an, wenn auch nicht automatisch. Das ist aber per se ein Problem. Das Attribut ist nur dafür da, das MachineQuota überwachen zu können.

Moin, hast Du mal probiert, es zu löschen? Warum sollte das kritisch sein? So wie es jetzt ist, ist der jeweilige Admin ja vermutlich sogar Owner des Computer-Objektes - das wäre evtl. kritisch, wenn das Admin-Account kompromittiert wird. Aber die SID eines Accounts kann doch jeder lesen, also nicht "Jeder", sondern jeder Und welchen Bezug hat es zum LAPS? Wenn ein Angreifer wissen will, wer LAPS-Attribute lesen darf, fragt er auch danach und nicht nach obskuren Attributen...

...es sei denn, der Zugriff erfolgt von Terminalservern oder VDI Man sollte es dennoch lieber lassen.

Das ehrt Dich - ist aber in diesem speziellen Fall vermutlich eh egal, denn wenn ich einen Deiner User phishe (hat Adminrechte, wir erinnern uns!), komme ich an CredMan aller lokaler Benutzer auf dieser Maschine so oder so ran.

Ich glaube, dieses Forum ist der falsche Ort, um auf diese Frage eine objektive Antwort zu erwarten. Klar werden weiterhin Admins gebraucht, aber bei offiziellen Lehrgängen sind die Schulen ja nicht ganz unabhängig von den Herstellern, und die pushen ja sehr stark in die Cloud. Man findet aber durchaus gute Weiterbildungsmöglichkeiten zu den klassischen Themen, so bei https://www.it-administrator.de/trainings/ oder auch bei anderen Verlagen.

Hast Du da auch ne Quelle zu, aus der Dein Wissen stammt?

Und spätestens hier ist es dann vollkommen wurscht, welche vermeintlichen Sicherheitsmaßnahmen Du wo ergreifst. Leg einfach auf dem Master-PC gleichlautende Konten mit gleichen Kennwörtern an, sensibilisiere die User, dass sie die Kennwortänderungen 2x machen müssen, und vergiss den ganten CredMan-Kram.

So etwas wäre ja auch nur beim Versand aus Funktionspostfächern überhaupt zustimmungsfähig. Wenn eine Mail mit einem persönlichen Absender vor Verlassen der Organisation ohne Wissen des Absenders bearbeitet werden kann, müsste das die Beschäftigtenvertretung sofort auf die Barrikaden treiben. Und in der Tat ist ein solcher Workflow im DMS eher zu Hause als im Mailsystem.

Warum ist IPMI böse? (Immer vorausgesetzt, Hardware-Managrment ist vom produktiven Traffic getrennt)

Moin, Intel RMM kann zumindest IPMI. Damit kannst Du mit Start-PCSVDevice die Maschine einschalten.

Es sei denn, der Zugriff erfolgt von einer Terminalserver- oder VDI-Lösung aus. Dann ist es funktional supported, aber für die Performance übernimmt Microsoft keine Gewähr: https://docs.microsoft.com/de-de/outlook/troubleshoot/data-files/limits-using-pst-files-over-lan-wan#outlook-2010-or-later-versions-hosted-remotely-by-using-windows-server-2008-r2-or-later-rdsh-or-vdi-configuration Ist bei diesen Usern %AppData% auch umgeleitet? Ich habe bei Outlook schon alle möglichen Schweinereien erlebt, die auf eine Umleitung von %AppData% zurückzuführen waren.

...also vielleicht nicht die letzte Änderung, sondern pwdLastSet. Letzte Änderung kann sonstwas sein.

Dann musst Du die Geräte wohl erst einmal betanken - ebenfalls mit dem HPDM. Images gibt es bei HP zum Download.

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.