Hintergrund

Damit man eine Software mit Matrix42 Empirum verteilen kann, benötigt man ein Software-Paket. Dies muss im Falle von Matrix42 Empirum ein gewisses Format haben und ist am Ende eine Steuerdatei bzw. ein Skript mit dem Namen Setup.inf. Diese Setup.inf wird auch vom Matrix42 Package Wizard ein Paket erstellt, wenn man sich für die Installation einer MSI oder EXE, die unattended installiert werden kann, entscheidet. Der Vorteil ist, dass die Setup.inf neben der Fehler- bzw. Erfolgsbehandlung auch weitere Aufgaben übernehmen kann, die für diese Software nötig ist. Beispiele: Löschen der Desktop-Verknüpfung, Installation einer VCRedist vorab, Kopieren einer Datei danach, uvm.

Warum nun doppelte Einträge?

Die eben genannte Setup.inf ist im Ursprung eine Installationsroutine für Programme, die sich eben nicht „unattended“ bzw. „silent“ installieren lassen. Wenn man nun innerhalb der Setup.inf eine MSI oder EXE installiert, die selbst eine Installationsroutine mitbringt, haben wir eben zwei Installationsroutinen. Beide Installationsroutinen tragen sich in der Registry ein, womit sie dann in den oben genannten Dialogen erscheinen.

Bei MSI Paketen ist dies nicht der Fall!

Erstellt man mit dem Matrix42 Package Wizard ein Paket auf der Grundlage von MSI Quellen passiert das zumeist nicht – warum? In der MSI.inf Vorlage wird dem MSI Aufruf standardmäßig der Parameter ARPSYSTEMCOMPONENT=1 angehängt. Dieser MSI Parameter sorgt dafür, das die zu installierende Software anschließend mit dem Flag SYSTEMCOMPONENT versehen wird, welches die Anzeige in der Systemsteuerung bzw. unter Einstellungen unterdrückt wird: https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent

Was passiert da?

Die Software bzw. die Anzeige in der Systemsteuerung bzw. unter Einstellungen wird zumeist über die Registry sichergestellt. Dazu legen die Installationsroutinen Einträge in den folgenden Registry Zweigen ab …
64bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

32bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Erstellt man nun in einem Zweig einer entsprechenden Software einen Eintrag: SYSTEMCOMPONENT vom Typ: REG_DWORD und setzt dessen Wert: 1, so wird diese Software anschließend nicht mehr angezeigt.

Empirum Inventory

Dieses verstecken der Software bezieht sich nur auf die Anzeige direkt am Computer! Das Empirum Inventory erfasst trotz alledem beide Einträge, was man auch eher als Vorteil sehen sollte.

Unatteded.inf Anpassung

In der Setup.inf können wir diesen Wert nach der Installation durch Empirum auch selbsttätig setzen und löschen. Dazu sind die folgenden Anpassungen in der unattended.inf notwendig. Anpassen des Reg:Product Aufrufes unter [Product]. Der wahrscheinlich vorhandene Parameter ,DONTDELETE ist zu entfernen.

[Product]
...
#Reg:Product
...

Die Reg:Product Sektion ist entsprechend der Software anzupassen…

[Reg:Product]
;32bit - oder [Setup] Platform Wert entsprechend setzen!
;HKLM,SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1
;64bit
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1

Der Beitrag Software in der Systemsteuerung verstecken erschien zuerst auf Workplace Management Blog.

Fehlende Treiber hinzufügen

Die Surface Tastatur funktioniert deswegen nicht, weil dem WinPE ein paar Treiber fehlen. Welche Treiber das sind, könnt ihr hier nachschlagen. Einbinden müsst ihr diese Treiber dann in der Management Console und Konfiguration\Boot Konfigurationen – Zusätzliche Treiberverzeichnisse. Wie das geht und wo ihr das findet, habe ich wiederum bereits in diesem Artikel beschrieben.

Wie komme ich an die genannten Treiber?

Jetzt liegen die Microsoft Surface Treiber jedoch als MSI Dateien vor. Wie kommt man nun an die einzelnen, oben genannten, Gerätetreiber?  Dazu ruft ihr die MSI Datei wie folgt auf:

MSIEXEC /a <Pfad und Dateiname zur heruntergeladenden Treiberdatei>.msi TARGETDIR=<Ausgabe Ordner> /qn

Beispielhafter Aufruf:
MSIEXEC /a SurfacePro8_Win10_19042_22.011.9738.0.msi TARGETDIR=C:\Temp\SurfacePro8Drivers /qn

Das Entpacken dauert einen Moment, also nicht zu ungeduldig sein.

