Kopano Deskapp Rollout per Batchdatei

Ich habe mir zuletzt ein paar Gedanken darüber gemacht, wie man das Rollout von Kopano vereinfachen könnte. Nachdem das Paket als MSI Datei vorliegt, kann man es per WSUS Package Publisher ausrollen. Was aber, wenn man keinen WSUS / Package Publisher hat und sich dennoch, das „herumgerenne“ sparen will?

Remoteausführung auf dem Client-PC

Grundsätzlich muss die MSI-Datei mit Administratorrechten auf einem Remote-PC ausgeführt werden.

Bei einer Neuinstallation, kann das Setup einzig mit dem MSI Zusatzparameter /quiet angestoßen werden.

Aufpassen muss man, sofern eine bestehende Kopano DeskApp Installation aktualisiert werden soll! In der Regel, hat der Benutzer die Deskapp offen. Wenn man nun ohne Parameter – per Remote – eine Installation anstößt, dann startet der PC nach Fertigstellung der Installation von selbst neu, ohne Rücksicht auf offene Programme etc zu nehmen, oder den Benutzer zu informieren.

In meiner Testumgebung wurde der Parameter (sinngemäß) „Prompt for Restart“ ignoriert, weshalb ich auf den Parameter /norestart zurückgegriffen habe.

Die Crux: Der Benutzer sollte den PC nach der Installation möglichst zeitnah neu starten.

Tool zur Remoteausführung von Programmen

Einigen vermutlich gut bekannt, ist der Befehl „psexec“, enthalten im Paket Windows Sysinternals (Entwickler Mark Russinovich). (Download hier).

Bitte downloaden und installieren, ohne geht’s nicht.

Vorgangsweise

Die Installation soll per Batchdatei auf einem PC in der Adminkonsole (in der Domäne > Ausführung als Domänenadmin) angestartet werden. Diese kopiert notwendige Setupdateien auf den Ziel-PC und startet die Installation.

Vor Start der Installationsprozedur,  soll aber geprüft werden, ob der Ziel-PC überhaupt online ist, da es ansonsten zu einer nervigen Verzögerung kommt, bis Windows „merkt“, dass der PC nicht online ist.

Die eigentlichen Installationsparameter + Verweis auf die MSI Datei sind in einer eigenen Batchdatei enthalten.

Eine separate Batchdatei (die am Admin-PC gestartet wird) schaut so aus:

@echo off
ping -n 1 -4 %1 | findstr /r /c:“[0-9] *ms“

if %errorlevel% == 0 (
cls
echo ————————————————-
echo === DEPLOYING KOPANO DESKAPP 2 ===
echo ————————————————-
echo –> Kopiere kopano.bat nach \\%1\C$
copy \\server\Daten\deploy\kopano.bat \\%1\c$
copy \\server\Daten\deploy\kopano-deskapp-2.0.31-x64.msi \\%1\c$
echo –>Starte PSEXEC und fuehre Remoteinstaller aus…
psexec \\%1 -u domäne\administrator -p <geheimespasswort> c:\kopano.bat
goto ende
) else (
goto error
)
:error
cls
echo ——————————————————-
echo Ping nicht ok! PC offline bzw. falscher PC-Name?!
echo ——————————————————-
:ende

Per Ping wird geprüft, ob der PC online ist, wenn ja (=Errorlevel ist 0), werden die darauffolgenden Befehle abgearbeitet.

Das %1 ist der „Platzhalter“ für den PC-Namen der beim Aufruf der BAT Datei als Parameter übergeben wird.

Bsp: Angenommen ihr startet obiges BAT-File mit dem Namen „kopano.bat“, dann würde der korrekte Befehlsaufruf so aussehen:

kopano.bat pc-name

Das BAT-File mit den Setupparametern von Kopano und die MSI Datei selbst, liegen in dem Fall auf einem Server und werden auf den PC kopiert, auf dem die Installation angestoßen werden soll.

Die BAT Datei, die auf den jeweiligen PC kopiert wird, sieht so aus:

c:\kopano-deskapp-2.0.31-x64.msi /quiet /norestart

Fazit

