Reboot Möglichkeiten

Fangen wir vorne an. Es gibt in der Empirum Setup.inf mindestens zwei Möglichkeiten einen Neustart aus dem Paket heraus anzufordern. Wie das Ganze dann vom Empirum UEM Agenten dann verarbeitet wird, liegt dann zusätzlich an den Agenten Einstellungen, dem Agent-Template.
In der [Application] Sektion gibt es den Paramter Reboot=[Wert von 1 bis 5] für die Anforderung eines Neustarts. Zusätzlich kann man im Verlauf der Setup.inf mit dem Befehl SetReboot [Wert] eine Reboot-Anforderung setzen.

Wo ist der Unterschied?

In der [Application] Sektion setzt man einen Wert für die Installation und Deinstallation, ganz gleich, wie der Verlauf des Paketes ist. Mit dem Befehl SetReboot wiederum kann man fallweise eine Neustart-Anforderung platzieren. Dies kann man sich z.B. bei Paketen basierend auf der MSI Vorlage ansehen. Falls sich ein MSI Paket mit einem ReturnCode 3010 beendet (erfolgreich, jedoch Neustart notwendig), dann wird in der Sektion [RebootRequired] ein SetReboot 1 ausgeführt.

Welchen Wert nutzen?

Wie oben bereits geschrieben, gibt es Werte von 0 bis 5 mit unterschiedlicher Ausprägung und Funktion. Dabei bedeutet der Wert 0 nicht, dass dieses Paket keinen Neustart benötigt, wie zumeist angenommen. Der Wert 0 steht vielmehr für den „Automatikmodus“. Kann zum Beispiel eine Datei im Paketablauf (Ablauf der Setup.inf) nicht ersetzt oder gelöscht werden, fordert beim Wert 0 das Software-Paket trotzdem einen Reboot einen, um beim Neustart, wenn die Datei nicht in Benutzung ist, zu ersetzen oder zu löschen. Möchte man einen Neustart des Paketes unterbinden, so muss man Reboot=2 setzen. Dagegen ist der Wert 1, wie man es sich schon denken konnte, eine direkte Anforderung eines Neustarts. Neben den genannten Werten, wir dann noch häufig der Wert 5 genutzt. Dieser bestimmt, dass nach der Beendigung dieses Paketes ein Neustart angefordert wird (wie bei 1), jedoch auch keine weiteren Pakete zur Ausführung kommen. Die weiteren Pakete werden dann nach dem ausgeführten Reboot durchgeführt.

Wer einen Neustart in gewisser Weise erzwingen mag, kann sich auch meinen Beitrag zum SystemShutdown anlesen.

Komplette Übersicht

Da nun die Eigenschaften für 3 und 4 unter den Tisch gefallen sind, möchte ich diese zur Vollständigkeit hier auch noch erläutern:

• 0 – startet das System nach der Installation neu, wenn ein Neustart erforderlich ist, weil z.B. Dateien überschrieben/gelöscht werden müssen, die in Benutzung sind.
• 1 – startet das System in jedem Fall neu
• 2 – startet das System nicht neu
• 3 – abmelden des Benutzers
• 4 – Herunterfahren (kein Neustart)
• 5 – nach der Installation kein weiteres Paket installiert und zwingend ein Neustart durchgeführt. Dies entspricht dem Verhalten der Option „Installation weiterer Pakete nicht fortsetzen“ in den Paketeigenschaften

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

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.

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.

LAPS und deren Unterschiede

Der Unterschied im Namen ist gering „Microsoft LAPS“ (alt, Legacy LAPS) und „Windows LAPS“ (neu), die Möglichkeiten unterscheiden sich jedoch enorm. Der ganz klare Vorteil ist, Windows LAPS ist nun Bestandteil des Betriebssystems. Die weiteren Vorteile sind die Integration in die moderne Verwaltung.
Die Einstellungen können nun nicht mehr nur aus Gruppenrichtlinien (GPOS) kommen und das Kennwort kann nun auch verschlüsselt im Azure Active Directory (AAD) gespeichert werden. Wer tiefer in die Materie und Möglichkeiten eintauchen möchte, dem lege ich die folgenden Seiten ans Herz:
https://learn.microsoft.com/de-de/windows-server/identity/laps/laps-overview

Active Directory Berechtigungen

Wer das LAPS Kennwort im Active Directory speichert, sollte auch weitere Aspekte berücksichtigen, damit dies auch entsprechend abgesichert wird. Neben der spärlichen Vergabe der Benutzer die auf die LAPS Felder Zugriff haben, sollte man auch den Benutzer ins Auge fassen, der das Computerkonto erstellt. Weiteres dazu kann man hier finden.

Zusammenspiel mit Empirum

Im Zusammenspiel mit Empirum sind ein paar Dinge zu beachten, wenn man das Maximum an Sicherheit herausholen möchte.

DomainJoin Variablen

Die Variablen und somit der Benutzer für den Domain-Join sollte bestenfalls nur für den Zeitpunkt der Betriebssysteminstallation zugewiesen sein. Dies kann über eine separate Konfigurations- oder Zuweisungsgruppe geschehen, in dem der Computer nur für die Betriebssysteminstallation zugeordnet ist.

Windows LAPS

Will man die Vorteile von Windows LAPS nutzen, sollte man darüber nachdenken eine Windows 10 bzw. 11 Quelle für die Betriebssysteminstallation einzubinden, die das April oder besser Mai 2023 Update beinhaltet. Alternativ kann man auch das Windows Update in seine Quellen integrieren.

Reinstallation von Computern

