You searched for verhalten agent - Workplace Management Blog https://www.wpm-blog.de/ ... ideas and solutions making workplace management easier Sun, 08 Dec 2024 17:26:10 +0000 de hourly 1 https://wordpress.org/?v=6.1.7 Empirum Paketeigenschaften – Zur Installation freigeben https://www.wpm-blog.de/empirum-paketeigenschaften-zur-installation-freigeben/ https://www.wpm-blog.de/empirum-paketeigenschaften-zur-installation-freigeben/#respond Sun, 08 Dec 2024 17:26:10 +0000 https://www.wpm-blog.de/?p=3054 Wenn man ein Paket in das Empirum Software-Depot einbindet, setzt man fast schon automatisch den Haken bei der Checkbox „Zur Installation freigeben“ (Ready to Install=1). Jeder weiß, dass das entsprechende Software-Paket nicht verteilt wird, wenn … Weiterlesen

Der Beitrag Empirum Paketeigenschaften – Zur Installation freigeben erschien zuerst auf Workplace Management Blog.

]]>
Wenn man ein Paket in das Empirum Software-Depot einbindet, setzt man fast schon automatisch den Haken bei der Checkbox „Zur Installation freigeben“ (Ready to Install=1). Jeder weiß, dass das entsprechende Software-Paket nicht verteilt wird, wenn diese Option nicht gesetzt ist. Dies wird zusätzlich damit symbolisiert, in dem der Name des Paketes in brauner Farbe dargestellt wird. Aber was bewirkt diese Option und wie kann man sich diese zu nutze machen?

Paketeigenschaften

Hier nochmals ein Screenshot der Paketeigenschaften, um die Option in Erinnerung zu rufen:

Hinweis: Diese Option bezieht sich auf die Softwareverteilung per Zuweisung (Zuweisung in Management > Administration) und nicht auf Software im Kiosk.

Computervariable – ReadyToInstall_Test

Software-Pakete, die nicht „zur Installation freigegeben“ sind, werden trotz Zuweisung zu einem oder mehrerer Computer nicht in deren Auftragsdatei (DDC) geschrieben und somit installiert. In Abhängigkeit der Computervariablen „ReadyToInstall_Test“ werden nun auch diese Pakete und somit Installationsaufträge in die Auftragsdatei aufgenommen. Mit dieser Variable definiert man somit, dass ein Computer auch nicht freigegebene (noch im Test befindliche) Software installiert bekommt.

Nachfolgend eine Aufstellung, was die Werte der Option bewirken:

  • 0 (deaktiviert) = Software Installationsauftrag nicht in die DDC schreiben
  • 1 (aktiviert) = Software Installationsauftrag in die entsprechende DDC des Computers schreiben

Die Computervariable kann man nun über den althergebrachten Weg, oder per definierter und zugewiesener Variablen Konfiguration setzen und somit einen Computer in die Lage versetzen, auch die nicht freigegeben Pakete zu installieren.

UEM Agent AutoUpdate

Die oben genannte Paketeigenschaft hat im Falle der Matrix42 UEM Agent Windows Pakete auch eine Auswirkung auf die UEM Agent Auto Update Funktion. Möchte man die UEM Agent Auto Update Funktion nutzen, so geschieht die Aktivierung auch über entsprechende Computervariablen.

Die Konfiguration und das unterschiedliche Verhalten geschieht über die Variable: MX42_UEM_Agent, Auto Update.

Variablenwert Erläuterung
No – Use assigned version (Standard) [0] Das Auto Update ist deaktiviert. Die Aktualisierung geschieht klassisch über die Zuweisung eines Paketes.
Yes – Use latest approved version [1] Das Auto Update ist aktiviert. Es wird die höchste Version der „Zur Installation freigegeben“en UEM Agent Pakete installiert.
Yes – Use latest approved version (Pilot Rollout) [2] Das Auto Update ist aktiviert. Es wird die höchste eingebundene Version der UEM Agent Pakete installiert, auch wenn dieses nicht freigegeben ist.

Meine Präferenz zum UEM Agent Auto Update

Ich selbst nutze bevorzugt die klassische Art der UEM Agent Verteilung und lasse das Auto Update deaktiviert. Meines Erachtens ist es besser transparenter, nachvollziehbar, welcher Computer, welche Version bekommen soll und wann das geschieht. Aber wie immer gibt es verschiedene Geschmäcker und Vorgehensweisen/Vorlieben.

Der Beitrag Empirum Paketeigenschaften – Zur Installation freigeben erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-paketeigenschaften-zur-installation-freigeben/feed/ 0
Reboot Werte – Empirum Setup.inf https://www.wpm-blog.de/reboot-werte-empirum-setup-inf/ https://www.wpm-blog.de/reboot-werte-empirum-setup-inf/#respond Sun, 21 Apr 2024 18:14:00 +0000 https://www.wpm-blog.de/?p=2960 Gerne bekomme ich die Frage gestellt: Warum fordert mein Empirum Paket einen Neustart an, obwohl ich Reboot=0 in der Setup.inf gesetzt habe? Dieser Frage möchte ich im heutigen Beitrag heute nachgehen. Reboot Möglichkeiten Fangen wir … Weiterlesen

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

]]>
Gerne bekomme ich die Frage gestellt: Warum fordert mein Empirum Paket einen Neustart an, obwohl ich Reboot=0 in der Setup.inf gesetzt habe? Dieser Frage möchte ich im heutigen Beitrag heute nachgehen.

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.

]]>
https://www.wpm-blog.de/reboot-werte-empirum-setup-inf/feed/ 0
Anstehende Matrix42 UEM Agent Änderungen https://www.wpm-blog.de/anstehende-matrix42-uem-agent-aenderungen/ https://www.wpm-blog.de/anstehende-matrix42-uem-agent-aenderungen/#respond Thu, 06 Oct 2022 11:13:40 +0000 https://www.wpm-blog.de/?p=2821 Der Matrix42 UEM Agent für Windows bringt ab dem Oktober 2022 in der SFR Version einige Änderungen mit. Mit den Änderungen soll die Stabilität, als auch das Verhalten bei Aktualisierungen signifikant verbessert werden. Zusätzlich halten … Weiterlesen

