Voraussetzungen

Aus meinen Erfahrungen heraus gibt es zwei Dinge, auf die man achten sollte. Seinen volle Leistung entfaltet der UEM Agent erst mit dem aktuellen Hotfix auf der Empirum Server Seite. Zusätzlich sollte man eine kleine Verbesserung in Form einer Setup.inf Anpassung vornehmen, bevor man diese Version einsetzt.

Matrix42 Empirum v21.0.3

Wichtig bei der Nutzung des neuen UEM Agents ist, das man beim Einsatz von Empirum v21.0.3 auch den aktuellen Hotfix Installer vom 28.10.2022 oder später ausführt.

Download

Matrix42 stellt alle UEM Agent für Windows Versionen an der gleichen Stelle zum Download bereit.
Den aktuellen Hotfix Installer für Matrix42 Empirum v21.0.3 gibt es hier.

Anpassungen

Nachdem man den UEM Agenten in das Empirum Software-Depot eingebunden hat, sollte man jedoch auf Dateiebene in der Setup.inf noch eine Anpassung vornehmen. Die Datei findet ihr auf dem EmpirumServer unter Empirum\Configurator\Packages\Matrix42\UEM Agent Windows\2210.1.2\Install.
Dazu die Finish Sektion der ausgelieferten Setup.inf wie folgt anpassen.
Hinzukommen sollte die Zeile mit dem Callhidden.

[Finish]
Callhidden reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\RebootPackagesPending /v "Restart Matrix42 UEM Agent Windows" /f
Exit

Hinweis

Trotz aller Empfehlungen von meiner Seite, sollte man, wie bei jedem Stück neuer Software, diese stückweise bzw. in Wellen (Test, Pilot, Rollout) an die Clients verteilen.

Der Beitrag UEM Agent für Windows 2210.1.2 released erschien zuerst auf Workplace Management Blog.

Was ist so anders bei Office 365?

Generell besteht die Umstellung darin, dass das die Office 365 Installation nicht mehr aus MSI und MSP Dateien besteht. Die „neue“ Installationsvariante hört auf den Namen „Click-To-Run“ oder kurz C2R bzw. ins deutsche übersetzt Klick und Los. Die nachfolgenden Links geben Antworten auf viele Fragen rund um das Thema „Breitstellung und Aktualisierung von Office 365“. Zusätzlich habe ich Links zur Aktualisierung von Office 365 per Matrix42 Patch-Management hinzugefügt.

Die häufigsten Fragen

Die hauptsächlichen Fragen bei der Bereitstellung von Office 365 sind:

• Welche Programme sollen alles verteilt werden?
• Was soll nicht Bestandteil der Bereitstellung sein (Publisher, OneDrive, Teams, …)?
• Welche Sprachen sollen bereitgestellt werden?
• Welcher Update-Kanal soll gewählt werden?
• Wo halten sich meine Clients am häufigsten auf?
• Wie und wo sollen die Updates-Quellen bereitgestellt werden?

Wie man sieht, sind das einige Fragen die beantwortet werden wollen, bevor man so richtig loslegen kann.

Was muss ich beachten, wenn ich zusätzlich Visio und Project installieren möchte?
https://docs.microsoft.com/de-de/deployoffice/install-different-office-visio-and-project-versions-on-the-same-computer

Was sind die Office Update Channels und was unterscheidet diese und welches ist der richtige Update Channel für mich oder meine Benutzer?https://docs.microsoft.com/en-us/deployoffice/overview-update-channels

Welchen Update Channel habe ich aktuell konfiguriert?
https://techcommunity.microsoft.com/t5/office-365-blog/how-to-manage-office-365-proplus-channels-for-it-pros/ba-p/795813

Wie aktuell bin ich?
Überblick über die aktuellen Versionen in den jeweiligen Update Channels:
https://docs.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date

Office 365 Updates

Welche Gruppenrichtlinien sind für das Update per Matrix42 Patch-Management zu setzen?
Wichtig zu wissen: Das Matrix42 Patch-Management für Office 365 „triggert“ nur die Aktualisierung und bringt nicht die Updates mit. Dazu müssen die aktualisierten Quellen für die Aktualisierung entweder auf einer UNC Freigabe, einer Web-Freigabe oder im Internet (Standard) abgelegt sein. Mein Wissensstand heute: Wenn man das Office365 Update gegen das Internet „triggert“, wird immer die aktuell verfügbare Version installiert, unabhängig von dem Office 365 „Patch“ den ich im Empirum Patch-Management freigegeben habe. Dies könnte man mit dem Parameter „Targetversion“ in der Gruppenrichtlinie steuern.
https://helpfiles.matrix42-web.de/2020_DE/M42_WebDocu.htm#WM/Manuals/Patch_Management/PM_Office.htm?