Gerade bei Tests oder im Client Lifecycle kommt es vor, dass vorhandene Computer mit dem gleichen Namen nochmals installiert werden. Wurde das Computerobjekt vor der Neu-Installation nicht aus dem Verzeichnisdienst (AD/AAD) gelöscht, kann es dauern bis das LAPS neu erstellt und gespeichert wird, da das „Ablaufdatum“ vom Verzeichnisdienst vorgegeben wird. Etwas was mir diesbezüglich schon länger durch den Kopf ging, hat ein mir bekannter Administrator als WinPE Paket umgesetzt.

Das WinPE Paket zusätzlich der detaillierten Erläuterungen und Einstellmöglichkeiten findet ihr in seinem github Repository: https://github.com/htcfreek/PreOS-ResetLapsPassword.

Wem das nicht reicht, so wird er dort auch fündig hinsichtlich einer GUI für das Windows LAPS Kennwort: https://github.com/htcfreek/SimpleLapsGui

Ein großes Kompliment für diese Erweiterung von meiner Seite!

Microsoft LAPS Benutzer

Für all diejenigen, für die Microsoft LAPS nichts neues ist, sollten sich mit der Co-Existenz, den Änderungen und neuen Möglichkeiten auseinandersetzen. Man muss jedoch sehr achtsam mit den Begrifflichkeiten und Funktionen umgehen, da die ähnlichen Worte und Begriffe einen schon gerne einmal verwirren.

Der Beitrag Windows LAPS und Empirum WinPE 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.

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.

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.

Welche Datei meine ich denn nun genau?

Es geht um die Unattended.inf im Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates Ordner. Diese wird bei der Auswahl „Unattended“ im Verlaufe des „Package Wizards“ herangezogen.

Erfolgsüberprüfung

Nach dem „silent“ Aufruf einer EXE Datei, wird eine, wie ich sie nenne, „Erfolgsüberprüfung“ durchgeführt. Denn jede Setup.inf, die nicht mit einem „Abort“ beendet wird, wird per se als Erfolg gewertet. Sprich, wir sollten nach dem Aufruf eines externen Programms (Setup.exe, Installer, etc.) überprüfen, ob eingetroffen ist, was wir erwarten würden. Andernfalls, kann ein Paket ein „Success“ zurückmelden und die Software ist nicht installiert.

ErrorLevel Abfrage in der Vorlage

Die oben angesprochene Setup.inf Vorlage prüft deswegen nach einem Aufruf einer Installation den ErrorLevel ab. Weit verbreitet ist ein ErrorLevel mit dem Wert 0 ein Erfolg. Deswegen enthält die Vorlage auch die nachfolgende Zeile:

If "%ErrorLevel%" <> "0" Then "SET:InstallationError" EndIf

Doch was passiert, wenn die Installation z.B. einen Wert von 3010 zurückliefert? Ist dann ein Fehler aufgetreten? Nein. Der Wert 3010 bedeutet beispielsweise, die Installation war erfolgreich, doch es wird zusätzlich ein Neustart benötigt. Microsoft hat es mit den MSI Installern begonnen und einige haben diese Werte übernommen oder rufen in ihrer EXE Datei eine MSI Installation auf und geben den ErrorLevel der MSI Installation zurück.

Anpassung

Diese Anpassung setzt automatisch eine Neustart-Anforderung für dieses Paket und wertet den Rückgabewert von 3010 nicht als Fehler.

If "%ErrorLevel%" == "3010" Then "RebootRequired" EndIf
If "%ErrorLevel%" <> "0" & "%ErrorLevel%" <> "3010" Then "SET:InstallationError" EndIf

[RebootRequired]
SetReboot 1
-SetReboot 1

Wer noch weiter gehen möchte, für z.B. VCRedist Installationen oder Updates, der kann zusätzlich noch den Wert 1638 (Another version of this product is already installed) überprüfen.

ErrorLevel oder gibt es auch andere Methoden

Der ErrorLevel ist nicht die einzig wahre Methode. Natürlich kannst Du auch überprüfen, ob es einen bestimmten Registry Wert nach der Installation gibt, den es zuvor nicht gibt. Eine Überprüfung, ob die Software in Form ihrer ausführbaren Date vorhanden ist, kann genauso gut sein. Zu diesen Abfragen kommen wir dann bei den nächsten Tipps. Falls Du bereits Neugierig bist, so kannst Du in der Hilfe nach DoesRegKeyExist oder DoesFileExists suchen. Die DoesRegKeyExist Abfrage ist auch in der MSI.inf (Vorlage für MSI Installationen) enthalten ;-).

Der Beitrag ErrorLevel Abfrage bei Unattended Installationen erschien zuerst auf Workplace Management Blog.

Installation des Dell PowerManagers 3.5.0 schlägt fehl

Die Installation bzw. der Aufruf der EXE bzw. MSI Datei war nicht das Problem. Die Installation scheiterte jedoch. Auch bei der interaktiven Installation wurde ein „Rollback“ der Installation durchgeführt. Die Log-Datei war auch nicht sehr ergiebig …

Die Lösung: aktueller WLAN Treiber

Glücklicherweise war und bin ich nicht die erste Person, die dieses Problem hatte. Im Dell Forum wurde ich fündig. Der Verursacher ist der Treiber für den WLAN Adapter. Tauscht man den Treiber aus dem SCCM Treiberpaket gegen den aktuellen (21.50.1 oder neuer) von Intel aus, funktioniert die Installation reibungslos.

Der Beitrag Dell PowerManager Dienst – Installation fehlgeschlagen 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 (679 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (736 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.