Der Beitrag Anstehende Matrix42 UEM Agent Änderungen erschien zuerst auf Workplace Management Blog.

]]>

Der Matrix42 UEM Agent für Windows bringt ab dem Oktober 2022 in der SFR Version einige Änderungen mit. Mit den Änderungen soll die Stabilität, als auch das Verhalten bei Aktualisierungen signifikant verbessert werden. Zusätzlich halten weitere Verbesserungen hinsichtlich der Sicherheit Einzug.

Installation / Update

Die Installation des UEM Agenten geschieht nicht mehr über die Setup.inf, wie man das gewöhnt ist bzw. war. Ein Matrix42Maintenance Dienst hält Einzug, der die Installation und die Aktualisierung des UEM Agents durchführt. Alle Komponenten des UEM Agents werden per einfachen Dateikopieroperationen installiert oder entfernt. Die Setup.inf des UEM Agenten für Windows installiert den Matrix42Maintenance Dienst und im Anschluß übernimmt dieser die komplette Installation oder Aktualisierung. Über einen Registry Wert wird der „Matrix42Maintenance“ angetriggert, die verschiedenen Aktionen durchzuführen. Der Dienst schreibt sein Log in den Ordner: C:\ProgramData\Matrix42\Logs\MaintenanceService

Der Matrix42Maintenance Dienst kann einen „Rollback“ des Agenten durchführen, da der bestehende Agent während der Aktualisierung lokal gesichert wird.

Die Installation als auch die Aktualisierung müsste aufgrund der Änderungen schneller durchgeführt werden können.

Visual C Redistributable Komponenten

Die benötigten VCRedist Komponenten werden mitgeliefert und befinden sich im UEM Agent Programmverzeichnis.

Agenten-Templates

Der UEM Agent lädt nur noch die benötigten Agent-Templates herunter bzw. befinden sich im loklen „User“ Ordner gar keine Agent-Templates mehr.

Voraussetzung dazu ist eine aktuelle Empirum Version in Form eines aktuellen Hotfix (ca. August 2022), der für die Versionen 21.0.3 und 22.0 verfügbar ist.

Für Empirum v22.0 ist das der Hotfix mit der Nummer PRB36814: Security Issue: All Agent Template XML files with (encrypted) passwords are available on the client computers.
Für Empirum v21.0.3 ist das der Hotfix mit der Nummer PRB36844: All Agent Configurations are downloaded to the client cache folder (fix will also require a UEM Agent version greater than 2205.3.2 (SFR) or 2006.13.3 (ESR)).

SWDepot-Log Meldung

Es wird eine SWDepot-Log Meldung geschrieben, dass der OS-Install Mode verlassen wurde:
* Agent Installation Status   2209.46.1   0     OS Mode     Disabled    No more open tasks. OS Installation Mode disabled.

Wichtiger Hinweis

Dieser UEM Agent wird zusammen mit einem neuen UEMAgentUpdater ausgeliefert, welcher das genannte Backup und Zurückspielen beim Upgrade von älteren auf diesen Agenten unterstützt. Sollte im Nachhinein ein älterer Agent (also ohne MMS – Matrix42MaintenanceService) nach Empirum kopiert werden, ist darauf zu achten, dass die Dateien in „Configurator$\User\UEMAgentUpdater“ nicht überschrieben werden.

Download

Wer bereits einen Blick auf die oben genannten Neuerungen werfen mag, für den steht seit dem 30.09.2022 die Technical Preview (TP) des UEM Agenten im Marketplace zur Verfügung: https://marketplace.matrix42.com/details/uem-agent-windows-release/

Der Beitrag Anstehende Matrix42 UEM Agent Änderungen erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/anstehende-matrix42-uem-agent-aenderungen/feed/ 0
Software Depot / Kiosk mit anderem Benutzer starten https://www.wpm-blog.de/software-depot-kiosk-mit-anderem-benutzer-starten/ https://www.wpm-blog.de/software-depot-kiosk-mit-anderem-benutzer-starten/#respond Sun, 26 Sep 2021 07:12:11 +0000 https://www.wpm-blog.de/?p=2752 Hallo zusammen, nach einer längeren „Auszeit“ melde ich mich wieder zurück. Entschuldigung dafür schon Mal an dieser Stelle. Heute möchte ich auf eine Bitte eingehen, die ich per Mail und in der Vergangenheit bereits mehrmals … Weiterlesen