Gruppenrichtlinien setzen per GPO oder Registry
Eine Übersicht über die Einstellmöglichkeiten zu Office Click To Run per GPO findest Du hier.
https://admx.help/?Category=Office2016&Policy=office16.Office.Microsoft.Policies.Windows::L_UpdatePath

Wo in der Registry finde ich die Gruppenrichtlinien zu Office 365?
HKEY_LOCAL_MACHINE\software\policies\microsoft\office\16.0\common\officeupdate

Was muss ich beachten, wenn ich eine eigene Update Freigabe erstelle?
Wenn man die Aktualisierungen im internen Netz bereitstellen mag, muss man noch die Entscheidung fällen, ob die Freigabe per UNC oder http/https erreichbar sein soll.
Erstellt man eine UNC-Freigabe, so darf diese keine versteckte („$“) Freigabe sein. Hinweis: Die NTFS Berechtigungen sollten Zugriff für Everyone oder das Computerkonto erlauben! Die Quellen müssen im Unterordner Office\Data liegen (Die Quellen liegen dann also unter dem zuvorgenannten „updatepath“ + „\Office\Data“). Darin gibt es eine v<Architektur>.cab, eine v<Architektur>_<Version>.cab und ein Unterordner mit der <Version>. Der Unterordner mit der Version enthält die Quellen für die Installation. Die Dateien haben für eine deutsche Installation folgendes Namensschema: $$$1031.cab. In den Quellen können mehr Office Produkte/Module enthalten sein, als installiert werden. Sprich, die Quellen können in der Freigabe das Access beinhalten, aber in der Configuration.xml ist das Access ausgeschlossen.

Wie lade ich die Office 365 Quellen für eine Installation oder Aktualisierung herunter?
Die Quellen werden mit dem Microsoft Bereitstellungstool (Setup.exe) und einer passenden Konfigurationsdatei heruntergeladen.
Setup.exe /download <Datei.xml>
Die Konfigurationsdatei benötigt die Angabe des Ablageortes SourcePath=“<Pfad>“.
Bereitstellungskonfiguration: https://config.office.com/
Bereitstellungstool: https://www.microsoft.com/en-us/download/details.aspx?id=49117

Protokollierung

Das Logging der Installation als auch der Aktualisierung erfolgt nach %WinDir%\Temp\%Computername%-<Datum>-<Uhrzeit>.log
Wenn die Datei %Computername%-<Datum>-<Uhrzeit>.log größer oder annähernd 100kb groß ist, dann hat zumeist ein Update stattgefunden.
Die kann man u.a. auch daran festmachen, ob in der Datei „Update mode context starting: /update“ zu finden ist.
Wenn etwas fehlschlägt, oder man nach einem Fehler sucht. Dann sollte man in der Datei nach „error“ suchen.
Für die Installation kann man einen alternativen Log Pfad in der Bereitstellungskonfiguration angeben.

Erweiterte Protokollierung
Falls die standardmäßige Protokollierung von Office 365 nicht ausreichend ist, so kann man diese wie folgt erweitern:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3 /f
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1 /f

Quelle: https://docs.microsoft.com/de-de/office/troubleshoot/diagnostic-logs/how-to-enable-office-365-proplus-uls-logging

Weitergehende Scripte für Office 365 (Click to Run)
https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts

Der Beitrag Office 365 Installation und Update – Gesammelte Werke erschien zuerst auf Workplace Management Blog.

Empirum OS-Installer – die drei Phasen

Teilen wir die Probleme ein, in die drei Phasen der OS-Installation per Empirum WinPE.

• PXE-Boot
• WinPE
• Windows

PXE Boot

A.) Der PXE Boot funktioniert nicht bzw. hat noch nie funktioniert.
Die Switche bzw. VLANs müssen den Broadcast an den PXE-Server (zusätzlich zum DHCP Server) weiterleiten, gerne wird hier der Begriff „IP Helper“ aus der Cisco Welt hergenommen.
Die Windows Firewall muss den eingehenden Netzwerkverkehr auf den PXE- und TFTP-Ports zulassen. Die freizugebenen Ports sind abhängig von PXE Einstellungen. Wer auf Nummer sich gehen will, gibt die UDP Ports: 67,68,69,4011,10042 frei.

