Wie ist die Syntax zur Erstellung einer Verknüpfung?

Die Syntax bzw. Abfolge der Angaben ist wie folgt.

<Verknüpfung>, <Kommando>, <Argumente>, <Arbeitsverzeichnis>, <Beschreibung>, <Symboldatei>, <Symbolindex>, <Fensterzustand>, <Tastenkombination>

Es müssen nicht alle Angaben gesetzt werden, wie die nachfolgenden Beispiele zeigen.

Beispiele:

;---Erstellung einer einfachen Verknüpfung auf dem Desktop abhängig von CommonShellLinks
%Desktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer einfachen Verknüpfung auf dem Desktop aller Benutzer unabhängig von CommonShellLinks
%CommonDesktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer Verknüpfung auf dem Desktop aller Benutzer
%CommonDesktop%\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü abhängig von CommonShellLinks
ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü Ordner "MyComany" unabhängig von CommonShellLinks
%CommonPrograms%\MyCompany\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

Besonderheiten

Die mittels Shell:Product erstellen Verknüpfungen werden beim Deinstallieren auch wieder entfernt. Möchte man beim Installieren Verknüpfungen entfernen, so geht das nur über den Del bzw. Deltree Befehl.

Beispiele:

;---löschen des Startmenü Ordners MyComany
Deltree "%CommonPrograms%\MyCompany"

;---löschen einer Verknüpfung vom Desktop aller Benutzer
Del "%CommonDesktop%\ServicePortal.lnk"

;---löschen einer Verknüpfung vom Desktop des jeweiligen angemeldeten Benutzers - Achtung: Das Paket muss mit /AW ausgeführt werden.
Del "%UserDesktop%\ServicePortal.lnk"

Abhängigkeiten

Die Shell:Product Ausführung ist von mindestens zwei Eigenschaften in der Application Sektion abhängig

CommonShellLinks=[1|0]
Wenn CommonShellLinks den Wert 1 hat, so ist die Variable %Desktop% gleichzusetzen mit %CommonDesktop%, genauso wie %Programs% mit %CommonPrograms%.
Ist der Wert 0, so ist %Desktop% gleichzusetzen mit %UserDesktop% und %Programs% mit %UserPrograms%.

ShellLinks=[0|1]
Ist der Wert 1, werden die Verknüpfungen erst am Ende der Installation, für jede Option der Abschnitt [Shell:<Option>], automatsich erzeugt ohne explizit aufgerufen zu werden. Ist der Wert 0, können Verknüpfungen auch durch den direkten Aufruf von #Shell:<Option> erstellt werden.

Der Beitrag Verknüpfungen / Links erstellen erschien zuerst auf Workplace Management Blog.

Das im Anhang zusammengestellte Verfahren aus Skripten erweitert den OS-Installer bzw. die Installation von Computern.

Meines Erachtens bietet dies dann:

• Einfachere Integration von einer Vielzahl von Treibern.
• Einfachere Aktualisierung der Treiber in der Test und Integrations-Phase
• Schnellere Einbindung neuer Hardwaretypen
• Einfachere Übernahme in einer andere Empirum Installation (Test, QA, Produktion)
• Einfache Installation von hardwarespezifischen Treibern und Software per EXE und MSI.

Vorbereitungen

Verzeichnisse und Skripte

Was ist vorzubereiten, was wurde angepasst und was ist in der Download Datei?

• End_winvista.eis Script
• Vorlage (Template) für ein Hardwareprofil mit div.Logik
• Batch-Datei zur Installation von hardwarespezifischer Software je Hardwareprofil nach der OS-Installation

Angepasstes End_winvista.eis Script

Die angepasste „end_winvista.eis“ prüft, ob im Hardwareprofil-Ordner ein PnP Ordner vorhanden ist. Wenn dieser existiert, wird der Pfad zum PnP Ordner zu den Plug & Play-Pfaden für die OS-Installation hinzugefügt. Das bedeutet, dass dieser Ordner während der Windows Installation nach passenden Treibern durchsucht wird. Es ist zu prüfen, ob bereits Änderungen an der End_winvista.eis (Empirum\Empinst\Wizard\Scripts2\Custom) durchgeführt wurden. Wenn dies der Fall ist sind die Änderungen zusammenzuführen (die beigefügten Zeilen werden dann angehängt).