Nebeneffekt

Das entpackte Verzeichnis könnt ihr auch für den Treiber-Import für die Windows Installation nutzen. Dazu packt ihr es jedoch am besten wieder als ZIP Datei.

Der Beitrag Surface Tastaturen während der WinPE Phase erschien zuerst auf Workplace Management Blog.

Was ist so anders bei Office 365?

Generell besteht die Umstellung darin, dass das die Office 365 Installation nicht mehr aus MSI und MSP Dateien besteht. Die „neue“ Installationsvariante hört auf den Namen „Click-To-Run“ oder kurz C2R bzw. ins deutsche übersetzt Klick und Los. Die nachfolgenden Links geben Antworten auf viele Fragen rund um das Thema „Breitstellung und Aktualisierung von Office 365“. Zusätzlich habe ich Links zur Aktualisierung von Office 365 per Matrix42 Patch-Management hinzugefügt.

Die häufigsten Fragen

Die hauptsächlichen Fragen bei der Bereitstellung von Office 365 sind:

• Welche Programme sollen alles verteilt werden?
• Was soll nicht Bestandteil der Bereitstellung sein (Publisher, OneDrive, Teams, …)?
• Welche Sprachen sollen bereitgestellt werden?
• Welcher Update-Kanal soll gewählt werden?
• Wo halten sich meine Clients am häufigsten auf?
• Wie und wo sollen die Updates-Quellen bereitgestellt werden?

Wie man sieht, sind das einige Fragen die beantwortet werden wollen, bevor man so richtig loslegen kann.

Was muss ich beachten, wenn ich zusätzlich Visio und Project installieren möchte?
https://docs.microsoft.com/de-de/deployoffice/install-different-office-visio-and-project-versions-on-the-same-computer

Was sind die Office Update Channels und was unterscheidet diese und welches ist der richtige Update Channel für mich oder meine Benutzer?https://docs.microsoft.com/en-us/deployoffice/overview-update-channels

Welchen Update Channel habe ich aktuell konfiguriert?
https://techcommunity.microsoft.com/t5/office-365-blog/how-to-manage-office-365-proplus-channels-for-it-pros/ba-p/795813

Wie aktuell bin ich?
Überblick über die aktuellen Versionen in den jeweiligen Update Channels:
https://docs.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date

Office 365 Updates

Welche Gruppenrichtlinien sind für das Update per Matrix42 Patch-Management zu setzen?
Wichtig zu wissen: Das Matrix42 Patch-Management für Office 365 „triggert“ nur die Aktualisierung und bringt nicht die Updates mit. Dazu müssen die aktualisierten Quellen für die Aktualisierung entweder auf einer UNC Freigabe, einer Web-Freigabe oder im Internet (Standard) abgelegt sein. Mein Wissensstand heute: Wenn man das Office365 Update gegen das Internet „triggert“, wird immer die aktuell verfügbare Version installiert, unabhängig von dem Office 365 „Patch“ den ich im Empirum Patch-Management freigegeben habe. Dies könnte man mit dem Parameter „Targetversion“ in der Gruppenrichtlinie steuern.
https://helpfiles.matrix42-web.de/2020_DE/M42_WebDocu.htm#WM/Manuals/Patch_Management/PM_Office.htm?

Gruppenrichtlinien setzen per GPO oder Registry
Eine Übersicht über die Einstellmöglichkeiten zu Office Click To Run per GPO findest Du hier.
https://admx.help/?Category=Office2016&Policy=office16.Office.Microsoft.Policies.Windows::L_UpdatePath

Wo in der Registry finde ich die Gruppenrichtlinien zu Office 365?
HKEY_LOCAL_MACHINE\software\policies\microsoft\office\16.0\common\officeupdate

Was muss ich beachten, wenn ich eine eigene Update Freigabe erstelle?
Wenn man die Aktualisierungen im internen Netz bereitstellen mag, muss man noch die Entscheidung fällen, ob die Freigabe per UNC oder http/https erreichbar sein soll.
Erstellt man eine UNC-Freigabe, so darf diese keine versteckte („$“) Freigabe sein. Hinweis: Die NTFS Berechtigungen sollten Zugriff für Everyone oder das Computerkonto erlauben! Die Quellen müssen im Unterordner Office\Data liegen (Die Quellen liegen dann also unter dem zuvorgenannten „updatepath“ + „\Office\Data“). Darin gibt es eine v<Architektur>.cab, eine v<Architektur>_<Version>.cab und ein Unterordner mit der <Version>. Der Unterordner mit der Version enthält die Quellen für die Installation. Die Dateien haben für eine deutsche Installation folgendes Namensschema: $$$1031.cab. In den Quellen können mehr Office Produkte/Module enthalten sein, als installiert werden. Sprich, die Quellen können in der Freigabe das Access beinhalten, aber in der Configuration.xml ist das Access ausgeschlossen.

