Variablen

Nachfolgend sollten die meistgenutzten Variablen aufgeführt sein. Falls ihr eine Variable häufig nutzt, die hier nicht aufgeführt ist, so lasst es mich wissen.

Beispiele

Del "%CommonDesktop%\WinSCP.lnk"

Del "%CommonPrograms%\TotalCommander Repair und Uninstall.lnk"

Deltree "%ProgramFiles%\WinSCP"

Callhidden %ComSpec% /C Echo %%date%% %%time%% [Set:Product] Install or repair >>"%App%\Debug.log"

Copy "%Src%\filezilla.xml" "%App%\FileZilla.xml"

Copy "%App%\filezilla.xml" "%AppData%\FileZilla\FileZilla.xml"

Der Beitrag Empirum Setup.inf – Variablen erschien zuerst auf Workplace Management Blog.

Was wurde geändert?

Die ausführende Datei wurde aus dem C:\Windows\Empirum Verzeichnis passender nach C:\Programme\Matrix42\Personal Backup verschoben. Die Konfigurationsdateien werden nun im Verzeichnis C:\ProgramData\Matrix42\PBackup abgelegt und bei der Nutzung herangezogen. „Früher“, also vor der Änderung, wurden die Konfigurationsdateien direkt vom EmpirumServer herangezogen.

Warum wurde das geändert?

Die Programmdateien im Programme Verzeichnis abzulegen ist eine Korrektur, die schon lange hätte vollzogen werden können. Viel entscheidender ist die Ablage der Konfigurations- und Hilfsdateien in C:\ProgramData\Matrix42\PBackup.
Damit kann Personal Backup „standardmäßig“ genutzt werden und die Sicherheit von Empirum erhöht konfiguriert werden.
Stichworte sind hier die Absicherung des allgemeinen Zugriffes auf das lokalen EmpirumAgent\User und das zentrale Configurator\User Verzeichnis. Hier kann man nun soweit gehen, dass nur noch der EmpirumAgent Benutzer auf die beiden genannten Verzeichnisse zugreifen kann. Vielen Dank dafür Matrix42.

Der Beitrag Personal Backup – Breaking Changes erschien zuerst auf Workplace Management Blog.

Hintergrund

Im Standard der Empirum Paket Vorlagen werden diese detaillierten Log Dateien von extern aufgerufenen Setup Routinen wie MSI und Unattended im %WINDIR%\Temp Ordner abgelegt. Schlägt eine Installation fehl, werden diese Log Dateien mit den Fehlern vorgehalten (nicht gelöscht) damit das Problem näher erörtert werden kann. Wenn nun Computer ausgeschaltet sind oder der Zugriff auf den Computer nicht sichergestellt ist (Notebook Benutzer, Firewall, etc.) kann derzeit jedoch keine weiterführende bzw. zeitnahe Analyse bezüglich des Problems stattfinden.

Idee

Ich habe mir dazu ausgedacht, dass im Fehlerfalle diese Log Dateien zusätzlich in das Log Verzeichnis des Agenten kopiert werden und dieser überträgt die Dateien auf den zentralen EmpirumServer. Dieser ist immer erreichbar und der Zugriff kann zentral gesteuert werden. Die Synchronisierung der Log Dateien wird über den EmpirumAgenten sichergestellt, da diese in einem Unterverzeichnis von C:\EmpirumAgent\Log abgelegt werden.

Umsetzung

Die nachfolgenden Beispiele sind ggf. auf die eigene Umgebung und das Agenten-Verzeichnis anzupassen.

Notwendige Setup.inf Anpassung

Dazu wurde folgende Änderung bzw. zusätzlichen Zeilen in der Setup.inf erstellt:

[Environment]
MSILogFileName=MSI_%ProductName%.%Version%.%Revision%.log
MSILogFile=%Temp%\%MSILogFileName%
ErrorMsgSyncDir=C:\EmpirumAgent\Log\InstallErrors.CU\%Computername%

[AbortMSIInst]
CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"
COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
Abort

[AbortMSIUnInst]
-Abort
-ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
-COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
-CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"

Anpassung in der Management Console

Der Zugriff auf das zentrale Log Verzeichnis eines Computers kann über einen „Rechtsklick“ auf den Computer geschehen. Die Konfiguration wird über die Management Console, Extras, Eigenschaften unter „Externe Programme“ vorgenommen.