Der Beitrag Software Depot / Kiosk mit anderem Benutzer starten erschien zuerst auf Workplace Management Blog.

]]>
Hallo zusammen, nach einer längeren „Auszeit“ melde ich mich wieder zurück. Entschuldigung dafür schon Mal an dieser Stelle.

Heute möchte ich auf eine Bitte eingehen, die ich per Mail und in der Vergangenheit bereits mehrmals ähnlich gestellt bekommen habe. Das Software Depot bzw. weitläufig bekannt als Kiosk, das der Benutzer über den Empirum Agenten am Client starten kann, verwenden (bzw. verwendeten) einige, um weitere Software für den Anwender zu installieren. Warum spreche ich in der Vergangenheit. Es gibt und gab Mechanismen, das Software Depot aufzurufen wozu der Anwender keine Berechtigungen hat. Dann wurde die Software aus dem Software Depot gegebenenfalls unter anderen Berechtigungen installiert.

Warum wird das gemacht?

Man ist gerade beim Anwender vor Ort oder aufgeschaltet und möchte „mal eben schnell“ die Software-Installation durchführen oder nachholen, die man vergessen hat. Den Weg, jetzt zurück an seinen Arbeitsplatz oder „irgendwie“ in die Management Console zu gehen, sieht man als „umständlich“ an.

Warum bin ich nicht für diese Methode?

Wie man oben aus den Zeilen lesen kann, möchte ich nicht darauf eingehen, wie das einige gemacht haben bzw. machen.
Das mache ich deswegen, weil „veraltete“ Empirum Methoden genutzt werden, die unter Umständen nicht die volle Unterstützung erlangen. Ein weiterer Grund, warum ich nicht „Fan“ dieser Methode bin, ist in den Grundgedanken des Software Depots / Kiosks verankert.

  • Die Software wird nicht in der Management Console dem Client zugordnet. Ergo wird Sie bei einer Reinstallation des Computers, Vergabe eines neuen Computers nicht berücksichtigt.
  • Ein etwaiger Client-Teil des Paketes wird unter Umständen für diesen und andere Benutzer nicht installiert. Die Software kann sich also anders verhalten/voreingestellt sein, als auf den Computern, bei denen die Software zugewiesen wurde in der Management Console.

Was ist mein Vorschlag?

Kennen Sie die Empirum Web Console? Wenn nicht … Die Emprum Web Console ist, anders als ihr Name suggeriert, ein WebServer, der die wichtigsten Dinge der Empirum Management Console bereitstellt. Deswegen gehört die Empirum Web Console auch nur einmalig auf einen Server installiert und nicht als Paket auf die Clients verteilt (meine Meinung!).
Anschließend ist im Standard die Web Console über http://<ServerName>:8080/Empirum erreichbar (Firewall Einstellungen berücksichtigen!). Die Web Console kann auch auf https umgestellt werden. Wie das geht, kann unter help.matrix42.com nachgeschlagen werden.

Nun könnt ihr von jedem Arbeitsplatz die Console starten und mit wenigen Klicks die Software „normal“ dem Arbeitsplatz zuordnen. Damit entfallen dann auch die oben genannten Nachteile hinsichtlich Client-Teile und vergessen geraten bei einer Neu-Installation.

Als Idee: Die URL zur Web Console könnt ihr auch bei dem Agenten-Template hinterlegen, dann ist es auch an ähnlicher Stelle, wie das Kiosk.

Das sind meine Hinweise, meine Meinung zum Thema – „volles“ Kiosk für bestimmte Benutzer. Vielleicht haben Mitleser aus der Gemeinschaft weitere Ideen oder Erfahrungen, die Sie teilen/kommentieren wollen. Dank und Grüße Jochen

Der Beitrag Software Depot / Kiosk mit anderem Benutzer starten erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/software-depot-kiosk-mit-anderem-benutzer-starten/feed/ 0
Empirum SubDepot Paket und lokaler Agenten Benutzer https://www.wpm-blog.de/empirum-subdepot-paket-und-lokaler-agenten-benutzer/ https://www.wpm-blog.de/empirum-subdepot-paket-und-lokaler-agenten-benutzer/#respond Sat, 10 Apr 2021 16:33:00 +0000 https://www.wpm-blog.de/?p=2742 Das Matrix42 SubDepot Paket löscht und erstellt den Empirum-Agenten Benutzer bei jeder Installation und Aktualisierung. Nutzt man einen lokalen Benutzer für den Empirum-Agenten und für diesen Benutzer explizite Berechtigungen vergeben, verwaisen diese mit jedem Update … Weiterlesen

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

]]>
Das Matrix42 SubDepot Paket löscht und erstellt den Empirum-Agenten Benutzer bei jeder Installation und Aktualisierung. Nutzt man einen lokalen Benutzer für den Empirum-Agenten und für diesen Benutzer explizite Berechtigungen vergeben, verwaisen diese mit jedem Update des SubDepot Paketes. Die Setup.inf ist bereits dafür ausgelegt, diesen lokalen Benutzer nicht bei jeder Ausführung des SubDepot Paketes zu löschen und neu anzulegen.

Variable USER_UPDATE

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

Erstellen der Variable

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

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

