Diese Meldung erscheint, wenn kein passender Eintrag oder kein eindeutiger Eintrag in der DeviceMapping.xml gefunden werden kann. Die DeviceMapping.xml wird während der OS Installation hergenommen, um von den Hardwareeigenschaften (MAC oder UUID) auf den späteren Computernamen und Workgroup/Domain zu verweisen.

Die ersten Troubleshooting Schritte …

(1) Die Voraussetzung für einen Eintrag in der DeviceMapping.xml ist: Die Eigenschaft des Computerobjektes muss „PXE fähig“ markiert haben – er muss jedoch nicht unbedingt PXE aktiviert sein!

(2) Wo liegt die DeviceMapping.xml? Die Datei ist im folgenden Verzeichnis abgelegt: \\%EmpirumServer%\Configurator$\Empirum\Configurator\Values
Folgendes sollte geprüft werden: Ist die Datei aktuell bzw. so aktuell wie die letzte Änderung? Geschieht die OS Installation an einem SubDepot, so gilt dies für das SubDepot! Hier muss ggf. der DepotSync betrachtet werden, wenn die Datei am HauptServer anders bzw. vollständig ist. Ergo zuerst die Datei auf dem HauptServer und anschließend auf dem SubDepot prüfen.

(3) Ist die MAC-Adresse / UUID in der DeviceMapping.xml zu finden und nur einmal (1x) vorhanden? Dazu die Datei mittels eines Editors öffnen und darin nach den Werten (Computername, MAC, UUID) des Computerobjektes suchen.

(4) Falls der Computer, die MAC-Adresse oder die UUID nicht in der DeviceMapping.xml zu finden ist: „Empirum-Backend Task Queue Host (64 bit)“ Dienst prüfen, da er für die Erstellung der Datei zuständig ist. Ist der Dienst gestartet und läuft – funktioniert der Dienst einwandfrei? Die Log-Datei zum BTQH64 Dienst befindet sich hier: „C:\ProgramData\Matrix42\Logs\BackendTaskQueueHost64\BackendTaskQueueHost64.log“

Wird die MAC-Adresse oder UUID mehrfach gefunden, dann diese Informationen (Computernamen) nutzen und in der EMC an den Computerobjekten nachschauen.

Löschen doppelter UUIDs aus der Empirum Datenbank

Doppelte UUIDs aus der Empirum Datenbank können wie folgt gelöscht werden:
Empirum bzw. Matrix42 Management Console starten, Konfiguration, Boot Konfiguration – im Menü unter: Extras, Ungültige UUID’s
Suchen und Löschen der doppelten Einträge per Auswahl und Papierkorb Symbol. Bitte beachte die Hinweise, wenn ein Eintrag nicht gelöscht werden kann. Der Hinweis zeigt an, welche Computernamen die gleiche UUID eingetragen haben. Anhand der letzten Inventarisierung o.ä. kann man erörtern, welches das aktuelle Computerobjekt ist.

Wenn die zuvor genannten Hilfestellungen alle nicht geholfen haben …

Weitere Infos am Client (vor der Windows Installation)

Wenn die Meldung erscheint gelangt man direkt in das Log per Tastenkombination „STRG+L„. In der Log-Datei sucht man am besten nach „ComputerIdentification.ResolveComputername„. Nachfolgend ein beispielhafter Auszug:

