Was ist der Präsentationsmodus?

Der Präsentationsmodus (Presentation mode) ist eine Funktion des Betriebssystems, der von Programmen eingeschaltet und von anderen Programmen systemweit ausgewertet werden kann. Der Präsentationsmodus wird zumeist von Programmen gesetzt die im Vollbild-Modus ausgeführt werden, wie aktive Präsentationen (Microsoft Powerpoint, etc.), Kiosk Modus von Browsern, jedoch auch von Vollbild Terminal Server Sitzungen, Citrix Wokspace App Sitzungen, uvm..

Präsentationsmodus und Empirum UEM Agent

Matrix42 hat sich diese Funktion zu Nutze gemacht und wertet den Präsentationsmodus aus, um den Anwender davor zu schützen, das Software-Installationen während einer laufenden Präsentation starten. Damit man eben nicht nur ein Programm und somit Anwendungsfall abfragt, wo es doch eine Vielzahl an Programmen und Anwendungsfälle gibt, wertet der UEM Agent je nach Konfiguration genau diesen Präsentationsmodus aus.

Feststellungen

So kann es in einer bestehenden Umgebung vorkommen, dass bei der häufigen Nutzung von Programmen, die den Präsentationsmodus aktivieren, die Installation(en) nicht starten. Dies kommt u.a. dann vor, wenn die Windows Clients als „Terminal Clients“ im HomeOffice genutzt werden. Ähnliche Konstellationen treffen auf Administratoren zu, die per Remotedesktopverbindung (mstsc) auf Windows Server aufgeschaltet sind.

Wie bekommen ich nun wichtige Software trotz alledem installiert?

Bei der Zuweisung einer Software wird im Standard die Verteilungsoption „Installieren und Erneuern“ gesetzt. Ergänzt man die Verteilungsoption um die Option „Installationszeitraum ignorieren“, wird die Installation auch bei gesetztem Präsentationsmodus ausgeführt.

Eine weitere Möglichkeit ist natürlich auch, das man sich für diese Clients eine weiteres Agenten-Template erstellt und zuweist. Hier gilt der Grundsatz der Empirum Console, das nähere am Computer befindliche Objekt hat Vorrang. Welches Agenten-Template tatsächlich angezogen wird, kannst du in den Computereigenschaften unter „Zugeordnete Objekte“ überprüfen.
Eine solches Agenten-Template, also mit deaktiviertem Präsentationsmodus, könnte somit für Computer in der Produktion, Kiosksysteme, Anzeigesysteme, Windows als „Terminal Client“ sinnvoll eingesetzt werden.

Was sagt die Empirum Hilfe?

Hier der dazugehörige Text aus der Empirum Hilfe …
Präsentationsmodus beachten:  Wenn der Anwender diese Funktion aktiviert, verhält sich der Agent während einer Präsentation so, als wäre der Computer außerhalb des Installationszeitraums. Es wird keine Software installiert, es sei denn ein Paket hat die Verteilungsoption „Installationszeitraum ignorieren“ gesetzt.

UEM Agent beachtet Präsentationsmodus – Was nun?

Möchte man die Vorteile des Präsentationsmodus nutzen, um seine Kollegen, Chef, Vorstand nicht zu verärgern :), kann bzw. sollte man meines Erachtens trotzdem zumindest Pakete wie die folgenden mit der obigen Verteilungsoption zusätzlich konfigurieren:

• Empirum Inventory
• Matrix42 Patch-Management (Scan)

Weitere Pakete, wie vielleicht auch das Fix Paket des Patch-Managements, können somit von euch auch entsprechend priorisiert werden.

Da ich hier selbst einige Zeit im Dunkeln getappt bin, habe ich das hier für mich und euch zusammengefasst. Wie sind eure Erfahrungen mit dem Präsentationsmodus oder habt ihr Ergänzungen?