• Zentrales Log Verzeichnis
• explorer \\%EmpirumServer%\configurator$\Log\InstallErrors.CU\%Computername%

Das gezeigte Beispiel nutzt die EmpirumServer Variable. Hier muss ggf. der zentrale EmpirumServer eingetragen werden und das Support-Personal zum Lesen berechtigt werden.

Bereinigung

Die zyklische Bereinigung des zentralen Log Verzeichnisses muss derzeit von Hand durchgeführt werden.

Der Beitrag Empirum: Einfacherer Zugriff auf detaillierte Fehler-Protokolle erschien zuerst auf Workplace Management Blog.

Los geht’s!

Diese Linksammlung ist auf dem Stand: 07.04.2020

Generelles

• Software-Paketierung / Repaketierung
• Aufwand zur Erstellung eines Softwarepaketes
• Verzeichnisse und Freigaben des Empirum Servers
• Softwareverteilung mit Empirum von Matrix42
• Wissenswertes zum Installationskontext

Erstes Paket erstellen und verteilen

• Softwarepakete erstellen und verfeinern
• Empirum Paket erstellen – MSI
• Aufgepasst im Package Wizard – MSI
• Platform Eigenschaft – Empirum Setup.inf
• Empirum Setup.inf – Platform Wert Tabelle
• Setup.inf Abarbeitung
• Erste Setup.inf Anpassungen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)

Paketierung – Erweitert

• Umgebungsvariablen
• Empirum Setup.inf – Variablen
• Empirum Paket Versionen – Früher an später denken?
• Empirum Kopierbefehl und Kopierflags
• Empirum Paket – Registry ändern
• Registry ändern mit REG Dateien
• Setup.inf – Datei pro Benutzer kopieren
• Empirum Setup.inf Skript vorzeitig verlassen
• Neustart oder nicht
• SystemShutdown vs. SetReboot
• Empirum – Übernehmen von vorhandenen Installationen
• Empirum und For – Next Schleife
• Empirum – NTFS Berechtigungen setzen
• Verknüpfungen / Links erstellen
• Empirum Setup.inf – SoftwareDepotDistributionFlags
• Schließen von geöffneten Programmen
• Verstecken von Software in der Systemsteuerung
• Empirum Sektionen mehrfach aufrufen
• Unattended Paket – ErrorLevel Abfrage verbessern
• Unattended Paket – Reparatur Funktion einbauen
• Unattended Paket – Deinstallation ohne Quellen

Software-Management

• Empirum – Paket in das SoftwareDepot einfügen
• Aufgepasst beim Einfügen eines Paketes in das SoftwareDepot
• Einbinden eines Software-Paketes in Empirum (Basis)
• Einbinden eines Software-Paketes in Empirum (Erweitert)
• Empirum Paketeigenschaft – Erlaube Deinstallation
• Erweiterte Paketvoraussetzungen

Paketierung – Besonderes zur Verteilung

• Empirum Paket Versionen
• Softwarepakete-Updateverhalten Verteilen von neuen Versionen
• Empirum Paket – Registry, SoftwareDepot, Version
• Empirum Paket – Revision
• Empirum Paket – Revisionserhöhung bei großen Installationen
• Definition des Zeitplaners

Anpassen der Paketierungsvorlagen

• Anpassung Paketierungsvorlage – Einleitung
• Anpassung Paketierungsvorlage – Kopfdaten
• Anpassung Paketierungsvorlage – MSI Paket
• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Anpassung Paketierungsvorlage – lokaler Setup.inf Ablageort

Der Beitrag Empirum – Software Paketierung Selbststudium 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.

Der Blog wird „alt“ – Neuerung seit Empirum v14.2

Vergleich der Versionsnummer: Ist die Version im Abschnitt [Setup] der Setup.inf GRÖSSER GLEICH 14.2 gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt bis zum nächsten Punkt als komplette Zahl verglichen (45 kleiner 100). Daher ist die Version 1.100 höherwertiger als die Version 1.45 .

Ist die Version im Abschnitt [Setup] der Setup.inf KLEINER 14.2 (z.B. 10.5) gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt Spaltenweise verglichen. Daher ist die Version 1.45 höherwertiger als die Version 1.100. Die Zahlen nach dem ersten Punkt werden nicht als eine Zahl verglichen (45 kleiner 100), sondern Zahlenweise (4 ist größer 1 und 5 ist größer 0). Da die erste Zahl 4 nach dem Punkt bereits größer als die Zahl 1 ist, wird nicht geprüft.