B.) Kein Computer führt mehr einen PXE-Boot durch, obschon dies vorher der Fall war.
In diesem Fall, schaut nach, ob Euer Empirum PXE-Dienst weiterhin läuft und erreichbar ist.

C.) Andere Computer starten einen PXE-Boot, doch dieser eine Computer nicht. Dies hat zumeist die folgenden Ursachen:

• Überprüft die beim Computer hinterlegte MAC/UUID mit den Werten die im BIOS angezeigt werden. Ausnahmen sind natürlich externe Docking-Stationen oder Netzwerkadapter.
• Wird MAC Passthrough genutzt und welche Einstellungen dazu bietet das BIOS. MAC Passthrough ist auch sehr abhängig vom Windows Treiber.
• Ist das Computerobjekt in den Eigenschaften als „PXE fähig“ markiert?
• Wenn dies alles passt, so führt bitte über Matrix42 DBUtil das SQL Script: „OS_CleanupNonUniqueDhcpEntries.sql“ aus dem Verzeichnis Empirum\Empirum DBUtil\Scripts\SQLServer\Custom aus. Mit der Ausführung dieses Skripts könnt ihr nichts kaputt machen! Es kann auch mehrfach ausgeführt werden.

D.) Wenn Sie diesen Bildschirm sehen, dann haben sie die vorgenannten Probleme nicht, nicht mehr oder erfolgreich gemeistert.

WinPE

Hast Du es in die WinPE Phase „geschafft“, sieht Du einen grauen Hintergrund oder gar das Matrix42 Logo, und eine Fortschrittsanzeige, wie hier abgebildet.

Die letzten drei Schritte in der Anzeige (wie in diesem Screenshot) bekommst Du erst mit der WinPE Umgebung neuer als 1.8.3 aufgelistet. Schlägt der „Connect to server“ fehl, dann muss man sich zumeist um die Einbindung der passenden Treiber kümmern (siehe Einbinden der WinPE Treiber). Alternativ kann es auch zu Problemen mit der Anmeldung (Benutzername und Kennwort) kommen. In das Log kommt man mit STRG+L. Dies kann man zur genaueren Analyse auch auf einen USB-Stick kopieren.

War die Verbindung erfolgreich und es erscheint die vorherige Meldung, dann liegt es daran, dass kein eindeutiger Eintrag (kein oder doppelter) in der DeviceMapping.xml (Empirum\Configurator\Values) vorhanden ist. Dazu kann man die DeviceMapping.xml mit einem Editor starten und prüfen, ob der Computername gefunden werden kann. Falls ja, nutzt die dazugehörige MAC Adresse oder UUID und sucht danach in der Datei – wahrscheinlich findet ihr einen weiteren Computer mit identischen Werten. Dieses Problem muss behoben werden!

Unabhängig der genannten Probleme, kann es sein, dass der EmpirumAgent Benutzer keine Schreibberechtigungen auf den Empirum\EmpInst\Wizard\OS\WinPEStatus Ordner hat.

Sind all diese Hürden genommen und es kommt trotzdem zu Problemen, dann liegt das zumeist an der Ausführung eines der WinPE Pakete. In seltenen Fällen sollte man prüfen, ob das Paket tatsächlich auf dem EmpirumServer oder dem SubDepot vorhanden ist. Ansonsten sind es dann Probleme bei der Parametrisierung der Pakete. Da hilft Euch jedoch das Log in WinPEStatus Order weiter bzw. sogar häufig das SWDepotLog in der Management Console.

Einbinden der WinPE Treiber

Für die WinPE Phase müssen die Treiber (zumeist nur Netzwerkkartentreiber) über die Management Console, Konfiguration, Boot Konfiguration eingebunden werden.
Dazu die Erweiterten Eigenschaften aktivieren (oben rechts) und bei Zusätzliche Treiberverzeichnisse ein Ordner angeben, in dem die Treiber abgelegt sind oder werden.Ich empfehle ein Ordner unterhalb von Empirum\EmpInst\DRV anzulegen und dort die Treiber ggf. nach Modell sortiert abzulegen. Die Treiber werden auch aus den Unterverzeichnissen (rekursiv) hinzugefügt, so muss man nicht pro Treiber ein Ordner in der Oberfläche angeben. Hast Du diesen Ordner bereits, brauchst Du die Treiber nur in diesem Ordner zusätzlich abzulegen und die Boot Konfiguration neu zu speichern, über den „Speichern“ Button (unten rechts).

