Was passiert da?

Nachfragen, Recherchen und eigene Tests haben folgendes ergeben. Microsoft installiert direkt nach der Windows Installation ein Windows Update und führt direkt danach einen Neustart durch. Voraussetzung dafür ist: der Computer verfügt über eine Internet Verbindung und es liegt eine bestimmte Windows Version vor. Das Update, das installiert wird, ist das „KB5005716“. Mit diesem Update passt Microsoft die OOBE Phase an, um Windows 11 zu „promoten“.

Weitergehende Informationen

Bis dato sind keine Einstellungen bekannt das zu unterbinden. Wenn man den folgenden Artikel aufmerksam liest, wird das auch nicht geplant sein. Wie heißt es im nachfolgenden Link zu „Windows updates during Windows 10 OOBE“ so schön: „…Critical driver updates, and critical Windows zero-day patch (ZDP) updates, will begin downloading automatically during OOBE after the user has connected to a network. The user can’t opt-out of these critical updates as they are required for the device to operate properly. …“

Hier geht es zur KB5005716 Update Beschreibung

Weitere Meldungen aus dem Netz, auch Meldungen von SCCM Nutzern über Probleme:
https://www.reddit.com/r/SCCM/comments/q2msk7/kb5005716_breaks_osd/
https://www.borncity.com/blog/2021/10/09/windows-10-oobe-update-kb5005716/

Workaround / Lösung

Die Hinweise im Netz gehen in die Richtung, dass obige Update in seine Windows Quellen zu integrieren. Dies funktioniert, wie ich auch bereits erfahren habe. Ein Veränderung der Windows Quellen mache ich selbst ungern, da sich die Windows Quellen dann nicht so einfach austauschen lassen.

Das hat mich dazu gebracht, ein PreOS Paket zu erstellen, welches man direkt nach dem PxeOffAndReboot einreiht. Dies installiert „geplant“ das Update und führt einen gewollten Neustart durch. Somit wurde die Installation zuverlässig zu Ende geführt. Voraussetzung ist bis dato mindestens Windows 10 Build 20H2 (2009).

PreOS Paket

Install-MS-KB5005716_x64 (294 Downloads )
SHA256 Hash der Downloaddatei: C5E6E64DBFD4E654C9D2E1F4DA5036B6528F817449653A4D52211156DF81ECA0

Hilfestellung: Hinweise, wie man ein PreOS Paket einbindet, findet ihr hier.

Der Beitrag Ungeplante Neustarts während der Windows 10 Installation durch KB5005716 erschien zuerst auf Workplace Management Blog.

UEM Agent Einführung und Funktionen

Ein Vorteil des UEM Agenten ist, das er unabhängig von der eingesetzten Empirum Version ist. So muss man nicht warten bis eine neue Empirum Version erscheint, um neue Empirum Agenten Funktionen nutzen zu können. Eine Übersicht über die Neuerungen und die jeweils aktuelle Version steht im Marketplace bereit.

UEM Agent Rollout

So sollte der Advanced Agent durch den UEM Agent ersetzt werden, wenn dies noch nicht geschehen ist. Der Rollout kann unter anderem durch die Neu-Installation des Windows 10 geschehen. Die Vielzahl der Agenten Aktualisierungen passieren jedoch im laufenden Windows Betrieb. Dies wird durch die Zuweisung des UEM Agenten per Paket erledigt.
Der Austausch des gerade laufenden Agenten ist bis zu einem gewissen Teil „Operation am Herzen“. Damit meine ich, wenn die „Operation“ fehlschlägt, verliert man mit unter Verbindung zum Endgerät und somit das Endgerät aus der aktiven Verwaltung.

Fehlerprävention

Wie sich bei den letzten Empirum Agent Updates herausgestellt hat, sollte man vor der Aktualisierung des UEM Agents sicherstellen, dass der Client über das .NET Frameworks 4.7.2 oder neuer verfügt. Dazu empfiehlt es sich das .NET Framework bereits vor dem UEM Agenten zu aktualisieren – besser noch eine Abhängigkeit des UEM Agenten auf die .NET Framework Version vorzunehmen. Diese Abhängigkeit setzt man als erweitere Bedingung im UEM Agent Paket. Wie das geht, habe ich in folgendem Artikel erklärt. Die Release Nummern des .NET Frameworks wiederum sind auf dieser Seite aufgelistet.

