You searched for softwaredepot - Workplace Management Blog

Empirum: Pakete bleiben im Status Download

Jochen — Sat, 30 Nov 2024 09:24:42 +0000

Du wunderst dich, dass Pakete nach einer Zuweisung und Aktivierung zwar auf den Client heruntergeladen werden, jedoch nicht installiert werden? Die Softwarepakete verharren ggf. im Status „Download“. Eine Möglichkeit für diesen Zustand kann sein, das Du den Präsentationsmodus im Agenten-Template, der Agenten-Konfiguration, eingestellt hast.

Was ist der Präsentationsmodus?

Der Präsentationsmodus (Presentation mode) ist eine Funktion des Betriebssystems, der von Programmen eingeschaltet und von anderen Programmen systemweit ausgewertet werden kann. Der Präsentationsmodus wird zumeist von Programmen gesetzt die im Vollbild-Modus ausgeführt werden, wie aktive Präsentationen (Microsoft Powerpoint, etc.), Kiosk Modus von Browsern, jedoch auch von Vollbild Terminal Server Sitzungen, Citrix Wokspace App Sitzungen, uvm..

Präsentationsmodus und Empirum UEM Agent

Matrix42 hat sich diese Funktion zu Nutze gemacht und wertet den Präsentationsmodus aus, um den Anwender davor zu schützen, das Software-Installationen während einer laufenden Präsentation starten. Damit man eben nicht nur ein Programm und somit Anwendungsfall abfragt, wo es doch eine Vielzahl an Programmen und Anwendungsfälle gibt, wertet der UEM Agent je nach Konfiguration genau diesen Präsentationsmodus aus.

Feststellungen

So kann es in einer bestehenden Umgebung vorkommen, dass bei der häufigen Nutzung von Programmen, die den Präsentationsmodus aktivieren, die Installation(en) nicht starten. Dies kommt u.a. dann vor, wenn die Windows Clients als „Terminal Clients“ im HomeOffice genutzt werden. Ähnliche Konstellationen treffen auf Administratoren zu, die per Remotedesktopverbindung (mstsc) auf Windows Server aufgeschaltet sind.

Wie bekommen ich nun wichtige Software trotz alledem installiert?

Bei der Zuweisung einer Software wird im Standard die Verteilungsoption „Installieren und Erneuern“ gesetzt. Ergänzt man die Verteilungsoption um die Option „Installationszeitraum ignorieren“, wird die Installation auch bei gesetztem Präsentationsmodus ausgeführt.

Eine weitere Möglichkeit ist natürlich auch, das man sich für diese Clients eine weiteres Agenten-Template erstellt und zuweist. Hier gilt der Grundsatz der Empirum Console, das nähere am Computer befindliche Objekt hat Vorrang. Welches Agenten-Template tatsächlich angezogen wird, kannst du in den Computereigenschaften unter „Zugeordnete Objekte“ überprüfen.
Eine solches Agenten-Template, also mit deaktiviertem Präsentationsmodus, könnte somit für Computer in der Produktion, Kiosksysteme, Anzeigesysteme, Windows als „Terminal Client“ sinnvoll eingesetzt werden.

Was sagt die Empirum Hilfe?

Hier der dazugehörige Text aus der Empirum Hilfe …
Präsentationsmodus beachten: Wenn der Anwender diese Funktion aktiviert, verhält sich der Agent während einer Präsentation so, als wäre der Computer außerhalb des Installationszeitraums. Es wird keine Software installiert, es sei denn ein Paket hat die Verteilungsoption „Installationszeitraum ignorieren“ gesetzt.

UEM Agent beachtet Präsentationsmodus – Was nun?

Möchte man die Vorteile des Präsentationsmodus nutzen, um seine Kollegen, Chef, Vorstand nicht zu verärgern :), kann bzw. sollte man meines Erachtens trotzdem zumindest Pakete wie die folgenden mit der obigen Verteilungsoption zusätzlich konfigurieren:

Empirum Inventory
Matrix42 Patch-Management (Scan)

Weitere Pakete, wie vielleicht auch das Fix Paket des Patch-Managements, können somit von euch auch entsprechend priorisiert werden.

Da ich hier selbst einige Zeit im Dunkeln getappt bin, habe ich das hier für mich und euch zusammengefasst. Wie sind eure Erfahrungen mit dem Präsentationsmodus oder habt ihr Ergänzungen?

