Softwarezuweisung - Software im Unternehmen verteilen

09.03.2013 | Autor: Mark Heitbrink

Softwareverteilung mittels Gruppenrichtlinien ist eine Möglichkeit. Die GPSI (Group Policy Software Installation) hat  aber in größeren Umgebungen einige Schwachpunkte:

  • es gibt kein Feedback, die Clients melden weder Erfolg noch Misserfolg
  • es gibt kein Reporting, Inventarisierung und Verwaltung der Software ist darüber nicht möglich.
  • es gibt keine aktuelle Übersicht. Wer läd gerade die Software? Wer installiert? Wer hat Fehler gemeldet? Wer macht gerade was?
  • die GPSI läuft nur im Vordergrund. Homeoffices/Road Warrior können nur über Site-To-Site VPN oder Direct Access mit Software bestückt werden
  • es gibt keinen Download Cache. Die Installation muss online erfolgen
  • einmal integrierte Pakete lassen sich nicht nachträglich mit einem MST (Transform) manipulieren. Das ist ein Klassiker bei der Verteilung von Office 2003. Seit Office 2007 ist das Problem aufgrund der geänderten Installationtechnik von Office nicht mehr so kritisch, aber wie das Beispiel Acrobat Reader zeigt noch immer relevant.
  • Der Pfad aus dem die Pakete installiert werden trägt sich am Client ein, bei Änderung der Ressource ändert sich nicht der Pfad am Client. Das führt zu Problemen bei Änderungen, Update und Deinstallation
  • die GPSI kann nur MSI Pakete verteilen, keine Legacy Executables, auch wenn diese Silent/Unattended Switche kennen würden. Für diese gibt es ZAP Pakete, kleine Textdateien in denen die Commandline drinsteht. Diese können aber nur PRO Benutzer veröffentlicht werden und laufen auch in seinem Kontext. (Siehe: Software Installation als Benutzer)

Lösung für oben genannte Problem
Ganz viel Scripting und manuelles anpassen der Installation, eventuell sogar Umstellung der Installation auf ein Computer Startup Script, da im Script alle Probleme direkt abgefangen werden können. Vorausgesetzt man kann scripten ... 
Einfacher ist der Einsatz einer professionellen Software, wie Specops Deploy von Special Operation Software die ich absolut empfehlen kann. Als Freeware bietet der WPP - WSUS Package Publisher eine gute Lösung. Der LUP - Local Update Publisher läuft leider aktuell nicht  unter Windows Server 2012, somit ist er keine Alternative für die Zukunft.

Empfohlene Grundkonfiguration für die GPSI

  1. Software wird immer nur PRO COMPUTER verteilt. Ein Office wird ja auch nicht mehrfach auf dem Rechner installiert, was "pro Benutzer" passieren würde ... (Ausnahmen bestätigen die Regel)
  2. Software wird "zugewiesen" nicht "veröffentlicht", d.h. sie wird direkt installiert, ohne weiteren Benutzereingriff. Die Veröffentlichtung muss der Benutzer initiieren, der ist damit überfordert.
  3. Die Softwarepakete liegen in einem DFS Stamm. Der Domänenname ändert sich normalerweise nicht mehr. Die Server darunter können ausgetauscht werden
  4. Es gibt eine Freigabe z.B.: Clients, auf dieser haben entweder Authentifizierte Benutzer oder Domänen-Computer Lesen Rechte, denn der Computeraccount benötigt Zugriff auf diese Share
  5. Pro Software wird EINE Gruppenrichtlinie erstellt. Richtlinien können "nach oben" und "nach unten" sortiert werden und damit lassen sich Abhängigkeiten und Reihenfolgen festelegen. Es lassen sich zwar mehrere Pakete in einer GPO verpacken, aber die Reihenfolgen können nicht festgelegt werden. 
  6. Wer ein MST (Transform) verteilen möchte, der integriert es direkt bei der Erstellung des Softwarepakets.

Schritt für Schritt Anleitung am Beispiel vom Acrobat Reader 11.x

1. Das erste Problem beim Acrobat ist: Wo kriege ich das MSI her? Hier hilft ein wenig suchen mit eine Suchmaschine eurer Wahl. Acrobat baut immer nur für die Major Verionen eigene MSI Installationen. Ihr nehmt das MSI von der 11er Version und macht das Update mittels MSP Paket und SlipStream auf die 11.0.0.x.
ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.00/de_DE/
ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.01/misc/ 
ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.02/misc/

Das MSP integrieren wir per SlipStreaming in das vorhandenen MSI. Die MSPs sind nicht kumulativ, d.h. ihr müsst erst das 01 anwenden, dann das 02, dann das ...

msiexec.exe /a AdbeRdr11000_de_DE.msi /p AdbeRdrUpd11001.msp /qb

Wenn der Acrobat Reader schon verteilt wurde und man möchte eine aktualisierte Version Verteilen, dann  geht der Weg über das Kontextmenü des in der Gruppenrichtlinie hinterlegten Pakets -> Alle Aufgaben -> Erneut bereitstellen

