Grober Ablauf – MSI Paketerstellung

Eine MSI Datei ist „eigentlich“ ein fertiges Paket für den Windows-Installer. Bei der Erstellung einer Empirum Setup.inf werden beim Packaging diverse Werte aus der MSI ausgelesen und in die Setup.inf übertragen. Die Setup.inf enthält am Ende die Logik und Erfolgsüberprüfung für die Installation, Reparatur und Deinstallation der MSI Datei und bietet Raum für Erweiterungen, die über die reine MSI Installation hinausgehen.

Aufmerksam sein …

Die aus der MSI Datei ausgelesen Werte für Hersteller, Software(name) und Version werden im Packaging Vorgang vorgeschlagen.

Hier sollte man wachsam sein und darauf achten, dass ..
1. bei Software auch nur der „Softwarename“ steht und nicht gleich der Hersteller und die Version zusätzlich.
2. es sich beim vorgeschlagenen Text um Zeichen handelt, die auch im Dateisystem verwendet werden können. Ansonsten fällt einem das später auf die Füße.

Beispiel: Dell Command Update

Im angezeigten Beispiel sind gleich mehrere „Hürden“ enthalten.
1. Es handelt sich um das Dell Command Update. Der Softwarename ist dann genau genommen nur noch „Command Update“. Also Dell am Anfang kann entfernt werden.
2. Vorgeschlagen wird „Command | Update“. Bitte macht daraus ein Command Update! Die „Pipe“ wird bei der Verzeichniserstellung für Probleme sorgen.
3. Der Hersteller ist „Dell Inc.“. Hier empfehle ich „Dell“ oder „Dell Inc“ daraus zu machen, weil es sonst weitere Probleme geben wird.

Man sollte also darauf achten, dass Hersteller, Softwarename und Version nicht auf einen „Punkt“ (.) enden!

Gemeistert

Hat man die Dinge oben beachtet, sollten keine Probleme bei der Paket-Erstellung, Import und Verteilung auftreten.
War man „clever“ und hat sich im die ein oder anderen Probleme „herumgearbeitet“, aber in der Setup.inf vielleicht noch „Dell Inc.“ stehen, dann kann das wie folgt enden.
Die Installation des Paketes schlägt fehl. Beim genaueren Hinsehen hat einen Ordner „Dell Inc.“, auf den man jedoch nicht zugreifen kann…

Wenn er stört, dann löscht man ihn halt. Argh – das funktioniert leider auch nicht so einfach.

Egal wie man es dreht und wendet, man bekommt den Ordner weder per Explorer oder den normalen Angaben in der CMD nicht entfernt.

Mit folgenden Befehl kann man den Ordner jedoch entfernen:

rd /s /q "\\?\C:\ProgramData\$Matrix42Scripts$\Dell Inc."

Der Beitrag Aufgepasst im Package Wizard – MSI erschien zuerst auf Workplace Management Blog.

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.

• https://www.wpm-blog.de/empirum-paket-deinstallation-ohne-quellen/
• https://www.wpm-blog.de/empirum-errorlevel-abfrage-bei-unattended-installationen/

Reparatur Logik

Das Resultat wird, je nach Betrachtung, nicht das Optimum darstellen. Meines Erachtens ist dies jedoch schon ein gutes Stück weiter als das Original. Wir betreiben also etwas Tuning :). In diesem Beitrag soll es um die Reparatur gehen.
Das Reparatur-Handling hilft uns …

• für die Reparatur einer Software durch Deinstallation und Neuinstallation
• falls die Software zuvor anderweitig ggf. manuell installiert wurde, damit diese zuvor deinstalliert wird
• falls die Software durch das Matrix42 Patch-Management vielleicht schon auf eine andere Version angehoben wurde

Grober Ablauf

Die Reparatur setzt grob auf folgenden Ablauf:
1) Erkennung, ob diese Software ggf. auch in einer anderen Version bereits installiert ist.
2) Falls ja, entfernen dieser Installation.
3) Anschließend wird mit dem „normalen Installationsablauf“ fortgefahren.

Anpassungen

