Prüfmöglichkeiten

Die neuen Vorbedingungen sind „universal“ einsetzbar und können folgende Eigenschaften prüfen:

• Registrierung
• WMI
• Datei
• Ordner

Ideen

Nachfolgend möchte ich nicht auf alle Möglichkeiten eingehen, euch jedoch ein paar Anregungen geben, die ich schon genutzt habe.

• Ist das .NET Framework in einer bestimmten Version oder neuer installiert?
• Hat das Windows einen bestimmten Versionsstand?
• Handelt es sich um einen bestimmten Hardwaretyp?
• Ist eine VPN Verbindung aktiv?

Ihr könnt auch mehrer Bedingungen „UND“ oder „ODER“ verknüpfen, wie ich das schon für Treiber gemacht habe. Vielleicht habt ihr auch coole Ideen oder Einsatzmöglichkeiten für Euch erkannt und wollt diese hier teilen. Ich bin gespannt und freue mich auf Feedback!

Beispiel

Zumeist habe ich bis dato auf Registry Werte geprüft, wie beim nachfolgenden detaillierteren Beispiel: „Ist das .NET Framework in einer bestimmten Version oder neuer installiert?“

Hier nochmals die Werte für eine einfachere Eingabe:

Registry Wert vergleichen
Registry Pfad: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\V4\Full
Wert Name: Release
Vergleichstyp: Nummer
Operator: Größer als oder gleich
Wert: 461808

Übertragen von Vorbedingungen

Die Vorbedingungen, wie z.B. eine .NET Framework Voraussetzung beim UEM Agent Paket, müssen bei einer neuen Versionen eines Paketes nicht auch erneut eingeben werden. Zur einfachen Übernahme der vorhandenen Vorbedingungen könnt ihr die Funktion: „Vorbedingungen kopieren“ und „Vorbedingungen einfügen“ nutzen.

Matrix42 Hilfe

Da ich hier jetzt nicht alle Möglichkeiten eingehen werde und eingegangen bin, möchte ich Euch den Eintrag in der Matrix42 Hilfe natürlich nicht vorenthalten.

Der Beitrag Erweiterte Paketvoraussetzungen erschien zuerst auf Workplace Management Blog.

Der WinPE PXE-Boot bootet ein von Empirum modifiziertes bzw. ergänztes Windows PE. Das WinPE wurde im Bedarf um weitere Treiber ergänzt, aber auf jeden Fall um nützliche Libraries und den Matrix42 UAF Dienst. Letzterer führt die zugewiesenen PreOS-Packages (Powershell „Pakete“) aus und bedient sich der gesetzten Variablen. Diese zugewiesenen Pakete beschreiben die Art und Weise, wie z.B. die Betriebssystem-Installation stattfinden soll. Auf weitere Einzelheiten und Vergleiche mit dem EPE Boot werde ich an anderer Stelle eingehen.

So gliedert sich der WinPE PXE-Bootvorgang in:

• Laden und Ausführen der WinPE Umgebung
• Laden des Matrix42 UAF Dienstes
• Verarbeiten der PreOS-Packages

Nun zu möglichen Problemen und Maßnahmen/Hilfestellungen zur Bearbeitung.

Laden der Windows PE Umgebung

Schlägt bereits das Laden der WinPE Umgebung fehl, so könnte dies ggf. an der TFTP Blocksize liegen. Diese kann bis Empirum v19 global in der .config Datei des BTQH (Backend Task Queue Host Services) Dienstes eingestellt werden. Standardmäßig steht dieser Wert auf 4096. Mit größeren Werten kann man den Boot beschleunigen. Damit kann er jedoch unzuverlässiger werden. In einem Falle musste ich die Größe auf 1456 festsetzen, damit der Boot zuverlässig an allen Standorten funktioniert hat.

Windows PE ist gestartet

Sobald das Windows PE gestartet ist, kann mittels STRG+C auf die Kommandozeile und per STRG+L direkt auf die Log Datei des UAF Dienstes zugegriffen werden. Die Windows PE Umgebung befindet sich unter X:\. Der UAF Dienst liegt im Ordner X:\UAF. Das wpeinit.log unter X:\Windows\System32.