Es gibt sicher noch viel bessere Lösungen und auch in diesem Fall viel Luft nach oben. Braucht man eine kurzfristige Lösung, läuft aber auch diese Herangehensweise ganz gut. So könnte man beispielsweise die Installation direkt über ein Netzwerkshare anstarten, auf das alle Benutzer Zugriff haben etc.

 

Anleitung – Local Update Publisher (LUP) Softwaredeployment

Jeder Admin (unter Windows) kennt wahrscheinlich das Problem: Windows und die gesamte Microsoft-Software-Schiene bekommt die Updates automatisiert via kostenlosem WSUS (Windows Server Update Services), aber was ist mit Software von anderen Anbietern? Spätestens wenn man an  das Java Runtime Environment, den Adobe Flashplayer, oder auch den Adobe Acrobat Reader denkt, vergrößern sich die -ohnehin schon vorhandenen- Sorgenfalten um ein Vielfaches.

Für große Umgebungen gibt es -wie soll es auch anders sein-  natürlich entsprechende Programme, um das gesamte System aktuell zu halten. Gerade aber im Bereich der kleineren und mittleren Umgebungen ist soetwas zu teuer.

Die Lösung

…lautet Local Update Publisher (kurz LUP). Obwohl es dieses tolle Tool schon länger gibt, bin ich erst vor ein paar Tagen darüber gestolpert. Damit LUP eingesetzt werden kann, muss ein WSUS Server im Netzwerk aktiv sein und korrekt funktionieren.

LUP kommuniziert mit dem WSUS  Server und „checkt“ Pakete in das WSUS-Software-Repository ein, abgesehen davon können mit dem LUP während der Paketerstellung Regeln definiert werden:

a.) Kriterien, ob das Paket auf den Clients schon installiert ist
b.) Auf welchen Rechnern das Paket überhaupt installiert werden soll (z.b. nur auf Clients mit Windows 7, oder nur Clients mit XP Pro SP3)

Signierung

Damit  Pakete in den WSUS eingecheckt werden können bzw. die Clients die von uns über den LUP erstellten Pakete überhaupt akzeptieren, müssen die Pakete signiert werden. Dies wiederum setzt voraus, dass ein entsprechendes Zertifikat vorhanden ist.

