daabm

Gern geschehen. Lösung des gMSA-Fehlers übrigens: Es gibt pro Benutzerdatenbank einen eigenen Account. Soll heißen: Alle DCs nutzen gemeinsam einen gMSA, und auf allen Membern ist es ein computerlokaler Account mit individuellem Zufallskennwort, das niemand kennt. Wird bei der Agent-Installation ausgewürfelt, auf dem Account gesetzt und in der Service-Konfig eingetragen, dann weggeworfen. (g)MSA pro Member wäre auch noch ok, ein gMSA für eine große Gruppe von Membern schon nicht mehr (lateral movement...).

Erinnert mich an das Steuergeräte-Problem, das Fahrer der ersten EFI-Fahrzeuge haben. Corvette-Besitzer von C3 ab BJ 81 und frühe C4 kennen das. Die Steuergeräte gibt es quasi nicht mehr (neu eh nicht, aber auch gebraucht nicht), und wer (wie die meisten) nicht ein frei programmierbares adaptieren kann, der kann dann entweder auf Vergaser umrüsten mit allen Konsequenzen bei der HU. Oder das Auto für 1,- bei ebay einstellen. Da kommt noch viel Elend mit "Mechanik top, Elektronik EOL" auf uns zu...

Es gibt nicht "den" häufigsten Fehler, aber ganz vorne dabei: Fehlerhafte ACLs auf höher berechtigten Konten (gMSA - das ist uns bspw passiert...), lateral Movement, vertical Movement. Und fehlende Koordination zwischen verschiedenen Teams und auch innerhalb eines Teams. Das mit dem gMSA war ein echter Anfängerfehler - Teammember, die überwiegend den operativen Teil abdecken, haben den gMSA etabliert für Splunk. Und dabei die Tier-Trennung übersehen - allowedToRetrievePassword: Domain Computers. b***d dabei nur: Der wurde auch für Domain Controller genutzt. Zack bist Du pwned. "Selber suchen" ist IMHO übrigens sinnlos - man ist da leider betriebsblind und hat weder einen strukturierten Angriffsplan noch ausreichend ungestörte Zeit.

Ignorier's einfach. Steht ja auch in der Meldung: "seit dem letzten Neustart nicht erfolgreich" - dann warten wir halt, bis es erfolgreich war

Hilft beides nix beim Ursprungsproblem - Prozesse erben ihre Umgebung, wenn sie erstellt werden. Danach ändert sich daran nichts mehr. Gibt nur einen "Frickel-Workaround": Variable nicht nur global setzen, sondern auch im aktuellen Prozess. Hilft aber allen anderen Prozessen natürlich nichts

Zwei Doofe, ein Gedanke

Hier...

Der Pfad der Gerechten ist zu beiden Seiten gesäumt mit Freveleien der Selbstsüchtigen und der Tyrannei böser Männer.

Ein Prozess bekommt seine Umgebung beim Start. Was auch immer Du jetzt in der (übergeordneten) Umgebung änderst, kommt im Prozess nicht an. War schon immer so, Du mußt auf andere Weise prüfen oder so wie @BOfH_666 vorschlägt.

Ich schütte den Kaffee mal weg, schmeckt nicht mehr und braucht auch niemand jetzt 🍺

Ja, ich konnte auch mal TCP-Header dekodieren. Das sind Grundlagen, von denen man Jahrzehnte leben kann. Nicht daß ich das heute noch auswendig könnte, aber ich weiß, daß es geht und ungefähr wie. Und damit finde ich dann den Rest der Infos, um es zu tun. "Handwerkszeug" hieß das mal.

Was da drauf ist, ist glaub nur noch von ideellem Wert - ersetze den Aufkleber, nachschauen kann mangels Lesegerät eh keiner 😂

Damit hast Du eine der größten Hürden der "selbstgelernten IT" genommen - die Erkenntnis der eigenen Fehlbarkeit 😂😘 Viele bleiben da lange stecken...