Quelle: Matrix42 Online Hilfe

Ab hier folgt nun die Erläuterung zu [Setup] Version=10.5 …

Martin Niemann hat dies sehr anschaulich und ausführlich auf seinem Blog erläutert. Beim Treffen auf dem vor wenigen Tagen stattgefundenen Matrix42 CustomerDay habe ich in darauf angesprochen, ob ich seinen Eintrag samt Quellenverweis hierher übernehmen darf. Vielen Dank Martin für Deine Erlaubnis!

So hier nun die Erläuterung:

Fast ein jeder wunderte sich schon, wieso die neue Version 4.10 des Paketes von Empirum nicht als höherwertig identifiziert wurde, als das alte 4.9er Paket – „die Zehn ich doch höher als die Neun!“

Hierzu muss man wissen, das in Empirum nur die Zahl vor dem ersten Punkt als ganze Zahl verstanden wird. Alle Werte danach werden Ziffer für Ziffer verglichen.

Hier eine Liste von Versionsnummer in absteigender Reihenfolge:

Die grauen Zahlen zeigen, wie man sich beim Vergleichen von Versionsnummern diese Vorstellen sollte. Vergleicht man nun eine 3.10 mit einer 3.90, ist die 3.9 selbstverständlich höher als die 3.10.

Um zukünftig nicht an die Grenzen der Versionierung zu stoßen, empfiehlt es sich die Versionsnummern nach einem einheitlichen Schema zu erstellen: Die Hauptversion kann aus einer beliebigen Zahl bestehen – bei der Nebenversion sollte man mindestens “zweistellig” vorgehen. Anstelle einer 3.1 sollte man daher besser eine 3.01 verwenden. So ist es später problemlos möglich, nach der 3.09 noch weitere Versionen anzubieten. Vorsichtigere Naturen verwenden für die Nebenversion sogar eine dreistellige Zahl: 3.009. Dies sollte man jedoch nur bei Paketen vornehmen, von denen man weiß, dass sie sich häufig verändern und die Erhöhung der Revisionsnummer nicht verwendet werden kann. Ist man jedoch in die “.9-Falle” getreten, empfiehlt es sich für die neue Version einen weiteren Zahlenblock anzuhängen: 3.9.01. Das sieht zwar nicht so schön aus, rettet einen jedoch aus der misslichen Lage die Version 4.00 einzuführen.

Autor: Martin Niemann

Der Beitrag Empirum Paket Versionen – Früher an später denken? erschien zuerst auf Workplace Management Blog.

Zweiteres kann man über die Logik der Revisionserhöhung realisieren. Möchte bei einem bereits verteilten Paket mit einer MSI oder Unattended Installation nun noch ein paar Dateien oder Registry Einträge austauschen/hinzufügen, so kann man den nachfolgend erläuterten Mechanismus nutzen. Dieser Mechanismus ermöglicht, dass bei bereits vorhandenen Installationen mit der Revision=0 nur minimale Änderungen durchgeführt werden und bei Neuinstallationen, die komplette Installation zuzüglich der nachträglichen Änderung.

[Product]
#CheckRevisionChanges, DONTDELETE
...
;<Installationslogik MSI / Unattended>
;<z.B.: Set:Product>
;<z.B.: Set:Installation>
#DoMinorUpdate

[CheckRevisionChanges]
Set LocalRevision=%%HKLM,Software\%MachineKeyName%\Setup,Revision%%
ReplaceEnv LocalRevision
IF "%LocalRevision%" < "%Revision%" & "%LocalRevision%" <> "" THEN "OnlyDoRevisionUpdate" EndIf

[OnlyDoRevisionUpdate]
#DoMinorUpdate
Exit

[DoMinorUpdate]
;Examples / Beispiele
;#CopyAdditionalFiles
;#Reg:Changes

Der Beitrag Empirum Paket – Revisionserhöhung bei „großen“ Installationen erschien zuerst auf Workplace Management Blog.

Ein Beispiel: Ein Paket von FileZilla mit der Version 3.7.3 wurde erstellt. Das Paket macht wie es soll, die Software funktioniert und es wurde bereits verteilt. Nun wird festgestellt, dass die automatischen Updates nicht ausgeschaltet wurden.