Der Beitrag Empirum: Pakete bleiben im Status Download erschien zuerst auf Workplace Management Blog.

Empirum – Paket in das SoftwareDepot einfügen

Jochen — Sun, 03 Dec 2023 14:28:12 +0000

Möchte man ein Softwarepaket mit Matrix42 Client-Management (Empirum) verteilen, so muss dieses nach der Erstellung (Paketierung) in das sogenannte Software-Depot eingefügt werden. Das Software-Depot ist das Verzeichnis, das alle Software-Pakete und deren Eigenschaften kennt, damit diese in der Empirum Softwareverteilung genutzt werden können.

Warum schreibe ich diesen Artikel?

Lange Zeit gab es keine Frage danach, wie ein Software-Paket in das Software-Depot aufgenommen wird, da es nur eine Methode gab. Da sich seit geraumer Zeit auch der Package Wizard verändert hat, stellt sich die Frage vielleicht um so mehr. Der Package Wizard ist das Werkzeug der Matrix42 zur Paket-Erstellung. Der Package Wizard wurde angepasst, damit die Pakete besser vorbereitet sind, um sie nicht nur in einer klassischen Empirum Console einfacher zu importieren, sondern auch, wenn man Empirum von Matrix42 als SaaS Angebot bezieht. Gerade im letzteren Fall, geschieht der Upload und Import von Software-Paketen über die sogenannte UUX Oberfläche.

Wie und wo importiert man Software-Pakete in Empirum?

Wenn ich hier vom Import von Software-Paketen in Empirum schreibe, dann beziehe ich mich in diesem Artikel auf die Empirum Oberfläche und nicht die Matrix42 UUX. Für den Import startet man die Empirum Console oder auch als Matrix42 Management Console bekannt und wechselt in den Bereich Konfiguration, Software Management, Depot.

Anschließend klickt man mit der rechten Maustaste auf das Register, in das man das erstellte Paket einfügen möchte …

Welche Methode nutzt man wann?

Doch welchen der beiden gezeigten Einsprungspunkte nutze ich denn nun?

Paket einfügen …

Hat man ein Software-Paket durch Kopieren eines vorhandenen Empirum Paketes auf dem EmpirumServer erstellt und dabei höchst wahrscheinlich selbst die Setup.inf angepasst, dann nutzt man die Methode „Paket einfügen …“. Welche Angaben man dabei treffen muss und kann, habe ich bereits in den Links zuvor beschrieben. Diese Methode benötigt man auch, wenn man einen Package Wizard vor der Empirum Version 22 nutzt, wenn mich nicht alles täuscht. Am besten, man achtet auf den Ablage des Paketes am Ende des Package Wizard Vorganges. Endet dieser mit einer Kopie des Paketes nach \\%EmpirumServer%\Configurator$\Packages, dann ist das hier die richtige Methode.

Hinweis: Bitte dabei auch immer das Paket aus der vorgeschlagenen Freigabe importieren und nicht auf die lokale Dateistruktur im Explorer wechseln und das Paket einfügen. Dies resultiert dann zumeist mit Paketen, die unter Check, Directory, etc. einen lokalen Pfad wie D:\Empirum\… eingetragen haben. Die Verteilung dieser hinzugefügten Pakete wird nicht funktionieren!

Import/Export

Wann nutzte ich nun die Import/Export Methode? Nun, diese Methode wird zumeist genutzt, wenn man Pakete übergeben bekommt wie z.B. der Matrix42 PackageCloud, der innomea Paketbox oder weiteren Paketanbietern … oder eben, wenn man einen aktuellen Empirum Package Wizard nutzt. Den aktuellen Package Wizard erkennt man daran, dann er mit den folgenden vier Bildern endet. Diese Abfragen hat die Vorgängerversion nicht getätigt.

Wird man also nach den Paket-Informationen, den Betriebssystemfreigaben, diversen Paket-Eigenschaften, zusätzlich zu den essentiellen Angaben wie: Hersteller, Softwarename und Version gefragt, dann hat man die „neue“ Version. Der Package Wizard schlägt dann auch im letzten Dialog die Kopie des Paketes nach \\%EmpirumServer%\Configurator$\PackageStore vor.

