Richtige Methode zum Aktualisieren von Google Chrome MSI über Gruppenrichtlinien

Ich stelle Chrome über Gruppenrichtlinien bereit. Das funktioniert gut.

Offensichtlich hat Chrome einen ziemlich regelmäßigen Aktualisierungszyklus. Ich erlaube Domänenbenutzern nicht, Chrome-Updates zu installieren.

Was ist der "richtige" Weg, um ein Chrome-MSI bereitzustellen, nachdem Sie den Release-Blog abonniert und ein neues Release-MSI heruntergeladen / getestet haben?

Beispiel: Verwenden Sie die integrierte MSI-Aktualisierungsfunktion für Gruppenrichtlinien? Überschreibe ich die MSI-Datei mit einer neuen? Lösche ich die Richtlinie und erstelle eine neue, die mit der neueren MSI verknüpft ist? Oder erlaube ich Domänenbenutzern, Chrome-Updates automatisch durchzuführen?

PS Nebenbei bemerkt, wenn diese Frage als nicht konstruktiv abgelehnt, geschlossen oder als geschlossen eingestuft wird, werde ich mich wahrscheinlich umbringen. Du wirst Blut an deinen Händen haben.

— George
quelle

+1 für das Nachskript

— Ryan Ries

Haha danke. Ich bin sehr frustriert über die Menge an legitimen Fragen (einige meiner eigenen), die in der gesamten Stack Exchange-Community übermodernisiert werden. Seit ich SO vor ein paar Jahren zum ersten Mal benutzt habe, sind die Dinge wirklich bergab gegangen, imo natürlich.

— George

pretty regular update cyclehmm. ganz. Der Grund, warum wir es hier nicht verwenden.

— Tombull89

@ tombull89 Im Gegensatz zu beispielsweise Flash, Reader, Java oder Windows? :)

— Jscott

@George Der Google Update Service aktualisiert Chrome und die mitgelieferte Version von Flash Player. Die ActiveX / Plugin (Mozilla) -Versionen von Flash Player sind davon nicht betroffen.

— Jscott

Antworten:

Sie müssen letztendlich prüfen, ob Chrome aktualisiert werden kann oder nicht - schlagen Sie vor, eine Richtlinie in einer Test-Organisationseinheit mit einem Computer darin zu erstellen.

Wenn es aktualisiert werden kann, können Sie jedes Mal ein neues MSI zum selben Gruppenrichtlinienobjekt hinzufügen und es ausrollen lassen.

Wenn Sie die Option " Diese Anwendung deinstallieren, wenn sie nicht mehr im Verwaltungsbereich liegt " deaktivieren, können Sie alte MSIs aus dem Gruppenrichtlinienobjekt entfernen, ohne zu versuchen, eine Deinstallation auf den Clients durchzuführen, wenn diese ihre Richtlinien das nächste Mal aktualisieren.

Ich weiß, dass ich mit diesem Programm nicht ganz spezifisch war, aber ich hoffe, dass dies trotzdem hilft. Mit Feedback kann die Antwort wahrscheinlich spezifischer für Chrome gemacht werden, aber ihr Unternehmens-MSI ist als solches nicht speziell, es ist nur ein MSI!

BEARBEITEN / ANTWORTEN / LÖSUNG:

Nur um die Antwort auf diese Frage zusammenzufassen (basierend auf der weiteren Diskussion in den Kommentaren unten).

Erstellen Sie ein Gruppenrichtlinienobjekt für die Handhabung von Chrome (dies ist nur eine gute Idee für die Organisation).
Fügen Sie bei jeder Veröffentlichung eines Chrome-Updates die MSI als neuen zugewiesenen Eintrag im Abschnitt Softwareinstallation des Gruppenrichtlinienobjekts hinzu.
Achten Sie darauf, deaktivieren Sie die „Software deinstallieren , wenn es Spielraum geht“ Option
Da ein Gruppenrichtlinienobjekt in einer alten> neuen Reihenfolge angewendet wird, können Sie die Softwarezuweisungen für alte Chrome-Versionen sicher löschen, indem Sie nur die neueste Version und eine oder zwei vorher beibehalten.

Gutschrift an Snellgrove.

— Snellgrove
quelle

Vielen Dank für die Veröffentlichung, dies ist hilfreich. Ich habe festgestellt, dass sich Chrome durch Hinzufügen eines neuen MSI anscheinend selbst aktualisiert. Ich befürchte jedoch, dass ich innerhalb weniger Monate eine Menge redundanter alter MSIs haben würde. Ihr dritter Absatz ist besonders hilfreich - da ich weiß, dass ich das MSI jetzt einfach mit einer neuen Version überschreiben kann, vorausgesetzt, das Kontrollkästchen ist deaktiviert. Vielen Dank.

— George

Um dies weiter zu verdeutlichen, müssen Sie es nicht überschreiben, sondern nur das nächste MSI zum gleichen Gruppenrichtlinienobjekt hinzufügen. Wenn also ein neuer PC der Domäne beitritt und von dieser Richtlinie betroffen ist, durchläuft er die Richtlinie und installiert die MSI-Dateien der Reihe nach. Die MSIs haben Priorität (im Grunde genommen die ältesten zuerst). Das, was Sie wahrscheinlich tun möchten, ist, nur die alten MSI-Dateien zu entfernen, damit nur die vorherigen (falls ein Rollback erforderlich ist) und die neuesten im Gruppenrichtlinienobjekt verbleiben. HTH!

— Snellgrove

Oh, richtig, genau das habe ich getan. Kann ich also nur klarstellen: Ein Gruppenrichtlinienobjekt; mehrere MSI-Zuweisungen (jede Version); die ältesten MSI-Dateien löschen und nur die letzten beiden übrig lassen?

— George

Das war's, verfahrenstechnisch. Es liegt natürlich an Ihnen, ob Sie eine frühere Version verlassen oder nicht, oder vielleicht mehr! Dies dient nur dazu, die Arbeit zu vereinfachen, wenn Sie eine Version zurücksetzen müssen. Alternativ können Sie alle Ihre MSIs in einem Ordner irgendwo aufbewahren ( ich gehe davon aus, dass Sie wie die meisten Leute einen Binär- und Download-Speicherauszug haben! ), Um sie an ein Gruppenrichtlinienobjekt anzuhängen.

— Snellgrove

Danke, das ist großartig. Ich habe Ihre Antwort akzeptiert und bearbeitet, um hier eine Zusammenfassung der Diskussion aufzunehmen. Die Prüfung durch Fachkollegen steht noch aus, aber ich bin sicher, dass dies im Interesse der Fertigstellung ein guter Schritt sein wird. Danke für all deine Zeit.

— George

Ich weiß, dass Sie bei Verwendung einer GP-Verwaltungssuite eines Drittanbieters (wie PolicyPak) MSIs problemlos als Updates / Upgrades für vorhandene Installationen veröffentlichen können. Das MSI wird als Update und nicht als vollständige Installation ausgeführt. So hat der Ort, an dem ich im letzten Frühjahr / Sommer gearbeitet habe, Updates und dergleichen verwaltet.

— Akolyth
quelle

Möchte Lösungen von Drittanbietern nach Möglichkeit vermeiden, aber danke für Ihren Vorschlag :)

— George

Das ist gerecht genug.

— Akolyth