Fehleranalyse

Die Aktualisierung des UEM Agenten wird im nachfolgenden Log auf dem entsprechenden Endgerät aufgezeichnet: „%ProgramData%\Matrix42\Logs\UEM Agent Update\UEMAgentUpdate.log“. Hier kann man Hinweise für die fehlgeschlagene Aktualisierung finden bzw. sollte diese Datei für den Support sichern.

Möglichkeiten der Reparatur

Eine Reparatur einer gestrandeten Aktualisierung kann per Agent-Push geschehen, wenn der Computer erreichbar ist und diverse Voraussetzungen erfüllt sind. Wer es noch nicht kennt, den Agent-Push erreicht man über das Kontextmenü des Computers bzw. der Gruppe: Experte\Push Agent …
Weiterführende Informationen sind in der Matrix42 Hilfe zu finden:
Die wichtigsten Voraussetzungen habe ich bereits im Artikel „Empirum Agent Verteilung per Push“ beschrieben.

Agent Push

Möchte man mehrere Clients mit dem Agent Push erreichen, so kann man sich eine Zuweisunggruppe mit den betroffenen Systemen erstellen. Zusätzlich muss ein passendes Agent-Template zugewiesen sein und die Variable „MX42_AGENT_PUSH_PACKAGE_FOLDER“ auf die zu pushende Agent Version gesetzt sein. Um eine definierte UEM Agent Version zu installieren, ist es erforderlich, die Variable MX42_AGENT_PUSH_PACKAGE_FOLDER mit dem Pfad zur gewünschten UEM Agent Version zu belegen. Beispiel: UEM Agent Windows\2006.4

Bestimmen der Systeme …

Wenn eine Installation fehlschlägt, so verbleibt gerne die Installation des UEM Agents mit dem Status Running im SWDepot-Log. Diese fehlgeschlagenen Updates kann man mittels eines Filters in in der Rollout-Koordination oder im SWDepot-Log bestimmen. Für eine andere Art der Übersicht, habe ich einen Filter erstellt, der per Empirum DBUtil erstellt werden kann. Dieser Filter enthält alle Computer, die einen „Install“ Eintrag zum „UEM Agent“ mit dem Status „Running“ haben. Falls es nachfolgende erfolgreiche Installationen gibt, so sind diese derzeit trotzdem in diesem Filter enthalten. Dieser Filter kann also „false positive“ Ergebnisse beinhalten.

Dazu die angehängte Datei entpacken und über die Empirum Struktur kopieren. Nachdem das SQL Script „SW_UEM-Agent_Install_Running“ aus dem Unterordner Custom über Empirum DBUtil ausgeführt wurde, steht der Filter in der Management Console zur Verfügung.

Download

SW_UEM-Agent_Install_Running (523 Downloads )
MD5 Hash der Downloaddatei: B27EAA30786436633DBB1AB63409353F

Der Beitrag UEM Agent Rollout erschien zuerst auf Workplace Management Blog.

Matrix42 SubDepot PXE Service Configuration

Da dies neben dem Self Provisioning die zweite Konfiguration für den PXE-Dienst ist, habe ich es kurzfristig in einem Empirum Paket umgesetzt. Somit kannst Du die Einstellung einfach und nachvollziehbar auf einer Vielzahl von SubDepots bzw. PXE-Servern setzen.

Schritte …

Dazu ist das unten angefügte ZIP zu entpacken und in/über die Empirum Struktur zu kopieren, wie man das von Empirum Erweiterungen und Updates bereits kennt. Im Anschluss importierst Du im SoftwareDepot das Paket „Matrix42 SubDepot PXE Service Configuration 1.0“, welches im Register „Empirum“ eingebunden wird. Das Paket bringt für die zwei Optionen Variablen mit, die Du unter SUBDEPOT_PXESERVICE_CONFIG für die SubDepots anpassen kannst. Im Standard sind beide Optionen deaktiviert. Dann fehlt nur noch die Zuweisung und Installation des Paketes.

Variablen

EnableSelfProvisioning
[1|0] 1= Aktiviere SelfProvisioning, 0=Deaktiviere SelfProvisioning
Standardwert = 0

