daabm

Ich korrigiere das mal - aber nur ein wenig. Ja, wenn man eine GPO löscht, dann ist die GPO weg. Nein, wenn man eine GPO löscht, verschwinden ihre Settings NICHT automatisch auf allen Clients. Das trifft inbsesondere zu für Ordnerumleitung und SW-Installation (und auch das inzwischzen beerdigte IEAK). Die beiden haben so ein nettes Feature, bei Ordnerumleitung "Verhalten beim Entfernen der Richtlinie", bei SW-Install "Deinstallieren, wenn außerhalb des Verwaltungsbereichs" (oder so ähnlich). Soll heißen, diese Extensions haben ein definierbares Verhalten, was passieren soll, wenn eine GPO nicht mehr da ist. Und damit das funktioniert, merkt sich JEDER Client, was er über diese Settings bekommen hat, sonst kann er das ja nicht rückgängig machen, wenn die GPO weg ist. Im konkreten Fall wurde für das MSI-Paket wohl "Deinstallieren" ausgewählt, wenn die GPO weg ist. Deshalb soll das MSI jetzt deinstalliert werden. Leider hab ich nicht mehr auswendig im Kopf, wo GENAU das lokal in der Registry zu finden ist, aber mit den Infos sollte sich mal ne gute Google-Suchparty veranstalten lassen Hat auf jeden Fall was mit {C6DC5466-785A-11D2-84D0-00C04FB169F7} zu tun - das ist die GUID der Software Installation CSE. Daß die Installationsquelle nicht verfügbar ist, liegt üblicherweise am übergelaufenen Installer-Cache (c:\Windows\Installer). Hier liegen alle MSI-Pakete, die jemals installiert wurden, nur ohne die eigentlichen Programmdatei-Inhalte. Damit kann der Installer alles rückgängig machen, was das Paket installiert hat (das steht ja noch drin). Leider hat der ein FIFO-Größenlimit, irgendwann fliegen alte Pakete raus. Welches genau da fehlt, kriegt man auch über die Registry raus. Exemplarisch HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\00006109C80000000000000000F01FEC\InstallProperties (die ID zwischen Products und InstallProperties ist natürlich variabel und ist die GUID des Paktes nach einer völlig abstrusen Transformation ). Hier gibt es dann den Wert LocalPackage, das ist das MSI im Installer Cache. Weiß man nun genau, zu was das gehört, kann man das ursprüngliche MSI unter diesem Namen dahin kopieren und der Uninstall klappt. Bei Fragen einfach fragen. PS: Im AD bleiben von SW-Inst GPOs auch Reste - Stichwort AAS-Container. Aber die tun niemandem weh.

Stuck in batch- stuck in last century

Ja. In einer frühen Phase meiner IT-Erfahrung war ich im First Level Support, und nah dran bin ich heute immer noch. Man riecht das irgendwann

Check mal https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj966265(v%3Dws.11)

Hm - hab ich nicht oben schon was von "nachgebaut" geschrieben? Das ist das "Schöne" an Powershell - ein Cmdlet muß nicht das sein, für das man es hält Mich würde mal ganz schnell get-command remove-localgroupmember | fl * der Beteiligten interessieren. Da kommen bestimmt interessante Unterschiede zum Vorschein.

Start- und Anmeldeskripts kann man prima durch geplante Tasks ersetzen. Die werden auch beim Hintergrund-GPUpdate erstellt. Und wenn sie mal da sind, dann laufen sie auch.

Du führst angabegemäß folgenden Befehl aus: Wie wird denn daraus dieser Befehl aus der Fehlermeldung? Hast Du Remove-LocalGroupmember nachgebaut? (Edit: Bzw. hat das der Autor dieses Moduls nachgebaut?) Und um Lokalisierungsproblemen aus dem Weg zu gehen, könnte man sich die Well Known Groups auch gezielt holen (z.B. über den RID oder über die Builtin Roles). PS: Wenn Du die Member einmalig hinzufügst, könntest Du sie auch einmalig entfernen - Zielgruppenadressierung dazu, fertig.