Der Beitrag Empirum: Pakete bleiben im Status Download erschien zuerst auf Workplace Management Blog.

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.

• 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.

wpm-Blog WinPE-Extension-Pack 1.3

Aufgrund der Windows 11 Implementierung und Unterscheidung im OS-Installer habe das PrepareDRVbyModel_Packages Paket überarbeiten „müssen“. Der Vorteil für Euch – auch eine weitere Funktion ist nun für alle nutzbar. Es ist die CommonDrivers Funktion. Ein Ordner mit Treibern wird für alle Modelle kopiert. So könnt ihr in diesem Ordner, die (neuen?) Dockingstation oder USB-Netzwerkadapter Treiber ablegen und müsst dazu nicht alle Modellpakete erneut anpassen. Es gibt einen Standard-Ordner (CommonDrivers) der kopiert wird, alternativ könnt ihr per Variable einen anderen Namen angeben. Den Gedanke hatte ich auch schon einmal und ein Nutzer hat mich da noch etwas „geschuppst“ – jetzt steht es Euch allen zur Verfügung. Ich hoffe, es gefällt Euch.

Das Paket, dass den Hotfix installiert, damit Windows 10 Pro keine ungewollten Neustart direkt nach WinPE Phase durchführt, habe ich in das Extension Pack aufgenommen. Ihr könnt selbst entscheiden, ob ihr es benötigt, oder nicht.

Das aktuelle wpm-Blog WinPE-Extension-Pack bekommt ihr hier.

innomea WinPE Extension Pack

Neben den WinPE Erweiterungen die ihr hier auf meinem Blog seht, arbeite ich auch den WinPE Erweiterungen der innomea mit. Die Erweiterungen der innomea sind hauptsächlich Ergänzungen zu den Paketen die Matrix42 anbietet. Mit den Ergänzungspaketen (HardwareProfileValidator und CommonDrivers) sollen annährend die Funktionen bereitgestellt werden, die z.B. hier mit PrepareDrvByModel_Packages erreicht werden.

Das innomea PostWindowsInstallation Paket wiederum ist eine starke Weiterentwicklung des hier angebotenen PostOSInstallation. Dieses Paket ermöglicht viele Anpassungen an der Windows Installation, die einige von Euch noch von den Betriebssystemvorlagen her kennen. Dabei wurde teilweise auch auf Einträge im Matrix42 ideas Portal eingegangen.

Hier ein kleiner Auszug der Funktionen, die ihr zum Großen Teil per Variablen steuern könnt: Installation von Treibern per EXE/MSI, Firewall Modifikationen, Festplatte/Partition C: umbenennen, Support, Besitzer Informationen hinterlegen, EmpirumServer der OS-Installation als Umgebungsvariable setzen, „Kennwort läuft nicht ab“ für den zusätzlichen lokalen Admin setzen, uvm.

Den kompletten Umfang und die weiteren Pakete könnt ihr hier einsehen.

Matrix42 DomainJoin Paket

Das Matrix42 DomainJoin Paket wird in Kürze auch eine neue Version erhalten, dessen Vorteil einige zu nutzen wissen werden. Vielen Dank an die Beteiligten der Matrix42 für eure offene Kommunikation und Umsetzung!

Beyond Empirum WinPE

Natürlich dreht sich die hier zumeist angesprochene Matrix42 Empirum Welt nicht nur um WinPE. Jedoch kann man ganz gut erkennen, dass diese mir sehr viel Spaß bereitet. Matrix42 ist dabei eine größere Änderung im UEM-Agent vorzunehmen. Darauf werde ich mit Euch in Kürze schauen.

Stay save!

Wer mich kennt, weiß wie sehr ich versuche „Anglizismen“, wenn möglich, zu umgehen. Es gibt meines Erachtens jedoch einige Situationen bei diesen diese Worte oder Sätze einfach kürzer und treffender sind. Wie auch immer: Bleibt weiterhin gesund in dieser „unbekannten“ und noch „verrückteren“ Zeit!