Nachfolgend die Dialoge des aktuellen Package Wizards …

Der Beitrag Empirum – Paket in das SoftwareDepot einfügen erschien zuerst auf Workplace Management Blog.

Erweiterte Empirum PXE-Server Konfiguration

Jochen — Fri, 03 Jul 2020 16:53:37 +0000

Mit dem aktuellen Empirum v19.0.3 Hotfix und der Empirum v20.0.1 wurde eine neue Funktion hinsichtlich der Nutzung der DHCP Option 82 (DHCP Snooping) eingeführt. In der Hotfix Beschreibung ist ein „Post-Step“ vorhanden, dass wenn man diese Funktion noch nicht nutzen möchte oder kann, ein Registry Wert zu setzen sei. In der Empirum Online Hilfe befindet sich zur DHCP Option 82 Nutzung folgender Hinweis.

Matrix42 SubDepot PXE Service Configuration

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

Schritte …

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

Variablen

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

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

Download

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

Zusammenfassung

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

Fertig!

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

EmoCheck per Empirum Paket

Jochen — Thu, 13 Feb 2020 21:16:33 +0000

Nachdem ich die Nachricht über EmoCheck bei Heise gelesen hatte, kam mir die Idee gleich in den Sinn. Doch es hat noch etwas gedauert bis ich die „freie“ Zeit für die Umsetzung gefunden habe. EmoCheck ist ein vom Japan CERT veröffentlichtes Prüfwerkzeug hinsichtlich einer Emotet Infektion, die vielleicht auch noch nicht „aktiv“ geworden ist. Das Japan CERT hat ein Schema bei der Generierung der Prozessnamen erkannt und macht sich das zu nutze. Wie zuverlässig das Werkzeug ist und wie lange es genutzt werden kann, muss jeder für sich entscheiden. Ich selbst fand es eine spannende Aufgabe zur Implementierung in eine Softwareverteilung. Deswegen ist das nachfolgende Empirum Paket entstanden …

EmoCheck

Das Japan CERT stellt das Werkzeug EmoCheck auf GitHub zum Download bereit. Die Datei(en) müssen von dort heruntergeladen werden, ggf. auf Virustotal geprüft und in das unten stehende Paket eingebunden werden.

wpm-blog EmoCheck Paket

Nachfolgend gib es das wpm-blog EmoCheck Paket zum Download. In der ZIP Datei sind wiederum zwei ZIP Archive. Eines was man für den Import nutzen kann, oder alternativ das Paket zum Entpacken für den Packages Ordner und selbst hinzufügen in das SoftwareDepot. Welche Methode ihr auch immer präferiert, die zuvor genannten EmoCheck*.exe Dateien müssen im „pTools“ Unterordner des Paketes abgelegt werden.

EmoCheck Empirum Package (556 Downloads )
MD5 Hash der Downloaddatei: FEB7522A6A138EED59D779828E784D55

Wie läuft es ab, was kann konfiguriert werden?

Das Paket kopiert das Tool nach „C:\ProgramData\EmoCheck\Exe“ und generiert eine Ausgabe nach „C:\ProgramData\EmoCheck\Log“. Findet es im aktuellen Log einen definierten Text, so wird „Alarm“ geschlagen, indem das Paket auf einen Fehler läuft und je nach gesetzter Variable im Paket auch die Ausgabe auf den EmpirumServer nach „Empirum\Configurator\Log\EmoCheck\“ überträgt (Voreinstellung). Die Log Dateien werden auf dem Client in „C:\ProgramData\EmoCheck\Log\Archive“ archiviert. Das Paket kann somit gerne komplett „silent“, mit der Verteilungsoption „Nicht anzeigen“ mittels Zeitplaner regelmäßig ausgeführt werden. Die Deinstallation räumt alles wieder weg.

Nur Überprüfung!

Das EmoCheck Tool, und somit auch dieses Softwarepaket, überprüft nur auf verdächtige Dateien! Falls eine verdächtige Datei gefunden wurde, muss noch Hand angelegt werden. Das Paket erstellt bereits einen Registry-Eintrag mittels dem man, ähnlich der Patch-Management Scan und Fix Kombination, mit einem Aufräumpaket hinterhergehen könnte. Aufgrund der Log/Rollout-Koordinations-Rückmeldungen sollte man die betroffenen Computer jedoch besser vom Netz nehmen bzw. per OS Installation komplett überschreiben.