DisableDhcpRelayAgentOption
[0|1] 1=Deaktiviere DhcpRelayAgentOption Nutzung, 0=Aktiviere die Nutzung der DHCP Option 82
Standardwert = 1

Download

Matrix42 SubDepot PXE Service Configuration (425 Downloads )
MD5 Hash der Downloaddatei: 7E386171796ECD409B1EF827B970B1E5

Zusammenfassung

• ZIP entpacken und in die Empirum Struktur kopieren
• Paket im SoftwareDepot importieren
• Paket den SubDepots zuweisen
• Variablen je nach Anforderung anpassen
• Paket installieren

Fertig!

Der Beitrag Erweiterte Empirum PXE-Server Konfiguration erschien zuerst auf Workplace Management Blog.

„Makel“ DomainJoin 1.4

Das vorhandene Matrix42 PreOS Paket DomainJoin 1.4 hat meiner Meinung jedoch diverse Makel, die das angehängte PreOS Paket besser machen soll.
In Zusammenarbeit mit einem Kollegen und einem Kunden ist somit das angehängte MoveComputerToEmpirumOU PreOS Paket entstanden. Die Makel aus unserer Sicht sind:

• Für das Verschieben des Computer in eine OU werden die RSAT Tools benötigt bzw. versucht bei Bedarf nachzuladen, was bei den meisten Nutzern zu Problemen führt und einen „Add-WindowsCapability“ Fehler im PXE-Log anzeigt.
• Wenn das Paket ausgeführt wurde und der Computer nicht verschoben wurde, wird trotzdem die Ziel OU angezeigt.

MoveComputerToEmpirumOU

Das MoveComputerToEmpirumOU ist ein AddOn zum DomainJoin Paket, da wir es als Zugabe sehen und Matrix42 vielleicht zukünftig das eigene Paket überarbeitet.
So ist MoveComputerToEmpirumOU zusätzlich und nach dem DomainJoin (getestet mit Version 1.4) auszuführen.

• Es benötigt keine RSAT Tools und gibt die am Ende „aktive / resultierende“ OU aus.
• Das Paket bedient sich den DomainJoin Variablen und kann somit auch bzgl. des „führenden“ Systems (Empirum oder AD) konfiguriert werden.
• Eine eigene Variable „NotMandatory“ kann gesetzt werden, damit das Paket auch bei einem Fehler oder Misserfolg mit Erfolg beendet wird.

Weitere Informationen können der dem Download beiliegenden ReadMe.txt entnommen werden.

Feedback

Rückmeldung zum Paket ist ausdrücklich erwünscht, um die Funktion/Stabilität weiter zu verbessern. Angedacht ist zusätzlich eine Erweiterung, die Mobile Computer (Notebooks, Tablets,…) in eine noch zu definierende alternative OU verschieben kann.

Download

Empirum WinPE PreOS Paket: MoveComputerToEmpirumOU
MoveComputerToEmpirumOU (619 Downloads )
MD5 Hash der Downloaddatei: 885AD1614EFC476345A8BE1FA95F1A1A08C27AF3

Beispielsausgaben des PXE-Log

DomainJoin Authority: Empirum

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Moving the computer succeeded!
[PEAgent] [Windows] Try moving the computer to the defined OU ...
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: Empirum
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join failed: Fehler bei Add-WindowsCapability". Fehlercode: 0x8024402c, Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'"
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

DomainJoin Authority: AD

[PEAgent] [Windows] Finished execution of wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Active OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Empirum defined OU : OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] Computers current OU: OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de
[PEAgent] [Windows] DomainJoin Authority: AD
[PEAgent] [Windows] Start to execute wpm-blog\OsPackages\MoveComputerToEmpirumOU\1.1 package.
[PEAgent] [Windows] Finished execution of Matrix42\OsPackages\DomainJoin\1.4 package.
[PEAgent] [Windows] Domain join (option 33) successful: Domain 'wpm-blog.de' and OU 'OU=02_Mobile,OU=02_Windows10,OU=03_Computers,DC=wpm-blog,DC=de'
[PEAgent] [Windows] Start to execute Matrix42\OsPackages\DomainJoin\1.4 package.