Wie lade ich die Office 365 Quellen für eine Installation oder Aktualisierung herunter?
Die Quellen werden mit dem Microsoft Bereitstellungstool (Setup.exe) und einer passenden Konfigurationsdatei heruntergeladen.
Setup.exe /download <Datei.xml>
Die Konfigurationsdatei benötigt die Angabe des Ablageortes SourcePath=“<Pfad>“.
Bereitstellungskonfiguration: https://config.office.com/
Bereitstellungstool: https://www.microsoft.com/en-us/download/details.aspx?id=49117

Protokollierung

Das Logging der Installation als auch der Aktualisierung erfolgt nach %WinDir%\Temp\%Computername%-<Datum>-<Uhrzeit>.log
Wenn die Datei %Computername%-<Datum>-<Uhrzeit>.log größer oder annähernd 100kb groß ist, dann hat zumeist ein Update stattgefunden.
Die kann man u.a. auch daran festmachen, ob in der Datei „Update mode context starting: /update“ zu finden ist.
Wenn etwas fehlschlägt, oder man nach einem Fehler sucht. Dann sollte man in der Datei nach „error“ suchen.
Für die Installation kann man einen alternativen Log Pfad in der Bereitstellungskonfiguration angeben.

Erweiterte Protokollierung
Falls die standardmäßige Protokollierung von Office 365 nicht ausreichend ist, so kann man diese wie folgt erweitern:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3 /f
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1 /f

Quelle: https://docs.microsoft.com/de-de/office/troubleshoot/diagnostic-logs/how-to-enable-office-365-proplus-uls-logging

Weitergehende Scripte für Office 365 (Click to Run)
https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts

Der Beitrag Office 365 Installation und Update – Gesammelte Werke erschien zuerst auf Workplace Management Blog.

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.

Zutaten zusammenstellen …

Import der Pakete

Wer die vorhandenen PreOS Pakete nutzen mag, kann direkt zum nächsten Punkt springen. Wer wiederum aktuelle Pakete importieren mag, muss in der Management Console unter Konfiguration, Software-Depot mit der rechten Maustaste auf das Register „Matrix42 PreOS Packages“ klicken und „Import/Export“ auswählen. Im darauffolgenden Dialog wählt man dann den zumeist vorgegebenen Ordner „\\%EmpirumServer%\Configurator$\PackageStore“ aus.
Die Schritte für einen erfolgreichen Import von PreOS Paketen sind nun hier per Screenshots dokumentiert:

Auswählen des Quellverzeichnisses, wie z.B.: \\%EmpirumServer%\Configurator$\PackageStore …
Da im „PackageStore“ bestimmt mehr als die gewünschten Pakete vorliegen und angeboten werden, ist es ratsam zuvor per „Keine auswählen“ die Auswahl zu negieren. Dann wählt man die für sich notwendigen Pakete aus der Liste aus und startet den Importvorgang. Die Liste der Pakete ist weiter unten zu entnehmen. Die Abbildung zeigt eine exemplarische Auswahl, da das Paket PxeOffAndReboot bis dato unverändert blieb.

Werden die Pakete auf der Zusammenfassung rot angezeigt und nicht importiert, dann startet entweder die Management Console nochmals neu und versucht die Schritte noch einmal, oder schaut nach, ob das Paket vielleicht schon in der Dateistruktur vorliegt. Wenn ja, so löscht es aus der Dateistruktur und startet anschließend den Importvorgang nochmals von neuem.

Nach einem erfolgreichen Importvorgang, werden die Pakete im Matrix42 PreOS Packages Ordner ähnlich wie folgt angezeigt.

Die neu importierten Pakete werden im Status „nicht freigegeben“ importiert und sind braun eingefärbt. Dies kann sich in Zukunft noch ändern, doch derzeit müssen die Pakete noch einzeln zur Installation freigegeben werden. Dazu öffnet man die Paketeigenschaften mit einem Doppelklick bzw. wählt „Eigenschaften“ im Kontextmenü eines jeden Paketes.

Welche Pakete werden benötigt?

Zur Durchführung einer Windows Installation benötigt man die nachfolgenden Pakete.