Letzter Hinweis

Das Paket muss keine verlässliche Prüfung sein, da die Malware Schreiber und Jäger natürlich ein stetes Katz und Maus Spiel betreiben. Einen besseren Schutz bieten hier eher sogenannte NextGen AntiVirus Lösungen, die ausgefeiltere Mechanismen zur Malware Erkennung und Behandlung beinhalten.

Der Beitrag EmoCheck per Empirum Paket erschien zuerst auf Workplace Management Blog.

Empirum WinPE – PreOS Packages

Jochen — Wed, 06 Nov 2019 20:44:03 +0000

Damit man Windows mit Hilfe des Empirum WinPE PreBoot Supportes installieren kann, benötigt man ein Empirum WinPE PXE-Image, ein importiertes Windows Betriebssystem und diverse sogenannte Empirum PreOS Pakete. Die Empirum PreOS Pakete sind „spezielle“ Empirum Pakete, die vom so genannten Empirum WinPE PreBoot Support genutzt werden. Matrix42 stellt diese Pakete immer wieder aktualisiert in der WinPE PreBoot Support Erweiterung im Marketplace zur Verfügung. Empirum beinhaltet, je nach installierter Version, auch immer einen nutzbaren Stand der WinPE Umgebung. Wie bereits zuvor in Empirum WinPE – PXE-Image Erstellung geschrieben, kann man den WinPE PreBoot Support unabhängig von seiner genutzten Empirum Version aktualisieren.

Zutaten zusammenstellen …

Import der Pakete

Wer die vorhandenen PreOS Pakete nutzen mag, kann direkt zum nächsten Punkt springen. Wer wiederum aktuelle Pakete importieren mag, muss in der Management Console unter Konfiguration, Software-Depot mit der rechten Maustaste auf das Register „Matrix42 PreOS Packages“ klicken und „Import/Export“ auswählen. Im darauffolgenden Dialog wählt man dann den zumeist vorgegebenen Ordner „\\%EmpirumServer%\Configurator$\PackageStore“ aus.
Die Schritte für einen erfolgreichen Import von PreOS Paketen sind nun hier per Screenshots dokumentiert:

Auswählen des Quellverzeichnisses, wie z.B.: \\%EmpirumServer%\Configurator$\PackageStore …
Da im „PackageStore“ bestimmt mehr als die gewünschten Pakete vorliegen und angeboten werden, ist es ratsam zuvor per „Keine auswählen“ die Auswahl zu negieren. Dann wählt man die für sich notwendigen Pakete aus der Liste aus und startet den Importvorgang. Die Liste der Pakete ist weiter unten zu entnehmen. Die Abbildung zeigt eine exemplarische Auswahl, da das Paket PxeOffAndReboot bis dato unverändert blieb.

Werden die Pakete auf der Zusammenfassung rot angezeigt und nicht importiert, dann startet entweder die Management Console nochmals neu und versucht die Schritte noch einmal, oder schaut nach, ob das Paket vielleicht schon in der Dateistruktur vorliegt. Wenn ja, so löscht es aus der Dateistruktur und startet anschließend den Importvorgang nochmals von neuem.

Nach einem erfolgreichen Importvorgang, werden die Pakete im Matrix42 PreOS Packages Ordner ähnlich wie folgt angezeigt.

Die neu importierten Pakete werden im Status „nicht freigegeben“ importiert und sind braun eingefärbt. Dies kann sich in Zukunft noch ändern, doch derzeit müssen die Pakete noch einzeln zur Installation freigegeben werden. Dazu öffnet man die Paketeigenschaften mit einem Doppelklick bzw. wählt „Eigenschaften“ im Kontextmenü eines jeden Paketes.

Hinweis: Die PreOS-Pakete sind powershell Skripte mit dem Namen install.ps1 und liegen in einer definierten Struktur \OSPackages\\\Install vor. Eigene PreOS Pakete kann man mit Hilfe des PreOS Package Editors erstellen.

Welche Pakete werden benötigt?

Zur Durchführung einer Windows Installation benötigt man die nachfolgenden Pakete.