Zuweisung des Wertes

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

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

]]>
https://www.wpm-blog.de/empirum-subdepot-paket-und-lokaler-agenten-benutzer/feed/ 0
Empirum WinPE – Windows Installation https://www.wpm-blog.de/empirum-winpe-windows-installation/ https://www.wpm-blog.de/empirum-winpe-windows-installation/#comments Wed, 06 Nov 2019 21:39:04 +0000 https://www.wpm-blog.de/?p=2426 Die Zutatenliste für eine erfolgreiche Windows Installation mittels des Empirum WinPE PreBoot Support besteht aus: Empirum WinPE PXE-Image, ein importiertes Windows Betriebssystem, diversen sogenannten Empirum PreOS Paketen, gesetzten Variablen und einem Computer. Zutaten zusammenführen Die … Weiterlesen

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

]]>
Die Zutatenliste für eine erfolgreiche Windows Installation mittels des Empirum WinPE PreBoot Support besteht aus: Empirum WinPE PXE-Image, ein importiertes Windows Betriebssystem, diversen sogenannten Empirum PreOS Paketen, gesetzten Variablen und einem Computer.

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.

]]>
https://www.wpm-blog.de/empirum-winpe-windows-installation/feed/ 6
Empirum Agent – Troubleshooting Verbindungsaufbau https://www.wpm-blog.de/empirum-agent-troubleshooting-verbindungsaufbau/ https://www.wpm-blog.de/empirum-agent-troubleshooting-verbindungsaufbau/#comments Fri, 20 Sep 2019 18:15:21 +0000 https://www.wpm-blog.de/?p=2316 Es gibt Fragen zum Empirum Agenten, die häufiger vorkommen als andere. Neben der Frage: „Warum macht der Agent nichts?“, ist die zweit häufigste Frage: „Mit welchem EmpirumServer verbindet sich mein Client und warum?“. Die Frage … Weiterlesen

Der Beitrag Empirum Agent – Troubleshooting Verbindungsaufbau erschien zuerst auf Workplace Management Blog.

]]>
Es gibt Fragen zum Empirum Agenten, die häufiger vorkommen als andere. Neben der Frage: „Warum macht der Agent nichts?“, ist die zweit häufigste Frage: „Mit welchem EmpirumServer verbindet sich mein Client und warum?“. Die Frage wird zumeist gestellt, weil der Computer sich nicht mit dem EmpirumServer verbindet, oder weil der Empirum Administrator die Konfiguration anpasst und verstehen will, warum der Empirum Agent sich mit dem entsprechenden EmpirumServer verbindet. Das sind wir auch an dem Punkt, dass es eine serverseitige Konfiguration gibt und eine Seite, was der Computer daraus macht.

Zentrale Steuerung – Agent Template

Sein Verhalten bekommt der Empirum Agent über das sogenannte Agent-Template mitgegeben. Dieses Agent-Template ist unabhängig, ob der Advanced oder UEM Agent eingesetzt wird. Funktionen die nur der UEM Agent bedienen kann sind mit einem fliederfarbenen Symbol gekennzeichnet. In Bezug auf die Verbindungsmöglichkeiten gibt es bis dato jedoch keine Unterschiede.

DHCP Optionen

In Empirum DBUtil muss zuerst die Option EmpirumServer aktiviert werden und mit einer Options-Nummer versehen sein. Dies geht in den Eigenschaften zu den PXE-Servern.Im Anschluss sollte man das Agent-Template erstellen bzw. aktualisieren mit der DHCP Option gesetzt (siehe Abbildung 1). Vertrauen ist gut – Kontrolle ist besser! Am besten man schaut nach der Erstellung in die daraus resultierende XML Datei im \\%EmpirumServer%\Configurator$\User Verzeichnis (<Konfigurationsname>.xml). In der Datei sollte eine Suche nach DHCP einen ähnlichen Eintrag wie folgt finden …

<DHCPOptions enabled="true">
     <DHCPEntry id="128">EmpirumServer</DHCPEntry>
</DHCPOptions>

Anschließend ist zu prüfen, ob die zuvor genutzte DHCP Options ID (hier 128) auf dem DHCP Server für den entsprechenden IP-Adressraum konfiguriert ist. Falls die Option 128 noch nicht vorhanden ist, so muss diese auf dem DHCP Server noch erstellt werden. Eine Anleitung, die man sich als Vorlage nutzen kann, ist hier verfügbar. Die zu erstellende Option (ab ID 128) ist vom Typ: Zeichenkette bzw. String und sollte mit dem Namen „EmpirumServer“ belegt werden.

Zugewiesene EmpirumServer verwenden

Wenn man mit der Zuweisung des EmpirumServers über die Konfigurations- bzw. Zuweisungsgruppen arbeiten will, muss man diverse Voraussetzungen erfüllen.
In den Computereigenschaften des zuzuweisenden EmpirumServers müssen die folgenden Werte gesetzt sein:

  • die Computerrolle: Empirum Master Server oder Empirum Depot Server
  • die Variablen: SubDepot\USER_x / PASSWORD_x

Der EmpirumServer wird über die Eigenschaften der Konfigurations-/Zuweisunggruppe zugewiesen und vererbt. Dem Computerobjekt wird automatisch nochmals direkt der Empirum Master Server zugewiesen.Die Reihenfolge der EmpirumServer Nutzung kann optisch oder in der %Computername%.ini Datei eingesehen werden. In den Eigenschaften der Gruppe entspricht die Reihenfolge von open nach unten. In der %Computername%.ini entspricht die Reihenfolge von unten (höchste Zahl) nach oben (kleinste Zahl).