• DiskPartitioning – Vorbereiten der Festplatte
• DriverIntegration – Kopieren der Treiber des Models auf die vorbereitete Festplatte
• WindowsInstallation – durchführen der Windows Installation samt der Treiber und kopieren/installieren des UAF Agents vom WinPE
• PxeOffAndReboot – deaktivieren des WinPE PXE-Boots
• DomainJoin – Hinzufügen des Computers zur Domäne
• EmpirumAgentSetup – Installieren des vollwertigen Empirum Agenten und entfernen des UAF Agenten, Neustart …

Besonderheiten: Wenn man die PreOS Pakete aktualisiert bzw. aktuelle Pakete nutzt, muss man auch sein Empirum WinPE PXE-Image aktualisieren.

Die Reihenfolge ist wichtig!

Die Pakete müssen sich zur korrekten Verarbeitung in der oben aufgeführten Reihenfolge befinden. Auch bei neu importierten Versionen von Paketen muss auf die Reihenfolge geachtet werden. Dazu arrangiert man die Pakete, per Drag & Drop, von oben nach unten im SoftwareDepot.

Windows Installation Bundle

Man kann die zuvor genannten PreOS Pakete später einzeln zu seiner Konfigurations- oder Zuweisungsgruppe hinzufügen, oder eine UND-Klasse (Bundle) erstellen die diese Pakete enthält. Bei der Zuweisung der Pakete zu einer UND-Klasse muss die Reihenfolge nicht beachtet werden. Bei der clientseitigen Verarbeitung ist die Reihenfolge im SoftwareDepot maßgebend. Hier ein Beispiel für eine UND-Klasse, die im SoftwareDepot erstellt werden kann.

Der Beitrag Empirum WinPE – PreOS Packages erschien zuerst auf Workplace Management Blog.

Los geht’s!

WADK

Eine Installation des WADK auf dem EmpirumServer ist eine Voraussetzung zur Erstellung der WinPE PXE-Images. Dazu habe ich bereits zwei Artikel geschrieben, die die Hintergründe und die Bereitstellung erläutern:

• Empirum: WinPE anstatt EPE als PXE-Image
• Microsoft WADK / WinPE Versionen

Matrix42 WinPE Erweiterung

Mit jeder neuen Empirum Version kommt auch ein Stand des WinPE PreBoot Supports in das Empirum System. Die PreBoot Support Entwicklung ist jedoch nahezu völlig von der Empirum Entwicklung entkoppelt. Man kann den jeweils aktuellsten WinPE PreBoot Support mit einer noch unterstützen Empirum Version einsetzen. Den aktuellen WinPE PreBoot Support gibt es im Matrix42 Marketplace zum Download.

Der WinPE PreBoot Support, der derzeit als EXE angeboten wird, entpackt, mit einem Doppelklick, im gleichen Ordner eine Empirum Struktur. Falls man in diesem Ordner in der Vergangenheit bereits einen WinPE PreBoot Support entpackt hat, sollte man das vorhandene Empirum Verzeichnis löschen. Nur zur Sicherheit: Nicht das produktiv genutzte Empirum Verzeichnis löschen! Alternativ kann man auch ein Komprimierungsprogramm (7-zip) nutzen, um es in einen Ordner des EXE Namens zu entpacken.

Die entpackte Struktur wird dann über die vorhandene produktive Empirum Struktur kopiert und bestehende Dateien werden ersetzt.
Laut Matrix42 wird ein Backup der produktiven Empirum Struktur empfohlen. Soweit bin ich bis dato noch nicht gegangen. Meines Erachtens vorteilhaft kann jedoch eine Sicherung des nachfolgenden Ordners sein: Empirum\EmpInst\Sys\Images\WinPE sein. Im zuvor angegebenen Ordner liegen die Matrix42 Quellen zur Erstellung des Empirum WinPE PXE-Images.

Konfiguration WinPE PXE-Image

Dazu wechselt man in der Management Console in den Bereich „Konfiguration\Boot Konfigurationen“. Mit einem Klick auf das „+ Neu“ (unten links) beginnt man mit der Erstellung eines neuen PXE-Images.

Dem PXE-Image gibt man einen Namen – der Dialog weißt einen schon darauf hin, welche Zeichen und Buchstaben erlaubt sind.
In der Beschreibung kann man für sich die Grundlage des WinPE PXE-Images festhalten.
Der Konfigurationstyp ist in diesem Fall natürlich: WinPE.

Die Auswahl des Agent-Templates hat folgende Funktion:
Aus dem Agent-Template werden die Informationen bzgl. des EmpirumAgent Benutzernamens, des Ausfall-Servers und ob DHCP Optionen genutzt. Diese Informationen werden vom erstellten PXE-Image genutzt, um während der Ausführung des WinPE die Verbindung zum EmpirumServer herzustellen.