2. Wir passen das vorhandenen MSI mit dem Customization Wizard von Adobe an:
ftp://ftp.adobe.com/pub/adobe/acrobat/win/11.x/11.0.00/misc/

Hilfe zum Wizard und auch zur Installation von Adobe selbst gibts hier

Damit können wir zB den EULA akzeptieren, das Update Verhalten einstellen, das DesktopIcon entfernen etc. Die Datei speichern wir als AcrobatReader.mst

3. Wir brauchen eine Freigabe. Ihr habt noch nie einen DFS Stamm eingerichtet und möchtet das auch garnicht? Dann ist der einfachste Weg: Nehmt doch den, den ihr schon habt!
Euer SYSVOL der Domäne ist ein DFS Stamm und ist immer über \\eure.dom\sysvol zu erreichen. Dieser wird auch zwischen den DCs repliziert, d.h. wir erzeugen hier Traffic, wenn die DCs an verteilten Standorten stehen aber wir verteilen damit auch automatisch die Installations Ressource, sodass der entfernte Standort automatisch die Dateien aus seinem Standort nutzt und nicht für die Installation über die WAN Strecke muss.

Auf der einen Seite ist der Missbrauch des SYSVOLS etwas unschön, auf der anderen bietet er aber auch Vorteile.

Erstellt euch unterhalb vom NETLOGON einen neuen Ordner SoftDeploy. Darin legen wir jetzt pro Produkt immer neue Ordner an, sodass jede Applikation nach Ordnern getrennt vorliegt.

UAC Besonderheit: Damit ihr eine UAC Elevation Aufforderung bekommt müsst ihr den Lokalen PFad auf dem DC verwenden um die Ordner zu erstellen und die Dateien abzulegen:
C:\Windows\SYSVOL\sysvol\gallier.ads\scripts\

Sieht dann so aus:

4. Wir erstellen eine neue Gruppenrichtlinie: C_SW_Acrobat_Reader
Siehe: Erstellen einer Richtlinie

Wir verlinken die Richtlinie an der OU der Computer, die die Software erhalten sollen. Alternativ können wir die Richtlinie auch mit anderen Filtern (Sicherheitseinstellungen  oder WMI) bestücken, wenn die Computerziele OU übergreifend sind. Siehe: Filtern von Gruppenrichtlinien anhand von Benutzergruppen, WMI und Zielgruppenadressierung

Editieren: Computerkonfiguration \ Richtlinien \ Softwareeinstellungen \ Softwareinstallation

Pfad: \\eure.dom\NETLOGON\Softdeploy\AcrotbatReader

6. Achtung, Stolperfalle: Wenn ihr jetzt "Zugewiesen" auswählt, dann können wir kein Transforms Paket mehr integrieren. Also wählen wir "Erweitert".

7. Allgemein
zur Information, Anzeigename könnte geändert werden, aber wozu?

8. Bereitstellen der Software
Hier entscheidet sich das Verhalten, was mit der Software passiert, wenn ich den Computer aus dem Verwaltungsbereich der Richtlinie entferne. Bleibt die Software erhalten, oder wird sie entfernt? Das Feld ist optional und ist eine Überlegung, die jeder selber treffen muss. Darf Software erhalten bleiben, wenn der Computer verschoben wird? Das kann auch von Paket zu Paket unterschiedlich sein.

9. Aktualisierungen
Eventuell wird durch diese Paket ein anderes ersetzt, wird normalerweise nicht benötigt

10. Kategorien
Ob ihr eure Software in Kategorien einteilt ober nicht, ist euch überlassen. Ich persönlich nutze diese Funktion nicht. Warum soll ich etwas kategoriesieren, was ich garnicht ordentlich auswerten kann? Die GPSI kenn sowas nicht. Also ist es mit recht egal, ob ich weiss "wie viele verschiedene PDF Reader" ich verteile.

11. Änderungen
Hier gehört unser Transforms Paket rein, das wir mit dem Adobe Customization Wizard gebaut haben.

12. Sicherheit
Ihr könnt innerhalb der Softwarezuweisung das Paket auf bestimmten Sicherheitsgruppen filtern. Dieser Filter funktioniert ähnlich dem, den ihr auf der Richtlinie definieren könnt, allerdings wird er später ausgewertet. Das bedeutet, wenn die Richtlinie selbst schon vom Ziel nicht gelesen werden kann, dann wird der Filter "innerhalb" nicht mehr bewertet.
Die Richtlinien könnte "für alle" gelten, abder diese Paket speziell nur für die Computer aus der "Buchhaltung".

Da wir PRO Software eine eigene GPO erstellen, hat dieser Filter für uns keine Bedeutung.

13. Windows 7 übernimmt die Richtlinien beim nächsten Neustart. Windows XP erst nach dem 2ten Neustart. Beim ersten Start stellt XP fest: Hoppla da war ja Software zum installieren, beim 2ten Mal macht es das dann auch.