daabm

Ich würde ja mit Telnet anfangen und schauen, ob ich vom Server ein EHLO bekomme... Ohne das ist alles weitere zum Scheitern verurteilt.

Manche möchten das - warum auch immer. https://www.grouppolicy.biz/2012/07/how-to-configuring-ie-site-zone-mapping-using-group-policy-without-locking-out-the-user/ beschreibt das korrekte Vorgehen.

Also ich nicht. Ich lese auch keine Anleitungen... Du etwa?

gpresult /r ist etwas sparsam in der Anzeige - besser wäre gpresult /h report.html. Und natürlich die Ereignisanzeige. Gruppenrichtlinien haben seit 2005 ein eigenes Eventlog (Anwendungs- und Dienstprotokolle/Microsoft/Windows/GroupPolicy:Operational)

Ich hätte auch PSCustomObject empfohlen, wenn ich den Thread vor Olaf gesehen hätte Du kannst aber auch an die originären VM-Objekte zusätzliche Properties pappen, kommt auf das gleiche raus.

Ja, ich kenne eines Lies Dir das hier zweimal durch: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Dann reden wir darüber, wie man das für lokale Admins auf Clients total einfach nutzen kann.

Warum setzt Du das als Regwert und nicht über https://gpsearch.azurewebsites.net/#1492 oder https://gpsearch.azurewebsites.net/#1493?

DAS wiederum unterstütze ich ohne Einschränkung

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