DiskPartitioning – Vorbereiten der Festplatte
DriverIntegration – Kopieren der Treiber des Models auf die vorbereitete Festplatte
WindowsInstallation – durchführen der Windows Installation samt der Treiber und kopieren/installieren des UAF Agents vom WinPE
PxeOffAndReboot – deaktivieren des WinPE PXE-Boots
DomainJoin – Hinzufügen des Computers zur Domäne
EmpirumAgentSetup – Installieren des vollwertigen Empirum Agenten und entfernen des UAF Agenten, Neustart …

Besonderheiten: Wenn man die PreOS Pakete aktualisiert bzw. aktuelle Pakete nutzt, muss man auch sein Empirum WinPE PXE-Image aktualisieren.

Die Reihenfolge ist wichtig!

Die Pakete müssen sich zur korrekten Verarbeitung in der oben aufgeführten Reihenfolge befinden. Auch bei neu importierten Versionen von Paketen muss auf die Reihenfolge geachtet werden. Dazu arrangiert man die Pakete, per Drag & Drop, von oben nach unten im SoftwareDepot.

Windows Installation Bundle

Man kann die zuvor genannten PreOS Pakete später einzeln zu seiner Konfigurations- oder Zuweisungsgruppe hinzufügen, oder eine UND-Klasse (Bundle) erstellen die diese Pakete enthält. Bei der Zuweisung der Pakete zu einer UND-Klasse muss die Reihenfolge nicht beachtet werden. Bei der clientseitigen Verarbeitung ist die Reihenfolge im SoftwareDepot maßgebend. Hier ein Beispiel für eine UND-Klasse, die im SoftwareDepot erstellt werden kann.

Der Beitrag Empirum WinPE – PreOS Packages erschien zuerst auf Workplace Management Blog.

Empirum WinPE – EPE Gegenüberstellung

Jochen — Sun, 31 Mar 2019 21:26:44 +0000

Die Unterscheidung EPE (Empirum PreInstallation Environment) zu WinPE bezieht sich hauptsächlich auf das Image, dass per PXE übertragen und ausgeführt wird. Nachfolgend werde ich zumeist von einer Installation per EPE bzw. WinPE sprechen, wobei natürlich auch andere Aufträge wie BIOS Konfiguration, BIOS Update, oder Löschen der Festplatten Aufgaben des PXEs sind. In der nachfolgenden Beschreibung gebe ich einen kurzen Überblick über die EPE Installation und gehe etwas detaillierter auf die Installation per WinPE ein.

Empirum PE (Linux)

Das EPE (Empirum PreInstallation Environment) auf Linux Basis verarbeitet mittels des EIS Interpreters die zugewiesenen Jobs (EIS Skripte), die per OS.INI im MAC8 Verzeichnis (letzten 8 Stellen der MAC-Adresse) zugewiesen werden. Die Abfolge der Aufträge sind durch das EIS Skript weitestgehend vorgegeben. An definierten Punkten kann man mittels der Custom EIS Skripte in den Ablauf eingreifen. Bei einer Betriebssysteminstallation werden das Windows PE und die Betriebssystemquellen auf die lokale Festplatte übertragen und von dort die Windows Installation per Windows PE gestartet. Die Installation wird mittels der Betriebssystemvorlage (OS.INI) beschrieben und parametrisiert (Windows Einstellungen, Lizenz-Schlüssel, Partitionierung, Domain-Join, uvm.). Am Ende einer Betriebssysteminstallation wird mittels des Parameters „Befehl“ der Empirum Agent installiert und der Übergang zur Softwareverteilung bereitet.

Empirum WinPE (Windows PE)

Das Empirum WinPE wird ebenso über die Management Console, Konfiguration, Bootkonfiguration erstellt. Bei der Erstellung bedient sich Empirum dem auf dem EmpirumServer installierten WADK (C:\Program Files (x86)\…), nicht dem in Empirum importieren WADK. Das erstellte Empirum WinPE beinhaltet einen EmpirumAgenten (Matrix42 UAF) und diverse WinPE Erweiterungen. Der im WinPE integrierte UAF Agent verarbeitet die zugewiesenen PreOS Pakete (aus der %Computername%.DDC).