Hinweis: Zwei Aufrufe in der End_winvista.eis sind Empirum Versions abhängig. Nur die Zeilen der eingesetzten Empirum Version aktivieren!

Batch Datei für den Aufruf nach der OS-Installation

• Installation des .NET Framework 3.5 SP1 oder 4.0 und ggf. weiterer Hotfixe (optional)
• Aufruf einer Setup.inf, falls vorhanden, zur Installation weiterer Treiber und Software (siehe Hardwareprofil)
• Installation des Internet Explorers (optional)
• Schreiben von Hardware und OS-Installations Informationen in die Registry für die spätere Verwendung (optional – nicht enthalten)
• Aufruf der von Matrix42 gelieferten EmpirumAgent.bat

Kopieren der Empirum\Configurator\User\PostOSInstallation_W<OS><Architektur>.bat in den Empirum\Configurator\User Ordner. Einige Treiber und zusätzliche Software setzen das .NET Framework voraus, weshalb es hier direkt installiert wird. Hier wird entweder das .NET Framework über ein vorhandenes Paket installiert, oder separat. Wenn ein Paket vorliegt, wird der Aufruf zur Installation des .NET Framework 4.0 adaptiert, ansonsten verfährt man wie bei .NET Framework 3.5 aufgezeigt. Die Quellen dazu müssen in diesem Fall noch integriert werden, wie in der „Missing Files.txt“ Datei angegeben.

Die Installation des Internet Explorers und des .NET Framework Paketes sind nicht zwingend erforderlich. Gerade das Paket für den Internet Explorer muss selbst beigesteuert werden.

EmpirumAgent.bat

Beim Aufruf zur Installation des Empirum-Agenten in der EmpirumAgent.bat wird an die Zeile ein /X8 zur Unterdrückung des Neustarts angefügt. Dies sorgt für einen zuverlässigeren Ablauf der Skripte.

Call \\%EmpirumServer%\Configurator$\User\Setup.exe \\%EmpirumServer%\Configurator$\Packages\matrix42\EmpirumAgent\%EmpirumVersion%\Install\Setup.inf /S1 /X8

Betriebssystemvorlage

In der bzw. den genutzten Betriebssystemvorlagen wird der „Abschließende Befehl“ angepasst. Hier wird nun, je nach Betriebssystem die oben erstelle PostOSInstallation_W<OS><Architektur>.bat aufgerufen. Wenn Sie keine unterschiedlichen Installationen hinsichtlich des Betriebssystems an dieser Stelle durchführen, können Sie auch nur eine PostOSInstallation_W7.bat o.ä. erstellen.

Vorgehensweise und Ablauf

Was ist nun bei einer Einbindung eines neuen Hardwaretyps zu tun?

• Einbinden der Netzwerkkarte, wie gehabt (optional)
• Einbinden der Grafikkarte, wie gehabt (optional)
• Erstellen eines Hardwareprofils mit der Angabe eines Ordner (letztes Feld) (Wichtig! – Namen merken!)
• Kopieren der Vorlage in den erstellten Hardwareprofilordner
• Ablegen der weiteren PnP Treiber in den Hardwareprofilordner\PnP
• Einbinden von Treiber bzw. Softwareinstallationen per EXE/MSI (Ablage in HWspecificSW und anpassen der HWspecificSW\Setup.inf)

Erstellen eines Hardwareprofils

Der erste Schritt ist die Erstellung eines Hardwareprofils in der Management Console, unter Konfiguration, OS-Installer, Hardware, Hardwareprofil. Matrix42 Hilfe bis Punkt 14 durchführen.

Wo befindet sich das Hardwareprofilverzeichnis?

