Grober Ablauf – MSI Paketerstellung

Eine MSI Datei ist „eigentlich“ ein fertiges Paket für den Windows-Installer. Bei der Erstellung einer Empirum Setup.inf werden beim Packaging diverse Werte aus der MSI ausgelesen und in die Setup.inf übertragen. Die Setup.inf enthält am Ende die Logik und Erfolgsüberprüfung für die Installation, Reparatur und Deinstallation der MSI Datei und bietet Raum für Erweiterungen, die über die reine MSI Installation hinausgehen.

Aufmerksam sein …

Die aus der MSI Datei ausgelesen Werte für Hersteller, Software(name) und Version werden im Packaging Vorgang vorgeschlagen.

Hier sollte man wachsam sein und darauf achten, dass ..
1. bei Software auch nur der „Softwarename“ steht und nicht gleich der Hersteller und die Version zusätzlich.
2. es sich beim vorgeschlagenen Text um Zeichen handelt, die auch im Dateisystem verwendet werden können. Ansonsten fällt einem das später auf die Füße.

Beispiel: Dell Command Update

Im angezeigten Beispiel sind gleich mehrere „Hürden“ enthalten.
1. Es handelt sich um das Dell Command Update. Der Softwarename ist dann genau genommen nur noch „Command Update“. Also Dell am Anfang kann entfernt werden.
2. Vorgeschlagen wird „Command | Update“. Bitte macht daraus ein Command Update! Die „Pipe“ wird bei der Verzeichniserstellung für Probleme sorgen.
3. Der Hersteller ist „Dell Inc.“. Hier empfehle ich „Dell“ oder „Dell Inc“ daraus zu machen, weil es sonst weitere Probleme geben wird.

Man sollte also darauf achten, dass Hersteller, Softwarename und Version nicht auf einen „Punkt“ (.) enden!

Gemeistert

Hat man die Dinge oben beachtet, sollten keine Probleme bei der Paket-Erstellung, Import und Verteilung auftreten.
War man „clever“ und hat sich im die ein oder anderen Probleme „herumgearbeitet“, aber in der Setup.inf vielleicht noch „Dell Inc.“ stehen, dann kann das wie folgt enden.
Die Installation des Paketes schlägt fehl. Beim genaueren Hinsehen hat einen Ordner „Dell Inc.“, auf den man jedoch nicht zugreifen kann…

Wenn er stört, dann löscht man ihn halt. Argh – das funktioniert leider auch nicht so einfach.

Egal wie man es dreht und wendet, man bekommt den Ordner weder per Explorer oder den normalen Angaben in der CMD nicht entfernt.

Mit folgenden Befehl kann man den Ordner jedoch entfernen:

rd /s /q "\\?\C:\ProgramData\$Matrix42Scripts$\Dell Inc."

Der Beitrag Aufgepasst im Package Wizard – MSI erschien zuerst auf Workplace Management Blog.

Hintergrund

Damit man eine Software mit Matrix42 Empirum verteilen kann, benötigt man ein Software-Paket. Dies muss im Falle von Matrix42 Empirum ein gewisses Format haben und ist am Ende eine Steuerdatei bzw. ein Skript mit dem Namen Setup.inf. Diese Setup.inf wird auch vom Matrix42 Package Wizard ein Paket erstellt, wenn man sich für die Installation einer MSI oder EXE, die unattended installiert werden kann, entscheidet. Der Vorteil ist, dass die Setup.inf neben der Fehler- bzw. Erfolgsbehandlung auch weitere Aufgaben übernehmen kann, die für diese Software nötig ist. Beispiele: Löschen der Desktop-Verknüpfung, Installation einer VCRedist vorab, Kopieren einer Datei danach, uvm.

Warum nun doppelte Einträge?

Die eben genannte Setup.inf ist im Ursprung eine Installationsroutine für Programme, die sich eben nicht „unattended“ bzw. „silent“ installieren lassen. Wenn man nun innerhalb der Setup.inf eine MSI oder EXE installiert, die selbst eine Installationsroutine mitbringt, haben wir eben zwei Installationsroutinen. Beide Installationsroutinen tragen sich in der Registry ein, womit sie dann in den oben genannten Dialogen erscheinen.