Der Beitrag Aktualisierungen Frühjahr 2022 erschien zuerst auf Workplace Management Blog.

Variable USER_UPDATE

Eine Variable steuert, wie das Paket sich verhalten soll. Die nachfolgende Zeile in der Setup.inf verrät, was man machen muss.
If „%VM_SUBDEPOT_USER_UPDATE%“ != „0“ Then „Set:DeleteUser2“ EndIf

Erstellen der Variable

Erstellt man unterhalb der Variablendefinition „SUBDEPOT“ eine Variable mit dem Namen „USER_UPDATE“ (Typ: Zahl oder Text), so kann man steuern, was bei einem „Update“ geschehen soll. Setzt man die Variable explizit auf „0“, so wird der Benutzer nicht bei jedem Update gelöscht und neu angelegt

Möchte man die vorgenannte Funktion nutzen, so erstellt man die Variable „USER_UPDATE“ vom Typ Zahl in der Variablendefinition: SUBDEPOT.
Dazu wählt man in der Matrix42 Management Console, Administration, Extras, Variablendefinitionen … aus und navigiert zur vorhandenen Variablendefinition „SUBDEPOT“. Durch einen Doppelklick oder der Auswahl und Bearbeiten, landet man in den Eigenschaften der Variablengruppe SUBDEPOT. Hier fügt man die Variable mit einem Klick auf das „+“ Symbol hinzu. Wer einen vorgefertigten Beschreibungstext haben möchte: 0 – Don not delete user | 1 – Delete and create user

Zuweisung des Wertes

Anschließend setzt man diese Variable für einen Computer, eine Konfigurations- oder Zuweisungsgruppe. Weitergehende Informationen zur Übernahme des Wertes für untergeordnete Objekte findet man hier.

Der Beitrag Empirum SubDepot Paket und lokaler Agenten Benutzer erschien zuerst auf Workplace Management Blog.

Was ist das Problem?

Die Installation des WinPE Paketes „LanguagePacksInstallation“ läuft erfolgreich durch, jedoch befindet sich das LanguagePack anschließend nicht im installierten Windows.

Ergänzender Hinweis

Es gibt für Windows 10 1909 keine separaten LanguagePack Quellen. Das Build 1909 nutzt die gleichen Quellen wie das Build 1903. Das bezieht sich auch, wie ich schon festgestellt habe, auf das WADK – auch hier wird auf die Version 1903 verwiesen.

Lösungsvorschläge

Nun aber zu den Lösungsvorschlägen. Diese sind im Original auch in den Kommentaren zu nachzulesen. Da die Formatierung der Kommentare nur eingeschränkt ist, habe ich es hier nochmals zusammengefasst.

Zwei Lösungsmöglichkeiten

Es gibt zwei von Ingo getestete Lösungsvorschläge.

• Die Windows 10 Build 1909 Quellen auf einen neueren Stand bringen, der die Installation wieder erlaubt (gleich oder neuer als 18363.476). Das aktuelle Update gibt es im Matrix42 Patch-Management oder im Windows Catalog zum Download.
• Das Sprachpaket direkt in die Quellen integrieren.

Für beide Fälle ist eine Anpassung der Quellen notwendig (Sicherheitskopie anfertigen!). Dazu sollte man mit dem Umgang der DISM oder äquivalenten Powershell Befehle vertraut sein. Alternativ kann man es bestimmt auch mit DISM GUI oder DISM++ bewerkstelligen. Mit beiden genannten DISM GUI Tools habe ich leider noch keine Erfahrung gesammelt.

Grober Ablauf

• Passenden Index herausfinden. Da die Windows Images zumeist mehrere Editionen enthalten, muss man vor einer Anpassung wissen, welchen Index man nutzt.
• Mounten des Images/Index in einen Ordner
• Hinzufügen des Updates oder des Sprachpaketes (später Schritt 3)
• Dismounten des Images