Hier gilt die Reihenfolge, von oben nach unten, wie sie im SoftwareDepot festgelegt wurde. Die WinPE Pakete (auf Basis von powershell) werden über die EMC Variablen parametrisiert und nicht mehr über die OS.INI. Deswegen muss bei einer Aktivierung auch kein Haken mehr bei „Betriebssystemkonfiguration (OS.INI) erstellen“ gesetzt werden. Die Variablen bzw. die Variablengruppierungen sind nach den zugewiesenen Paketen benannt (z.B. DiskPartitioning, WindowsInstallation). Im Paket WindowsInstallation wird ebenso ein minimaler Matrix42 UAF Dienst installiert, der nach dem Paket „PxeOffAndReboot“ bis zur Installation des eigentlichen Matrix42 Windows Agenten durch das Paket EmpirumAgentSetup aktiv ist. Somit werden die PreOSPakete bis zum PxeOffAndReboot im Kontext des WinPE ausgeführt und im Anschluss im Kontext des installierten Windows. In dem Installations-Vorgang mittels WinPE stellt die erfolgreiche Ausführung des EmpirumAgentSetup Paketes den Übergang zur Softwareverteilung dar. Eigene PreOS Pakete können mittels Powershell Kenntnissen und dem PreOS Package Editors erzeugt und in die Abfolge eingebaut werden.

PreOS Paket Variablen

Die folgende Variablen bzw. Variablengruppen müssen für eine erfolgreiche Installation per WinPE gesetzt werden.

DiskPartitioning (optional)
DriverIntegration (optional)
WindowsInstallation
FQDN
ORGANIZATIONAL_UNIT
TimeZone
DomainJoin
MX42_AGENT_PUSH_PACKAGE_FOLDER

Zu diesem Thema werde ich in Kürze einen gesonderten Artikel erstellen. Wer nicht warten mag, sollte das PDF, dass der Empirum WinPE Erweiterung beiliegt, nutzen.

Vorteil der PreOS Pakete

Die sogenannten PreOS Pakete kann man, wie oben beschrieben, auch selbst erstellen. Damit man die Pakete in Empirum importieren und nutzen kann, muss man diese mit dem PreOS Package Editor erstellen. Durch das beschriebene Konstrukt kommen die Vorteile des WinPE Boots und der einzelnen Pakete erst richtig zum Vorschein. Beispielhaft, kann man bei einer Windows 7 zu Windows 10 Migration direkt auch das BIOS aktualisieren, auf UEFI umstellen, uvm. Diese Möglichkeiten waren mit dem EPE und der EIS basierten Installation nicht bis schwer umzusetzen.

Beispiele selbsterstellter PreOS Pakete

In Kundenumgebungen habe ich bereits Pakete wie:

BIOS Update
BIOS Konfiguration in unterschiedlicher Art und Weise
UEFISecureBootValidator
PostOSInstallation

erstellt und genutzt.
Einen Teil der Pakete hatte ich bereits veröffentlicht.

In Kürze werde ich ein Update der gesammelten und universellen Werke bereitstellen.

Der Beitrag Empirum WinPE – EPE Gegenüberstellung erschien zuerst auf Workplace Management Blog.

Empirum Setup.inf – SoftwareDepotDistributionFlags

Jochen — Wed, 05 Jul 2017 19:39:48 +0000

Ich hatte die Tage die Aufgabe ein Paket so zu modifizieren, dass es sich bei der Reinstallation bzw. beim einmaligen Erzwingen anders verhält als im Standard. Dabei fiel mir gleich die Variable SoftwareDepotDistributionFlags ein, die ich jedoch bis dato nicht genutzt hatte. In der Matrix42 Online Hilfe fand ich Hinweise zur Nutzung und Auswertung der entsprechenden SoftwareDepotDistributionFlags Variable. So „gestärkt“ machte ich mich an das Werk. Doch nach kurzer Zeit stellte sich etwas Ernüchterung ein, da es nicht sofort so funktioniert hat wie ich es mir vorgestellt hatte.

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.