Ab einem Hotfix für die Empirum Version 19.0.1 werden standardmäßig die „erweiterten Eigenschaften“ zur Erstellung ausgeblendet.

Mit der TFTP Blockgröße kann man „spielen“, um die Übertragung des WinPE zu beschleunigen bzw. auf Stabilität zu trimmen.

Zusätzliche Treiberverzeichnisse
Unter „Zusätzliche Treiberverzeichnisse“ gibt man eine Quelle für Treiber an, die in das WinPE eingebunden werden sollen.

• Das sind nicht alle Treiber die später für das zu installierende Windows genutzt werden:
• Zumeist werden hier Netzwerkkartentreiber für das WinPE auf Windows 10 Basis benötigt, damit das WinPE PXE-Image eine Verbindung zum EmpirumServer herstellen kann.
• Bis dato war nur einmal ein Storage Treiber notwendig – damit verfährt man jedoch in gleicher Weise.
• Ich nutze in der Abbildung ein selbst erstelltes Verzeichnis, was separat vom vorhandenen DRV Ordner liegt, da dies meines Erachtens in absehbarer Zeit überflüssig wird.
• Es werden alle Treiber, die in diesem Ordner und auch Unterordner liegen, in das WinPE eingebunden.
• Idealerweise generiert man im angegebenen Ordner Unterordner mit den Namen der Modelle oder Netzwerkkarten.

Erstellung PXE-Image

Bei der Erstellung des WinPE PXE-Images, mit Klick auf Speichern (unten rechts), werden dann die …

• Windows PE Quellen (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment)
• Matrix42 WinPE Erweiterung (Empirum\EmpInst\Sys\Images\WinPE)
• angegebene „Zusätzliche Treiberverzeichnisse“
• mit Hilfe des Skriptes (CreatePXEWinPEMultiPlatform.ps1)

zu einem PXE-Image zusammengeführt.

Status der Erstellung

Die Erstellung dauert ca. 15-20 Minuten. Den Status der Erstellung kann man am Symbol bei der Konfigurationsübersicht (oben links) oder unter Management im Menü „Info“ unter „Back-end tasks …“ einsehen.

In der Konfigurationsübersicht gibt es die:

• Sanduhr – warten das der BTQHx64 Dienst es verarbeitet
• Zahnräder – der BTQHx64 Dienst ist dabei, Dauer ca. 15-20min
• grüner Haken – erfolgreich erstellt
• rotes Kreuz – Fehler bei der Erstellung

Fertig!

Die erfolgreiche Fertigstellung kann, wie zuvor beschrieben, an mehreren Stellen eingesehen werden. Hier ein Auszug aus dem Back-end task Log:

Für technisch Interessierte: Das erstelle PXE-Image ist anschließend unter „Empirum\EmpInst\Wizard\Image\VirtualRoots\BootEnvironment\<PXE-ID>“ zu finden.

Einmalige Einrichtung ist getan. Was nun?

Wenn man sich für eine neue WinPE Erweiterung (siehe oben) entscheidet, muss das PXE-Image neu erstellt werden, da die neuen WinPE PreOS Packages zumeist auch auf Neuerungen im Empirum WinPE zurückgreifen. Ob man dazu eine neue Konfiguration erstellt, oder nur die vorhandene mittels „Speichern“ mit den neuen Quellen aktualisiert, muss man selbst entscheiden. Benötigt das vorhandene PXE-Image aufgrund einer noch nicht getesteten oder neuen Hardware einen zusätzlichen Netzwerkkartentreiber, so legt man den Treiber im oben genannten Ordner („Zusätzliche Treiberverzeichnisse“) ab und generiert durch „Speichern“ das PXE-Image neu.

Fehler bei der Erstellung …

Bei Fehlern bei der Erstellung kann man entweder in die Back-end task Verarbeitung schauen, oder direkt in das aktuelle Log des BTQHx64 Dienstes auf dem EmpirumServer unter
%ProgramData%\Matrix42\Logs\BackendTaskQueueHost64.

Der Beitrag Empirum WinPE – PXE-Image Erstellung erschien zuerst auf Workplace Management Blog.

Wenn nicht, so schaut der Dialog aus:

Damit sind wir auch schon mitten im Thema. Der SystemShutdown Befehl der Empirum Setup.inf gibt dem Benutzer einen Hinweis, dass ein Neustart ansteht, den der Benutzer je nach Parameter nicht umgehen kann. Darin unterscheidet sich der SystemShutdown gegenüber dem Reboot= bzw. SetReboot Befehl. Der SetReboot Befehl gibt die Neustart Anforderung an den Agenten weiter und ermöglicht somit dem Benutzer, dass dieser den Neustart, je nach Agenten Konfiguration, verschieben kann. Bei BIOS Updates oder Windows Feature Upgrades ist dies, nach der teilweise vorgenommenen Änderungen, nicht unbedingt gewünscht. An dieser Stelle kann der SystemShutdown eingesetzt werden, um dem Benutzer keine Wahl zu lassen, wann er den Computer neu starten möchte.