Bei MSI Paketen ist dies nicht der Fall!

Erstellt man mit dem Matrix42 Package Wizard ein Paket auf der Grundlage von MSI Quellen passiert das zumeist nicht – warum? In der MSI.inf Vorlage wird dem MSI Aufruf standardmäßig der Parameter ARPSYSTEMCOMPONENT=1 angehängt. Dieser MSI Parameter sorgt dafür, das die zu installierende Software anschließend mit dem Flag SYSTEMCOMPONENT versehen wird, welches die Anzeige in der Systemsteuerung bzw. unter Einstellungen unterdrückt wird: https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent

Was passiert da?

Die Software bzw. die Anzeige in der Systemsteuerung bzw. unter Einstellungen wird zumeist über die Registry sichergestellt. Dazu legen die Installationsroutinen Einträge in den folgenden Registry Zweigen ab …
64bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

32bit Programme bzw. Installationsroutinen:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Erstellt man nun in einem Zweig einer entsprechenden Software einen Eintrag: SYSTEMCOMPONENT vom Typ: REG_DWORD und setzt dessen Wert: 1, so wird diese Software anschließend nicht mehr angezeigt.

Empirum Inventory

Dieses verstecken der Software bezieht sich nur auf die Anzeige direkt am Computer! Das Empirum Inventory erfasst trotz alledem beide Einträge, was man auch eher als Vorteil sehen sollte.

Unatteded.inf Anpassung

In der Setup.inf können wir diesen Wert nach der Installation durch Empirum auch selbsttätig setzen und löschen. Dazu sind die folgenden Anpassungen in der unattended.inf notwendig. Anpassen des Reg:Product Aufrufes unter [Product]. Der wahrscheinlich vorhandene Parameter ,DONTDELETE ist zu entfernen.

[Product]
...
#Reg:Product
...

Die Reg:Product Sektion ist entsprechend der Software anzupassen…

[Reg:Product]
;32bit - oder [Setup] Platform Wert entsprechend setzen!
;HKLM,SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1
;64bit
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<SoftwareName>,SystemComponent,0x00010001,1

Der Beitrag Software in der Systemsteuerung verstecken erschien zuerst auf Workplace Management Blog.

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.

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

Firefox

• Voreinstellungen HowTo
• Liste der Voreinstellungen
• Richtlinien – Auflistung und Werte
• Richtlinen Generator

Google Chrome

• Übersicht für den Administrator
• Voreinstellungen oder Richtlinien
• Richtlinen Verarbeitung
• Richtlinien Einstieg
• Google Chrome Richtlinien (Achtet auf „Supported on“ in den Artikeln)

Chrome ManagedBookmarks

Die „Managed Bookmarks“ sind vorgegebene und vom Benutzer nicht veränderbare Favoriten – im Google Chrome – Bookmarks.
Hier habe ich länger gesucht, um eine passende Seite mit einem funktionierenden Beispiel zu finden. Am einfachsten ist es, sich die Json Datei zusammenzubauen und in den unten beschrieben REG_SZ Eintrag einzufügen. Alternativ habe ich eine simple Liste mit zwei Einträgen als Reg-Datei beigefügt.

• Alte Referenz
• Neue Referenz

