daabm

"net localgroup" und dann je nach Sprache "net localgroup administrators" oder "net localgroup administratoren". Was hat C:\Users damit zu tun? Und einen gibt es IMMER - SID "-500"...

Wie Nils sagt: Eine abstrakte DNS Domain, die der Firma GEHÖRT! Und das AD dann als Sub-Domain. Beispiel: Registrierte Domain: we-are-a-weird-company.de AD: total-nerds.we-are-a-weird-company.de Dann hast nie wieder Probleme mit AD-Renames oder DNS-Domains

@NorbertFe hat Recht. klist /purge schmeißt alle Tickets weg, beim ersten Zugriff auf eine Ressource wird ein neues Ticket angefordert, in dem die neue Gruppenmitgliedschaft enthalten ist. Klappt aber nur, wenn auch wirklich Kerberos am Start ist. Bei NTLM "ab und wieder anmelden"...

Ich bin ja schon bekannt für süffisante Kommentare, aber Deinen Humor verstehe nicht mal ich. Schönen Tag noch - und denk mal über %%a nach.

Olaf, man kann keine Denkfehler im Code haben, nur im Kopf SCNR...

Ja, ist es. Bei schtasks übrigens ähnlich... Das ist völlig wirr, was da lokalisiert wird und was nicht.

Nein, ist es nicht. Schlußendlich arbeitet ja alles, wie es soll - nur das MSI im Installer-Cache fehlt, deshalb schlägt die Deinstallation fehl. Wenn ich Freelancer wäre, würde ich dem TO ein Angebot zur Verhandlung über einen Vorort-Termin per PN schicken. Bin ich aber nicht, das scheidet also aus. Technisch ist das Problem identifiziert, nur "vorort gelöst" werden muß es jetzt noch Ach, btw: msizap aus dem Office Resource Kit wäre da auch noch ein nützliches Werkzeug. Aber nur, wenn man weiß, was man tut.

Sunny, fast "uneingeschränkt" gilt das für Administrative Vorlagen, ja. Viele andere CSEs haben da oft abweichendes Verhalten, aber die machen ja auch nicht nur trivial Reg-Werte... Die ADM-Templates verschwinden tatsächlich einfach so, wenn das (oder "die" - die Diskussion hatte ich mit MS Press seinerzeit auch) GPO gelöscht wird. Aber nur diejenigen, die auch per GPO kamen - setzt Du einen Reg-Wert in einem der 4 Policies-Keys manuell, überlebt der.

Nur so am Rande: %a und %%a ist Dir bekannt?

VM-Sync abschalten. Nur dann weiß man sicher, woher die Zeit kommt (oder kommen sollte). Wenn 2 Zeitprovider aktiv sind, hat das immer Potential für Irritationen...

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.