Du kannst dann an Deiner Boot Konfiguration verschiedene Zustände feststellen – Sanduhr, Zahnräder und am Ende einen grünen Haken. Sobald die Boot Konfiguration erfolgreich neu erstellt wurde, kannst Du den nächsten Boot-Versuch starten.

Import-Certificate -FilePath "<EmpirumLaufwerk>:\Empirum\EmpInst\Sys\Images\WinPE\binaries\UAF\matrix42ag.Cer" -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

Möchtest Du nicht den Netzwerkartentreiber für die einzelnen Modelle raussuchen bzw. aus dem Windows 10 Treiberpaket entnehmen, so kannst Du auch ein komplettes WinPE Treiberpaket des jeweiligen Herstellers hinterlegen. Dazu jedoch immer erst das alte Verzeichnis löschen und anschließend das neue kopieren/ablegen.

Hier ein paar Beispiele:

• Dell Command | Deploy WinPE Driver Packs
• HP Client Windows PE Driver Packs

Windows

Mit den vorherigen Tipps sollte sich das Windows automatisiert installieren lassen. Ein weiterer häufiger Knackpunkt kommt im Anschluss an die Windows-Installation.
In der Management Console kann man noch eine erfolgreiche Installation von PxeOffAndReboot verzeichnen, jedoch schreitet die Installation nicht weiter voran.

Am Client sieht man dann eine durchlaufende Fortschrittsanzeige vor dem ausgeblendeten Windows-Hintergrund und das System führt alle 5 Minuten einen Neustart durch.
Ein weiterer Indiz ist, dass im PXE-Log des Computers während des DriverIntegration Pakets kein Treiber für das Model kopiert wurde. In diesem Fall fehlt in den meisten Fällen mindestens der Netzwerkkartentreiber für Windows bzw. das komplette Treiberpaket. Diese integriert man mit Hilfe des WinPEDriverAssistant’s aus dem Empirum\AddOns\WinPEDriverAssistant Ordner.

Die Treiber, ganz gleich ob *.zip, *.cab oder ein Ordner werden dann unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt. Du kannst die Treiber auch direkt dort ablegen und nur den Namen in das Treiberfeld einfügen – und nicht über das Ordner Symbol für den Import daneben gehen.

Dazu benötigt man die Hersteller und Modellbezeichnung und die entsprechenden Treiber.
Die Hersteller und Modellbezeichnung könnt ihr mit dem HardwareInfo Paket auslesen, oder wie gerade schon beschrieben, schaut ihr in das PXE-Log des Computers. Die erste Meldung ist „Using OS specific driver assignment for vendor …“.

Die Treiber dazu bekommst du bei den Herstellern. Dazu hatte ich bereits beim Beitrag für EPE die Seiten der Hersteller zusammengefasst.
Hast Du die Windows 10 Treiber eingebunden und das DriverIntegration Paket kopiert die Treiber, wie im zu vorigen Screenshot zu erkennen („Using the drivers: …), dann sollte es auch keine Probleme nach der Windows Installation geben.
Wenn es trotz Windows 10 Treiber nach dem PxeOffAndReboot nicht „weitergeht“, dann solltest Du schauen, dass du in Empirum DBUtil die UUID anstatt der MAC als „führendes“ Merkmal nutzt.

Mit diesen Tipps bin ich bester Dinge, dass Du eine erfolgreiche Windows Installation hinbekommst.

Als Grundlage solltest Du die anderen Blog Beiträge erfolgreich umgesetzt haben.
Zum Troubleshooting hatte ich bereits diesen Beitrag hier geschrieben.

Der Beitrag Empirum WinPE – neues Computermodell erschien zuerst auf Workplace Management Blog.

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.

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

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

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.

Szenario – Was ist zu beachten?