Herstellen einer Netzwerkverbindung

Damit der im WinPE implementierte UAF Dienst seine Aufträge abarbeiten kann, bedarf es einer grundlegenden Netzwerkverbindung. Diese Verbindung wird durch Laden und Starten des Netzwerk-Stacks durch die  X:\Windows\StartNet.cmd und nachvollziehbar durch die wpeinit.log  vorgenommen (QueryAdapterStatus ist hier das passende Suchwort). Kann das WinPE keine Netzwerkverbindung aufbauen, kann es notwendig sein, das WinPE mit Netzwerk- und/oder Speicherverwaltungs-Treibern (Storage) zu versorgen. Dies geht über die Bootkonfiguration und wird in einem anderen Beitrag erläutert.

DeviceMapping.xml

Die DeviceMapping.xml im \\%EmpirumServer%\Values$ Verzeichnis stellt die Verbindung MAC-Adresse bzw. UUID zum Computernamen her. Somit darf jede MAC Adresse bzw. UUID auch nur einmal in der DeviceMapping.xml vorhanden sein. Beim Einsatz von SubDepots muss zusätzlich beachtet werden, dass es für die DeviceMapping Datei einen separaten SyncJob (ESubdepot_DeviceMapping) gibt, der zugewiesenen werden muss.

UAF – Auftragsverarbeitung

Das Vorgehen des UAF Dienstes wird im Matrix42.Platform.Service.Host.log festgehalten. Wie zuvor beschrieben, kann dies per STRG+L geöffnet werden. Um Neuerungen mitzubekommen, muss man ggf. das Fenster schließen und erneut aufrufen. Nach einer UAF Sitzung wird das Log auf den EmpirumServer zurückgeschrieben. In Empirum v18 bzw. WinPE 1.4.14 ist das das Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\OS\Auto\<letzten8 Stellen der MAC-Adrese> bzw. <UUID>.

PXE-Image / WADK Version

Wenn man die neuen WinPE Versionen einsetzt, sollte man wie ein Blog-Leser zusätzlich darauf hingewiesen hat, sicherstellen, dass man die aktuelle WADK Version auf dem EmpirumServer installiert hat. Matrix42 empfiehlt den Einsatz der WADK Version 1903 (eine Version 1909 wird nicht von Microsoft bereitgestellt). Mit dem WADK 1903 habe ich bis dato keine schlechten Erfahrungen gemacht, ganz gleich ob Windows 10 Enterprise 2016 LTSB oder Windows 10 Build 1909 installiert wurde. Zusätzlich sollte man darauf achten, dass die PXE-Image Erstellung (unter Konfiguration\Boot-Konfiguration) erfolgreich ist. Die aktualisierten PreOS Pakete funktionieren auch nur zuverlässig mit einer zu der Version passenden Boot-Konfiguration bzw. aktualisierten PXE-Image.

Der Beitrag Empirum WinPE Boot Troubleshooting erschien zuerst auf Workplace Management Blog.

PMClientConfigExporter (571 Downloads )
MD5 Hash der Downloaddatei: EC2AA5956DBCF312072A548814F89ED7

Der Beitrag PMClientConfigExporter für Matrix42 Patch-Management erschien zuerst auf Workplace Management Blog.

Dann habe ich angefangen mir den Wert der SoftwareDepotDistributionFlags Variable durch Logging zu erarbeiten …

Nach dem Logging, der anschließenden Bestätigung durch den Support (Danke an Hr. Zinn) und weitere erfahrene Empirum Nutzer habe ich die nachfolgende Tabelle erstellt, die Euch bei der Nutzung hoffentlich schneller zum Ziel bringt als mich ursprünglich. In der Nachbetrachtung hat mich am meisten zum Stolpern gebracht, dass in der Hilfe vom bitweisen Vergleich mit Dezimal Werten gesprochen wird und dann die aufgeführte Tabelle Hex Werte enthält!

Anbei die von mir zusammengestellte Tabelle mit den Verteilbefehlen aus der DDC, den dazugehörigen Dezimal Werten für den bitweisen Vergleich sowie dem Verteilbefehl aus der deutschen Oberfläche.