Der Beitrag PreOS Paket: MoveComputerToEmpirumOU 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 (424 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

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

Das hat mich dazu gebracht, ein WinPE Paket zu erstellen, die die meines Erachtens hilfreichen Informationen zusammenträgt und in das PXE.log schreibt. Ein Kunde hat mir hier auch schon passendes Feedback gegeben und weitere Wünsche geäußert. Somit wird es bestimmt nicht die letzte Version sein.

In Anlehnung an den Protokoll Droiden aus Star Wars „C-3PO“ habe ich das Paket nun WinPE „D-2PXE“ (Data to PXE.log) getauft. Das Paket kann eigentlich bei jeder WinPE Aktion vorweg bzw. als erstes laufen. Einen kleinen Auszug, was es protokolliert, findet ihr hier.

Zum Einbinden müsst ihr die angehängte ZIP entpacken und mittels des Paket Imports in Eure Empirum Umgebung einbinden. Konfiguriert werden muss in diesem Falle nichts. In der Matrix42 Hilfe gibt es ein verlinktes Dokument das vom Einbinden bis zum Nutzen der WinPE Pakete vieles erläutert.

Beispielausgabe PXE.log

Hier ein Screenshot und Beispiel des Log Inhaltes:

[PEAgent] [WinPE] Computername: PC006, Domain: wpm, FQDN: wpm-blog.local
[PEAgent] [WinPE] Manufacturer Model: [Dell Inc.] [OptiPlex 9010]
[PEAgent] [WinPE] BIOS Version: A08, FirmwareType: UEFI, SecureBoot: Disabled
[PEAgent] [WinPE] UUID: 4C4C4544-004A-5710-8038-C8C04F445831
[PEAgent] [WinPE] Mac-Address: 00B11C942953 - MAC8: 1C942953
[PEAgent] [WinPE] Size PhysicalDrive0: 233 GB
[PEAgent] [WinPE] Running Windows: Windows (TM) 10 Preinstallation Environment, Version 1803 (Build 17134.1)
[PEAgent] [WinPE] Client IP Address: 192.168.44.117
[PEAgent] [WinPE] UAF EmpirumServer: myEmpirumServer.wpm-blog.local
[PEAgent] [WinPE] UAF User: wpm-blog.local\Empirum
[PEAgent] [WinPE] Matrix42 UAF Version: 1.0.25.0
[PEAgent] [WinPE] PeBootServer: myEmpirumServer IP: 192.168.0.5

Ich bin gespannt über Euer Feedback und Anregungen.

Download

Empirum PreOS Package zur Anzeige der oben aufgeführten Informationen im Empirum PXE.log.
WinPE D-2PXE (638 Downloads )
MD5 Hash der Downloaddatei: FD2338429A180ECF02DF16027B991230B8E63E5

Der Beitrag WinPE: PXE.log mit Basisinformationen erschien zuerst auf Workplace Management Blog.

„SetComputerOwner“ definiert den Hauptbenutzer eines Computers anhand der Häufigkeit der letzten Logins. Wenn ein Benutzer sich für eine bestimmte Anzahl hintereinander an einem Computer anmeldet, so wird dieser in einem separaten Registry Wert abgelegt. Hier wird je nach Konfiguration entweder nur der Login Name, oder zusätzlich der „Fullname“ aus dem Active Directory geholt.

Weitere Konfigurationsmöglichkeiten könnt ihr der unteren Übersicht entnehmen.

Dieses Programm ist dafür gedacht, mit dem Matrix42 Software-Management und Inventory zusammenzuarbeiten, da die Ziel Registry Schlüssel auch für einen normalen Benutzer beschreibbar sind. Wenn Sie dieses Programm auch anderweitig einsetzen wollen, so müssen Sie sicherstellen, dass „Vollzugriff“ Berechtigungen auf den HKLM\Software\Matrix42 Registry Schlüssel vorhanden sind.

Management Console

Darüber hinaus können diese Informationen auch direkt in der Management Console angezeigt werden. Dazu sind die „Zusätzlichen Informationen“ (Custom Fields) zu konfigurieren (EMC, Extras, Einstellungen, Zusätzliche Informationen).

Damit die Werte in der Management Console angezeigt werden, muss das Matrix42 Inventory nach dem Schreiben der Registry-Wert ausgeführt werden.

Konfiguration per Registry

Liste der Konfigurations-Möglichkeiten (alle REG_SZ):

• CustomValueOSLogin = Custom29 (Standard)
• CustomValueUsername = Custom30 (Standard)
• GetFullname_from_AD = 1(Standard) oder 0 – Wenn der Wert 0 ist, wird keine Active Directory Abfrage getätigt bzw. versucht.
• LastLogon = Zwischengespeicherte letzte Anmeldung.
• LoginCount = Anzahl der Anmeldungen des LastLogon.
• Threshold = 10 (Standard) – Setzt die Schwelle, ab wann der LastLogon als Besitzer gespeichert wird.
• UserBlacklist = Komma separierte Liste von auszuschließenden Benutzern.
• Debug = 1 – Wenn eine Log-Datei (SetComputerOwner.log) nach %TEMP% geschrieben werden soll.
• CustomValueDepartment = Custom28 (Standard) (ab Version 1.1.0).
• GetDepartment_from_AD = 0 (Standard) oder 1 – Wenn der Wert 0 ist, wird keine Active Directory Abfrage getätigt bzw. versucht (ab Version 1.1.0).
• ForceGetADValues = 0 (Standard) oder 1 – Wenn der Wert 1 ist, dann werden nach dem Überschreiten des Schwellwertes die AD Werte immer aktualisiert (ab Version 1.1.0).

Die Konfiguration wird über die Registry, und hier der 32bit Schlüssel, getätigt.
Bei 32bit Windows Systemen hier: HKEY_LOCAL_MACHINE\SOFTWARE\matrix42\SetComputerOwner
Bei 64bit Windows Systemen hier: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\matrix42\SetComputerOwner

Wenn es keine Vorkonfiguration gibt, läuft SetComputerOwner mit Standard Einstellungen!

Download

Hier geht es zum Download:
SetComputerOwner (1554 Downloads )
MD5 Hashwert der Version 1.1.0: 4FB63950099CD81F7F21B780B0A7B52D

Aktualisierungen

Update (21.10.2013) – Seit heute steht eine neue Version 1.0.3 zur Verfügung, da es im vorbereiteten Paket zu Problemen unter Windows x64 kam.

Update (05.01.2020) – Seit heute steht die Version 1.1.0 zur Verfügung, die auch die Abteilungsinformation aus dem ActiveDirectory auslesen kann.

Genereller Hinweis

Der Beitrag Wer ist der Hauptbenutzer eines Computers? erschien zuerst auf Workplace Management Blog.

Aufruf und Ergebnis

Wie nutzt man nun das Tool während der Softwareverteilung? Dazu ruft man die GetPowerState.exe auf und prüft anschließend die Registry. Die GetPowerState.exe speichert das Ergebnis unter „HKLM\SOFTWARE\matrix42\ClientInfo\PowerState“. Hier werden die Eigenschaften „PowerState“ und „BatteryState“ gespeichert.

• PowerState kann die Werte „Battery“ (Batteriebetrieb) oder „AC“ (Netzbetrieb) annehmen.
• BatteryState enthält den prozentualen Ladezustand der Batterie.

Im Empirum Paket kann dies in der Setup.inf wie folgt abgeprüft werden:

CALLHIDDEN "%SRC%\GetPowerState.exe"
IF %HKLM,Software\Matrix42\ClientInfo\PowerState,PowerState% <> "AC" THEN "ErrorHandling" EndIf

[ErrorHandling]
ErrorLogMsg "Computer is on battery. Exiting Script! | Computer ist nicht am Stromnetz angeschlossen. Script wird beendet!" 
AbortSilent

GetPowerState.exe gibt es hier zum Download:
GetPowerState (1090 Downloads )
MD5 Hash der Downloaddatei: D74C4B71639872DABA45C844584F609D38CE427C

Der Beitrag HowTo: Akku oder Netzbetrieb unterscheiden erschien zuerst auf Workplace Management Blog.

Aktualisierung der Quellen

Möchte man die Quellen für das Paket mit einer unveränderten Version aktualisieren, reicht ein verändern des Zeitstempels der Setup.inf aus. Dazu kann man die Setup.inf öffnen und wieder speichern (sogenannt „touchen“), oder gar einen Vermerk in den Header [SetupInfo] schreiben, warum man eine Änderung durchgeführt hat.

Löschen von Paketen aus dem Cache

Möchte man jedoch auf die automatische Cacheverwaltung Einfluss nehmen und ein Paket vorzeitig, oder mit Absicht, komplett aus dem Cache löschen, so hilft das angefügte Tool, um dies von der Kommandozeile aus zu machen. Dies kann unter anderem dann notwendig sein, wenn man den Ablauf des Caches auf „0“, also niemals, stehen hat.

CleanUpEmpirumAgentCache.exe löscht die Registry Einträge und die Quellen aus dem lokalen Empirum Advanced Agent Cache-Verzeichnis für ein angegebenes Paket.

Die folgenden Parameter sind vorhanden:

/ITEM:“<Paketname>“ – ITEM muss angegeben werden, und der Paketname sollte zur Sicherheit in Hochkommas eingeschlossen werden. Der Paketname entspricht dem Namen aus dem Softwaredepot. {Developername}\{ProductName}\{Version}.

/S – Silent. Ist dieser Parameter nicht gesetzt, so werden die Rückmeldungen per Messageboxen angezeigt, was gefunden wurde und welche Änderungen durchgeführt werden bzw. wurden.

/L – LogFile. Erstelle eine Log-Datei in %TEMP% mit dem Namen CleanUpEmpirumAgentCache.log und enthält Debug und Log Informationen bei der Ausführung.

/T – Test only. Mittels dieses Schalters werden die Funde und möglichen Löschvorgänge angezeigt bzw. protokolliert, jedoch nicht durchgeführt.

Beispielhafte Aufrufe: CleanUpEmpirumAgentCache.exe /ITEM:“Microsoft\Office\12.0″ /S /L
– löscht das Microsoft Office 12.0 Paket ohne Anzeige aus dem Empirum Agent Cache und schreibt dazu Informationen in die Log-Datei.

CleanUpEmpirumAgentCache.exe /ITEM:“Matrix42″ /S /L
– löscht ALLE Pakete, die Matrix42 im Namen beinhalten ohne Anzeige aus dem Empirum Agent Cache und schreibt dazu Informationen in die Log-Datei.

CleanUpEmpirumAgentCache.exe /ITEM:“Matrix42″ /T
– zeigt ALLE Pakete an, die Matrix42 im Namen beinhalten und ohne den Parameter /T gelöscht werden.

Hier gibt es das CleanUpEmpirumAgentCache Tool:
CleanUpEmpirumAgentCache (1765 Downloads )

Der Beitrag Empirum Advanced Agent Cache – Aktualisieren und Löschen erschien zuerst auf Workplace Management Blog.

Favoriten

Zumeist interessieren einen immer wieder die gleichen Pfade in der Registry.
Die installierte Software trägt sich in der Registry ein. Die meisten kennen die Einträge in der Systemsteuerung unter „Software hinzufügen“ (Windows XP) oder „Programme“ (Windows 7 und neuer). Die hier angezeigten Informationen werden aus der Registry unterhalb von:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

bzw. auf 64bit Windows Systemen für 32bit Software aus

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

geholt.

Den Weg dorthin legen die „Kenner“ in wenigen Sekunden zurück.
Mit einem Tipp, können das auch weniger „Geübte“ in Sekunden.
Denn nutzt man die „Favoriten“ im Registry Editor steuert man zielsicher die wichtigsten Einträge an.

So lohnt es sich, die „Favoriten“ in seiner Paketierungsumgebung anzulegen!

Möchte man die Favoriten austauschen, so kann man den nachfolgen Registry Schlüssel exportieren und importieren.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favorites

Hier habe ich Favoriten für die „Uninstall“ und „Run“ Einträge zum Download angehängt.
Registry Favoriten (1055 Downloads )

Schlüsselnamen in die Zwischenablage kopieren.

Eine weitere Hilfestellung ist die Funktion „Schlüsselnamen kopieren“. Damit kann man einen gerade „angesteuerten“ Registrypfad bzw. Schlüssel in die Zwischenablage kopieren und in sein Paket einfügen.

Wenn man den Pfad in eine Reg: Sektion der Empirum Setup.inf einfügt, sollte man aber daran denken die Wurzel mit einem „,“ (Komma) anstatt dem „\“ (Backslash) abzutrennen.

Aus

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

wird für die Empirum Setup.inf Datei:

HKCU,Software\Microsoft\Windows\CurrentVersion\Internet Settings

Der Beitrag Tipps für den Windows Registry Editor erschien zuerst auf Workplace Management Blog.