Anschließend wird der Ordner des erstellten Hardwareprofils mit den weiteren Treibern und ggf. Aufrufen versehen. Das Verzeichnis für das Hardwareprofil befindet sich je nach Architektur des Betriebssystems in den hier angegebenen Pfaden.

• X86 = Empirum\Empinst\DRV\Win7\HWMisc
• X64 = Empirum\Empinst\DRV\Win7\x64\HWMisc

Hardwareprofil

Es liegt eine Vorlage für ein Hardwareprofilordner in Empirum\Empinst\DRV\Win7\<Architektur>\HWMisc\_Template vor, damit alle Skripte zusammen funktionieren. Bitte jeweils für x86/x64 die Datei „Missing Files.txt“ in „HWspecificSW\VCRe100“ beachten, da hier ggf. noch die notwendigen Dateien abgelegt werden müssen. Nachfolgend ist die Wirkungsweise und Nutzung der Verzeichnisse und Skripte im Hardwareprofil erläutert. Es kann auch ohne die VCRedist100 Dateien getestet werden.

PNP Verzeichnis

Wie zuvor beschrieben, dient das PNP Verzeichnis zur Ablage mehrerer Verzeichnisse mit Treibern die während der OS-Installation durchsucht werden.  Das heißt, hier können weitere Verzeichnisse erstellt werden, die dann wiederum die notwendigen Plug & Play (kurz PnP) Treiber beinhalten. Dieses Verzeichnis kann auch mit einer Zusammenstellung von DoubleDriver befüllt werden, dass zuvor mit Hilfe eines Backups von einem vorhandenen System erstellt wurde. Eine andere Methode ist es die DriverPacks, DriverKits, SCCM Driver Packages, o.ä. die Hersteller wie Dell, Fujitsu, HP, uvm. bereitstellen, entpackt in den PnP Ordner abzulegen.

Install\Setup.inf

Die Setup.inf im Install Ordner sorgt für das Kopieren des HWspecifcSW Ordners nach %WinDir%\HWspecifiSW, damit er nach der OS-Installation zur Verfügung steht. In meinem Falle wird die Setup.inf des HWspecifSW Ordners durch die PostOSInstallation_W<OS><Architektur>.bat aus Empirum\Configurator\User aufgerufen. Zusätzlich kann hier bereits eine VCRedist Installation stattfinden, da dies von immer mehr Grafikkartentreibern vorausgesetzt wird.

Aufgrund dessen, dass im Hardwareprofilordner ein Install Ordner mit einer Setup.inf liegt, bedarf es der Anpassung der End_Winvista.eis (siehe oben). Matrix42 erstellt für jeden Treiberordner in dem sich eine Install\Setup.inf befindet einen Installationsbefehl (Früher: EmpirumJob=Yes) und nimmt diesen Ordner nicht in die PnP Pfade mit auf.

HWspecificSW Verzeichnis

In diesem Verzeichnis werden Treiber und Software für diesen Hardwaretyp abgelegt, die mittels einer EXE oder MSI installiert werden. Die Durchführung der Installation(en) findet nach der OS-Installation und vor der EmpirumAgent Installation im Kontext des lokalen Administrators statt. Beispielhafte Aufrufe dazu befinden sich in der HWspecificSW\Setup.inf Datei. Es bietet sich an, für die Treiber ggf. nochmals Unterverzeichnisse zu erstellen. Wird kein Treiber oder sonstige hardwarespezifische Installation nach der OS-Installation mehr benötigt, kann dieser Ordner auch weggelassen werden. Wenn die PostOSInstallation_W<OS><Architektur>.bat keine Setup.inf im %WinDir%\HWspecificSW findet, wird auch keine Installation durchgeführt.

Weitere Optimierung

PostDelaySeconds

Falls die PostDelaySeconds Variable noch nicht als Betriebssystemvariable in der Empirum Management Console vorhanden ist, so sollte diese noch erstellt und auf den Standardwert 180 gesetzt werden.

Empirum Management Console starten, im Menü unter  „Extras, Variablendefinition“