Dieses Szenario kommt vor, wenn zuvor die Software „von Hand“ oder einer zuvor eingesetzten Software-Management Lösung auf den Endgeräten installiert wurde und man sich nun für den Einsatz von Empirum entschieden hat. Jetzt kann man alle Geräte komplett neu installieren, oder eben die Endgeräte „wie sie sind“ in Empirum mittels der Verteilung des Empirum Agenten und des Empirum Inventorys in Empirum aufnehmen. Letzteres Verfahren spart zumindest erst einmal Zeit, jedoch muss man bei der Erstellung und Verteilung der weiteren Software-Pakete beachten, dass man ggf. nicht die gleiche Installationsgrundlage antrifft. Dies bedeutet wiederum ausgiebigere Tests und eine größere, oder andere Pilotgruppe.

Umsetzung in der Setup.inf

Wie ergänzt man nun sein Software-Paket, dass Microsoft Office eben nicht noch einmal installiert wird, wenn es zuvor schon anderweitig auf einem Endgerät installiert wurde? Diese Abfrage kann wie folgt umgesetzt werden. Natürlich kann man die Mehrsprachigkeit über die Strings Sektionen noch schöner handhaben ;-).

[Product]
#CheckAlreadyInstalled, DONTDELETE
;... eigentliche Installationsabfolge ...

[CheckAlreadyInstalled]
;*** Prüfen ob bereits Office 2010 manuell/anderweitig installiert wurde.
;*** Check existing Office 2010 Installation prior to Empirum Software-Distribution
IF DoesRegKeyExist ("HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90140000-0019-0407-0000-0000000FF1CE},InstallDate") == "1" & DoesRegKeyExist ("HKLM,SOFTWARE\%MachineKeyName%\Setup,DisplayName") == "0" Then "AlreadyInstalled" EndIf

[AlreadyInstalled]
ErrorLogMsg %DeveloperName% %ProductName% %Version% ist bereits installiert ohne Empirum | is already installed without Empirum
Exit %DeveloperName% %ProductName% %Version% ist bereits installiert ohne Empirum | is already installed without Empirum

Der Beitrag Empirum – Übernehmen von vorhandenen Installationen 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.

Wie bekommt man nun Werte vom Computer in die Empirum Datenbank?

Dazu man muss die benötigten Information auf dem Client in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\matrix42\Inventory ablegen.
Dazu können die Einträge Custom01 bis Custom30 mit Werten versehen werden. Anbei ein exemplarische Befüllung.

Beim Ausführen des Empirum Inventory werden diese Werte an die Empirum Standort Datenbank übermittelt.

Empirum Management Console

Sind in der Empirum Management Console unter Extras die entsprechenden Custom Werte mit Namen versehen und zugeordnet …

werden diese auch direkt beim Computer angezeigt…

Wie und mit was ihr diese Werte befüllt, könnt ihr selbst entscheiden.
Ein Weg ist sicherlich der Empirum Data Collector oder eben selbst erstellte Tools.

Diese Werte können auch in den Filtern genutzt werden …

Der Beitrag Zusätzliche Informationen vom Client befüllen lassen erschien zuerst auf Workplace Management Blog.

Reihenfolge und Abhängigkeiten

Bezüglich der Reihenfolge der Verteilung hat die Reihenfolge (von oben nach unten) der Pakete im SoftwareDepot grundlegenden Einfluss. Diese Reihenfolge kann mit der Option „Reihenfolge“ auf dem Reiter „Version“ überschrieben werden. Hier werden die Software Pakete angegeben, die vor dieser Software installiert werden muss. Im Dialog „Abhängigkeiten“ können Pakete angegeben werden, die installiert sein müssen, damit diese Software auch installiert wird. Hierüber können auch „Verbote“ definiert werden. Dieses Paket wird nicht installiert, wenn bereits Software xy bereits installier ist. (Bespiele sind die Matrix42 Pakete SubDepot Services und DataCollector).

Betriebssystem Freigabe

Auf diesem Reiter werden die Betriebssysteme „angehakt“, auf denen die Setup.inf erfolgreich ausgeführt wird und getestet ist. Ist ein Paket nur für Windows 7 freigegeben und wird einem Windows XP Computer in der EMC zugewiesen, wird die Setup.inf erst gar nicht „angestartet“, da das Paket nicht dafür freigegeben wurde.

Computerumgebung 