Somit muss also dieses Paket erneuert bzw. angepasst und erneut verteilt werden. Doch welche Version hat die Software nun? Es ist faktisch immer noch FileZilla 3.7.3. Jedoch benötigt man zur erneuten Verteilung (falls man keine Reinstallation durchführt) eine Erhöhung der Version. Die Revision wird nahezu „unsichtbar“ immer an die Version angehängt.

Somit hilft jetzt die Revision!

ACHTUNG – die nachfolgenden Zeilen sorgfältig lesen bevor man dies mit einem produktiven Paket durchführt!

Erster Schritt – Erhöhung der Revision in der Setup.inf um einen Zähler (z.B. von 0 auf 1).

Zweiter Schritt – Erhöhung der Revision auch im SoftwareDepot. Dies geht auf zwei Arten. Man wechselt in der EMC in die Eigenschaften des Paketes. Dazu die EMC starten, Konfiguration, Software-Management, Depot, Software-Paket auswählen und die Eigenschaften aufrufen und auf den Reiter „Version“ wechseln. Hier die gleiche Revision eintragen, wie sie auch in der Setup.inf steht! Konfigurationsänderung mittels des Diskettensymbols speichern. Fertig!

Der bessere und einfachere Weg ist folgender: Durchführen des Versionsabgleiches im SoftwareDepot. Dabei werden die im SoftwareDepot bekannten Pakete (Setup.inf) erneut eingelesen und mit den Werten in der Datenbank verglichen und zur Anpassung vorgeschlagen. Dazu die EMC starten, Konfiguration, Software-Management, Depot, im Baum (links) auf Register gehen. Dann im Menü unter „Extras“, „Versionen abgleichen …“ starten und durchführen (mehr hierzu in der Matrix42 Online Hilfe). Konfigurationsänderung mittels des Diskettensymbols speichern. Fertig!

Wichtig ist hier auch das man weiß, was man mit dem „Versionen abgleichen …“ tatsächlich macht. Darauf werde ich in einem anderen Beitrag nochmals genauer eingehen. Denn hier ist Vorsicht geboten.

Sind die zuvor getätigten Änderung in der Setup.inf in das SoftwareDepot (und somit der SWDepot.dds) übertragen und gespeichert, gehts auch schon los …

Warum habe ich zuvor groß ACHTUNG geschrieben? Ist die Revisionsänderung durchgeführt (Setup.inf und SoftwareDepot) müssen die Computer nicht erneut aktiviert werden, damit die „Neuverteilung“ aktiviert ist. Alle bereits aktivierten Installationen sind mit der Änderung „scharfgeschaltet“ für eine erneute Durchführung der Installation beim nächsten Agenten-Polling! Sprich, wenn man die Revision erhöht, hat man keine Chance mehr das Paket definiert mittels der Softwareverteilung zu testen! Die notwendigen Tests müssen zuvor durchgeführt worden sein (ggf. mittels Setup.exe/Setup.inf Aufruf)!

Diesen besonderen Umstand sollte man sich in Erinnerung rufen, wenn man den Schritt der Revisionserhöhung durchführt.

Wozu kann man die Revisionserhöhung sorgenfrei nutzen?

Bei Paketen, wie der reinen Kopieraktion von SapLogon.ini, TnsNames.ora, o.ä. die einem ständigen Wandel unterliegen, ist die Nutzung der Revision zur Neuverteilung der einfachste Weg. Wurden Dateien in Differenzpaketen ausgetauscht, wie z.B. der Matrix42 eigenen Pakete wie EmpirumAgent, Inventory, etc. nach einem Update oder Hotfix, ist es auch ein leichtes, diese mittels der Revisionserhöhung erneut auf die Computer zu verteilen. Bei den beiden zuletzt genannten Einsatzvarianten kann man, oder sollte man, auch darüber nachdenken diese Pakete komplett „silent“ zu verteilen (/S0 und „Nicht anzeigen“ bei den Verteilungsoptionen).

Wenn die Revisionserhöhung bei Paketen genutzt wird, deren Installationsumfang sehr groß ist, sollte man die Revisionsänderung ggf. im Paket „abfangen“. Dazu jedoch auch mehr in einem separaten folgenden Blog-Beitrag.

Der Beitrag Empirum Paket – Revision erschien zuerst auf Workplace Management Blog.