• Variable: PostDelaySeconds
• Variablentyp: Betriebssystem
• Kontrollelement: Zahl
• Null-Wert erlauben: Ja
• Standardwert: 180

Falls der Wert trotz Standardwert nicht in die Variablendateien der Computer eingetragen wird, so hilft ein Setzen der Variable auf die oberste Konfigurationsgruppe und Aktivierung der „Zwangsvererbung“.

Fertig

Das sollten alle Schritte sein, damit die „Rädchen“ ineinander greifen. Diese Methode kann auch für Windows 8, 8.1 übernommen werden.

Viel Spaß und einfache Umsetzung wünsche ich Euch!

Benötigte Dateien für den oben genannten Ablauf:  TreiberFramework (3124 Downloads )

Der Beitrag Empirum Treiberintegration – einfacher gemacht! erschien zuerst auf Workplace Management Blog.

ErrorCodes

Die Rückmeldungen von ausführbaren Dateien haben unterschiedliche Bezeichnungen, wie z.B.: ReturnCode, ErrorCode, ErrorLevel, etc. Hier hatte ich bereits einige bekannte Fehler aus dem „DOS“ Umfeld aufgelistet. Jeder ErrorCode für einen vom Entwickler definierten Fehlergrund. Ist kein Fehler aufgetreten, so ist der ErrorCode = 0. Microsoft nutzt z.B. durchweg den ErrorLevel 3010, der bedeutet das diese Installation einen Neustart benötigt. Dieser ReturnCode wird von Microsoft auch bei weiteren Installationsroutinen genutzt. Nun gibt es jedoch noch eine große Liste an weiteren Rückmeldungen. Diese sind zumeist etwas schwieriger heraus zu bekommen.

Nachfolgend zwei Listen, die ich im Internet gefunden habe, mit Hinweisen bzw. Kurzerläuterungen zu diversen ErrorCodes im Windows Update Umfeld:

• http://inetexplorer.mvps.org/archive/windows_update_codes.htm
• http://support.microsoft.com/kb/938205

Der Beitrag ErrorCodes – Windows Update erschien zuerst auf Workplace Management Blog.

Empirum Inventory Konfiguration

Damit man die genaue Dateiversion hier angezeigt bekommt, muss man die Konfiguration der Inventarisierung anpassen. Dazu wechselt man in der Management Console unter Konfiguration, Inventory auf das Register Inventory-Konfiguration und öffnet über den „Datei, Öffnen“ Dialog die EmpInvScan_Windows.xml.

Anschließend wählt man in der rechten Baumansicht „Dateisuche“ aus. Nun fügen wir unter der Dateisuche Einträge hinzu (Link zur WebHilfe).Hierbei ist nur der Dateiname, Hersteller und Anwendungsname auszufüllen! Den Rest erledigt die Inventarisierung durch den Parameter /V2 für uns.

Die folgende Liste enthält Beispiele, die je nach Wunsch angepasst werden kann.
Hersteller, Anwendungsname, Dateiname
Matrix42, Empirum Inventory, %SYSTEM%\Empirum\EmpInventory.exe
Matrix42, Empirum Remote Installer Service, %SYSTEM%\Empirum\ERIS.exe
Matrix42, Empirum Personal Backup, %SYSTEM%\Empirum\PBackup.exe
Matrix42, PM3Client, %ProgramFiles%\Matrix42\PM3Client\PM3Client.exe

Hier auch Beispiel für eine nicht Matrix42 Komponente:
Microsoft, Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

Wenn die Einstellungen vorgenommen wurde, muss die Konfiguration gespeichert werden.
Für die letztendliche Nutzung muss die Konfiguration je nach Infrastruktur ggf. noch auf SubDepots synchronisiert und mittels des EmpirumAgenten auch noch auf die Clients synchronisiert werden. Ab diesem Zeitpunkt sollte dann das Inventory „auskunftsfreudiger“ sein. Hierzu finden sich dann genauere Versionsangaben unter „Inventory\Dateien“ und „Inventory\Software“ eines jeden Computers.