[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Retries at copying DeviceMapping XML file: 10
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Copying DeviceMapping XML file (retry 0/10): Values\DeviceMapping.xml
[INFO] [ComputerIdentification.ResolveComputerName] SMBIOS UUID: 4c4c4544-004a-5710-8038-c8c04f335831
[INFO] [ComputerIdentification.ResolveComputerName] Physical addresses: 90B11C147953
[INFO] [ComputerIdentification.MapDevice] Solved computer name 'LABPC001' in domain 'IMAGOVERUM' for SMBIOS UUID '4c4c4544-004a-5710-8038-c8c04f335831'
[INFO] [PeAgent.ResolveComputerName] Resolve computer name: LABPC001 in domain IMAGOVERUM
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Finished copying DeviceMapping.xml from the Empirum Server.

Weitere Infos am Client (nach der Windows Installation) …

ALT-TAB zum Wechseln in den Hintergrund und anmelden als Admin.
Höchstwahrscheinlich muss dieser Vorgang 2x getätigt werden, da man beim ersten Versuch durch einen Neustart schnell wieder abgemeldet wird.
Nun findet man die entsprechende Log-Datei im %Programdata%\Matrix42\Logs\UAF Ordner.
Die Stelle, nach der man sucht, ist identisch zu den oben aufgeführten Meldungen.

UUID anstatt MAC Adressen bevorzugen

Die Eindeutigkeit ist mit der Nutzung von UUIDs anstatt MAC Adresse (siehe PXE Dienst im Empirum DBUtil) prinzipiell besser.
Wenn aus Gründen …

• nur die MAC Adresse bekannt bzw. einfacher zu pflegen ist
• nur die MAC Adresse eindeutig ist, weil es mehrere Hardware mit identischer UUID gibt
• die MAC Adresse genutzt wird, …

gelten trotzdem die gleichen Regeln – Eindeutigkeit bei den MAC Adressen am Computerobjekt!

Falls man mehrere Notebooks mit einem externen USB zu Ethernet Netzwerkanschluß installieren möchte, muss man bei Bedarf die Netzwerkadresse am bereits installierten Gerät anpassen, falls die MAC-Adresse das führende Merkmal für die PXE-Installation ist.

Der Beitrag Empirum: Failed to copy a sufficient DeviceMapping.xml 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.

Gründe

Möchte man nun die ODBC Verbindung neu setzen, weil …

• man den ODBC Treiber,
• Datenbank-Server oder
• die Datenbank

anpassen möchte, so muss man das Paket „zwingen“ dies zu tun.

Forcieren der Erstellung

Der Zwang bzw. die Interpretation des Zwanges ist bereits in dem Paket für die EMC enthalten. Doch wie nutzt man diese Funktion?

LocationDB.ini anpassen

Dazu wechselt man in das Paketverzeichnis der Management-Console unter Empirum\Configurator\Packages\Matrix42\EMC\<Version>. Dort öffnet man die LocationDB.ini mittels eines Editors und fügt der Locations Sektion einen Eintrag „Force=1“ hinzu. Wenn man nun die Management-Console reinstalliert, wird die ODBC Verbindung neu erstellt bzw. angepasst.

Beispiel für die Locations Sektion:

[Locations]
Count=1
Name1=EmpirumDB
Force=1

Der Beitrag Matrix42 Management Console – ODBC Verbindung aktualisieren erschien zuerst auf Workplace Management Blog.

ClearAllDisks Variable erstellen

Möchte man die vorgenannte Funktion nutzen, so erstellt man die Variable „ClearAllDisks“ vom Typ Zahl in der Variablendefinition: DiskPartitioning.
Dazu wählt man in der Matrix42 Management Console, Administration, Extras, Variablendefinitionen … aus und navigiert zur vorhandenen Variablendefinition „DiskPartitioning“.
Durch einen Doppelklick oder der Auswahl und Bearbeiten, landet man in den Eigenschaften der Variablengruppe DiskPartitioning.
Hier fügt man die Variable mit einem Klick auf das „+“ Symbol hinzu.

Setzen der Variable

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.

Matrix42 Hilfe

Anbei der Text aus der Empirum Hilfe. Über diese Variable, die Sie selbst hinzufügen müssen, können Sie beim Ausführen des DiskPartitioning Paketes alle Festplatten bereinigen.
Hierzu muss man in der EMC > Administration unter „Extras > Variablendefinitionen“ die Variable „ClearAllDisks“ als Zahl zu DiskPartitioning hinzufügen und diese auf 1 setzen.

Der Beitrag Empirum WinPE – Löschen von Partitionen erschien zuerst auf Workplace Management Blog.

Zutaten zusammenführen

Die Zutaten habt ihr bestenfalls mit Hilfe der zuvor getätigten Beschreibungen bereits vorbereitet. In diesem Blog-Eintrag geht es darum, die letzten Schritte vorzunehmen.
Nun werden die Zutaten in der Management Console (EMC), von der rechten Seite zur Mitte, in einer Konfigurations- oder Zuweisungsgruppe zusammengeführt:

• PreOS Pakete bzw. die erstellte UND-Klasse zuweisen
• WinPE PXE-Image zuweisen
• Betriebssystem zuweisen
• Agent-Template zuweisen
• die Variablen auf die Gruppe setzen und übertragen

Variablen setzen

Die Variablen übernehmen die Definition der kundenspezifischen Windows Installation. Die zu setzenden Variablen(gruppen) heißen identisch wie die genutzten PreOS Pakete.
Am besten geht man die Liste der zugewiesenen Pakete namentlich durch und stellt die für sich passenden Werte ein. Viele Variablen sind bereits vorbelegt und können auf den vordefinierten Werten belassen werden.

Somit konzentriere ich mich hier auf die meines Erachtens wichtigen Werte für eine Windows Installation in deutscher Sprache inklusive Domain Join.

• DiskPartitioning\PreferFastDisk
• WindowsInstallation\LocalUserName
• WindowsInstallation\LocalUserPassword
• WindowsInstallation\LocalUserDisplayName
• WindowsInstallation\SetupUILanguage
• WindowsInstallation\InputLocale
• WindowsInstallation\SystemLocale
• WindowsInstallation\UILanguage
• WindowsInstallation\UserLocale
• DomainJoin\DomainJoinCredentialsUser
• DomainJoin\DomainJoinCredentialsPassword

Zusätzlich sind die nachfolgenden Variablen, die nicht so lauten wie die zugewiesenen Pakete, wichtig anzusehen bzw. zu setzen:

• FQDN – WindowsInstallation, DomainJoin
• ORGANIZATIONAL_UNIT (optional) – DomainJoin
• TIMEZONE – WindowsInstallation
• MX42_AGENT_PUSH_PACKAGE_FOLDER\Windows – EmpirumAgentSetup

Aktivieren

Anschließend wird das Computerobjekt der Gruppe hinzugefügt und aktiviert. Beim Aktivieren für eine WinPE basierte Windows Installation braucht keine „Betriebssystemkonfiguration (OS.INI)“ mehr erstellt werden. Diese Aufgabe übernehmen die PreOS Packages samt der gesetzten Variablen.

Et voilà

Nun den Computer vom Netzwerk booten lassen und nach ca. 20 min ist das frisch installierte Windows fertig angerichtet!

Besonderheiten

Bis zu diesem Punkt wurde beschrieben, dass sich die PreOS Pakete wie herkömmliche Software Pakete verhalten. Es gibt (Stand Oktober 2019 – WinPE 1.6.6) jedoch ein paar Besonderheiten:

• es werden alle zugewiesenen Pakete ausgeführt, nicht nur die aktuellste/höhere Version
• mittels einer Verteilungsoption „Uninstall“ kann die Verarbeitung von Paketen nicht verhindert werden
• PreOS Pakete, die vor dem DiskPartitioning Paket ausgeführt werden, werden aus dem SWDepot-Log gelöscht und der Status bleibt „undefiniert = gelb“

Der Beitrag Empirum WinPE – Windows Installation erschien zuerst auf Workplace Management Blog.

Wie finde ich heraus, welche WADK version auf meinem EmpirumServer installiert ist?

In der Systemsteuerung unter Programme, Programme & Features sieht man die installierte Version des WADK (Windows Assessment und Deployment Kit). In diesem Dialog wird die Windows Build Version angezeigt. Doch welche Build Version entspricht welcher weitläufig bekannten Windows Version?

Eine recht einfache Zuordnung ist auf der folgenden Seite hinterlegt und erläutert:
https://www.systemcenterdudes.com/windows-10-adk-version-history/
Wer die ersten Stellen wie 10.0 oder 10.1 weglässt, kann die Zuordnung auch über die nachfolgende Seite vornehmen:
https://docs.microsoft.com/en-us/windows/release-information/

Woher bekomme ich meine aktuelle WADK Version?

Ein zentraler Einstiegspunkt für den Download der offiziellen WADK Versionen gibt es hier:
https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install
Auf dieser Seite gibt es nicht nur die aktuelle Version, sondern auch alle weiteren verfügbaren ADK Versionen zum Download.

Was muss mindestens installiert werden?

Das adksetup und das adkwinpesetup wird jeweils in den vorgeschlagenen Pfad installiert. Im weiteren Verlauf folgt man dem Assistenten und beantwortet die Fragen zur „Privacy (Datenschutz)“ und „License (Lizenzvertrag)“.

Bei der Ausführung des ADKSetups müssen mindestens die Bereitstellungsdienste installiert werden.

Bei der Ausführung des ADKWinPESetups gibt es nicht so viel Auswahl. Hier muss die Windows Vorinstallationsumgebung (Windows PE) installier werden.

Der Beitrag Microsoft WADK / WinPE Versionen (Stand 06/2019) 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.

Wo findet man das aktuelle Windows ADK / WADK?

Eine Einstiegsseite mit den passenden und verfügbaren ADKs gibt es hier.

Welche Funktionen des WADK muss ich im Zusammenhang mit Empirum installieren?

Auf dem EmpirumServer sind mindestens die Bereitstellungstools und die Vorinstallationsumgebung (Windows PE) zu installieren.

Empirum PreInstallation Environment (EPE) Boot (Linux)

Wer das EPE zum Starten einer OS-Installation nutzt, muss zusätzlich das WADK in Empirum importieren. Dazu ist es ausreichend das WADK des zur verteilenden Windows 8/10 zu importieren (x64/x86). Die Windows PE Dateien werden nach dem Import unterhalb von Empirum\EmpInst\SYS\WinPE abgelegt.

WinPE Boot

Wer sich bereits mit dem WinPE Boot von Empirum auseinandersetzt, muss das WADK nicht importieren, jedoch eine Bootkonfiguration (EMC\Konfiguration\Boot Konfigurationen) mit Hilfe der WinPE Quellen erstellen. Dieser Vorgang greift dann auf das zur lokal auf dem EmpirumServer installierte WADK / Windows PE zurück.

Der Beitrag Empirum und Windows 10 WADK erschien zuerst auf Workplace Management Blog.

Neue EPE4 Quellen …

Der Download neuer EPE Quellen erfolgt über den Matrix42 Marketplace. Dazu muss ein Marketplace bzw. ein Matrix42 Account vorhanden sein. Die neuen EPE4 Versionen, samt ihrer Historie werden unter folgendem Link im Marketplace angeboten.

Import der EPE Version in die eigene Empirum Umgebung

Die heruntergeladene ZIP Datei legt man am besten in einem separaten Ordner ab, auf den von der Management Console zugegriffen werden kann. Die Matrix42 Management Console „Als Administrator starten …“ ausführen und auf den Tabulator Konfiguration, OS Installer, Import wechseln. Starten des Import Vorganges wie ab Kapitel 2.3 dieser Matrix42 Hilfe Seite erläutert.

Wichtig ist hier, dass auf dem zweiten Import-Dialog der Name angepasst wird für eine bessere Unterscheidung bzw. Zuordnung beim Erstellen der Bootkonfiguration – ansonsten heißen alle „Empirum Preboot Environment 4“. Dieser Hinweis ist auch beim Import von Betriebssystem-Quellen wie Windows 7 und Windows 10 von Vorteil. Bei den Betriebssystem kann man hier wunderbar den Namen um Informationen wie Service Pack, Patch-Stand, PRO oder Enterprise, uvm. erweitern.

Der angepasste Import führt dann zu einem individuellen „BS Paket“ Namen, wie in dem hier verlinkten Artikel bereits angezeigt wird.

Erstellen einer Boot-Konfiguration

Das Erstellen der Boot Konfiguration ist ab Kapitel 2.4 des obigen Links erklärt. Hier sind ein paar Punkte besonders erwähnenswert: Wichtig ist hier, dass man eine Aktualisierung anstößt, wenn man gerade zuvor neue EPE Quellen importiert hat.
Meines Erachtens erzeugt man pro EPE Version auch eine eigene EPE Konfiguration, wie. z.B.: EPE464 für die EPE Quellen mit der Version 4.6.4. So kann man diese EPE4 Version explizit testen und ggf. auch nur einer bestimmten Hardware zuweisen.

Ein weiterer wichtiger Punkt kann sein, dass man unter Konfiguration, OS Installer, Bootdisk, Diskettenkonfiguration ggf. einen anderen Benutzer eingetragen hat, als den Benutzer den man in der Agenten-Konfiguration nutzt. Dies kann sich auf den Zugriff auf die EmpInst$ Freigabe, als auch den Domain-Join auswirken, wenn in der Betriebssystem-Vorlage definiert ist, dass der Domain-Join mit dem Benutzer aus der „Diskettenkonfiguration“ geschehen soll.

Der Beitrag EPE4 Import und Konfiguration ab Empirum 16.1.3 erschien zuerst auf Workplace Management Blog.

Übersicht Windows 10 Versionen und Wartungsoptionen

Zurück zu den Vorteilen. Als Administrator kann man nun einfacher herausfinden, welchen Sicherheits- und Qualitätsstand ein Windows 10 entspricht. Microsoft stellt auf der folgenden Seite eine Übersicht der veröffentlichten und aktuellen Windows 10 Stände der verschiedenen Versionen und Wartungsoptionen (CB, CBB, LTSB) zur Verfügung: https://technet.microsoft.com/de-de/windows/release-info.aspx

Empirum Inventory Standard

Im Empirum Inventory wird heute bereits in den Computereigenschaften, Inventory, Computer, Betriebssystemversion die Windows 10 Buildnummer (z.B. 14393) angezeigt. Um die inventarisierte Windows 10 Version noch besser mit der oben genannten Tabelle vergleichen zu können, benötigen wir jedoch auch die Unterversionen der zuvor genannten Buildnummer. Diese können wir uns über eine Anpassung der Inventarisierungskonfiguration in die Empirum Datenbank bzw. Management Console holen.

Windows 10 Build – Speicherort?

Woher bekommen wir denn die Werte, die uns interessieren?
Diese stehen in der Registrierung unter: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

Empirum Inventory Anpassung

Generelle Hinweise zur Anpassung der Empirum Inventory Konfiguration habe im Artikel „Ermittlung installierter Versionen“ bereits gegeben. Diesmal wird jedoch nicht die Dateisuche, sondern „Benutzerdefinierter Wert“ angepasst.
Wenn wir nun den OS Build identisch zur oben genannten Microsoft Seite in der Datenbank abgespeichert haben wollen, muss der Benutzerdefinierte Wert wie folgt eingegeben und gespeichert werden.

Windows10_OSBuild
%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","CurrentBuild"%.%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","UBR"%

Möchte man jedoch einen Filter bauen, indem man einfacher auf „größer“ oder „kleiner“ Wert prüfen möchte, kann eine Aufteilung auf zwei Werte sinnvoll sein.

Windows10_OSMajorBuild
%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","CurrentBuild"%

Windows10_OSMinorBuild
 %HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","UBR"%

Wo und wie wird es in der Empirum Management Console angezeigt?

Im folgenden Screenshot kann man sehen, wo und wie es in der Management Console angezeigt wird. In diesem Beispiel habe ich den Windows10_OSBuild Wert als einen zusammengesetzten Wert eingelesen.

Der Beitrag Windows 10 Buildversion in Empirum Inventory erschien zuerst auf Workplace Management Blog.