Der nachfolgende Code-Schnipsel kann in die unattended.inf übernommen werden, oder ihr wartet noch die nächsten zwei Artikel ab und übernehmt dann eine gesamte unattended.inf. Was wird noch folgen? Erkennung und Abfangen von geöffneten Programmen, sowie „verstecken“ der originären Installation in der Systemsteuerung unter „Programme“.

Falls ihr diesen Schnipsel nutzt …

In der [Product] Sektion muss vor die Installation die
#CheckExistingInstallation, DONTDELETE
eingebaut werden.

Die Erkennung bzw. das Deinstallationsprogramm hinter der Variablen „VM_UnInstCMD“ muss angepasst werden.

Code-Schnipsel

[CheckExistingInstallation]
;---setzen der Variable mit dem Deinstallationsprogramm
Set VM_UnInstCMD=%ProgramFilesDirx86%\My Program\unins000.exe
;---falls das Deinstallationsprogramm vorhanden ist, dann springe in die Sektion zu Deinstallation
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "DoUninstallBeforeInstall" EndIf

[DoUninstallBeforeInstall]
;---führe die Deinstallation durch und warte zur Sicherheit 3 Sekunden
-Call "%VM_UnInstCMD%" /S
Sleep 3000
;---Wurde die Deinstallation erfolgreich durchgeführt und ist die Deinstallationsroutine entfernt worden? Falls nicht, melde einen Fehler.
If DoesFileExist ("%VM_UnInstCMD%") == "1" Then "ErrorOnUninstallBeforeInstall" EndIf

[ErrorOnUninstallBeforeInstall]
ErrorLogMsg %ErrorText% %ErrorLevel% %CallingText% %VM_UnInstCMD%
Abort

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

Der WinPE PXE-Boot bootet ein von Empirum modifiziertes bzw. ergänztes Windows PE. Das WinPE wurde im Bedarf um weitere Treiber ergänzt, aber auf jeden Fall um nützliche Libraries und den Matrix42 UAF Dienst. Letzterer führt die zugewiesenen PreOS-Packages (Powershell „Pakete“) aus und bedient sich der gesetzten Variablen. Diese zugewiesenen Pakete beschreiben die Art und Weise, wie z.B. die Betriebssystem-Installation stattfinden soll. Auf weitere Einzelheiten und Vergleiche mit dem EPE Boot werde ich an anderer Stelle eingehen.

So gliedert sich der WinPE PXE-Bootvorgang in:

• Laden und Ausführen der WinPE Umgebung
• Laden des Matrix42 UAF Dienstes
• Verarbeiten der PreOS-Packages

Nun zu möglichen Problemen und Maßnahmen/Hilfestellungen zur Bearbeitung.

Laden der Windows PE Umgebung

Schlägt bereits das Laden der WinPE Umgebung fehl, so könnte dies ggf. an der TFTP Blocksize liegen. Diese kann bis Empirum v19 global in der .config Datei des BTQH (Backend Task Queue Host Services) Dienstes eingestellt werden. Standardmäßig steht dieser Wert auf 4096. Mit größeren Werten kann man den Boot beschleunigen. Damit kann er jedoch unzuverlässiger werden. In einem Falle musste ich die Größe auf 1456 festsetzen, damit der Boot zuverlässig an allen Standorten funktioniert hat.

Windows PE ist gestartet

Sobald das Windows PE gestartet ist, kann mittels STRG+C auf die Kommandozeile und per STRG+L direkt auf die Log Datei des UAF Dienstes zugegriffen werden. Die Windows PE Umgebung befindet sich unter X:\. Der UAF Dienst liegt im Ordner X:\UAF. Das wpeinit.log unter X:\Windows\System32.

Herstellen einer Netzwerkverbindung