SystemShutdown In fünf Minuten erfolgt ein Neustart!/nBitte beenden Sie alle offenen Anwendungen, 1, 1, 300, 1

[Strings:07]
ShutdownTextDesc=Das BIOS Update erfordert einen Neustart des Computers.\nSpeichern Sie Ihre Daten und schließen Sie alle offenen Anwendungen.\n\nKlicken Sie 'OK' um den Computer neu zu starten.

[Strings:09]
ShutdownTextDesc=The BIOS update needs to restart your computer.\nSave your work and close all open applications.\n\nClick 'OK' to restart your computer.

[Set:FinishedBIOSUpdate]
If DoesProcessExist ("Explorer.exe") == "1" Then "UserIsLoggedOn" Else "NoUserIsLoggedOn" EndIf

[UserIsLoggedOn]
SystemShutdown %ShutdownTextDesc%, 1, 0, 600, 1

[NoUserIsLoggedOn]
SystemShutdown %ShutdownTextDesc%, 1, 0, 15, 1

Der Beitrag SystemShutdown vs. SetReboot erschien zuerst auf Workplace Management Blog.

Neuer Treiber

Als erstes muss für das jeweilige Model der aktuelle Touchpad Treiber von Dell heruntergeladen werden. Dazu den Treiber samt Setup.exe herunterladen.

Vorgehensweise

Vor der Installation bzw. Reinstallation des Treibers muss jedoch ein Registry Baum gelöscht werden. Dazu den gesamten Baum unter HKLM\Software\Alps löschen. Anschließend den aktuellen Treiber per Setup.exe installieren und das Laptop neu starten. Nach dem Neustart wurde auch in dem Tasktray ein Touchpad Symbol sowie die Aktivitäten angezeigt und die Dell Touchpad Applikation hat die Konfiguration der Gesten ermöglicht.

Automatisierte Treiberinstallation per Empirum

Nun sollte die Installation nicht beaufsichtigt, sondern „unattended“ während der OS-Installation passieren. Dies haben wir dann wie folgt umgesetzt.

Callhidden reg delete HKLM\Software\Alps /f

Call "<Pfad>\DellTP\Setup.exe" /s /V"FORCE=true /qn"

Wie kann ich feststellen, ob bei mir die Touchpad Gesten funktionieren?

Rufen Sie die „Dell Touchpad“ Applikation über die Windows Suche auf. Diese sollte ihnen die Konfiguration der Gesten ermöglichen (links anzeigen). Im Standard sollte das Touchpad Symbol im Tasktray zu sehen sein.

Der Beitrag Dell Touchpad – Gesten funktionieren nicht erschien zuerst auf Workplace Management Blog.

PrepareDRVbyModel_Packages

Mein Ersatz bietet (meines Erachtens:)) einige Vorteile und weicht in den nachfolgenden Punkten von dem Matrix42 Grundgedanken ab:

• es ist „gesprächiger“ und man kann eher nachvollziehen, was es macht (siehe Screenshots am Ende des Beitrages)
• der Ablageort der Treiber kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• der Ablageort der Drivers.ini kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• es kann festgelegt werden, ob die WinPE Installation weitergehen soll, auch wenn kein Eintrag in der drivers.ini, Treiber, etc. gefunden wurde.

Übersicht dieses Beitrages

• Import der OS-Packages
• Kurze Einführung: Hardware Model zu Treiber/Software Zuordnung per drivers.ini
• Möglichkeiten mit PrepareDRVbyModel_Packages
• Einführung PostOSInstallation Paket
• Download
• Fehlersuche
• Screenshots

Import der OS-Packages

Zuerst ist es notwendig, die zusätzlichen OS-Package über das Software-Depot zu importieren. Danach muss die Reihenfolge arrangiert werden, damit die richtige Abarbeitung während der OS-Installation gewährleistet ist:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• <PrepareDRVbyModel_Packages>
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• <PostOSInstallation> (optional aber empfohlen)
• EmpirumAgentSetup

Hardware Model zu Treiber/Software Zuordnung

Die Zuordnung Model zu Treiber geschieht wie bei dem Paket der Matrix42 über die drivers.ini Datei. Diese ist im Standard unter Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt.