Verbindungs-Versuchs-Reihenfolge
Die Reihenfolge der Verbindungsversuche geschieht vorwiegend, wie in der Abbildung des Agent-Templates zu sehen ist, von oben nach unten:

  • DHCP Option
  • Zugewiesene EmpirumServer (unter Berücksichtigung der Sub-Optionen: zufällige Reihenfolge, MasterServer auslassen)
  • bereits gesetzte Umgebungsvariable %Empirumserver%
  • Ausfall Server (das sollte zumeist der Empirum Master Server sein) – angegebener Server in der AgentConfig.xml

Die Verbindung wird ausschließlich nach der Erreichbarkeit des Servers bzw. der Freigaben (SMB/https) bestimmt, nicht an der Qualität der Verbindung.

Wie sieht es am Client aus?

Die Frage lässt sich zumeist gut beantworten, bedarf jedoch eines Blickes „unter die Motorhaube“, sprich in die Log Dateien des Agenten. Diese findet man für den UEM Agent unter: C:\ProgramData\Matrix42\Logs\UAF\ und für den Advanced Agent unter: C:\ProgramData\Matrix42\Logs\ERIS. Dazu nimmt man am besten die Datei ohne Datum im Dateinamen (aktuelle Datei) und sucht nach DHCP. Somit findet man zumeist schnell den Start des Empirum Agenten bzw. die Informationen zum aktuellen Polling. Nachfolgend ein beispielhaftes Log mit Kommentaren in kursiver Schrift.

>Welches Agent Template wurde genutzt? Name und Version ist hier aufgeführt.
[Warning] [MxLog.LogS] DLL.Transport [SAC] Using Agent Template ‚AgentConfigSample‘ (Version 18.0.0.3) <19>
>Was sind die aus der AgentConfig.xml (auf dem Client heißt die Konfigurationsdatei immer gleich) ausgelesenen Einstellungen?
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use DHCP options <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use assigned EmpirumServers ; Use random order ; Exclude Empirum Master Server <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Fallback Server: empirumserver.domain.loc, account: Domain\EmpirumAgent <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Active protocol: SMB <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] END Configuration for checking server availability <19>
>sind EmpirumServer zugewiesen?
[Warning] [MxLog.LogS] DLL.Transport [SAC] Machine values file for this computer is „C:\EmpirumAgent\Values\MachineValues\Domain\ComputerName.ini“ <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Loading assigned EmpirumServers from „C:\EmpirumAgent\Values\MachineValues\Domain\ComputerName.ini“ <19>
>hier sind keine EmpirumServer zugeordnet …
[Warning] [MxLog.LogS] DLL.Transport [SAC] No assigned EmpirumServer found! <19>
>nutze den EmpirumServer aus der Umegbungsvariable: EmpirumServer …
[Warning] [MxLog.LogS] DLL.Transport [SAC] Loading configuration from environment variables <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] ENV-EmpirumServer: empirumserver.domain.loc, ENV-User: Domain\EmpirumAgent, ENV-Password: is set <19>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Checking availability of server with user <Domain\EmpirumAgent> using configured protocol <19>

>im Falle eines zugewiesenen EmpirumServers per DHCP …
[Warning] [MxLog.LogS] DLL.Transport [SAC] Use DHCP options <9>

[Warning] [MxLog.LogS] DLL.Transport [SAC] Reading DHCP options from network stack <9>
[Information] [MxLog.LogS] DLL.Transport Dhcp environment variables from xml read <9>
[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] START SelectAdapters <9>

[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] START GetDhcpOptions <9>

[Information] [MxLog.LogS] DLL.Transport Dhcp Option „EmpirumServer“ with ID 128 will be requested <9>
[Information] [MxLog.LogS] DLL.Transport Dhcp Received 19 bytes from DHCP server: „empirumserver.domain.loc“ for option 129 <9>
[Information] [MxLog.LogS] DLL.Transport [DhcpOptions] END GetDhcpOptions successful. ‚1‘ values found <9>
[Warning] [MxLog.LogS] DLL.Transport [SAC] Get for DHCP option ‚EmpirumServer‘ value ‚empirumserver.domain.loc‘ successfully <9>

>Verbindungsversuche
[Information] [MxLog.LogS] DLL.Transport SMB Session Manager Connection to \\empirumserver.domain.loc\Configurator$\Packages with user Domain\EmpirumAgent establishing. <34>
>hierauf sollte ein „established“ folgen, oder eben eine Fehlermeldung, warum der EmpirumServer nicht erreichbar ist.

Der Beitrag Empirum Agent – Troubleshooting Verbindungsaufbau erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-agent-troubleshooting-verbindungsaufbau/feed/ 2
Empirum Agent Steuerung per Registry https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/ https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/#comments Fri, 20 Sep 2019 07:23:37 +0000 https://www.wpm-blog.de/?p=2311 Nachdem ich die Tage beim Kunden für mein Gedächtnis gelobt wurde, habe ich es als Ansporn gesehen, alle mir bekannten Möglichkeiten zur Steuerung des Empirum Agenten per Registry Einträge zusammenzufassen. Der größte Teil der Einträge … Weiterlesen

