GPO Zur Installation von Software Sorgt für Probleme

[BimBamBino 0]

Vielen dank für eure Unterstützung!

 

Ich hab die Ansätze von Sunny ausprobiert, aber leider hat gpupdate /target:user nichts geändert. Und auch die GUID konnte ich nirgendwo auf dem AD finden. 

 

vor 1 Stunde schrieb daabm:

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.

Wenn ich daabm richtig versteh, habe ich zwei Möglichkeiten. Zum einen könnte ich in der Registry nach {C6DC5466-785A-11D2-84D0-00C04FB169F7} prüfen und den Eintrag ggf. löschen?

 

vor 1 Stunde schrieb 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.

Wäre es auch eine Möglichkeit die alte GPO aus einem Backup wieder herzustellen um diese dann zu deaktivieren? Ich bin immer sehr unsicher, wenn es darum geht,  in der Registry etwas zu löschen. 

 

vor 1 Stunde schrieb daabm:

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.

Den Entrag zu dem zu installierenden Programm konnte ich finden. Nun habe ich aber leider noch nicht verstanden was ich nun mit der Information machen muss. 

 

 

 

[NorbertFe 1.800]

vor 4 Minuten schrieb BimBamBino:

Wäre es auch eine Möglichkeit die alte GPO aus einem Backup wieder herzustellen um diese dann zu deaktivieren? 

Ja. Aber warum die Angst vorm löschen? ;)

[daabm 1.185]

vor 21 Stunden schrieb NorbertFe:

Ja. Aber warum die Angst vorm löschen? ;)

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.

[NorbertFe 1.800]

Ja könnte man... ;)