Befehle

Die nachfolgenden Befehle beinhalten mitunter Platzhalter oder beispielhafte Verzeichnisse, Indizes uvm.

;Schritt 1: Auflisten der Indizes und Windows Editionen
DISM /Get-Imageinfo /Imagefile:<Pfad>\install.wim

;Schritt 2: Mounten des genutzten Index - hier 5 in den Ordner D:\mount
DISM /Mount-Image /Imagefile:<Pfad>\install.wim /Index:5 /MountDir:D:\mount

;Schritt 3a: Hinzufügen des Updates 
DISM /Image:D:\Mount /Add-Package /Packagepath:<Pfad>\<Update.msu> 
;Schritt 3b: Hinzufügen des Sprachpaketes
;DISM /Image:D:_mount /Add-ProvisionedAppxPackage /PackagePath:<Pfad>\LanguageExperiencePack.de-DE.Neutral.appx /LicensePath:<Pfad>\License.xml)

;Schritt 4: Dismounten des Images 
DISM /Unmount-Image /MountDir:D:\mount /commit

;Schritt 5: (optional) Aufräumen nach getaner Arbeit
DISM /Cleanup-Wim

Euch – viel Erfolg!
Ingo – vielen Dank für das Teilen der Erkenntnisse!

Der Beitrag LanguagePacks und Windows 10 Build 1909 erschien zuerst auf Workplace Management Blog.

Empirum PE (Linux)

Das EPE (Empirum PreInstallation Environment) auf Linux Basis verarbeitet mittels des EIS Interpreters die zugewiesenen Jobs (EIS Skripte), die per OS.INI im MAC8 Verzeichnis (letzten 8 Stellen der MAC-Adresse) zugewiesen werden. Die Abfolge der Aufträge sind durch das EIS Skript weitestgehend vorgegeben. An definierten Punkten kann man mittels der Custom EIS Skripte in den Ablauf eingreifen. Bei einer Betriebssysteminstallation werden das Windows PE und die Betriebssystemquellen auf die lokale Festplatte übertragen und von dort die Windows Installation per Windows PE gestartet. Die Installation wird mittels der Betriebssystemvorlage (OS.INI) beschrieben und parametrisiert (Windows Einstellungen, Lizenz-Schlüssel, Partitionierung, Domain-Join, uvm.). Am Ende einer Betriebssysteminstallation wird mittels des Parameters „Befehl“ der Empirum Agent installiert und der Übergang zur Softwareverteilung bereitet.

Empirum WinPE (Windows PE)

Das Empirum WinPE wird ebenso über die Management Console, Konfiguration, Bootkonfiguration erstellt. Bei der Erstellung bedient sich Empirum dem auf dem EmpirumServer installierten WADK (C:\Program Files (x86)\…), nicht dem in Empirum importieren WADK. Das erstellte Empirum WinPE beinhaltet einen EmpirumAgenten (Matrix42 UAF) und diverse WinPE Erweiterungen. Der im WinPE integrierte UAF Agent verarbeitet die zugewiesenen PreOS Pakete (aus der %Computername%.DDC).

Hier gilt die Reihenfolge, von oben nach unten, wie sie im SoftwareDepot festgelegt wurde. Die WinPE Pakete (auf Basis von powershell) werden über die EMC Variablen parametrisiert und nicht mehr über die OS.INI. Deswegen muss bei einer Aktivierung auch kein Haken mehr bei „Betriebssystemkonfiguration (OS.INI) erstellen“ gesetzt werden. Die Variablen bzw. die Variablengruppierungen sind nach den zugewiesenen Paketen benannt (z.B. DiskPartitioning, WindowsInstallation). Im Paket WindowsInstallation wird ebenso ein minimaler Matrix42 UAF Dienst installiert, der nach dem Paket „PxeOffAndReboot“ bis zur Installation des eigentlichen Matrix42 Windows Agenten durch das Paket EmpirumAgentSetup aktiv ist. Somit werden die PreOSPakete bis zum PxeOffAndReboot im Kontext des WinPE ausgeführt und im Anschluss im Kontext des installierten Windows. In dem Installations-Vorgang mittels WinPE stellt die erfolgreiche Ausführung des EmpirumAgentSetup Paketes den Übergang zur Softwareverteilung dar. Eigene PreOS Pakete können mittels Powershell Kenntnissen und dem PreOS Package Editors erzeugt und in die Abfolge eingebaut werden.