Der Beitrag Empirum Agent Steuerung per Registry erschien zuerst auf Workplace Management Blog.

]]>
Nachdem ich die Tage beim Kunden für mein Gedächtnis gelobt wurde, habe ich es als Ansporn gesehen, alle mir bekannten Möglichkeiten zur Steuerung des Empirum Agenten per Registry Einträge zusammenzufassen. Der größte Teil der Einträge kommt aus dem ganz offiziellen PDF zum UEM Agenten der Matrix42. Einige andere Eigenschaften aus den jeweiligen „Neue Funktionen und Änderungen“ Dokument. Somit habe ich hier weitestgehend nichts neu erfunden, sondern mehr zusammengetragen. Wobei einige wenige Hinweise, meines Wissens nach, nicht ganz so öffentlich zugänglich sind. 

Die nachfolgende Auflistung enthält zumeist eine Kurzbeschreibung, den Registry Wert in der .reg und Setup.inf Syntax und einen möglichen Quellenverweis.
Falls Ihr noch Werte kennt, die hier fehlen, so nutzt bitte die Kommentarfunktion oder schickt mir eine E-Mail.

Danke und Grüße – Jochen

Hinweis: Bei der Übernahme der Registry Werte in Empirum o.ä. bitte auf das Format der Hochkommas achten. Gerne wird ein „falsches“ Format der Hochkommas in den Editor übernommen. Zur Sicherheit im Editor oder in der Setup.inf die Hochkommas nochmals überschreiben.

Prüfung auf ausstehenden Windows Reboot verhindern

In der Registry kann festgelegt werden, dass der Agent die Überprüfung ausstehender Windows Reboots (z.B. vorhandene Pending.xml) nicht durchführt und anstehende Software Management-Aktionen durchführt. Die Prüfung kann durch Setzen des Registry Wertes WindowsUpdateRebootCheck unter dem Schlüssel HKLM,Software\Matrix42\Agent auf 0 deaktiviert werden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“WindowsUpdateRebootCheck“,0x00010001,0

Weiterführende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2017/Matrix42_Empirum_17.0_New_Features_and_Changes_DE.pdf

Erweiterungen zur Neustart Steuerung (UEM Agent 2009.x und neuer)
Der Wert „2“ ist der neue „Standard“, wie wenn kein Wert gesetzt ist. Nach einer Verzögerung erscheint ein UEM Agent Fenster, das den Benutzer zu einem Neustart auffordert. Wem dieses Verhalten nicht gefällt, kann den Wert auf „1“ setzen, welches dem alten Standard entspricht (keine UEM Agent Aktivitäten bis ein Neustart durch den Anwender durchgeführt wurde).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000002

Das „neue“ Reboot-Verhalten wird verzögert initiiert. Wer möchte kann den Verzögerungswert (in Sekunden) anpassen. Wenn kein Wert gesetzt ist, ist der Standardwert 15 Minuten (900 Sekunden).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootDelaySeconds“=dword:00000120

Weiterführende Informationen: https://marketplace.matrix42.com/details/uem-agent-windows-release/

Getaktete Verbindung erkennen (ab UEM Agent 1808)

Der UEM Agent Windows erkennt eine getaktete Verbindung und schreibt am Anfang des Pollings einen Registry Schlüssel:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
“ NetworkCostType“ (DWORD) = Wert der Microsoft API
Mögliche Werte:
0 – Unknown: Cost information is not available.
1 – Unrestricted: The connection is unlimited and has unrestricted usage charges and capacity constraints.
2 – Fixed: The use of this connection is unrestricted up to a specific limit.
3 – Variable: The connection is costed on a per-byte basis.

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Globaler Silent Level (UEM Agent)

Alle zu installierenden Software-Pakete werden mit einem Silent Wert ausgeführt. Es greifen keine paketspezifischen Werte aus dem Feld „Befehl“ der Paketeigenschaft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„GlobalSilentLevel“=dword:00000004
Einschränkungen aktuell: Pakete, die eine Eingabe erfordern, funktionieren nicht mit dem Modus “0” und “1”.
Wenn der Eintrag (GlobalSilentLevel) nicht vorhanden ist, funktioniert es wie unter dem Advanced Agent und die individuellen Paket Parameter werden angezogen.

HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“,0x00010001,4
oder
-HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

InstallAtShutdown – Shutdown nach der OS Installation (UEM Agent)

Wenn der untenstehende Registry Key auf 1 steht, dann ist der „InstallAtShutdown“ Modus für den Agent aktiv.
Der Wert kann jedoch auch gezielt gesetzt werden, um die Funktionalität zu nutzen.
Dieser Wert kann beispielsweise in der UEMAgent.bat gesetzt werden um den Computer nach der OS Installation komplett auszuschalten.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„InstallAtShutdown“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“InstallAtShutdown“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Ausblenden der Option Installation beim Herunterfahren (UEM Agent)

Die Funktion „Installation beim Herunterfahren“ kann für Anwender verborgen werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„AllowPostponeUntilShutdown „=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“AllowPostponeUntilShutdown“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Suspend Modus (UEM Agent)

Mit einem Registry-Key kann der UEM Agent in einen Modus versetzt werden, in dem
keinerlei Polling-, Download- oder Installationsaktionen durchgeführt werden. Intern wird
dieser Modus für den Auto Update verwendet. Bei Bedarf kann man diesen Modus
beispielsweise verwenden um beim Aufbau einer VPN-Verbindung über ein Satellitentelefon
den möglichen Datenverbrauch des Agent zu unterbinden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Suspenduntil“ (Typ: STRING) = Endedatum des Suspendmodes
Der Wert gibt den Termin zur Beendigung des Suspendmode an. Beispielsweise 2018-12-
24T18:00. Jeder angegebene Wert, der nicht vom Agent als ISO Zeit-Wert in der
Vergangenheit erkannt wird, wird den Agent pausieren

