cj_berlin

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. 

vor 14 Minuten schrieb NorbertFe:

Pst Dateien auf unc Pfaden sind unsupported. Ich würde sagen, an der Stelle solltest du ansetzen.

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.

Gerade eben schrieb NorbertFe:

So dann geh jetzt zum dc und schau mal, wann im Computerkonto die letzte Änderung erfolgte. Dann kann man auf die Suche gehen.

...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.

vor einer Stunde schrieb Seppim:

Kann ich prüfen, an welchem DC er sich versucht anzumelden?

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.

vor 52 Minuten schrieb Der_Peter:

Ist sowas möglich mit Powershell ?

Absolut.

vor 1 Minute schrieb Dutch_OnE:

Ich habe im Postfach die Nachrichtenweiterleitung genutzt.

...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!

vor 25 Minuten schrieb zahni:

Wenn das wirklich so ist, was ich nicht glaube, halt ich das für groben Unfug.

Proxies verwenden meist NTLM oder besser Kerberos zur Benutzeranmeldung. Da wird nicht aus dem Eventlog gelesen, sondern vom Windows höchstens geschrieben.

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} ...

vor 3 Minuten schrieb Weingeist:

Früher konnte ich einzelne Updates zurückhalten welche die Fehlfunktion verursacht haben und alle anderen Updates direkt installieren. Danach in Ruhe eine Lösung für das jeweilige Update suchen. Mir war das generelle +- zeitnahe Update von soviel wie möglich wichtiger als das vollständige Paket. Klar im Büro ist das hundwurscht, in der Produktion aber nicht.

 

Deshalb brauche ich eine zuverlässige Verzögerung der Installation auf genau das Wartungsfenster was ich brauche. Seit MS die automatische Installation durchgeboxt hat und "Downloaden/Warten bis Installation" nicht mehr geht ist das wichtiger den je geworden.

...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.

vor 2 Minuten schrieb Weingeist:

Im richtigen Leben ist WSUS nunmal Bestandteil des Patchmanagements in Kleinumgebungen. Zumindest da wo nicht einfach Blind MS vertraut wird das es schon funktionieren wird.

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  

vor 32 Minuten schrieb Weingeist:

 

Windows Update Reports forcieren:

Jeder kennt glaub dieses leidige Thema.

 

...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.

vor 20 Minuten schrieb NilsK:

Zu dem konkreten Problem kann ich nichts beitragen, aber mir kommt die Beschreibung der Funktion sehr abenteuerlich vor. Bist du sicher, dass das so funktionieren soll? Mit ist völlig schleierhaft, warum eine Firewall die Login-Events auslesen soll, wenn sie eigentlich Gruppenmitgliedschaften prüfen soll. Das könnte sie auch völlig ohne Kontakt zum DC tun, wie alle anderen Rechner das auch tun.

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.

vor 3 Stunden schrieb NorbertFe:

Sicher, dass du Verteiler meinst und nicht Shared Mailbox? Einen Verteiler kannst du nicht "wandeln".

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".