Diese Informationen können natürlich dann auch über Filter, etc. ausgewertet werden.

Der Beitrag Ermittlung installierter Programm-Versionen erschien zuerst auf Workplace Management Blog.

Um die Betriebssystemquellen bzw. Installation aktuell zu haben, muss die in den Windows 7 Installationsquellen enthaltene „install.wim“ aktualisiert werden. Dazu gibt es grob gesagt zwei Methoden.

1. Man „mounted“ die install.wim Datei (ein Image) mit den Microsoft WAIK bzw. WADK Hilfsmitteln und integriert die Updates (zumeist *.msu oder *.cab Dateien) und „dismounted“ die Datei anschließend wieder.
2. Man führt eine Windows 7 Installation durch, aktualisiert sie nach eigenem „Gusto“, generalisiert die Installation und erstellt davon ein Image (install.wim).

Beide Methoden sind im Internet mehrfach erläutert und erklärt. Nachfolgend möchte ich die Methode der Integration der Updates in die „install.wim“ erklären, für die jedoch „keine Gewähr“ übernommen wird!

Ich habe es mir möglichst einfach gemacht und nutzte Hilfsmittel, in Form von Tools aus dem Internet. Natürlich kann man auch komplett auf die Werkzeuge von Microsoft „bauen“.

1. Schritt – Zusammenstellen der Updates

Damit ich nicht zu lange nach den benötigten Updates nach Windows 7 SP1 suchen musste, habe ich mich dem Windows Updates Downloader und der aktuellen Update Liste bedient.

Die aktuelle Update Liste für die entsprechende Windows Version samt Architektur (x86/x64) integriert man über das grüne „+“ Symbol neben dem „Update List“ Auswahlfeld.

Hier habe ich die „Non-Security Updates“ und „Security Updates“ komplett ausgewählt und herunterladen. Die Dateien werden in dem „Download Folder“ angegebenen Pfad in entsprechende Unterordner abgelegt.

2. Schritt – Integrieren der Updates in die install.wim Datei.

Vor der Integration der Updates habe ich die aktuell genutzten Betriebssystemquellen aus dem entsprechenden Unterverzeichnis von \\%EmpirumServer%\EmpInst$\SYS\Win7\<Architektur>\pro\1  auf den lokalen Computer heruntergeladen.