Aufbau der Drivers.ini
[<WMI Manufacturer>]
<WMI Model>=<Ordner, *.ZIP, *.cab unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers>

z.B.
[Dell Inc.]
OptiPlex 7010=DellOptiplex7010
;alternativ OptiPlex 7010=DellOptiplex7010.zip
;alternativ OptiPlex 7010=DellOptiplex7010.cab

Möglichkeiten mit PrepareDRVbyModel_Packages

Nachfolgend sind die Möglichkeiten erläutert, die sich aufgrund der Anpassung und Erweiterung ergeben. Diese Möglichkeiten können über die Variablen in der Management Console gesteuert werden. Die aufgeführten Variablen sind alle unter der Variablen Sammlung „PrepareDRVbyModel_Packages“ zu finden.

DriversAreMandatory:
Das Matrix42 Paket drehte sich bis vor kurzem solange in der Schleife bis ein Treiber in der drivers.ini gefunden wurde.
Dies ist für eine produktive Umgebung, den Dienstleister etc. gut so.
Wenn man jedoch einen Computer ohne spezifische Treiber installieren will (zum Test), dann muss man im Matrix42 Falle einen drivers.ini Eintrag erzeugen mit einem Verweis auf ein leeres Verzeichnis.
Dieses Verhalten wurde mit dem DriverIntegration 2.6 Pakete verändert – man kann es jedoch nicht steuern.

Variablenwerte:
0, WinPE fährt mit der WindowsInstallation fort, auch wenn kein Treiber in der drivers.ini gefunden wurde.
1, Matrix42 Standardverhalten – das System läuft in der Schleife und führt die WindowsInstallation nicht fort.
Somit kann man für eine produktive Struktur (Konfigurationsgruppe) sicherstellen, dass die Installation nur mit bekannten Hardware-Typen durchgeführt wird.

DriversRootPath:
Die Idee, den DriversRootPath anpassbar zu machen, hatte mehrere Gründe:
Selektive Synchronisation der Treiber: Hiermit kann man die Treiber direkt unter Packages\Drivers ablegen und mit einem angepassten „ESubDepot_Packages“ SyncJob diese für bestimmte Standorte auslassen und mit einem selbsterstellten ESubDepot_PackagesDrivers diese separat synchronisieren lassen.
Treiber-Update Softwarepakete: Durch eine Erweiterung der Ablage um eine Setup.inf, DPInst.exe und xml kann man eine Aktualisierung der Treiber auf bestehenden Systemen durchführen und mass dazu die Treiber nicht mehrmals ablegen. Dies werde ich in einem späteren Beitrag nochmals aufgreifen.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Kommentar:
Hinweis: Man kann in der drivers.ini auch Teilpfade angeben.
Für eine Kopie eines Ordners zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP
Für die Nutzung einer ZIP Datei zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP\Optiplex7010.zip
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

DriversINIPath:
Die Idee hierbei war, dass man eine zweite drivers.ini Datei, unabhängig von einer produktiv genutzten, einsetzen kann.
Darin kann man Einträge für eine bekannte Hardware auf einen anderen Pfad, ZIP, etc. setzen und somit vorab bzw. parallel testen.
Somit kann für eine bestimmte Konfigurationsgruppe ggf. der Wert: Matrix42\OsPackages\Drivers\Test sein.
In diesem Ordner muss dann die alternative drivers.ini abgelegt sein.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

Perfekt funktioniert PrepareDRVbyModel_Packages mit dem PostOsInstallation Paket von mir. Das genannte Paket prüft ob es eine C:\EmpirumAgent\Drivers\HWspecificSW\Setup.inf gibt und führt diese aus.

Möglichkeiten des PostOsInstallation

Das PostOSInstallation Paket ist einfach und ruft eine abgelegt PostOSInstall.bat auf.
Hinweis: Diese Datei solltet ihr vor der ersten Benutzung einsehen und anpassen!
Die Batch Datei hat heute mindestens drei Funktionen:

• Es importiert eine von dem PrepareDRVbyModel_Packages Paket erstellte Registry Datei, die ähnliche Werte in die Registry schreibt (HKLM\Matrix42\Installer), wie die EPE Installation.
• Es passt die durch Matrix42 vorgegebenen Firma, Benutzer, Support etc. Informationen in der Registry an, die man bei der EPE Installation in der Betriebssystemvorlage angegeben hat.
• Es führt eine Setup.inf aus dem C:\EmpirumAgent\Drivers\HWspecificSW Ordner aus, falls diese vorhanden ist. Somit kann man wieder im „Hardware-Profil“ Treiber per PNP und per EXE/MSI installieren.