Verteilbefehl DDC	SoftwareDistributionFlags (Dezimalwert)	Verteilbefehl aus der deutschen Oberfläche
INSTALL	1	Installieren
UPDATE	2	Erneuern
FORCE	4	Immer Erzwingen
UNINSTALL	8	Deinstallieren
REVOKE	16	Ablehnen möglich
FORCEONCEMACHINE	32	Maschinenteil erzwingen
FORCEONCECLIENT	64	Benutzerteil erzwingen
AFTERFORCE	128	Erzwingen (Nach Ablauf des Zeitplaners)
AFTERREVERSE	256	Umkehren (Nach Ablauf des Zeitplaners)
HIDE	512	Nicht anzeigen
REINSTALL	1024	Reinstallation mit vorheriger Deinstallation
OFFLINE	2048	Lokal cachen
IGNOREMTF	8192	Installationszeitraum ignorieren (ist bei einem Push immer gesetzt!)

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.

Empirum Sync-Job wird nicht auf Windows Server 2012R2 installiert

Jochen — Thu, 18 Aug 2016 06:09:16 +0000

Mit der Empirum Version 16 und neuer werden die Windows Server Versionen 2012 bzw. 2012 R2 separat unterstützt. Nach einem Update auf eine der aktuellen Empirum V16 Versionen und der Nutzung von selbst erstellten SYNC Jobs für den Empirum Sync Dienst, kann es dazu kommen das selbst erstellte SYNC Jobs nicht auf einem Windows Server 2012 R2 installiert werden.

Dies kann mit den folgenden beiden Schritten behoben werden …

Schritt1: Sync-Job für Windows Server 2012R2 freigeben

Der nachfolgende Befehl ist auf die Standort Datenbank auszuführen:

Update Software Set OSSystems='101171616' Where Type='SYNC'

Schritt 2: Neuerstellung der SWDepot.dds

Anschließend muss die neue Erstellung der SwDepot.dds Datei durch das Speichern der Konfiguration bzw. einer Konfigurationsänderung in der Management Console unter Konfiguration, Software-Management, SoftwareDepot erzwungen werden.

Hinweis in eigener Sache

Dieses Vorgehen habe ich mit der Empirum V16.1 mehrmals erfolgreich durchgeführt. Teilweise waren selbst erstellte SYNC Jobs für alle Betriebssysteme freigegeben. Bei neueren Empirum Versionen ist zur Sicherheit zuvor zu prüfen, welchen OSSystems Wert andere SYNC Jobs haben:

select SoftwareName, OSSystems from Software where Type='SYNC'

Der Beitrag Empirum Sync-Job wird nicht auf Windows Server 2012R2 installiert erschien zuerst auf Workplace Management Blog.

Empirum – Software Paketierung Selbststudium

Jochen — Mon, 08 Sep 2014 21:29:53 +0000

Im Laufe der Zeit habe ich nun bereits einige Artikel veröffentlicht, die sich immer wieder um die Software Paketierung bzw. Software Verteilung mit Empirum (Matrix42 Physical Workspace Management, UEM – Unified Endpoint Management, Client-Management) drehen. Damit man die einzelnen Artikel einfacher für ein Selbststudium nutzen kann, habe hier einmal alle Artikel mit dem Bezug zur Software Paketierung und Verteilung zusammengefasst, somit eine Art Anleitung zur „Empirum Paketierung“. Da die Seitenlinks recht selbst sprechend sind, habe ich mir jetzt auch nicht mehr die Mühe gemacht, diese nochmals „hübsch“ aufzubereiten. Für die regelmäßigen Leser gibt es hier nichts Neues – für alle anderen eine „interne“ Link-Sammlung.

Los geht’s!

Diese Linksammlung ist auf dem Stand: 07.04.2020

Generelles

Erstes Paket erstellen und verteilen

Paketierung – Erweitert

Software-Management

Paketierung – Besonderes zur Verteilung

Anpassen der Paketierungsvorlagen

Der Beitrag Empirum – Software Paketierung Selbststudium erschien zuerst auf Workplace Management Blog.

Empirum Paket – Revision

Jochen — Thu, 31 Oct 2013 17:55:58 +0000

Was ist eigentlich die Revision eines Paketes? Ich erkläre es zumeist so: Es ist die (firmen)interne Version der eigentlichen Software-Version.

Ein Beispiel: Ein Paket von FileZilla mit der Version 3.7.3 wurde erstellt. Das Paket macht wie es soll, die Software funktioniert und es wurde bereits verteilt. Nun wird festgestellt, dass die automatischen Updates nicht ausgeschaltet wurden.