Zentralpraxis Vlad, Transsilvanien?

In kurz aus dem Gedächtnis: $ADUser | Select-Object -Property Name, @{ Name="Mitgliedschaften"; Expression={ $_.MemberOf -Join "`r`n" }} https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_calculated_properties?view=powershell-7.4

Geht schon, wenn man sich festlegt, wie das im CSV dann entahalten sein soll. Kann man mit calculated properties bei Select-Object recht einfach lösen.

Aber bitte mit Write-Irgendwas davor (und Klammern um den Ausgabetext) und nicht einfach in die Pipe schieben (Nur so aus Gewohnheit...)

WSH-Objekte schmeißen eine Terminating Exception - bei mir zumindest: Try { $WshShell = New-Object -comObject WScript.Shell $Shortcut = $WshShell.CreateShortcut("$env:temp\Blubb\Scans.lnk") $Shortcut.TargetPath = "\\fs1\scan2file\$user" $Shortcut.Save() } Catch { $MyError = $_ Write-Host "Message: $( $MyError.Exception.Message )" Write-Host "HResult: $( $MyError.Exception.HResult )" } Was Du mit dem HResult anfängst, bleibt dann Dir überlassen

Jedes NAS bringt mit Samba eine "Art" Active Directory mit. Für ne Handvoll MA ohne große Verfügbarkeitsansprüche reicht das. Scale-Out ist aber nicht möglich, DHCP/DNS mit AD-Integration auch nicht und echtes Multi-Master wie in einem AD mit mehreren DCs gibt es auch nicht. Ich bin bei @Nobbyaushb - ne Anfangsberatung wäre nicht falsch. Was da am Ende rauskommt, würde ich mal "technologieoffen" 😁 lassen.

Ich stelle mir spontan die Frage, ob das überhaupt ein "Server" mit "Windows" sein muß . Vom Profil her - alles, was ich lese, deckt jedes bessere Home-NAS locker ab. Inkl. SMB1 und SAMBA als Minimal-AD-Ersatz.

Hm - mein Bauchgefühl sagt, daß da das Datenmodell "nicht optimal" ist (man könnte auch flapsig sagen #grütze), aber wer bin ich, daß ich das remote beurteilen könnte

XML hat per se kein "Eintrag bereits vorhanden", es gibt keinen "Primary Key", der eindeutig sein muß. "Duplikate" sind explizit nicht verboten. So gesehen mußt Du das so lösen Und falls Du mal wieder so ein Problem hast: Ohne Sample Data ist da schwer zu helfen. Ich verstehe z.B. nicht, was Du meinst mit

GPO. Siehe Link oben - seDenyXYZright.

Das regelt man aber bitte nicht über "allowed to logon" in den Accounteinstellungen, sondern über passende Gruppen und seDenyInteractiveLogonPrivilege (bzw. wenn die Umgebung vom Grundsatz her eh keine Anmeldung erlaubt - was auf Dauer einfacher ist - über seInteractiveLogonPrivilege).

Nachdem Ihr jetzt schon viel diskutiert habt, werfe ich noch "scope" in den Raum und [ref]. Ich glaube, jede Suchmaschine liefert passende vertiefende Hinweise @testperson Mein Monk achtet peinlichst darauf, die Pipeline sauber zu halte vor unbeabsichtigtem Inhalt, macht es wie @cj_berlin und gibt einfach das Ergebnis "aus", womit es in ebenjener Pipeline und damit im Return des aufrufenden Scope landet. "Return" hilft da nicht - alles was unbeabsichtigt in der Pipeline gelandet ist, wird ebenso zurückgegeben. @Dukel Das mit dem Scope gilt auch für Funktionen - jede "Hauptfunktion" kann ihre eigene Childversion von "Kind{}" haben. Macht es im Zweifel nicht einfacher, ist aber manchmal durchaus hilfreich, weil importierte Funktionen nicht die eigenen stören können.