PreOS Paket Variablen

Die folgende Variablen bzw. Variablengruppen müssen für eine erfolgreiche Installation per WinPE gesetzt werden.

• DiskPartitioning (optional)
• DriverIntegration (optional)
• WindowsInstallation
• FQDN
• ORGANIZATIONAL_UNIT
• TimeZone
• DomainJoin
• MX42_AGENT_PUSH_PACKAGE_FOLDER

Zu diesem Thema werde ich in Kürze einen gesonderten Artikel erstellen. Wer nicht warten mag, sollte das PDF, dass der Empirum WinPE Erweiterung beiliegt, nutzen.

Vorteil der PreOS Pakete

Die sogenannten PreOS Pakete kann man, wie oben beschrieben, auch selbst erstellen. Damit man die Pakete in Empirum importieren und nutzen kann, muss man diese mit dem PreOS Package Editor erstellen. Durch das beschriebene Konstrukt kommen die Vorteile des WinPE Boots und der einzelnen Pakete erst richtig zum Vorschein. Beispielhaft, kann man bei einer Windows 7 zu Windows 10 Migration direkt auch das BIOS aktualisieren, auf UEFI umstellen, uvm. Diese Möglichkeiten waren mit dem EPE und der EIS basierten Installation nicht bis schwer umzusetzen.

Beispiele selbsterstellter PreOS Pakete

In Kundenumgebungen habe ich bereits Pakete wie:

• BIOS Update
• BIOS Konfiguration in unterschiedlicher Art und Weise
• UEFISecureBootValidator
• PostOSInstallation

erstellt und genutzt.
Einen Teil der Pakete hatte ich bereits veröffentlicht.

In Kürze werde ich ein Update der gesammelten und universellen Werke bereitstellen.

Der Beitrag Empirum WinPE – EPE Gegenüberstellung erschien zuerst auf Workplace Management Blog.

Was muss man tun, um es zu nutzen?

WinPE Erweiterung installieren.

Zu aller erst muss man die WinPE Erweiterung installieren. Wie zuvor beschrieben gibt es die WinPE Booterweiterung im Matrix42 Marketplace. Diese Erweiterung musst Du in Deine Empirum Umgebung installieren/kopieren. Dazu liegt dem Download ein PDF bei, dass die Installation beschreibt.

Installation des WADK auf dem EmpirumServer

Auf dem EmpirumServer muss das WADK (möglichst aktuell) installiert sein. Die WinPE Erweiterung bedient sich dem installierten WADK und nicht dem in Empirum importierten WADK. Die Installation des WADK habe ich im Beitrag „Matrix42 OS Deployment mit WinPE – Vorausetzungen“ bereits beschrieben.

Erstellen einer Bootkonfiguration

Anschließend muss eine Bootkonfiguration vom Typ „WinPE“ anstatt „EPE“ erstellt werden. Dabei wird das PXE-Image mit dem Inhalt des WinPE erstellt. Die Besonderheiten bzgl. der Optionen EFI und BIOS sind ebenfalls in dem WinPE HowTo PDF Dokument erläutert.

WinPE PXE-Image