Die Einstellungen auf dem Reiter Computerumgebung wirken sich genauso auf die Verteilung aus, wie auf dem Reiter Betriebssystem. Hier können jedoch Rahmenbedingungen bzgl. RAM, Festplattenplatz, etc. definiert werden. Sind die Rahmenbedingungen nicht erfüllt, startet die Installation erst gar nicht. Die „nicht erfüllte Voraussetzung“ wird mit einer „Requirement“ Meldung im SoftwareDepot Log dokumentiert.

Sonstiges

Wie der Name schon sagt, vereinen sich auf dem Reiter „Sonstiges“ alle weiteren Einstellungen.  Die Einstellungen „Externes Installationsprogramm“ und „Installationsprogramm asynchron aufrufen“ werden in den allermeisten Fällen nicht genutzt und haben mehr eine „historische“ Bedeutung. Beim zweiten Falle, werden die Pakete nicht in einer Stapelverarbeitung eins nach dem anderen installiert, sondern eine weitere Installation wird bereits gestartet. Dies führt in den überwiegenden Fällen zu Installationsproblemen!

„Nur bei Verteilung“ benutzen steuert, ob eine Software im Kiosk sichtbar ist oder nicht, oder nur mittels EMC/EWC verteilt werden kann. „Erlaube Deinstallation“ hat auch nur Einfluss auf das Kiosk und ermöglicht dem Endbenutzer nur eine Deinstallation einer Software zu starten, wenn dies hiermit „erlaubt“ wird.

„Installation weiterer Pakete nicht fortsetzen“ ist interessant zu nutzen, wenn eine abhängige Software-Installation einen Neustart oder ähnlich voraussetzt. Sehr häufig ist dies nach einem Windows Service Pack oder Internet Explorer Update nötig, damit die nachfolgenden Installationen die richtige Version erkennen (mittlerweile auch durch den Wert SetReboot 5 in der Setup.inf steuerbar).

Die Option „Installationskontext“ erlaubt einem einzustellen, ob das Paket nur vor oder nach der Anmeldung ausgeführt werden darf, oder ob es „immer“ installiert werden kann. Wenn das Paket auf eine Abfrage vom Benutzer warten soll, so wäre „Nur nach der Benutzeranmeldung“ passend.

„Installationsdauer“ wird dem Benutzer vor bzw. während der Installation im sogenannten Z-Dialog angezeigt. Der Z-Dialog zeigt die anstehenden Installationen an und gibt ggf. die Möglichkeit  die Installation zu verschieben (je nach Agenten-Konfiguration und Verteilungsoption des Software-Paketes).

„Lizenzen“ – diese Eingabe kann komplett „vergessen“ werden und wird nicht mehr unterstützt.

„Sync. Bandbreite“ bezieht sich auf die Synchronisation der Pakete auf den Client. So kann hier für ein großes Software-Paket eine minimale verfügbare Bandbreite zur Synchronisation der Quellen auf den Client angegeben werden.

Die Eigenschaft „Pakettyp“ ist für die Zusammenarbeit mit dem Matrix42 Service Store relevant. Somit können die Pakettypen beim Import bereits unterschieden werden, wie diese weiter im Service Store zur Verfügung stehen bzw. „verarbeitet“ werden.

Prüfung

Auf diesem Reiter ist der Wert für Prüfdatei/Prüfwert noch sehr interessant. Nur wenn diese Kriterien erfüllt sind, findet die Ausführung des Software-Paketes statt. Hier lohnt sich ein Blick in die Matrix42 Pakete “Patch-Management (Install) bzw (Fix)“.

SetupInfo

Die Nutzung der Paketinformationen durch den bzw. die Paketierer habe ich hier bereits erklärt.

Registrierung

Auf dem Reiter Registrierung wird beim Import der Wert für Schlüssel aus der Setup.inf und der Eigenschaft „MachineKeyName“ übernommen. Dazu sind die bereits vorhandenen Blog Beiträge wichtig zu lesen:

• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Empirum Paket – Registry, SoftwareDepot, Version

AUT

Auf dem Reiter AUT kann eine zu „überwachende“ EXE Datei einem Software-Paket zugeordnet werden. Damit wird die Zuordnung und Erkennung auf dem Eigenschaften Reiter eines Computerobjektes vorgenommen.

Variablen

Hier werden Variablen, die zu dem Softwarepaket gehören und mit der Setup.inf importiert wurden angezeigt.

Der Beitrag Einbinden eines Software-Paketes in Empirum (Erweitert). erschien zuerst auf Workplace Management Blog.