Noooorbert...! Das hast Du sogar selber geschrieben: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Gut, könnte man mal alles in eine einzige GPO packen, per GPP Registry verteilen, dort mit Collections arbeiten, die ein ILT auf die Domainrole haben. Aber grundsätzlich ist es immer noch richtig

Das klingt NICHT nach diesem Skript als alleinige Ursache - Zitat von oben: Wenn das funktioniert, liegt es eher nicht am Skript, sondern an xyz, was in Deiner Umgebung auch noch so läuft.

Dann klemm schon mal die Beine zusammen, damit der Spagat nicht zu breit wird - sonst findst Dich in einer Reihe mit etlichen Kliniken und Stadtverwaltungen Sorry, aus meiner Sicht: Auch in "informierten" Unternehmen liegt die Hit Rate von APT bei deutlich über 20%, und da hilft nur "blocken, bis es weh tut".

Auch wenn hier eigentlich schon "zu" ist: Dem ist nichts hinzuzufügen. Wer in den Grundlagen verkackt, der verkackt auch im Endergebnis. Ich find's erschreckend, wie immer wieder sogar Behörden derart epic fail demonstrieren.

Dann mach das mal

Man möge mich als pedantisch bezeichnen, aber wo ist bei Kerberos der Zuammenhang zwischen Computer und User? Beide sind Security Principals, beide holen sich und haben dann auch unabhängig voneinander TGT und TGS. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)?redirectedfrom=MSDN (Immer noch einer der besten Grundlagen-Artikel dazu)

..man könnte auch auf die Idee kommen, die Replikation instant anzustoßen und gar nicht zu warten. ym2c...

1. rsop.msc ist deprecated 2. "gpresult /h report.html" in einer Admin-Commandline ist Dein Freund Und im Rest bin ich bei Sunny61: Das ganze funktioniert millionenfach recht problemlos, nur bei Dir nicht. Wo könnte das Problem liegen? Klar, das hilft Dir nicht, aber das Problem liegt in Deiner Umgebung bzw. in Deinem Verständnis dafür. Ich lehne mich mal etwas aus dem Fenster: Wenn ich vor Ort wäre und das Konstrukt live sehe, brauche ich keine 5 Minuten, um Dein Problem zu vestehen, zu erklären und zu beheben. Hier im Forum finden wir aber leider sehr oft "vor-interpretierte" Infos - und da fehlen dann entscheidende Merkmale.

Ich kenn da aus ferner Vergangenheit so ne Daumenregel, die sich bewährt hat: Ab 3 Installationen muß es automatisch gehen. Klingt wenig, stimmt aber.

Klar ist das Kerberos. Mit dem Admin-Kennwort, das Du beim Join eingibst (oder dem Offline-Join-File bei Prestaging) hat der Computer ein Secret, um einen Secure Channel aufzubauen, und dann geht auch Kerberos.

Der Computer wurde mal neu gestartet, seit er in der OU ist?

Ahem - grad mal geschaut, "Turn off the store" gibt es für User und Computer... Hast Du beides geprüft?

Korrekt. Mit Vista hat MS diese Profilordner-Versionierung eingeführt (damals V2), weil das in weiten Teilen nicht mehr wirklich kompatibel war zu XP.

Olaf, das hilft nicht viel - es ist jeweils "speziell". Offiziell ja eine einfache JScript-Funktion, aber der Teufel steckt im Detail.

Jede "einfache" Ausgabe eines Objekts (und $table ist ein Objekt) gibt per Default vordefinierte Eigenschaften aus - und fast nie sind das alle...

Doch, kann er. Für den Join braucht's kein NTLM.

Wo ich das grad noch mal so lese: Da ist wohl doch Loopback aktiviert - oder Du hast ein grundsätzliches Verständnisproblem beim Anwenden von GPOs. Vererbung blockieren ist halt Vererbung blockieren. Screenshots aus der GPMC wären jetzt echt hilfreich.

Dunkle Erinnerung - da gab es mal ein Problem mit der Größe... Wirklich testen kannst Du das nicht, nur ausprobieren.