Zur Integration der Updates habe ich mir dann wiederum dem „Win Toolkit“ (http://www.wincert.net/forum/files/) bedient. Darin habe unter „Main“, „Basic“, den „All-In-One Integrator“ gestartet.

Im nachfolgenden Dialog habe ich zum lokalen Ordner der Betriebssystemquellen und darin wiederum in den VistaDVD Ordner navigiert (Browse: Browse DVD) und das enthaltene Betriebssystem ausgewählt (Select bzw. Doppelklick).

Im nachfolgenden Dialog wechselt man dann auf den Reiter „Basic“, „Updates + Languages“ und fügt über das große grüne „+“ Symbol am linken Rand die Updates zur Integration hinzu. Hierbei habe ich zuerst die die Dateien aus dem „Non Security Updates“ Ordner und dann die Dateien aus dem „Security Updates“ Ordner ausgewählt.

Der letzte Schritt im „Win Toolkit“ ist „Start“ (oben links) zu wählen. Jetzt beginnt der mounten, Updates integrieren, dismount Vorgang. Dieser Ablauf dauert ca. eine Stunde.

3. Schritt – Bereitstellen der aktualisierten Quellen in Empirum

Ist der zuvor beschriebene Vorgang abgeschlossen und „Win Toolkit“ beendet, kopiert man die aktualisierten Quellen wieder auf den EmpirumServer. Es ist jedoch besser, man erstellt ein neues Verzeichnis parallel zum Verzeichnis „1“ oder ähnlich und fügt ggf. das Datum der Aktualisierung hinzu (Beispiel „1_20130823“).

Was muss Empirum seitig getan werden, damit diese Quellen genutzt werden können?

Import

Update (21.10.2013): Beim Einsatz von Empirum v15 und neuer muss vor dem Import die Datei „EmpirumPackageData.xml“ aus dem Versionsordner gelöscht werden.

Die Quellen müssen in Empirum „importiert“ bzw. bekannt gemacht werden. Dazu die EMC starten, Konfiguration, OS-Installer – Reiter „Import“ auswählen. Im Menü unter „Software“, „Liste von der Festplatte lesen“ auswählen und die abgelegten Quellen einbinden.

Betriebssystemvorlage

Im nächsten Schritt öffnet man die zuletzt genutzte Betriebssystemvorlage, wechselt bei „Allgemein“ auf den Reiter „Sprache“ und wählt bei „Betriebssystem“, „Version“ die neu eingebundenen Quellen aus (Beispiel: „1_20130823“).

Zur Sicherheit speichert man diese Betriebssystemkonfiguration unter einem neuen Namen („Datei“, „Speichern unter …“), damit die produktiv genutzte Betriebssystemkonfiguration unverändert bleibt!

Betriebssystemkonfiguration zuordnen und testen

Jetzt kann man die neu erstelle Betriebssystemkonfiguration einem Computer zuordnen und die Installation testen. Verläuft die Installation reibungslos und erfolgreich, kann man die Installation mittels „Windows Updates“ auf Vollständigkeit prüfen und ggf. weitere Windows Updates herunterladen und nach dem oben genannten Verfahren in die „install.wim“ integrieren.

In meinem Fall standen am Ende nur noch die .NET Framework 3.5 SP1 Updates und einige wenige andere Updates aus. Mit diesem Resultat war ich nach dem überschaubaren Aufwand sehr zufrieden. Dies spart die Installation von ca. 100 Updates und über eine Stunde bei der Betriebssysteminstallation.

Wie sind Eure Erfahrung mit integrierten Updates? Schreibt doch mal!

In Kürze werde ich auch noch schreiben, wie ich mit den Updates für das .NET Framework 3.5 SP1 verfahren bin.

Der Beitrag Integration von Updates in Windows 7 SP1 Quellen erschien zuerst auf Workplace Management Blog.

Reihenfolge und Abhängigkeiten

Bezüglich der Reihenfolge der Verteilung hat die Reihenfolge (von oben nach unten) der Pakete im SoftwareDepot grundlegenden Einfluss. Diese Reihenfolge kann mit der Option „Reihenfolge“ auf dem Reiter „Version“ überschrieben werden. Hier werden die Software Pakete angegeben, die vor dieser Software installiert werden muss. Im Dialog „Abhängigkeiten“ können Pakete angegeben werden, die installiert sein müssen, damit diese Software auch installiert wird. Hierüber können auch „Verbote“ definiert werden. Dieses Paket wird nicht installiert, wenn bereits Software xy bereits installier ist. (Bespiele sind die Matrix42 Pakete SubDepot Services und DataCollector).

Betriebssystem Freigabe

Auf diesem Reiter werden die Betriebssysteme „angehakt“, auf denen die Setup.inf erfolgreich ausgeführt wird und getestet ist. Ist ein Paket nur für Windows 7 freigegeben und wird einem Windows XP Computer in der EMC zugewiesen, wird die Setup.inf erst gar nicht „angestartet“, da das Paket nicht dafür freigegeben wurde.

Computerumgebung 

Die Einstellungen auf dem Reiter Computerumgebung wirken sich genauso auf die Verteilung aus, wie auf dem Reiter Betriebssystem. Hier können jedoch Rahmenbedingungen bzgl. RAM, Festplattenplatz, etc. definiert werden. Sind die Rahmenbedingungen nicht erfüllt, startet die Installation erst gar nicht. Die „nicht erfüllte Voraussetzung“ wird mit einer „Requirement“ Meldung im SoftwareDepot Log dokumentiert.

Sonstiges

Wie der Name schon sagt, vereinen sich auf dem Reiter „Sonstiges“ alle weiteren Einstellungen.  Die Einstellungen „Externes Installationsprogramm“ und „Installationsprogramm asynchron aufrufen“ werden in den allermeisten Fällen nicht genutzt und haben mehr eine „historische“ Bedeutung. Beim zweiten Falle, werden die Pakete nicht in einer Stapelverarbeitung eins nach dem anderen installiert, sondern eine weitere Installation wird bereits gestartet. Dies führt in den überwiegenden Fällen zu Installationsproblemen!

„Nur bei Verteilung“ benutzen steuert, ob eine Software im Kiosk sichtbar ist oder nicht, oder nur mittels EMC/EWC verteilt werden kann. „Erlaube Deinstallation“ hat auch nur Einfluss auf das Kiosk und ermöglicht dem Endbenutzer nur eine Deinstallation einer Software zu starten, wenn dies hiermit „erlaubt“ wird.

„Installation weiterer Pakete nicht fortsetzen“ ist interessant zu nutzen, wenn eine abhängige Software-Installation einen Neustart oder ähnlich voraussetzt. Sehr häufig ist dies nach einem Windows Service Pack oder Internet Explorer Update nötig, damit die nachfolgenden Installationen die richtige Version erkennen (mittlerweile auch durch den Wert SetReboot 5 in der Setup.inf steuerbar).

Die Option „Installationskontext“ erlaubt einem einzustellen, ob das Paket nur vor oder nach der Anmeldung ausgeführt werden darf, oder ob es „immer“ installiert werden kann. Wenn das Paket auf eine Abfrage vom Benutzer warten soll, so wäre „Nur nach der Benutzeranmeldung“ passend.

„Installationsdauer“ wird dem Benutzer vor bzw. während der Installation im sogenannten Z-Dialog angezeigt. Der Z-Dialog zeigt die anstehenden Installationen an und gibt ggf. die Möglichkeit  die Installation zu verschieben (je nach Agenten-Konfiguration und Verteilungsoption des Software-Paketes).

„Lizenzen“ – diese Eingabe kann komplett „vergessen“ werden und wird nicht mehr unterstützt.

„Sync. Bandbreite“ bezieht sich auf die Synchronisation der Pakete auf den Client. So kann hier für ein großes Software-Paket eine minimale verfügbare Bandbreite zur Synchronisation der Quellen auf den Client angegeben werden.

Die Eigenschaft „Pakettyp“ ist für die Zusammenarbeit mit dem Matrix42 Service Store relevant. Somit können die Pakettypen beim Import bereits unterschieden werden, wie diese weiter im Service Store zur Verfügung stehen bzw. „verarbeitet“ werden.

Prüfung

Auf diesem Reiter ist der Wert für Prüfdatei/Prüfwert noch sehr interessant. Nur wenn diese Kriterien erfüllt sind, findet die Ausführung des Software-Paketes statt. Hier lohnt sich ein Blick in die Matrix42 Pakete “Patch-Management (Install) bzw (Fix)“.

SetupInfo

Die Nutzung der Paketinformationen durch den bzw. die Paketierer habe ich hier bereits erklärt.

Registrierung

Auf dem Reiter Registrierung wird beim Import der Wert für Schlüssel aus der Setup.inf und der Eigenschaft „MachineKeyName“ übernommen. Dazu sind die bereits vorhandenen Blog Beiträge wichtig zu lesen:

• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Empirum Paket – Registry, SoftwareDepot, Version

AUT

Auf dem Reiter AUT kann eine zu „überwachende“ EXE Datei einem Software-Paket zugeordnet werden. Damit wird die Zuordnung und Erkennung auf dem Eigenschaften Reiter eines Computerobjektes vorgenommen.

Variablen

Hier werden Variablen, die zu dem Softwarepaket gehören und mit der Setup.inf importiert wurden angezeigt.

Der Beitrag Einbinden eines Software-Paketes in Empirum (Erweitert). erschien zuerst auf Workplace Management Blog.

Zuerst muss man die Aufgabe für das Softwarepaket mit dem Auftraggeber bestimmen, denn diese bestimmen somit auch die notwendigen Tests.

Um es etwas einfacher zu sagen: „Was soll das Softwarepaket machen?“

• Sollen alte vorhandene Software-Installationen des gleichen Produktes entfernt werden?
• Sollen Einstellungen der Software übernommen werden?
• Soll eine gerade laufende Instanz der Software abgefragt werden?
• Stellt der Hersteller eine „silent“ Installation zur Verfügung?
• Sollen nach der Installation auch Einstellungen vorgenommen werden?
• Sollen die Einstellungen auch für alle Benutzer des Computers vorgenommen werden?
• Soll das Softwarepaket die Software auch wieder deinstallieren?
• Sollen auch Dinge gelöscht werden, die nach der Installation der Software hinzugekommen sind?
• Dokumentation
• …

Ich denke, sie verstehen nun, dass die Frage nicht so leicht beantwortet werden kann, auch wenn man gesagt bekommt…

• „Die Software hat nur 5 MB.“
• „Sie müssen immer nur weiter drücken.“

Welche Einflüsse kann man „steuern“?

Ist die Umgebung sehr homogen, fallen weniger Tests an bzgl. möglicher vorhandener Altversionen.

Ist die Software für den Unternehmenseinsatz gedacht/geplant?

Überlegen Sie, ob sie die Software tatsächlich wieder deinstallieren (würden)?

Wie sieht es aus mit Internet Explorer, .NET Framework, AntiVirus.

Gerade im Fall AntiVirus – hier installiert man häufig immer wieder die aktuelle Version der gleichen Software.

Diese kann sich selbst meist wunderbar aktualisieren. Sollte der Tag kommen, an dem sie ihr vorhandenes Produkt austauschen, können sie sich immer noch viele Gedanken zur Entfernung des Vorgängerproduktes machen und dann auch in ein Softwarepaket „gießen“.

Auch wenn ich selbst „perfektionistisch“ veranlagt bin so sollte jeder Nutzer einer Softwareverteilung seinen Grad an „Perfektion“ (Das Softwarepaket ist fertig.) selbst bestimmen. Bevor sie ein Produkt nicht nutzen, nur weil ihnen jemand sagt bzw. gesagt hat, dass ein Softwarepaket alle oben genannten Merkmale besitzen muss, muss das für sie lange noch nicht zutreffen. Dann erstellen sie lieber ein Softwarepaket, das sich nicht deinstallieren lässt, oder nicht alle Einstellungen beinhaltet – dies hilft ihnen bereits Zeit zu sparen und Installationen zu vereinheitlichen.

80/20 Regel!

Wie auch an anderen Stellen trifft hier die 80/20 Regelung sehr häufig zu.

Sie erzielen 80% der Fertigstellung mit 20% Aufwand an Zeit und Geld. Die restlichen 20% kosten sie ggf. 80% Aufwand!

Erfahrung

Die Erfahrung bei der Erstellung von Softwarepaketen bzw. der Automatisierung von Softwareinstallationen ist bei all den genannten Punkten nicht zu vernachlässigen. Diese Erfahrung kann man jedoch nur „gewinnen“, wenn man es auch mal selbst „erfährt“ ;).

So werden sie bei den ersten Softwarepaketen mehr Zeit benötigen als jemand, der das schon viele Jahre macht. Es ist also „noch kein Meister vom Himmel gefallen“ und auf der anderen Seite „wer nicht wagt, der nicht gewinnt“ ;).

Also, lassen sie sich nicht entmutigen, sondern versuchen sie es!

Vielleicht helfen ihnen auch Tipps und Anleitungen (Tutorials), die hier noch veröffentlicht werden,

oder sie nutzen eine Schulung ggf. auch ganz individuell auf sie zugeschnitten!

Der Beitrag Aufwand zur Erstellung eines Softwarepaketes erschien zuerst auf Workplace Management Blog.