Damit der im WinPE implementierte UAF Dienst seine Aufträge abarbeiten kann, bedarf es einer grundlegenden Netzwerkverbindung. Diese Verbindung wird durch Laden und Starten des Netzwerk-Stacks durch die  X:\Windows\StartNet.cmd und nachvollziehbar durch die wpeinit.log  vorgenommen (QueryAdapterStatus ist hier das passende Suchwort). Kann das WinPE keine Netzwerkverbindung aufbauen, kann es notwendig sein, das WinPE mit Netzwerk- und/oder Speicherverwaltungs-Treibern (Storage) zu versorgen. Dies geht über die Bootkonfiguration und wird in einem anderen Beitrag erläutert.

DeviceMapping.xml

Die DeviceMapping.xml im \\%EmpirumServer%\Values$ Verzeichnis stellt die Verbindung MAC-Adresse bzw. UUID zum Computernamen her. Somit darf jede MAC Adresse bzw. UUID auch nur einmal in der DeviceMapping.xml vorhanden sein. Beim Einsatz von SubDepots muss zusätzlich beachtet werden, dass es für die DeviceMapping Datei einen separaten SyncJob (ESubdepot_DeviceMapping) gibt, der zugewiesenen werden muss.

UAF – Auftragsverarbeitung

Das Vorgehen des UAF Dienstes wird im Matrix42.Platform.Service.Host.log festgehalten. Wie zuvor beschrieben, kann dies per STRG+L geöffnet werden. Um Neuerungen mitzubekommen, muss man ggf. das Fenster schließen und erneut aufrufen. Nach einer UAF Sitzung wird das Log auf den EmpirumServer zurückgeschrieben. In Empirum v18 bzw. WinPE 1.4.14 ist das das Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\OS\Auto\<letzten8 Stellen der MAC-Adrese> bzw. <UUID>.

PXE-Image / WADK Version

Wenn man die neuen WinPE Versionen einsetzt, sollte man wie ein Blog-Leser zusätzlich darauf hingewiesen hat, sicherstellen, dass man die aktuelle WADK Version auf dem EmpirumServer installiert hat. Matrix42 empfiehlt den Einsatz der WADK Version 1903 (eine Version 1909 wird nicht von Microsoft bereitgestellt). Mit dem WADK 1903 habe ich bis dato keine schlechten Erfahrungen gemacht, ganz gleich ob Windows 10 Enterprise 2016 LTSB oder Windows 10 Build 1909 installiert wurde. Zusätzlich sollte man darauf achten, dass die PXE-Image Erstellung (unter Konfiguration\Boot-Konfiguration) erfolgreich ist. Die aktualisierten PreOS Pakete funktionieren auch nur zuverlässig mit einer zu der Version passenden Boot-Konfiguration bzw. aktualisierten PXE-Image.

Der Beitrag Empirum WinPE Boot Troubleshooting erschien zuerst auf Workplace Management Blog.

Was benötigt man dazu?

WADK

Das WADK (Windows Assessment and Deployment Kit) für Windows 8.1 wird zur „Behandlung“ der Windows 8.1 Quellen benötigt – hier im Speziellen die DISM.EXE.

SXS Ordner der Windows 8.1 Installationsquellen

Der SXS Ordner enthält unter anderem die Quellen für das .NET Framework 3.5 „Feature“. Dieser Ordner befindet sich in den Windows 8.1 Quellen unter sources/sxs.

Aktivieren!

Das Aktivieren des „Features“ funktioniert über das Mounten der Install.wim Datei, Aktivieren des „Features“ und Unmounten der Install.wim. Man kann dies Schritt für Schritt mit den entsprechenden DISM Befehlen durchführen. Ich habe die Abfolge in eine Batch Datei gepackt, die hier zum Download anhängt.

Danke an Peter für die Zuarbeit!

Hier die ActivateNETFX35.cmd zum Download:   ActivateNETFX35 (1312 Downloads )

Update – Version 2 (Fehler beim Ändern der WIM abgefangen)

Hier die ActivateNETFX35.cmd zum Download:   ActivateNETFX35v2 (1539 Downloads )

Der Beitrag Windows 8.1 und .NET Framework 3.5 erschien zuerst auf Workplace Management Blog.