Paket Validierung

Validierung von Paketen für UEM Agent aktivieren (UEM Agent 1903)
Um die Validierung von Software Paketen auf Client-Seite zu aktivieren setzten Sie „CheckPackageHash“ als DWORD auf einen Wert größer 0 in der Registry.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„CheckPackageHash“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“CheckPackageHash“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Behandeln von fehlerhaften Paket Validierungen

Stellt die Paketvalidierung einen Unterschied der Hashwerte auf dem Server zu dem auf dem Client fest, wird für dieses Paket der Zähler FailedInstallationRetries hochgezählt.
Dieses Verhalten lässt sich mit dem Schlüssel CountHashValidationErrors als DWORD gezielt steuern. Existiert der Eintrag nicht oder besitzt einen Wert ungleich „1“, so wird der Zähler nicht hochgezählt (Standard). Existiert der Eintrag und hat den Wert „1“, so wird der FailedInstallationRetries Zähler hochgezählt.

HKLM,“SOFTWARE\Matrix42\Agent“,“CountHashValidationErrors“,0x00010001,1

Feedback URL ausschalten/anpassen (UEM Agent)

Die Anzeige des Icons und der Link zum Matrix42 Feedback Portal ausschalten.
Wenn man eine URL angibt, kann man auf ein eigenes Portal bzw. Internetseite verzweigen.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Feedback_URL“=““

HKLM,“SOFTWARE\Matrix42\Agent“,“Feedback_URL“,0x00000000,““

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

UEM Agent Autoupdate Zeitraum beeinflussen (ab UEM Agent 1811)

Wenn man die UEM Agent Autoupdate Funktion nutzt, so kann man den Zeitraum des automatischen Updates beeinflussen.
Dazu gibt es zwei Einträge, die eine Angabe von Minuten (Typ: DWORD) annehmen.

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„MinAutoUpdateDelayAfterSystemStart“=dword:00000015
„MaxAutoUpdateDelayAfterProcessStart“=dword:00000030

HKLM,“SOFTWARE\Matrix42\Agent“,“MinAutoUpdateDelayAfterSystemStart“,0x00010001,15
HKLM,“SOFTWARE\Matrix42\Agent“,“MaxAutoUpdateDelayAfterProcessStart“,0x00010001,30

Hinweise: MaxAutoUpdateDelayAfterProcessStart muss mindestens das Doppelte des Wertes MinAutoUpdateDelayAfterSystemStart sein. Die Werte in Minuten nutzt der UEM Agent beim Start des Dienstes um einen zufälligen Wert in diesem Zeitraum zu ermitteln. Wenn der Dienst-Neustart nach dem ersten Wert (Min…) liegt, dann ist nur noch der Wert (Max…) relevant.

Anpassen der Berechtigungen auf den Agent Cache

Um eine größtmögliche Sicherheit zu gewährleisten setzten der Advanced und der UEM Agent die lokalen NTFS Berechtigungen bei jedem Start des Agent nach den Matrix42 Vorgaben auf den Empirum Agent Cache (zumeist C:\EmpirumAgent). Um Kunden spezielle Szenarien zu ermöglichen kann dieses Verhalten mit einem Registry-Wert unterbunden werden, wenn beispielsweise der lokale Benutzer Zugriff auf Dateien im Cache-Verzeichnis benötigt.
Registry Schlüssel „HKLM\SOFTWARE\Matrix42\Agent,SetNTFSCacheRights“, 0 = Keine Anpassung der NTFS Rechte, 1 oder nicht vorhanden (Standard) = Anpassung der NTFS Rechte, 2 = Der Agent setzt die Standard Zugriffsrechte, jedoch keine Zugriffsrechte für „Jeder“ auf das „User“-Verzeichnis (ab UEM-Agent SFR 2011.1.2 )

HKLM,“SOFTWARE\Matrix42\Agent“,“SetNTFSCacheRights“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2018/Matrix42_Empirum_18.0_Update2_New_Features_and_Changes_DE.pdf

Prüfung auf Scriptdateien für Kiosk Pakete

Ab dem UEM Agent 2009.1.2 findet für Pakete im Kiosk keine Prüfung auf Existenz der Scriptdateien auf dem Server statt. Dies führt auf den Depotservern zu einer deutlichen Lastreduzierung, insbesondere bei Verwendung von http(s). Die Prüfung der Scriptdateien auf dem Depotserver kann über folgenden Registry Key wieder aktiviert werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„UseCheckFileForKiosk“=dword:00000001

Zurücksetzen der fehlgeschlagenen Installationen

Die Anzahl der auf dem Computer fehlgeschlagenen Softwareinstallationen werden unter dem Registry Baum „HKLM\SOFTWARE\Matrix42\Agent\software“ abgelegt.
Diese Pakete werden beim Erreichen des jeweiligen Maximalwertes nicht erneut ausgeführt. Damit die Pakete erneut ausgeführt werden, muss man entweder das Paket auf dem entsprechenden Computer „reinstallieren“, oder den Wert im Agent-Template erhöhen – das gilt dann jedoch für alle fehlgeschlagenen Installationen. Wenn man den Computer „zwingen“ möchte, die Ausführung der Installation aller fehlgeschlagenen Pakete nochmals zu starten, kann man alternativ den nachfolgend genannten Registry-Baum löschen.
Es besteht die Möglichkeit das per Paket, oder auch als externes Programm in der Management Console (erforderliche Rechte vorausgesetzt), einzubinden.