Somit ist die PostOSInstall.bat eine Art Ersatz für die EmpirumAgent.bat/UEMAgent.bat.

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

PrepareDRVbyModel_Packages 1.5 (458 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (503 Downloads )
MD5 Hash der Downloaddatei: 0D3415555E6197DC510B02E946D96C5169FD8529

Los geht’s

Schritt 1:
Zuweisen der Pakete für eine Konfigurationsgruppe:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• PrepareDRVbyModel_Packages
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• PostOSInstallation (optional aber empfohlen)
• EmpirumAgentSetup
• Betriebssystem (per Variable oder aus dem rechten Baum)
• WinPE (Bootkonfiguration)
• Agent-Template

Schritt 2:
Setzen der Variablen für die oben genannten Pakete (siehe hierzu ggf. auch das WinPE Dokument der Matrix42).
Zuordnung des Betriebssystems

Schritt 3:
Zuweisen eines Computers

Schritt 4:
Aktivieren von PXE und Software (OS.INI ist nicht notwendig!)
Achtung:nicht während einer aktiven WinPE Phase den Computer nochmals aktivieren (dies kann ab WinPE 1.4.11 wieder getan werden).

Rückmeldungen sind willkommen!

Fehlersuche:

• Erster Anlauf: In der Management Console auf dem entsprechenden Computer das PXE-Log ansehen
• Informationen zum Ablauf der OS-Packages befinden sich in Empirum\EmpInst\Wizard\OS\Auto\<MAC8> oder <UUID>\debug_Matrix42.Platform.Service.Host.log.
  Suchen nach [wpm-blog und darunter sollten weitere Informationen zu finden sein …

Beispielhafte Screenshots:

DriversAreMandatory = 0 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1, passende Zuordnung/Treiber in drivers.ini gefunden, abweichende DriversIniPath Variable, Treiber werden kopiert

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

Ursachenforschung (Empirum v15.x/16.x)

Auf dem Computer waren die VCRedist Versionen des Empirum Agenten installiert und im %WinDir%\System32\Empirum Verzeichnis gab es einen Install Ordner mit der Setup.inf des Empirum Agenten. Das bedeutete, dass die Installation des Empirum Agenten durch die EmpirumAgent.bat gestartet wurde, jedoch abgebrochen ist. Nach den VCRedist Varianten wird das .NET Framework 4.0 installiert. Die Installation des .NET Framework schreibt ein Log in den %TEMP% Ordner des administrativen Kontos, das sich bei der OS-Installation einmalig automatisch anmeldet. Diesem Log war zu entnehmen, dass das .NET Framework einen KB Hotfix installieren möchte, den die Installation nicht bei sich hat. Dieses Problem scheint jedoch nur in bestimmten Konstellationen (bereits installierte Treiber) aufzutreten.

Lösung

Das Problem kann man nun beheben, indem man den Hotfix vorab in die Windows 7 Installation einbringt oder eben vor dem Emprium Agenten Aufruf in der EmpirumAgent.bat bereits installiert. Den fehlenden Hotfix KB958488 gibt es hier.

Slipstream in die OS Quellen

Die Integration des Hotfixes in die Betriebssystemquellen wurde hier von Marco bereits detailliert erklärt.

Installation vor dem Empirum Agenten

Man kann jedoch auch den Hotfix in einem Ordner unterhalb von Configurator$ ablegen und vor dem EmpirumAgenten Installation bereits installieren. Entweder ruft man die nachfolgende Zeile in der EmpirumAgent.bat vor der Agenten Installation auf, oder fügt dies in einer PostOSInstallationxxx.bat hinzu, die ich in meiner Treiberintegration bereits erwähnt habe. Wenn man die PostOSInstallationxxx.bat am Ende der Betriebssysteminstallation aufruft, kann man bei einem Empirum Versionswechsel/Update einfacher die EmpirumAgent.bat aktualisieren und braucht nicht die Änderungen die man gemacht hat zu überführen.

Hier ein Beispiel für die Installation des x64 Hotfixes.
CALL wusa.exe „\\%EmpirumServer%\Configurator$\<Ablage-Ort>\Windows6.1-KB958488-v6001-x64.msu“ /quiet /norestart

Weiterer Tipp

Generell sollte man auch, für eine zuverlässige Ausführung der EmpirumAgent.bat, den PostDelaySeconds Wert auf 120-180 setzen .
Die Erstellung der Variable und das Setzen des Wertes habe ich in diesem Artikel bereits erläutert.

Der Beitrag Empirum Agent wird nicht installiert nach der OS-Installation erschien zuerst auf Workplace Management Blog.