• Wie verteile ich neue Versionen von bestehender Software?
• Wie rolle ich diese Versionen aus?
• Was ist zu beachten?

Wichtige Grundlagen zu diesem Thema sind bereits in diesem Beitrag erläutert: Empirum Paket – Registry, SoftwareDepot, Version.

In Kurzform ist folgendes für die neue Version wichtig:

• Der Herstellername (DeveloperName) und Softwarename (ProductName) der Versionen sind identisch.
• Es ist lediglich die Version unterschiedlich und in diesem Falle die neuere Version höher als die alte.
• Die MachinekeyName Einträge (und somit im SoftwareDepot: Registrierung, Schlüssel) sind identisch.

Sind diese Voraussetzungen erfüllt kann das neue Paket dem Computer, der die Vorgängerversion zugewiesen hat, zugewiesen werden. Dazu die neue Version dem Computer mit den Verteilungsoptionen „Installieren, Erneuern“ zuweisen. Die alte Version aus der Zuweisung löschen. Bei der kommenden Abfrage: „Löschen“ auswählen. Dies bedeutet, dass der Verteilbefehl gelöscht wird und somit nur noch der Verteilbefehl für die neuere Version aktiv ist.

Findet nun die Softwareverteilung auf dem Zielcomputer eine Altversion anhand der MachineKeyName Werte in der Registry vor, so wird eine Deinstallation mit der lokal vorgehaltenen Setup.inf durchgeführt (AskUninstallOld=1). Dazu ist es wichtig, dass die Deinstallationsbefehle oder Zugriffe alle lokal erfolgen können! Häufig sorgen Zugriffe, in den betroffenen Sektionen für die Deinstallation, auf %SRC% oder ähnlich für Fehler bei der Deinstallation der Altversion. Ist die Altversion erfolgreich deinstalliert, beginnt die Installation der neuen Version.

Gibt es beim Testen (Deinstallation der Altversion), wie zuvor beschrieben, Probleme – und diese Probleme tauchen zumeist erst auch dann auf, wenn man die Nachfolgeversion paketiert hat, hat man noch „Handlungsspielraum“. Entweder man setzt nun die Vorgängerversion auf „Deinstallieren…“ anstatt „Löschen“ oder man passt das „neue“ Paket an (AskUninstallOld=0 und die Deinstallation auf Bedarf durchführen).

In einem anderen Beitrag werde ich der zumeist nachfolgenden Frage: „Wann passe ich die Version und wann die Revision an?“ nachgehen.

Der Beitrag Softwarepakete: Updateverhalten, Verteilen von neuen Versionen erschien zuerst auf Workplace Management Blog.

Der Empirum Agent prüft bei einem Verteilauftrag anhand der %Computername%.DDC und SWDepot.DDS Einträge, ob die Installation für diesen Computer ausgeführt werden muss. Sind die Voraussetzungen bzgl. Berechtigungen, Betriebssystem, etc. erfüllt, wird der MachineKeyName Eintrag aus der DDS Datei in der Registry überprüft.

Registry Eintrag nicht vorhanden
Ist der Eintrag in der Registry nicht vorhanden, wird die Installation (Voraussetzungen erfüllt!) gestartet.

Registry Eintrag vorhanden – Registry Version gleich wie im SoftwareDepot, Revision
Ist der Eintrag mit der entsprechenden Version vorhanden, wird die Revision (Version der Version) überprüft. Ist die Revision in der Software Depot.DDS höher als in der Registry, wird die Installation gestartet.

Registry Eintrag vorhanden – Registry Version kleiner als im SoftwareDepot
Ist ein Eintrag vorhanden und nur die Version weicht ab, so wird die Installation gestartet, wenn die Version in der SoftwareDepot.DDS höher bzw. größer ist.

Deinstallation der Altversion
Ob nun vor der Installation der neueren Version eine zu vorige Deinstallation des „älteren“ Paketes durchgeführt wird, wird über den Eintrag AskUninstallOld= in der [Application] Sektion gesteuert. Ist der Wert 1, so wird eine Deinstallation der kleineren/älteren Version durchgeführt. Ist der Wert 0 so wird direkt die Installation des höheren/neueren Version durchgeführt.

Der Beitrag Empirum Paket – Registry, SoftwareDepot, Version erschien zuerst auf Workplace Management Blog.