11
Suche Java und Flashplayer remote installation deinstallations software
Wie in der Überschrift erwähnt suche ich eine effiziente Lösung
Tach & danke schonmal fürs hinein schauen.
Ich habe die Lösung sowohl den Flashplayer & auch Java per Gruppenrichtlinie (MSi Paket) zu verteilen.
Doch diese Lösung ist nicht effektiv weil man in der AD herum fummeln muss ohne Ende.
Was ich Suche ist eine komfortablere Lösung, eine Möglichkeit unabhängig von der AD Struktur, einfach Verschiedene
Verteilerlisten zu erstellen die es ermöglichen das jeweilige Installerpaket für die jeweilige definierte Gruppe an PCs zu pushen.
Das ganze per Skripting zu erledigen ist nicht nur n kack schreibkram sondern auch wenig elegant & nicht wirklich praktisch.
Wir haben keine Microsoftlösungen zur Softwareverteilung im Einsatz - einzig einen Wsus. Und da ist das selbe Problem mit der
schlechten Verwaltungsstruktur. Also fällt der Wsus als Verteiler auch aus.
Gibt es eine Lösung die es ermöglicht auf einem WIN XP Client oder Windows 2008 Server eine Listen basierende Verteilung zu
erhalten? Zb. mit einer Blacklist zum ausklammern Problematischer PCs (alte Java version zwingend erforderlich, die neue ist inkompatibel).
Ich kann mit orca problemlos MSI editieren. Auch MST Dateien erzeugen stellt kein Problem dar.
Eine Lösung ähnlich der gruppenrichtlinien Verteilung wäre nice - nur eben mit dem luxus das die AD Struktur unangetastet bleibt.
Gibts da ne schlaue funktionierende Lösung die sich eingebürgert hat?
Tach & danke schonmal fürs hinein schauen.
Ich habe die Lösung sowohl den Flashplayer & auch Java per Gruppenrichtlinie (MSi Paket) zu verteilen.
Doch diese Lösung ist nicht effektiv weil man in der AD herum fummeln muss ohne Ende.
Was ich Suche ist eine komfortablere Lösung, eine Möglichkeit unabhängig von der AD Struktur, einfach Verschiedene
Verteilerlisten zu erstellen die es ermöglichen das jeweilige Installerpaket für die jeweilige definierte Gruppe an PCs zu pushen.
Das ganze per Skripting zu erledigen ist nicht nur n kack schreibkram sondern auch wenig elegant & nicht wirklich praktisch.
Wir haben keine Microsoftlösungen zur Softwareverteilung im Einsatz - einzig einen Wsus. Und da ist das selbe Problem mit der
schlechten Verwaltungsstruktur. Also fällt der Wsus als Verteiler auch aus.
Gibt es eine Lösung die es ermöglicht auf einem WIN XP Client oder Windows 2008 Server eine Listen basierende Verteilung zu
erhalten? Zb. mit einer Blacklist zum ausklammern Problematischer PCs (alte Java version zwingend erforderlich, die neue ist inkompatibel).
Ich kann mit orca problemlos MSI editieren. Auch MST Dateien erzeugen stellt kein Problem dar.
Eine Lösung ähnlich der gruppenrichtlinien Verteilung wäre nice - nur eben mit dem luxus das die AD Struktur unangetastet bleibt.
Gibts da ne schlaue funktionierende Lösung die sich eingebürgert hat?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 162463
Url: https://administrator.de/forum/suche-java-und-flashplayer-remote-installation-deinstallations-software-162463.html
Ausgedruckt am: 04.04.2025 um 11:04 Uhr
11 Kommentare
Neuester Kommentar
Also wenn man eine gut strukturiertes AD hat, dann ist eine Verteilung darüber einfach, dasselbe gilt für den WSUS.
Wir lassen ausschließlich unsere Softwareinstallation über das AD laufen und Windows Update über den WSUS und ich kann super überwachen, ob die Software/Updates installiert wurden. Ziemlich alles auf einen Blick.
Also m.E. sehr effizient.
Wir lassen ausschließlich unsere Softwareinstallation über das AD laufen und Windows Update über den WSUS und ich kann super überwachen, ob die Software/Updates installiert wurden. Ziemlich alles auf einen Blick.
Also m.E. sehr effizient.
Bei uns laufen aber auch diverse Technologien wie Citrix auf der AD zusammen. Es ist momentan weder per Standort noch per PC Typ / Server korrekt unterteilt. (Es wurde so von meinem Vorgesetzten eingeführt & der streubt sich also MUSS ich ohne kompliziertere AD Strukturen auskommen).
Ich möchte ungern eine Struktur schaffen die hinter der Niederlassung mit X Ordnern je Software und version existieren.
Denn das müsste ich machen, Neu Gruppe - neue gruppenrichtlinie mit angepasstem Pool & das je Niederlassung für jede Software.
Und die Installation wäre nur dann aktiv wenn der PC in den Ordner verschoben wird. Und beim Neustart machst klick und druff is.
Das is ja auch einfach - und funktioniert bereits.
Sicher, das passt wenn man viele PCs (ab 300 oder mehr) verrsorgen muss. Aber es ist leider so das mit jeder neuen Instanz das gesamte Gruppenrichtlinien Gedöns immer weiter anschwillt bis die gesammte Verwaltung - absolut unnötig aufgeplustert ist. Und irgendwann heist es dann Sainonara - passt nicht mehr überein mit der neuen Struktur der AD 2018. Dann darf man alles zurückschrauben & von grund auf neu anlegen. Und das nur wegen etwas so trivialem wie Flashplayer und Java.
Ich will einfach nicht das die Software sofort ausgetragen wird - ich will mir die Kontrolle bewahren sagen zu können:
Der, der & der sollens bekommen - der aber nicht. Und ich will das das beim Nächsten Start passiert.
Das erzeugt das Problem das ich also entweder JEDEN PC einzeln verschieben muss - oder aber eine Gruppe mit "sonder PCs" erzeuge in der wieder Ordner mit X Unterteilungen existieren die aber eben halt auch nicht permanent gelten. Weil der Wsus auch schon eine eigene Richtlinie hat die den Clients ihre Start Skripts etz zuweist.
Am Ende blickt keine Sau mehr durch welche Gruppenrichtlinie wo wie und warum zieht & man hat ein hausgemachtes und überflüssiges Chaos in der Gruppenrichtlinien Verwaltung. Ausserdem weis man am Ende auch nicht mehr welche Gruppenrichtlinnie nun von welcher was geerbt hat. Es reicht das ein schlauer Kollege die Vererbung unterbricht um seine Software ein zu binden.
Und warum? Nur weil es keine gescheite Verwaltung gibt die erlaubt ausserhalb der AD eine Logische unabhängige stuktur zu erschaffen. Um eine Banalität wie Java oder Flashplayer immer Up to Date zu halten.
Verteilung per Gruppenrichtlinie ist nur dann ein Mittel zum zweck wenn man wirklich mit Bestimmtheit sagen kann kriegt jeder - braucht jeder.
Dann is es ok - aber Flexibilität ist und war NIE die Stärke der AD Softwareverteilung. Denn Microsoft hat da andere Technologien die das übernehmen. Kostenpflichtig Entwickelt. Nur ich seh nich ein das ich für sowas wie Java oder Flash eine Lösung für mehere tausend € bezahlen muss nur weil die ihre updates uns sicherheitslücken nich in Griff kriegen.
Ich will doch nix unmögliches. Die AD ist gut Strukturiert den sie ist nicht unnötig verschachtelt. Alles was du nennst - macht die AD Struktur nur undurchsichtlicher. Und das ohne wirklich flexibel zu sein.
Ich möchte ungern eine Struktur schaffen die hinter der Niederlassung mit X Ordnern je Software und version existieren.
Denn das müsste ich machen, Neu Gruppe - neue gruppenrichtlinie mit angepasstem Pool & das je Niederlassung für jede Software.
Und die Installation wäre nur dann aktiv wenn der PC in den Ordner verschoben wird. Und beim Neustart machst klick und druff is.
Das is ja auch einfach - und funktioniert bereits.
Sicher, das passt wenn man viele PCs (ab 300 oder mehr) verrsorgen muss. Aber es ist leider so das mit jeder neuen Instanz das gesamte Gruppenrichtlinien Gedöns immer weiter anschwillt bis die gesammte Verwaltung - absolut unnötig aufgeplustert ist. Und irgendwann heist es dann Sainonara - passt nicht mehr überein mit der neuen Struktur der AD 2018. Dann darf man alles zurückschrauben & von grund auf neu anlegen. Und das nur wegen etwas so trivialem wie Flashplayer und Java.
Ich will einfach nicht das die Software sofort ausgetragen wird - ich will mir die Kontrolle bewahren sagen zu können:
Der, der & der sollens bekommen - der aber nicht. Und ich will das das beim Nächsten Start passiert.
Das erzeugt das Problem das ich also entweder JEDEN PC einzeln verschieben muss - oder aber eine Gruppe mit "sonder PCs" erzeuge in der wieder Ordner mit X Unterteilungen existieren die aber eben halt auch nicht permanent gelten. Weil der Wsus auch schon eine eigene Richtlinie hat die den Clients ihre Start Skripts etz zuweist.
Am Ende blickt keine Sau mehr durch welche Gruppenrichtlinie wo wie und warum zieht & man hat ein hausgemachtes und überflüssiges Chaos in der Gruppenrichtlinien Verwaltung. Ausserdem weis man am Ende auch nicht mehr welche Gruppenrichtlinnie nun von welcher was geerbt hat. Es reicht das ein schlauer Kollege die Vererbung unterbricht um seine Software ein zu binden.
Und warum? Nur weil es keine gescheite Verwaltung gibt die erlaubt ausserhalb der AD eine Logische unabhängige stuktur zu erschaffen. Um eine Banalität wie Java oder Flashplayer immer Up to Date zu halten.
Verteilung per Gruppenrichtlinie ist nur dann ein Mittel zum zweck wenn man wirklich mit Bestimmtheit sagen kann kriegt jeder - braucht jeder.
Dann is es ok - aber Flexibilität ist und war NIE die Stärke der AD Softwareverteilung. Denn Microsoft hat da andere Technologien die das übernehmen. Kostenpflichtig Entwickelt. Nur ich seh nich ein das ich für sowas wie Java oder Flash eine Lösung für mehere tausend € bezahlen muss nur weil die ihre updates uns sicherheitslücken nich in Griff kriegen.
Ich will doch nix unmögliches. Die AD ist gut Strukturiert den sie ist nicht unnötig verschachtelt. Alles was du nennst - macht die AD Struktur nur undurchsichtlicher. Und das ohne wirklich flexibel zu sein.
Hi.
Es ist nicht leicht, Dir zu folgen, wenn Du so viel schreibst. Fass die Frage kleiner und übersichtlicher.
Warum arbeitest Du nicht mit ACLs auf MSI-Paketen ("Sicherheitsfilterung")? Also z.B. Java 1.6.24 darf nur die Gruppe java_1.6.24 installieren oder aber mit Verweigerungen arbeiten.
Ich wüsste nicht, wie dieses Prinzip noch vereinfacht werden könnte, ohne die OUs zu ändern.
Zu den Deinstallationen: die MSI-Pakete können doch die Deinstallationen von alleine machen - sag genauer, was das Problem hierbei ist.
Es ist nicht leicht, Dir zu folgen, wenn Du so viel schreibst. Fass die Frage kleiner und übersichtlicher.
Warum arbeitest Du nicht mit ACLs auf MSI-Paketen ("Sicherheitsfilterung")? Also z.B. Java 1.6.24 darf nur die Gruppe java_1.6.24 installieren oder aber mit Verweigerungen arbeiten.
Ich wüsste nicht, wie dieses Prinzip noch vereinfacht werden könnte, ohne die OUs zu ändern.
Zu den Deinstallationen: die MSI-Pakete können doch die Deinstallationen von alleine machen - sag genauer, was das Problem hierbei ist.
Das klingt interessant. Wie funktioniert das mit ACLs?
In den Eigenschaften des MSI-Paketes (aufgerufen innerhalb der GPO) ist ein reiter Sicherheit. Da kannst Du Domänengruppen/-nutzer berechtigen.
Trotzdem is mit etwas unklar..
Ich erstelle also je Paket eine Gpo die dann zb. heißt Flashplayer10x_install in dieser Definiere ich was installiert werden soll. Also das MSI Paket - Dann definiere ich eine eigene Verteilergruppe für jedes Softwarepaket und füge innerhalb der jeweiligen Gpo diese Verteilergruppe dann in dem Reiter Sicherheit hinzu??
Und weise dann die Verteilergruppe dem PC jeweiligen PC zu?
Dieser zieht sich dann die GPO & somit die Installationsanweisung??
Habe ich das so richtig verstanden?
Ich erstelle also je Paket eine Gpo die dann zb. heißt Flashplayer10x_install in dieser Definiere ich was installiert werden soll. Also das MSI Paket - Dann definiere ich eine eigene Verteilergruppe für jedes Softwarepaket und füge innerhalb der jeweiligen Gpo diese Verteilergruppe dann in dem Reiter Sicherheit hinzu??
Und weise dann die Verteilergruppe dem PC jeweiligen PC zu?
Dieser zieht sich dann die GPO & somit die Installationsanweisung??
Habe ich das so richtig verstanden?
Ja, hast Du.
Du kannst auch eine einzige GPO nehmen und in dieser mehrere Pakete zuweisen - ganz wie du magst.
Du kannst auch eine einzige GPO nehmen und in dieser mehrere Pakete zuweisen - ganz wie du magst.
Irgendwie wills ned klappen.
Checkliste
Gruppenrichtlinienverwaltung:
1) Ich habe eine OU Gruppen darin habe ich eine OU "Softwareverteilung" erstellt.
2) Im Anschluss habe ich in der OU Softwareverteilung eine GPO "GPO Java installation" erstellt. Dieser das MSI Paket zugewiesen.
-> Die MSI Datei ist in dem Falle ein Java + eine Konfigdatei. Das Paket ist auch "zugewiesen".
AD Benutzer & Gruppen
3) Dann habe ich in der Gruppe "Softwareverteilung" eine Verteilergruppe - Local (in domäne) erstellt. Die ich mal
frei "VTG JAVA" benannt habe.
4) Als nächstes habe ich einen PC in diese Gruppe "VTG JAVA" eingefügt.
Zum Schluss habe ich die "GPO Java installation" erzwungen & den Test PC der in der Gruppe VTG JAVA Hängt neu gestartet.
Passiert is nix. GPRESULT zeigt aber auch an das die Gruppenrichtlinie - warum auch immer nicht auf der Kiste aktiv ist. OBWOHL
sie es sein müsste..
Sie Sache mit der Gruppenzuweisung (VTG JAVA) über die ALC, auf die MSI direkt ist nicht machbar. Er akzeptiert nur User keine Gruppen.
Was mach ich falsch?
Checkliste
Gruppenrichtlinienverwaltung:
1) Ich habe eine OU Gruppen darin habe ich eine OU "Softwareverteilung" erstellt.
2) Im Anschluss habe ich in der OU Softwareverteilung eine GPO "GPO Java installation" erstellt. Dieser das MSI Paket zugewiesen.
-> Die MSI Datei ist in dem Falle ein Java + eine Konfigdatei. Das Paket ist auch "zugewiesen".
AD Benutzer & Gruppen
3) Dann habe ich in der Gruppe "Softwareverteilung" eine Verteilergruppe - Local (in domäne) erstellt. Die ich mal
frei "VTG JAVA" benannt habe.
4) Als nächstes habe ich einen PC in diese Gruppe "VTG JAVA" eingefügt.
Zum Schluss habe ich die "GPO Java installation" erzwungen & den Test PC der in der Gruppe VTG JAVA Hängt neu gestartet.
Passiert is nix. GPRESULT zeigt aber auch an das die Gruppenrichtlinie - warum auch immer nicht auf der Kiste aktiv ist. OBWOHL
sie es sein müsste..
Sie Sache mit der Gruppenzuweisung (VTG JAVA) über die ALC, auf die MSI direkt ist nicht machbar. Er akzeptiert nur User keine Gruppen.
Was mach ich falsch?
GPOs wirken nicht auf Gruppen, Nur auf User/Computer.
Du sagtest doch das ich eine GPO erstellen soll in der ich das MSI Paket einhänge. Dann einen Gruppe erzeuge und diese dann zuweise.
Das bedeutet doch das die GPO dann nur für die Gruppe zählt & somit wirkt es auf die Gruppe. Oder besser auf die User/PCs innerhalb der Gruppe...
Sonst macht es doch keinen SINN. Ich brauche Verteilergruppen. Und wenn die GPO mit dem Paket nun nich auf eine Gruppe wirkt - kann ich auch keine Installer Pakete für Gruppen zuweisen.
Ich konnte nun zumindest die Gruppe in die Sicherheit einfügen nachdem ich keine Verteiler sondern Sicherheitsgruppe ausgewählt habe.
Was aber an sich unlogisch ist. Da ich ja etwas Verteilen will - hatte ich bisher mit einer "Verteilergruppe" gearbeitet. ODer brauche ich beides? Eine Verteilergruppe zur Definition der Computer die sich in der Gruppe befinden & eine Sicherheitsgruppe die dann auch sicherstellt das das Softwarepaket auch WIRKLICH nur an berechtige Mitglieder der Gruppe "java installation" verteilt wird??
Irgendwie is das ganze Konzept von Microsoft doch total bescheuert oder besser UMSTÄNDLICH gelöst.
Anstatt es simple zu halten, muss man sich durch 1000 Menüs und Untermenüs und darin dann in Sicherheitsreitern etz. durchkämpfen. Und trotzdem gehts nicht..
Das bedeutet doch das die GPO dann nur für die Gruppe zählt & somit wirkt es auf die Gruppe. Oder besser auf die User/PCs innerhalb der Gruppe...
Sonst macht es doch keinen SINN. Ich brauche Verteilergruppen. Und wenn die GPO mit dem Paket nun nich auf eine Gruppe wirkt - kann ich auch keine Installer Pakete für Gruppen zuweisen.
Ich konnte nun zumindest die Gruppe in die Sicherheit einfügen nachdem ich keine Verteiler sondern Sicherheitsgruppe ausgewählt habe.
Was aber an sich unlogisch ist. Da ich ja etwas Verteilen will - hatte ich bisher mit einer "Verteilergruppe" gearbeitet. ODer brauche ich beides? Eine Verteilergruppe zur Definition der Computer die sich in der Gruppe befinden & eine Sicherheitsgruppe die dann auch sicherstellt das das Softwarepaket auch WIRKLICH nur an berechtige Mitglieder der Gruppe "java installation" verteilt wird??
Irgendwie is das ganze Konzept von Microsoft doch total bescheuert oder besser UMSTÄNDLICH gelöst.
Anstatt es simple zu halten, muss man sich durch 1000 Menüs und Untermenüs und darin dann in Sicherheitsreitern etz. durchkämpfen. Und trotzdem gehts nicht..
Nun scheints zu gehen.
Ich habe die GPO neben die Globale Richtlinie gelegt. Und per Sicherheitsfilterung die Gruppe definiert für wen diese Richtlinie gelten soll.
Das Probem warum die Austragung nicht stattgefunden hat lag in der Zuweisung der Gruppenrichtlinie. Besser gesagt in der Hirachie.
Da ich aus Testzwecken die Gruppenrichtlinie nicht so weit oben über der gesammten Firmenstruktur haben wollte -
habe ich diese in den Gruppenorder eingefügt. In der Annahme das durch die Gruppe - also die Zuweisung des PCs -
dieser dann auch die GPO zugewiesen bekommt.
Da die Clients ausserhalb dieser Hirachie in einem Order Clients liegen (und nicht unter Softwareverteilung) - sorgte dies dazu das die GPO ausserhalb der Sichtweite der Clients lag. Diese hatten zwar die Zuteilung zur Gruppe (auf welche die Gpo angewendet wurde) jedoch da keine direkte Sicht darauf vorhanden war - wurde trotz korrekter Konfiguration der Gpo & Gruppe diese nicht angewendet.
Sehen kann man das recht leicht durch GPResult. Demnach hatte DerWoWusste vollkommen Recht es war nur etwas knapp erklärt als das ich es im ersten Moment geblickt habe.
Danke für die Hilfe - ein Gutes haben die 2 Tage Sucherei - nun bin ich weit aus Fitter als vorher was Gruppenrichtlinien & co angeht. Und die Lektion is gefressen
Ich habe die GPO neben die Globale Richtlinie gelegt. Und per Sicherheitsfilterung die Gruppe definiert für wen diese Richtlinie gelten soll.
Das Probem warum die Austragung nicht stattgefunden hat lag in der Zuweisung der Gruppenrichtlinie. Besser gesagt in der Hirachie.
Da ich aus Testzwecken die Gruppenrichtlinie nicht so weit oben über der gesammten Firmenstruktur haben wollte -
habe ich diese in den Gruppenorder eingefügt. In der Annahme das durch die Gruppe - also die Zuweisung des PCs -
dieser dann auch die GPO zugewiesen bekommt.
Da die Clients ausserhalb dieser Hirachie in einem Order Clients liegen (und nicht unter Softwareverteilung) - sorgte dies dazu das die GPO ausserhalb der Sichtweite der Clients lag. Diese hatten zwar die Zuteilung zur Gruppe (auf welche die Gpo angewendet wurde) jedoch da keine direkte Sicht darauf vorhanden war - wurde trotz korrekter Konfiguration der Gpo & Gruppe diese nicht angewendet.
Sehen kann man das recht leicht durch GPResult. Demnach hatte DerWoWusste vollkommen Recht es war nur etwas knapp erklärt als das ich es im ersten Moment geblickt habe.
Danke für die Hilfe - ein Gutes haben die 2 Tage Sucherei - nun bin ich weit aus Fitter als vorher was Gruppenrichtlinien & co angeht. Und die Lektion is gefressen