Auch hier gibt es nun 2 Varianten, wie man dieses Zertifikat erstellen kann:

  1. Man erstellt eine Kopie des -auf einem Windows Server vorhandenen – Zertifikates für „Code Signing“ (siehe bitte: http://infrablog.escde.net/2011/03/18/deployment-von-msp-updates-uber-wsus-teil-1-konfiguration/) -> Hierfür benötigt man aber die Enterprise Edition der Windows Server!
  2. Man verwendet das Zertifikat, welches beim Erststart vom LUP automatisch erstellt wird (für Umgebungen mit zb Windows Server STANDARD meiner Meinung nach die empfohlene Methode!)

Ich setze in diesem „How-To“ auf Variante b. -> also auf die Verwendung des „LUP-Zertifikates“.

 

Installation

Folgende Grundvoraussetzungen sind vor der Installation des LUP zu prüfen:

  • WSUS Server 3.0 SP2 vorhanden + einwandfreie Funktion?
  • .NET Framework in Version min. 3.5 installiert?
  • auf dem Client auf dem man LUP installiert -> WSUS Konsole vorhanden? Hier gibt es dann noch etwas, auf das man unbedingt achten muss. Im August 2012 wurde durch ein Update von MS der WSUS gehärtet (http://support.microsoft.com/kb/2720211). Hat man dieses Update auf dem Server eingespielt, muss man es auch auf dem Client einspielen, von dem aus man den WSUS administriert. (Also dort, wo die WSUS Konsole installiert ist).
  1. Zuerst müssen wir uns den LUP herunter laden: http://sourceforge.net/projects/localupdatepubl/files/ (hier bitte das MSI File nehmen)
  2. Dann starten wir die Installation auf einem beliebigen Windows Client (bevorzugt mittlerweile Windows 7!)
  3. Hierbei kann man die angebotenen Standardwerte einfach übernehmen

Der erste Start des LUP

LUP muss als Administrator (Domänen-Admin) ausgeführt werden.

Im darauffolgenden Fenster muss der Name (Netbiosname) des WSUS Server eingegeben werden. Standard ist ohne SSL. Habt ihr eine sichere Verbindung zum WSUS müsst ihr SSL aktivieren. (Anmerkung: Da LUP mehrere Sprachen beherrscht, kann man ihn – wie man unten sieht- auch auf Deutsch umstellen. Da die deutsche Übersetzung aber teilweise etwas unglücklich ist, rate ich dazu die Einstellung auf Englisch zu belassen bzw. auf Englisch umzustellen).

Habt ihr alles korrekt eingegeben sollte die Verbindung mit dem WSUS Server zustande kommen. Jetzt geht es dann langsam ans Eingemachte. Der LUP versucht nun ein Zertifikat vom WSUS herunter zu laden. Gelingt das nicht, schlägt LUP vor ein eigenes Zertifikat zu erstellen (self signed).

Wir lassen den LUP nun das Zertifikat entsprechend erstellen. Daraufhin öffnet LUP ein Fenster in dem euch das Zertifikat angezeigt wird.Ist das nicht der Fall gehen wir im LUP auf  Menü Tools -> Certificate Information.

Unten links in dem nun erscheinenden Fenster klicken wir auf „Export Certificate“ und speichern das Zertifikat unter einem aussagekräftigen Namen ab.

Anmerkung: Wie der Autor von LUP auf seiner Website erwähnt, ist das soeben exportierte Zertifikat in der Standardeinstellung für „all purposes“ –> also für ALLE ZWECKE verwendbar. Dies sollten wir auf  „Signature only“ –> also auf „nur signieren“ bzw. in der deutschen Version „Codesignatur“ umstellen.

Umstellen des Zertifikates auf „Codesignatur“

  • Unter Windows 7 starten wird die MMC (mit Adminrechten!)
  • Wir fügen das Snap-in „Zertifkate“ hinzu (wählen hier dann Computerkonto -> Lokaler Computer -> Fertigstellen -> Ok)
  • Wir navigieren in der Zertifikate MMC  zu Vertrauenswürdige Herausgeber -> Zertifkate
  • Rechtsklick auf Zertifikate -> Alle Aufgaben -> Importieren
  • Wir wählen das zuvor exportierte Zertifkat zum Import aus und bestätigen alles mit OK
  • Unter Vertrauenswürdige Herausgeber -> Zertifikate sollte nun ein „WSUS Publisher Self signed“ Zertifikat aufscheinen
  • Rechtsklick auf das Zertifikat -> Eigenschaften
  • Unter Zertifikatszwecke -> Nur für folgende Zwecke aktivieren -> Codesignatur
  • Mit Ok bestätigen
  • Rechtsklick auf das Zertifikat -> Alle Aufgaben -> Exportieren
  • Zertifikat unter einem eindeutigen Namen speichern
  • In der Zertifikats MMC das Zertifikat löschen

Das Fenster in der wir auf Codesignatur umstellen (Eigenschaften des Zertifikates) sieht so aus:

Wir verwenden ab hier nur noch das soeben exportierte Zertifikat!

Das Zertifikat auf die Clients bringen

Nachdem ich davon ausgehe, dass in einer Windows Domäne gearbeitet wird, ist der simpelste Weg, das Zertifikat auf die Clients auszubringen, die Verwendung der Gruppenrichtlinien. Wenn man noch Server 2003 bzw. Windows XP Clients einsetzt, müssen die folgenden Schritte von einer Windows 7 Maschine, die sich optimalerweise ebenso in der Domäne befindet, getätigt werden.

Vorarbeiten auf dem Windows 7 Client bzw. WSUS

  • RSAT auf Win7 Client installieren (http://www.microsoft.com/en-us/download/details.aspx?id=7887)
  • Per Wsus prüfen, dass die CSE (Client Side Extetnsions) auf den Windows XP Clients installiert sind.  (KB943729)
  • Auf dem Windows 7 Client -> Windows-Funktionen aktivieren deaktivieren -> Tools für die Gruppenrichtlinienverwaltung  (unter Remote-Serververwaltungstools -> Featureverwaltungstools) aktivieren -> OK

Eine Gruppenrichtlinie erstellen

Wir starten auf dem Windows 7 Client die MMC (als Domänen-Admin!) und fügen das Snap in „Gruppenrichtlinienverwaltung“ hinzu. Ihr solltet dann soetwas sehen (je nach Komplexität der Domänenstruktur):

In unserem Beispiel, nehmen wir an, dass alle Computer, die über den WSUS versorgt werden in der OU (Gruppenrichtlinie_Computer) enthalten sind. Deshalb passen wir nun diese Richtlinie an:

  • Bei Klick auf den Pfeil links neben der Richtlinie klappt dieser Eintrag „auf“ und man sieht die damit Verknüpften Richtlinien.
  • Wir klicken die gewünschte Richtlinie mit der rechten Maustaste an an und wählen „Bearbeiten“

Danach sollten wir in etwa soetwas angezeigt bekommen:

Bei Computerkonfiguration klappen wir folgende Menüs aus:

  • Windows Einstellungen -> Sicherheitseinstellungen -> Richtlinie für öffentliche Schlüssel -> Vertrauenswürdige Herausgeber
  • Importieren
  • Hier wählen wir dann das zuletzt exportierte Zertifkat (weiter oben nachzulesen)
  • Nach dem Importvorgang, klicken wir das Zertifikat mit der rechten Maustaste an und wählen „Eigenschaften“
  • Hier prüfen wir nochmals, ob das Zertifikat auf  Zweck -> Codesignatur eingestellt ist. Wenn nicht auf Codesignatur umstellen
  • Die exakt gleichen Schritte machen wir nochmals für : Windows Einstellungen -> Sicherheitseinstellungen -> Richtlinie für öffentliche Schlüssel -> Vertrauenswürdige Stammzertifizierungsstellen
  • Unter Computerkonfiguration -> Richtlinien -> Adminstrative Vorlagen -> Windows Komponenten -> Windows Update -> stellen wir „Signierte Updates aus einem Intranetspeicherort für Microsoft Updatedienste zulassen“ -> AKTIVIERT

Somit haben wir nun also die wichtigen Einstellungen für die Clients erledigt.

Auf dem WSUS Server habe ich die folgenden Schritte manuell erledigt:

  • MMC öffnen -> Zertifikate wählen
  • Computerkonto
  • Lokaler Computer
  • Schließen / OK
  • Vertrauenswürdige Stammzertifizierungsstellen -> Zertifikate -> Import -> Hier wieder das zuletzt erstelle LUP Zertifikat importieren
  • Vertraute Herausgeber -> Zertifikate -> Import -> Abermals das zuletzt erstellte LUP Zertifikat importieren
  • Snap in hinzufügen -> Gruppenrichtlinien Objekt Editor -> lokaler Computer
  • Einstellen:
  • Computerkonfiguration -> administrative Vorlagen -> Windows Komponenten -> Windows Update -> „Signierte Inhalte aus internem Speicherort für Microsoft-Updatedienste zulassen“ aktivieren

 Was sollte  jetzt funktionieren / geprüft werden

Wir haben in den vergangenen Schritten LUP installiert, alle Anforderungen überprüft und ggf. angepasst, ein Zertifikat erstellen lassen, eine GPO erstellt, die das notwendige Zertifikat für die entsprechende Computer – OU in der Domäne verteilen soll und schließlich auch auf dem Server einige Anpassungen vorgenommen.

Nun gilt es zu prüfen, ob die per GPO verteilten Zertifikate auch den Weg auf die Clients finden, die in der entsprechenden OU abgelegt sind.

Dies lässt sich leicht prüfen, in dem man auf einem beliebigen Client die Zertifikate MMC öffnet und nachschaut, ob unter den vertrauten Herausgebern bzw. auch unter den vertrauenswürdigen Stammzertifizierungsstellen unser Zertifikat auftaucht.

Es muss auf jeden Fall auf den Clients sein, bevor wir weiter machen können.

Anmerkung: Die Gruppenrichtlinien können auf einem Client per Befehl: gpupdate /force zur sofortigen Umsetzung angestoßen werden. Ein gpresult /r liefert u.a. Infos, welche Richtlinien umgesetzt wurden.

LUP starten und Updatepaket erstellen

Ich schicke gleich voraus, dass ich bislang nur mit EXE Paketen gearbeitet habe. Grundsätzlich funktioniert das Deployment mittles LUP so:

  1. Paket wählen
  2. Regel definieren, die prüft, ob das Paket auf dem Client schon installiert ist (am besten ging es bis jetzt mit Registrywert DisplayVersion unter Uninstall (genauere Info folgt unten))
  3. Regel definieren, die festlegt welche Anforderungen an den Client gestellt sind, damit das Paket überhaupt zur Installation angeboten wird (zb. Version von Windows größer oder gleich Win XP SP3)
  4. Paket für die entsprechende WSUS Gruppe (per LUP Console!!) freigeben (approved)
  5. Hoffen, dass alles klappt 😉

Detailiertere Vorgangsweise

  • LUP starten (als Domänen-Admin!)
  • Tools -> Create Update
  • Installationsdatei wählen (Zb. Adobe Reader, oder Flashplugin etc.)
  • Next
  • Ganz wichtig: Unter Command Line können / müssen Parameter eingegeben werden, damit die Installation Silent durchgeführt wird. Dieser Parameter ist bei jedem Programm anders. Bei Flash ist es -install:

  • Im nächsten Fenster müssen die Installed Rules angegeben werden. Dies sind die Bedingungen, die festlegen, ob ein Paket auf einem Client bereits vorhanden sind. Es bietet sich an, hier den Regkey (64-Bit Windows!) wobei das HKEY_LOCAL_MACHINE vorgegeben ist:
  • SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Adobe Flash Player ActiveX
  • Reg SZ Wert: DisplayVersion
  • Equal to
  • 11.4.402.287 (natürlich bei neueren Flashplayern anders! bitte Key selbst prüfen!)

zu verwenden.

Wichtig: Für 32-Bit Betriebssyteme muss noch eine zusätzliche Regel definiert werden! Diese sieht sehr ähnlich aus:

  • Im nächsten Fenster müssen die Installed Rules angegeben werden. Dies sind die Bedingungen, die festlegen, ob ein Paket auf einem Client bereits vorhanden sind. Es bietet sich an, hier den Regkey (32-Bit Windows!) wobei das HKEY_LOCAL_MACHINE vorgegeben ist:
  • SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Adobe Flash Player ActiveX
  • Reg SZ Wert: DisplayVersion
  • Equal to
  • 11.4.402.287 (natürlich bei neueren Flashplayern anders! bitte Key selbst prüfen!)

Hat man beide Regeln definiert, markiert man beide Regeln (STRG gedrückt halten) , danach klickt man auf Group und wählt „OR“. (Also eine ODER Regel, damit beide Varianten 32 und 64 Bit abgedeckt sind)

Zuletzt muss noch ein weiterer Regelsatz erstellt werden -> „Installable Rules“:

  • Hier kann man zb folgendes festlegen:
  • Rule Type: Windows Version
  • Comparision: Greater than or equal to Windows 7
  • Save Rule

Hier würden also nur Windows 7 Clients das Update bekommen.

Ab hier muss man dann eigentlich nichts mehr definieren, sondern kann sich mittels „NEXT“ durchklicken, bis das Paket erstellt wird.

Im LUP klickt man das Paket, welches man „Freigeben“ will mit rechts an und klickt auf „approve“.  Schließlich wählt man noch aus, für welche Gruppe von Computern (WSUS Gruppe) das Update freigegeben werden soll und die Sache sollte laufen.

Anmerkung zum Schluss: Die LUP Updates scheinen NICHT im WSUS auf,  sondern nur im LUP. Es macht also keinen Sinn, die selbst erstellten Updates im WSUS zu suchen. 🙂

Tips

32 Bit Registry

Bei aktiviertem „32 Bit Registry“ bei den installed rules wurde mir das Update immer wieder angeboten. Lösung: Häkchen nicht setzten

Falls ihr dennoch das Update immer wieder angeboten bekommt, schaut auch eure definierte „Installed rule“ nochmals an. Oft hat man hier einen Schreibfehler (z.b. ein Leerzeichen, wo keines hingehört)

Acrobat Reader

Dem Exe-Installer werden folgende Parameter mitgegeben, damit dieser „silent“ installiert bzw. das EULA automatisch auf „akzeptiert“ gestellt wird:

  • /msi EULA_ACCEPT=YES /qn

Adobe Flashplugin ActiveX

Dem Exe-Installer wird folgender Parameter mitgegeben, damit die Installation „silent“ erfolgt:

  • -install

Java Runtime Environment

Hier bedienen wir uns folgender Parameter:

  • /s /L C:\setup.log

…wobei an sich der Parameter /s hier reicht.

Windows 8

Nachdem ja mit morgigem Tag (26.10.2012) Windows 8 erscheint, habe ich bereits mit der Windows 8 Evalversion getestet. Bevor Ihr von einem WSUS 3.0 SP2 Updates in Richtung Win8 ausbringen könnt, müsst ihr KB2734608 auf dem WSUS Client Rechner (WSUS Konsole) und auf dem WSUS Server installieren. Nachdem das erledigt ist, müssen alle Packages im LUP „resigned“ werden.

Achtung: Das Self signed Serverzertifikat muss eine Schlüssellänge von mindestens 1024Bit haben! (prüfen!).

Bitte achtet darauf, dass ihr genügend Testläufe durchführt, bevor ihr eure Updates in das Produktivnetz ausrollt. Mit wenigen Clients zu testen, die verschiedene Versionen des OS installiert haben, macht hier am meisten Sinn.

Natürlich kann ich keine Verantwortung für eventuelle Probleme/Schäden etc. übernehmen.

 

Verteilen von Updates im Netzwerk: Flash, Acrobat, Java Runtime Environment aktuell halten

Hat man einige PC in einem Netzwerk zu betreuen, sollte man als „braver“ Admin möglichst dafür sorgen, dass diverse Sicherheitsupdates zeitnah eingespielt werden.

Am Beispiel eines Windowsnetzwerkes greift man für MS-Updates in der Regel auf den kostenlos erhältlichen WSUS (Windows Server Update Services) zurück. WSUS wird auf einen bestehenden Windows Server installiert. Danach erfolgt die Verteilung von Updates über entsprechend eingestellte Gruppenrichtlinien (z.B.: Alle Geräte in der Organisationseinheit „Verkauf“ bekommen die Updates zu einem bestimmten Zeitpunkt voll automatisch angeboten.)

Wie verhält es sich aber mit „Nicht-MS-Updates“. Vor allem der Adobe Acrobat Reader,  der Adobe Flashplayer und auch das Java Runtime Environment reissen nur all zu oft Sicherheitslücken auf.

Auch wenn ein PC noch so gut mit MS Updates versorgt wird, hilft es nichts, wenn dafür der Flashplayer, der Adobe Acrobat Reader, oder das Java Runtime Environment hoffnungslos veraltet ist.

Auf einem einzelnen PC ist auch das nicht das Problem, denn auch hier bekommt man entsprechende Updatemeldungen.

  • Was aber, wenn es sich um 100 PC handelt?
  • Die Anwender keine Berechtigung haben, etwas zu installieren bzw. herunter zu laden?

Problem 1: Wie komme ich an die Full Installer?

Problem 2: Welche Parameter benötige ich für eine „stille Installation“?

  • Flashplayer (für Internet Explorer):  install_flash_player_active_x.exe -install
  • Flashplayer (für Firefox/Mozilla): install_flash_player_plugin.exe -install
  • Adobe Acrobat Reader: AdbeRdr1014_de_DE.exe /msi EULA_ACCEPT=YES /qn
  • Java Runtime Environment: jre-7u7-windows-i586.exe /s /L C:\setup.log

Problem 3: Wie soll ich die Installationen Remote also „über das Netzwerk“ starten?

Hier gibt es viele verschiedene Möglichkeiten:

  1. Über Gruppenrichtlinien –> Die Datei wird in den Ordner Netlogon (des Server) gelegt und dann per Gruppenrichtlinie aufgerufen (hier kann es sinnvoll sein, ein eigenes Script/Batchdatei zu schreiben-> Systemkonfiguration\Startskript
  2. Man bedient sich des Befehls PSEXEC (ehem. Sysinternal-Tools) um die Befehlszeile Remote (mit einem Adminuser) ausführen zu können. Das ist natürlich bei -sagen wir- 100 PC mühsam
  3. Man greift zb auf „Purgos“ zurück. Dieses Tool ist zumindest in der Version 3 (noch) kostenlos (Genauere Infos hier: http://4sysops.com/archives/free-purgos-open-source-desktop-management-software-for-windows/)

Kurze Zusammenfassung zur Verwendung von Purgos

Zuerst installiert man die Serverkomponente auf dem PC, der der „Purgosserver“ sein soll. Hat man das erledigt, kann man die Client PC des Netzwerkes hinzufügen. Dies geschieht entweder per Angabe des IP Bereiches, oder der Namen der PC.  Abgesehen davon ist es auch möglich, direkt auf das Active Directory zuzugreifen, um die PC von dort zu „holen“.

Sind die Computer in Purgos „eingecheckt“, bringt man noch den Purgos Agent aus. (Man markiert unter „Managed Computer“ alle PC), klickt 1x rechts und wählt Agent/Software Config -> Install/Upgrade.

  • Nun erstellt man auf dem „Purgos Server“ einen Ordner und gibt diesen frei (Rechte -> Jeder -> lesen).
  • In diesen Ordner kopiert man die zuvor geladenen Files (Reader, Java, Flashplayer)
  • Danach „schreibt“ man sich -ebenso in dem Ordner- eine Batchdatei für jede Installation. Ich handhabe es so, dass ich die Installationsfiles zuerst auf den Client  kopiere, auf dem die Software installiert werden soll und dann erst die eigentliche Installation starte. Nach erfolgter Installation wird die Setupdatei dann vom Client gelöscht.

Die Batchdatei sieht zb so aus:

copy \\purgosserver\deploy\jre-7u7-windows-i586.exe c:\
c:
cd\
jre-7u7-windows-i586.exe /s /L C:\setup.log
del jre-7u7-windows-i586.exe

bzw.

copy \\purgosserver\deploy\install_flash_player_active_x.exe c:\
c:
cd\
install_flash_player_active_x.exe -install
del install_flash_player_active_x.exe

Schließlich wählt man in Purogs -> Action -> Execute Command und gibt folgendes ein (wobei der User, der hier angegeben wird (Alternate User) möglichst Administrator / Domänenadminrechte haben sollte!) Unter Command wird der Netzwerkpfad zur entsprechenden Batchdatei in Form von \\purgosserver\deploy\… angegeben.

Hat man das erledigt, kann man die vorgenommenen Einstellungen per Save As abspeichern.

Unter Managed Computer klickt man den Computer, auf dem das Script ausgeführt werden soll, mit der rechten Maustaste an und wählt „Execute Command …“ aus dem Kontextmenü aus. Abschließend wählt man den zuvor gespeicherten Befehl aus.

Das Manko bei dieser doch recht einfach gehaltenen Variante ist, dass Purgos offenbar keine Fehlerbehandlung durchführt. Selbst wenn im Script zb die Datei nicht gefunden werden kann, attestiert Purgos ein „Successfully executed…“. Hier dürfte sich Purgos rein auf die Batchdatei beziehen, nicht jedoch auf die Befehle in der Batchdatei.

Die „schönere Variante“ dürfte wohl die Erstellung eines entsprechenden MSI-Software-Paketes sein. Selbst das lässt sich mit Purgos erledigen.

Fazit

Die Installation von Updates lässt sich mit diversen Hilfstools sehr stark vereinfachen. Das Problem ist jedoch, dass selbst bei aktuellstem Patchstand, immer noch Sicherheitslücken vorhanden sein können. (siehe Oracle Java Runtime Environment: Hier wurde erst Ende August mit Version: 7.07 eine kritische Lücke gepatcht. Kurz nach dem Patch ist aber schon die nächste kritische Lücke gefunden worden. Patch gibt es allerdings noch immer keinen…)