Arbeiten mit den Werten in der Setup.inf

Setup.inf Beispiele:

;---Abfragen eines gesamten Verteilbefehls (Reinstallation per Pull/Push ohne vorherige Deinstallation)
 If BitXor (%SoftwareDepotDistributionFlags%, 99) == "0" | BitXor (%SoftwareDepotDistributionFlags%, 8291) == "0" Then "ReInstall" Else "EverythingElse" EndIf

;---Abfragen einer einzelnen Verteiloption
 If BitAnd (%SoftwareDepotDistributionFlags%, 32) != "0" then "ForceOnceMachine_is_set" else "ForceOnceMachine_is_not_set" endif

Der Beitrag Empirum Setup.inf – SoftwareDepotDistributionFlags 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.

Der Blog wird „alt“ – Neuerung seit Empirum v14.2

Vergleich der Versionsnummer: Ist die Version im Abschnitt [Setup] der Setup.inf GRÖSSER GLEICH 14.2 gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt bis zum nächsten Punkt als komplette Zahl verglichen (45 kleiner 100). Daher ist die Version 1.100 höherwertiger als die Version 1.45 .

Ist die Version im Abschnitt [Setup] der Setup.inf KLEINER 14.2 (z.B. 10.5) gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt Spaltenweise verglichen. Daher ist die Version 1.45 höherwertiger als die Version 1.100. Die Zahlen nach dem ersten Punkt werden nicht als eine Zahl verglichen (45 kleiner 100), sondern Zahlenweise (4 ist größer 1 und 5 ist größer 0). Da die erste Zahl 4 nach dem Punkt bereits größer als die Zahl 1 ist, wird nicht geprüft.

Quelle: Matrix42 Online Hilfe

Ab hier folgt nun die Erläuterung zu [Setup] Version=10.5 …

Martin Niemann hat dies sehr anschaulich und ausführlich auf seinem Blog erläutert. Beim Treffen auf dem vor wenigen Tagen stattgefundenen Matrix42 CustomerDay habe ich in darauf angesprochen, ob ich seinen Eintrag samt Quellenverweis hierher übernehmen darf. Vielen Dank Martin für Deine Erlaubnis!

So hier nun die Erläuterung:

Fast ein jeder wunderte sich schon, wieso die neue Version 4.10 des Paketes von Empirum nicht als höherwertig identifiziert wurde, als das alte 4.9er Paket – „die Zehn ich doch höher als die Neun!“

Hierzu muss man wissen, das in Empirum nur die Zahl vor dem ersten Punkt als ganze Zahl verstanden wird. Alle Werte danach werden Ziffer für Ziffer verglichen.

Hier eine Liste von Versionsnummer in absteigender Reihenfolge:

Die grauen Zahlen zeigen, wie man sich beim Vergleichen von Versionsnummern diese Vorstellen sollte. Vergleicht man nun eine 3.10 mit einer 3.90, ist die 3.9 selbstverständlich höher als die 3.10.

Um zukünftig nicht an die Grenzen der Versionierung zu stoßen, empfiehlt es sich die Versionsnummern nach einem einheitlichen Schema zu erstellen: Die Hauptversion kann aus einer beliebigen Zahl bestehen – bei der Nebenversion sollte man mindestens “zweistellig” vorgehen. Anstelle einer 3.1 sollte man daher besser eine 3.01 verwenden. So ist es später problemlos möglich, nach der 3.09 noch weitere Versionen anzubieten. Vorsichtigere Naturen verwenden für die Nebenversion sogar eine dreistellige Zahl: 3.009. Dies sollte man jedoch nur bei Paketen vornehmen, von denen man weiß, dass sie sich häufig verändern und die Erhöhung der Revisionsnummer nicht verwendet werden kann. Ist man jedoch in die “.9-Falle” getreten, empfiehlt es sich für die neue Version einen weiteren Zahlenblock anzuhängen: 3.9.01. Das sieht zwar nicht so schön aus, rettet einen jedoch aus der misslichen Lage die Version 4.00 einzuführen.

Autor: Martin Niemann

Der Beitrag Empirum Paket Versionen – Früher an später denken? erschien zuerst auf Workplace Management Blog.