Beispiel für einen Eintrag in einem Software Paket:
-HKLM,“SOFTWARE\Matrix42\Agent\software“

Beispiel für einen externen Aufruf:
reg delete \\%Computername%\HKLM\SOFTWARE\Matrix42\Agent\software /f

Verhalten bei Problemen beim Paket-Download (ab UEM Agent 2203.1.2 SFR)

Sollte es beim Herunterladen eines Paketes zu Problemen kommen (z. B. temporäre Netzwerkfehler, Zugriffsprobleme), dann kann der Agent veranlassen, dass der Vorgang automatisch wiederholt werden soll. Hierfür kann man die Anzahl der erneuten Versuche (Standard: 5) sowie die Pause zwischen den Versuchen in Sekunden (Standard: 60) einstellen. Der Standard kann in der Registry überschrieben werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„RetryTransferRepetitionLimit“=dword:00000005
„RetryTransferPause“=dword:00000060

Weitergehende Informationen: https://m42marketplacemediathek.blob.core.windows.net/matrix42-ag-pub/2022/03/Matrix42-UEM-Agent-Windows-2203_1_2-SFR-EN.pdf

Der Beitrag Empirum Agent Steuerung per Registry erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-agent-steuerung-per-registry/feed/ 4
PreOS Paket: MoveComputerToEmpirumOU https://www.wpm-blog.de/movecomputertoempirumou/ https://www.wpm-blog.de/movecomputertoempirumou/#comments Mon, 22 Jul 2019 13:42:07 +0000 https://www.wpm-blog.de/?p=2245 Matrix42 hat mit der Version 1.4 des PreOS Paketes „DomainJoin“ die Funktion hinzugefügt, den Computer beim Domain-Join in eine entsprechende OU zu verschieben. Diese Funktion war in den Vorgängerversionen auch bereits enthalten, wenn das Computer-Objekt … Weiterlesen

Der Beitrag PreOS Paket: MoveComputerToEmpirumOU erschien zuerst auf Workplace Management Blog.

]]>
Matrix42 hat mit der Version 1.4 des PreOS Paketes „DomainJoin“ die Funktion hinzugefügt, den Computer beim Domain-Join in eine entsprechende OU zu verschieben. Diese Funktion war in den Vorgängerversionen auch bereits enthalten, wenn das Computer-Objekt noch nicht in der Domäne enthalten war. War das Computer-Konto bereits in der Domäne vorhanden, so wurde das Computer Konto erneuert und das Computer-Objekt in der OU belassen in der es war. Nun ist es abhängig von der Variable DomainJoin.DomainJoinAuthority. Ist die genannte Variable auf den Wert „AD“ gesetzt, so ist das Verhalten wie zuvor beschrieben. Ist die Variable jedoch auf „Empirum“ gesetzt, wird versucht das Computer-Objekt in die von Empirum per ORGANIZATIONAL_UNIT vorgegebene OU zu verschieben.

„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 (572 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.

]]>
https://www.wpm-blog.de/movecomputertoempirumou/feed/ 7
Empirum WinPE Paket – DriverIntegration Ersatz https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/ https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/#comments Tue, 01 Jan 2019 13:51:56 +0000 https://www.wpm-blog.de/?p=2132 Das Empirum WinPE Paket, das ich hier vorstelle ist dazu gedacht das Matrix42 Paket „DriverIntegration“ zu ersetzen. Mein Paket heißt PrepareDRVbyModel_Packages, da mein erstes WinPE Paket die Treiber aus der EmpInst Verzeichnis Struktur holt. Was … Weiterlesen

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

]]>
Das Empirum WinPE Paket, das ich hier vorstelle ist dazu gedacht das Matrix42 Paket „DriverIntegration“ zu ersetzen. Mein Paket heißt PrepareDRVbyModel_Packages, da mein erstes WinPE Paket die Treiber aus der EmpInst Verzeichnis Struktur holt. Was macht das originale Matrix42 DriverIntegration Paket? Es sucht in einer drivers.ini nach dem Hersteller und Model und kopiert abhängig davon die Treiber nach C:\EmpirumAgent\Drivers. In diesem Verzeichnis sucht die automatisierte Windows Installation (WindowsInstallation Paket) nach nicht bekannten Treibern. Dies kann man in der unattend.xml im WindowsInstallation Paket Verzeichnis sehen. Jetzt kommt wahrscheinlich der längste Beitrag, den ich bis dato geschrieben habe …

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.

[Update am 27.08.2019] Die Version 1.5 unterstützt nun auch die Drivers.json Datei, die per WinPEDriverAssistant erstellt wird. Es werden auch Intel NUCs erkannt und ASUS Motherboards. Beide zuletzt genannte Typen werden vom DriverIntegration Paket nicht unterstützt. Bei der Nutzung des PostOSInstallation Paketes, die darin enthaltene PostOsInstall.bat anpassen!

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

PrepareDRVbyModel_Packages 1.5 (387 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

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

]]>
https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/feed/ 9