Die Informationen, welche Betriebssystemkonfiguration und welches Quellverzeichnis genutzt wird, steht jedoch zur Installationszeit zur Verfügung. Mit der Anpassung der „end_winvista.eis“ aus dem Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\Scripts2\Custom stehen diese Informationen nach der Installation dauerhaft zur Verfügung. Die nachfolgenden Zeilen müssen zur „end_winvista.eis“ Datei hinzugefügt werden. Wer weitere Informationen für sich interessant findet, kann den Tipp auch auf weitere Werte der OS.INI ausweiten.

;ServicePack definies the folder containing the os source files
TEXTOUT %HDM%Postjob/POSTSYS.CMD %%windir%%\System32\reg.exe ADD "HKLM\SOFTWARE\MATRIX42\Empirum Installer" /v ServicePackLevel /t REG_SZ /d "%ServicePack%" /f >>%%PostsysLog%%

;Write the used OS-Template to the registry
IF "%TemplateName%"<>"" THEN  
 TEXTOUT %HDM%Postjob/POSTSYS.CMD %%windir%%\System32\reg.exe ADD "HKLM\SOFTWARE\MATRIX42\Empirum Installer" /v OS_Template /t REG_SZ /d "%TemplateName%" /f >>%%PostsysLog%%
ENDIF

Der Beitrag Empirum OS-Installationsinformationen in der Registry speichern erschien zuerst auf Workplace Management Blog.

Wichtig ist im ersten Schritt mindestens die folgenden Variablen der Setup.inf zu kennen.

• %SRC% entspricht dem Source-Directory (SrcDir=) – das Verzeichnis „auf Höhe“ des Install Verzeichnisses bzw. unter dem Versionverzeichnis. %SRC% = <Hersteller>\<Softwarename>\<Version>.
• %APP% entspricht dem %ApplicationDir% aus der Sektion [Application], zumeist das Zielverzeichnis für eine Installation.

Syntax

Hier nun die Syntax für den Kopierbefehl:
1:Quelldatei,Zielverzeichnis,Kopierflag,Größe

Beispiel

Diese Zeile:
1:WinCmd.exe, ,NORMAL, 123456
kopiert die Datei WinCmd.exe mit der Größe 123456 aus dem %SRC% Verzeichnis in das %ApplicationDir% Verzeichnis.

Quelldatei

Die Quelldatei wird am dem Verzeichnis %SRC% angegeben.

Zielverzeichnis

Ist beim Zielverzeichnis nichts angegeben, wird %ApplicationDir% gesetzt.

Kopierflag

Das einfachste Kopierflag ist NORMAL.

Dieses Kopierflag sorgt dafür, dass die aktuellste Datei im Ziel (auf dem Clientcomputer) „landet“. Ist bereits eine aktuellere Datei auf dem Computer als in der Quelle, so wird die Datei nicht vom Server (Empirum Paket) überschrieben.

Empirum bietet eine Fülle an Kopierflags.
Hier führe ich die häufigst genutzten Befehle auf. Eine komplette Übersicht ist jedoch hier wieder zu finden.

• NORMAL – Die Datei wird nur kopiert, wenn sie neuer ist als das Ziel.
• ALWAYS – Die Datei wird immer kopiert.
• CLIENT – Die Datei wird im Benutzerteil/Benutzerkontext kopiert.
• DONTDELETE – Die Datei wird beim Deinstallieren des Paketes nicht gelöscht.
• SHAREDDLL – Der Zähler bei gemeinsam genutzten DLLs auch hoch und runtergezählt.
• USEFILENAME – Die Datei wird ohne den Quellpfad in das Ziel kopiert.
• WINDOWS32 – nur bei Windows 32bit Betriebssystemen ausführen
• WINDOWS64 – nur bei Windows 64bit Betriebssystemen ausführen

Es können auch mehrere Kopierflags mit einem Leerzeichen getrennt angegeben werden.

Größe

Die Größe bestimmt, wie sich in einem Paket mit Empirum Kopierbefehlen der Fortschrittsbalken verhält. Man kann die Größe auch auf „0“ setzen, dann wird die Größe ignoriert.

Der Beitrag Empirum Kopierbefehl und Kopierflags erschien zuerst auf Workplace Management Blog.