Achtung: falls Du die Datei per Skript einfügen willst, solltest Du es einmal manuell vornehmen und anschließend den Wert exportieren. Es werden einige „\“ eingefügt, um die Hochkommas wieder importieren zu können.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ManagedBookmarks"="[{\"toplevel_name\":\"My Favorites\"},{\"url\":\"https://www.wpm-blog.de/\",\"name\":\"WPM-Blog\"},{\"url\":\"https://www.matrix42.com/\",\"name\":\"Matrix42\"}]"

Microsoft Edge (Chromium)

Die Einstellungen des „neuen“ Microsoft Edge (Chromium), wer hätte es anders gedacht, ähneln sehr den Google Chrome Einstellungen zuvor.

• Microsoft Edge Richtlinien
• Microsoft Edge Richtlinien (Auflistung)
• Microsoft Edge Konfiguration von vorne bis hinten

Der Beitrag Internet Browser: Voreinstellungen und Richtlinien 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.

Bleibt gesund und vielleicht hört man sich auf dem diesjährigen Matrix42 Digital Workspace World 2020. Anmelden und schauen, welche Möglichkeiten es zum persönlichen Austausch gibt. Ich bin gespannt.

Bleibt gesund in dieser „unbekannten“ Zeit!

Der Beitrag Aktualisierungen Herbst 2020 erschien zuerst auf Workplace Management Blog.

Welche Datei meine ich denn nun genau?

Es geht um die Unattended.inf im Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates Ordner. Diese wird bei der Auswahl „Unattended“ im Verlaufe des „Package Wizards“ herangezogen.

Erfolgsüberprüfung

Nach dem „silent“ Aufruf einer EXE Datei, wird eine, wie ich sie nenne, „Erfolgsüberprüfung“ durchgeführt. Denn jede Setup.inf, die nicht mit einem „Abort“ beendet wird, wird per se als Erfolg gewertet. Sprich, wir sollten nach dem Aufruf eines externen Programms (Setup.exe, Installer, etc.) überprüfen, ob eingetroffen ist, was wir erwarten würden. Andernfalls, kann ein Paket ein „Success“ zurückmelden und die Software ist nicht installiert.

ErrorLevel Abfrage in der Vorlage

Die oben angesprochene Setup.inf Vorlage prüft deswegen nach einem Aufruf einer Installation den ErrorLevel ab. Weit verbreitet ist ein ErrorLevel mit dem Wert 0 ein Erfolg. Deswegen enthält die Vorlage auch die nachfolgende Zeile:

If "%ErrorLevel%" <> "0" Then "SET:InstallationError" EndIf

Doch was passiert, wenn die Installation z.B. einen Wert von 3010 zurückliefert? Ist dann ein Fehler aufgetreten? Nein. Der Wert 3010 bedeutet beispielsweise, die Installation war erfolgreich, doch es wird zusätzlich ein Neustart benötigt. Microsoft hat es mit den MSI Installern begonnen und einige haben diese Werte übernommen oder rufen in ihrer EXE Datei eine MSI Installation auf und geben den ErrorLevel der MSI Installation zurück.

Anpassung

Diese Anpassung setzt automatisch eine Neustart-Anforderung für dieses Paket und wertet den Rückgabewert von 3010 nicht als Fehler.

If "%ErrorLevel%" == "3010" Then "RebootRequired" EndIf
If "%ErrorLevel%" <> "0" & "%ErrorLevel%" <> "3010" Then "SET:InstallationError" EndIf

[RebootRequired]
SetReboot 1
-SetReboot 1

Wer noch weiter gehen möchte, für z.B. VCRedist Installationen oder Updates, der kann zusätzlich noch den Wert 1638 (Another version of this product is already installed) überprüfen.

ErrorLevel oder gibt es auch andere Methoden

Der ErrorLevel ist nicht die einzig wahre Methode. Natürlich kannst Du auch überprüfen, ob es einen bestimmten Registry Wert nach der Installation gibt, den es zuvor nicht gibt. Eine Überprüfung, ob die Software in Form ihrer ausführbaren Date vorhanden ist, kann genauso gut sein. Zu diesen Abfragen kommen wir dann bei den nächsten Tipps. Falls Du bereits Neugierig bist, so kannst Du in der Hilfe nach DoesRegKeyExist oder DoesFileExists suchen. Die DoesRegKeyExist Abfrage ist auch in der MSI.inf (Vorlage für MSI Installationen) enthalten ;-).

Der Beitrag ErrorLevel Abfrage bei Unattended Installationen erschien zuerst auf Workplace Management Blog.

Prüfmöglichkeiten

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

• Registrierung
• WMI
• Datei
• Ordner

Ideen

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

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

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

Beispiel

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

Hier nochmals die Werte für eine einfachere Eingabe:

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

Übertragen von Vorbedingungen

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

Matrix42 Hilfe

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

Der Beitrag Erweiterte Paketvoraussetzungen erschien zuerst auf Workplace Management Blog.

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 (435 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

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 (455 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\<Computername>“ ü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.