Somit muss also dieses Paket erneuert bzw. angepasst und erneut verteilt werden. Doch welche Version hat die Software nun? Es ist faktisch immer noch FileZilla 3.7.3. Jedoch benötigt man zur erneuten Verteilung (falls man keine Reinstallation durchführt) eine Erhöhung der Version. Die Revision wird nahezu „unsichtbar“ immer an die Version angehängt.

Somit hilft jetzt die Revision!

ACHTUNG – die nachfolgenden Zeilen sorgfältig lesen bevor man dies mit einem produktiven Paket durchführt!

Erster Schritt – Erhöhung der Revision in der Setup.inf um einen Zähler (z.B. von 0 auf 1).

Zweiter Schritt – Erhöhung der Revision auch im SoftwareDepot. Dies geht auf zwei Arten. Man wechselt in der EMC in die Eigenschaften des Paketes. Dazu die EMC starten, Konfiguration, Software-Management, Depot, Software-Paket auswählen und die Eigenschaften aufrufen und auf den Reiter „Version“ wechseln. Hier die gleiche Revision eintragen, wie sie auch in der Setup.inf steht! Konfigurationsänderung mittels des Diskettensymbols speichern. Fertig!

Der bessere und einfachere Weg ist folgender: Durchführen des Versionsabgleiches im SoftwareDepot. Dabei werden die im SoftwareDepot bekannten Pakete (Setup.inf) erneut eingelesen und mit den Werten in der Datenbank verglichen und zur Anpassung vorgeschlagen. Dazu die EMC starten, Konfiguration, Software-Management, Depot, im Baum (links) auf Register gehen. Dann im Menü unter „Extras“, „Versionen abgleichen …“ starten und durchführen (mehr hierzu in der Matrix42 Online Hilfe). Konfigurationsänderung mittels des Diskettensymbols speichern. Fertig!

Wichtig ist hier auch das man weiß, was man mit dem „Versionen abgleichen …“ tatsächlich macht. Darauf werde ich in einem anderen Beitrag nochmals genauer eingehen. Denn hier ist Vorsicht geboten.

Sind die zuvor getätigten Änderung in der Setup.inf in das SoftwareDepot (und somit der SWDepot.dds) übertragen und gespeichert, gehts auch schon los …

Warum habe ich zuvor groß ACHTUNG geschrieben? Ist die Revisionsänderung durchgeführt (Setup.inf und SoftwareDepot) müssen die Computer nicht erneut aktiviert werden, damit die „Neuverteilung“ aktiviert ist. Alle bereits aktivierten Installationen sind mit der Änderung „scharfgeschaltet“ für eine erneute Durchführung der Installation beim nächsten Agenten-Polling! Sprich, wenn man die Revision erhöht, hat man keine Chance mehr das Paket definiert mittels der Softwareverteilung zu testen! Die notwendigen Tests müssen zuvor durchgeführt worden sein (ggf. mittels Setup.exe/Setup.inf Aufruf)!

Diesen besonderen Umstand sollte man sich in Erinnerung rufen, wenn man den Schritt der Revisionserhöhung durchführt.

Wozu kann man die Revisionserhöhung sorgenfrei nutzen?

Bei Paketen, wie der reinen Kopieraktion von SapLogon.ini, TnsNames.ora, o.ä. die einem ständigen Wandel unterliegen, ist die Nutzung der Revision zur Neuverteilung der einfachste Weg. Wurden Dateien in Differenzpaketen ausgetauscht, wie z.B. der Matrix42 eigenen Pakete wie EmpirumAgent, Inventory, etc. nach einem Update oder Hotfix, ist es auch ein leichtes, diese mittels der Revisionserhöhung erneut auf die Computer zu verteilen. Bei den beiden zuletzt genannten Einsatzvarianten kann man, oder sollte man, auch darüber nachdenken diese Pakete komplett „silent“ zu verteilen (/S0 und „Nicht anzeigen“ bei den Verteilungsoptionen).

Wenn die Revisionserhöhung bei Paketen genutzt wird, deren Installationsumfang sehr groß ist, sollte man die Revisionsänderung ggf. im Paket „abfangen“. Dazu jedoch auch mehr in einem separaten folgenden Blog-Beitrag.

Der Beitrag Empirum Paket – Revision erschien zuerst auf Workplace Management Blog.