Das erstellte WinPE PXE-Image enthält den Matrix42 UAF (Universal Agent Framework). Der UAF wird dazu benutzt die PreOS-Pakete (Empirum Pakete für die WinPE Verarbeitung) auszuführen. Matrix42 liefert einige WinPE Beispielspakete mit. Schlußendlich bestimmen mehrere einzelne PreOS-Pakete die WinPE Auftragsabfolge bis der PXE-Boot deaktiviert wird.
Zum Beispiel kann man mit den folgenden drei Paketen eine Windows 10 Installation durchführen.

• DiskPartitioning (Vorbereiten/Partitionieren der Festplatte)
• DriverIntegration (Ablegen der Hardware-Modell spezifischen Treiber)
• WindowsInstallation (Installation von Windows 10 unter Nutzung der abgelegten Treiber)

Gesteuert werden diese Pakete über dazugehörige Variablen die pro Gruppe oder Computer gesetzt werden. Hier muss man etwas umdenken, da man keine Betriebssystemvorlage mehr erstellt und zuweist, sondern die PreOS-Pakete zuweist und die dazugehörigen Variablen setzt.

Bei der zuvor genannten Abfolge muss nicht Schluß sein. So kann man vor der OS Installation ggf. auch das BIOS aktualisieren und konfigurieren uvm. Für die BIOS Aktualisierung hat Matrix42 auch bereits ein Paket bereitgestellt.

Mein Fazit

Die Idee WinPE zum Starten und Verarbeiten von Befehlen per PXE birgt viel Potential für die Zukunft, da u.a. die Basis Windows anstatt Linux und die genutzte Skript-Sprache powershell anstatt „EIS“ ist. Von den bereitgestellten PreOS-Paketen bin ich jedoch etwas enttäuscht. Das DriverIntegration, WindowsInstallation und BIOSUpdate Paket kann man meines Erachtens als Grundlage und erahnen der Möglichkeiten nutzen bzw. auf deren Grundlage eigene Pakete erstellen. Die Nutzung dieser Pakete zur produktiven Installation von Windows 10 Systemen stehe ich jedoch noch kritisch gegenüber. Mehr dazu in Kürze.

Wenn Du es bereits getestet hast – wie ist Dein bisheriges Fazit?

Der Beitrag Empirum: WinPE anstatt EPE als PXE-Image erschien zuerst auf Workplace Management Blog.

So wird zum Beispiel:

• das Verhalten und Erscheinen des Patch-Management gesteuert,
• abhängig der Konfigurationsgruppe ein Computer einer bestimmten Active Directory Organisationseinheit zugeordnet,
• ein Lizenzschlüssel einer Software pro Computer unterschiedlich vergeben.

Wird eine Variable auf der Ebene einer Konfigurations- oder Zuweisungsgruppe gesetzt, kann entschieden werden, wie dieser Wert auf die darunterliegenden Objekte vergeben wird.
Zuerst muss der Haken bei „Wert leeren“ entfernt werden, damit man in der Lage ist einen Wert zu setzen.

Zwangsvererbung

Aktiviert man im Anschluss die „Zwangsvererbung“, wird dieser Wert bei allen untergeordneten Objekten gesetzt und kann am Objekt nicht geändert werden.
Versucht man an einem untergeordneten Objekt den Variablenwert zu ändern, erscheint die nachfolgende Meldung.

Für alle übernehmen

Betätigt man anstatt der Zwangsvererbung die Schaltfläche „Für alle übernehmen“, wird der Variablenwert bei allen vorhandenen und zukünftigen untergeordneten Objekten eingetragen.
Der Wert kann jedoch nachträglich an einem untergeordneten Objekt verändert werden, was bei der Zwangsvererbung nicht möglich ist.

Unnötig …

Aus diesem Grunde ist es nicht notwendig, wenn man die Zwangsvererbung aktiviert hat, nachträglich noch die Schaltfläche „Für alle übernehmen“ zu betätigen.

Der Beitrag Empirum Variablen Vererbung vs. Für alle übernehmen 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 (3146 Downloads )

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