wpm-Blog WinPE-Extension-Pack 1.3

Aufgrund der Windows 11 Implementierung und Unterscheidung im OS-Installer habe das PrepareDRVbyModel_Packages Paket überarbeiten „müssen“. Der Vorteil für Euch – auch eine weitere Funktion ist nun für alle nutzbar. Es ist die CommonDrivers Funktion. Ein Ordner mit Treibern wird für alle Modelle kopiert. So könnt ihr in diesem Ordner, die (neuen?) Dockingstation oder USB-Netzwerkadapter Treiber ablegen und müsst dazu nicht alle Modellpakete erneut anpassen. Es gibt einen Standard-Ordner (CommonDrivers) der kopiert wird, alternativ könnt ihr per Variable einen anderen Namen angeben. Den Gedanke hatte ich auch schon einmal und ein Nutzer hat mich da noch etwas „geschuppst“ – jetzt steht es Euch allen zur Verfügung. Ich hoffe, es gefällt Euch.

Das Paket, dass den Hotfix installiert, damit Windows 10 Pro keine ungewollten Neustart direkt nach WinPE Phase durchführt, habe ich in das Extension Pack aufgenommen. Ihr könnt selbst entscheiden, ob ihr es benötigt, oder nicht.

Das aktuelle wpm-Blog WinPE-Extension-Pack bekommt ihr hier.

innomea WinPE Extension Pack

Neben den WinPE Erweiterungen die ihr hier auf meinem Blog seht, arbeite ich auch den WinPE Erweiterungen der innomea mit. Die Erweiterungen der innomea sind hauptsächlich Ergänzungen zu den Paketen die Matrix42 anbietet. Mit den Ergänzungspaketen (HardwareProfileValidator und CommonDrivers) sollen annährend die Funktionen bereitgestellt werden, die z.B. hier mit PrepareDrvByModel_Packages erreicht werden.

Das innomea PostWindowsInstallation Paket wiederum ist eine starke Weiterentwicklung des hier angebotenen PostOSInstallation. Dieses Paket ermöglicht viele Anpassungen an der Windows Installation, die einige von Euch noch von den Betriebssystemvorlagen her kennen. Dabei wurde teilweise auch auf Einträge im Matrix42 ideas Portal eingegangen.

Hier ein kleiner Auszug der Funktionen, die ihr zum Großen Teil per Variablen steuern könnt: Installation von Treibern per EXE/MSI, Firewall Modifikationen, Festplatte/Partition C: umbenennen, Support, Besitzer Informationen hinterlegen, EmpirumServer der OS-Installation als Umgebungsvariable setzen, „Kennwort läuft nicht ab“ für den zusätzlichen lokalen Admin setzen, uvm.

Den kompletten Umfang und die weiteren Pakete könnt ihr hier einsehen.

Matrix42 DomainJoin Paket

Das Matrix42 DomainJoin Paket wird in Kürze auch eine neue Version erhalten, dessen Vorteil einige zu nutzen wissen werden. Vielen Dank an die Beteiligten der Matrix42 für eure offene Kommunikation und Umsetzung!

Beyond Empirum WinPE

Natürlich dreht sich die hier zumeist angesprochene Matrix42 Empirum Welt nicht nur um WinPE. Jedoch kann man ganz gut erkennen, dass diese mir sehr viel Spaß bereitet. Matrix42 ist dabei eine größere Änderung im UEM-Agent vorzunehmen. Darauf werde ich mit Euch in Kürze schauen.

Stay save!

Wer mich kennt, weiß wie sehr ich versuche „Anglizismen“, wenn möglich, zu umgehen. Es gibt meines Erachtens jedoch einige Situationen bei diesen diese Worte oder Sätze einfach kürzer und treffender sind. Wie auch immer: Bleibt weiterhin gesund in dieser „unbekannten“ und noch „verrückteren“ Zeit!

Der Beitrag Aktualisierungen Frühjahr 2022 erschien zuerst auf Workplace Management Blog.

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

Warum wird das gemacht?

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

Warum bin ich nicht für diese Methode?

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

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

Was ist mein Vorschlag?

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

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

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

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

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

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.

Was ist drin?

Im Empirum WinPE Extension Pack 1.0 sind enthalten:

• WinPE-D-2PXE 1.6
• PrepareDRVbyModel_Packages 1.7
• InstallNetFX3 1.2
• PostOSInstallation 1.2

Was hat sich geändert?

Nachfolgend gehe ich auf die wesentlichen Änderungen in den Paketen ein. Wie ich sehe, hat sich am meisten im WinPE-D-2PXE getan. Dieses Paket hilft immer wieder beim Troubleshooting, da es u.a. schon immer die WADK Version und nun auch die Empirum WinPE Version ausgibt.

WinPE-D-2PXE
liefert Informationen über den Computer und Umgebung

• neben den PXE-Einträgen wird auch eine Log-Datei mit den gleichen Informationen erstellt
• eine Import-Datei für den Matrix42WinPEDriverAssistant wird erzeugt
• die Dateien werden bereits nach dem WinPE 1.8.0 Verfahren übertragen
• die genutzte Empirum WinPE Version wird ausgegeben
• die erkannten eingebauten Festplatten und Netzwerkkarten werden ausgegeben

PrepareDRVbyModel_Packages
ist eine Alternative zum DriverIntegration Paket der Matrix42

• Kosmetik und anpassen von Ausgaben
• kann nun auch für Hardware genutzt werden, die keine Hersteller oder Modell-Information per WMI liefert

InstallNetFx3
installiert/aktiviert das .NET Framework 3.5 aus den zugewiesenen Betriebssystemquellen

• … hatte ich noch nicht veröffentlicht

PostOSInstallation
führt eine Batch Datei nach der Betriebssysteminstallation aus, die als Ersatz für die EmpirumAgent/UEMAgent.bat dienen kann. Diese Batch-Datei spielt auch mit dem PrepareDRVbyModel_Packages Paket zusammen.

• kann nun auch mit der %EmpirumServer% Variable in der PostOSInstall.bat umgehen
  
• öffnet den Firewall Port für den Push von Software Pakete

Weitere Vereinfachung

Die nachfolgende ZIP-Datei enthält nun eine Empirum Struktur, wie ihr die von Matrix42 Hotfixen und der WinPE Erweiterung bereits kennt, und kann „einfach“ in/über die Empirum Struktur kopiert werden.
Zusätzlich habe ich im „Empirum\Configurator\Packages\Matrix42\OSPackages\Drivers“ Ordner eine beispielhafte Verzeichnisstruktur und Setup.inf abgelegt, um mit PrepareDRVbyModel_Packages und PostOSInstallation Treiber nach der Betriebssysteminstallation zu installieren. Das ging schon immer, hat jedoch auch immer wieder nachfragen aufgeworfen, da ich dies nicht genug erläutert und dokumentiert habe. Ich hoffe, es ist nun einfacher aufzugreifen und zu nutzen.

Falls nicht, so gebt mir per Kommentar oder Mail eine Rückmeldung.
Wie immer – viel Spaß und gutes Gelingen!

Empirum WinPE Extension Pack 1.3 (324 Downloads )
SHA256 der Downloaddatei: EE118815DBD4DC80D6CBBFB9855C44C6639D08F63C0B8AE6779104176FB462A2

Empirum WinPE Extension Pack 1.2 (523 Downloads )
MD5 Hash der Downloaddatei: E10E01545793D0C4326D041CC1931FDD920CEAA0

Empirum WinPE Extension Pack 1.1 (596 Downloads )
MD5 Hash der Downloaddatei: 15A1A232F6D0C9124DB85CB14456C5D1D96F6BCA

Der Beitrag Empirum WinPE Extension Pack erschien zuerst auf Workplace Management Blog.

Hintergrund

Im Standard der Empirum Paket Vorlagen werden diese detaillierten Log Dateien von extern aufgerufenen Setup Routinen wie MSI und Unattended im %WINDIR%\Temp Ordner abgelegt. Schlägt eine Installation fehl, werden diese Log Dateien mit den Fehlern vorgehalten (nicht gelöscht) damit das Problem näher erörtert werden kann. Wenn nun Computer ausgeschaltet sind oder der Zugriff auf den Computer nicht sichergestellt ist (Notebook Benutzer, Firewall, etc.) kann derzeit jedoch keine weiterführende bzw. zeitnahe Analyse bezüglich des Problems stattfinden.

Idee

Ich habe mir dazu ausgedacht, dass im Fehlerfalle diese Log Dateien zusätzlich in das Log Verzeichnis des Agenten kopiert werden und dieser überträgt die Dateien auf den zentralen EmpirumServer. Dieser ist immer erreichbar und der Zugriff kann zentral gesteuert werden. Die Synchronisierung der Log Dateien wird über den EmpirumAgenten sichergestellt, da diese in einem Unterverzeichnis von C:\EmpirumAgent\Log abgelegt werden.

Umsetzung

Die nachfolgenden Beispiele sind ggf. auf die eigene Umgebung und das Agenten-Verzeichnis anzupassen.

Notwendige Setup.inf Anpassung

Dazu wurde folgende Änderung bzw. zusätzlichen Zeilen in der Setup.inf erstellt:

[Environment]
MSILogFileName=MSI_%ProductName%.%Version%.%Revision%.log
MSILogFile=%Temp%\%MSILogFileName%
ErrorMsgSyncDir=C:\EmpirumAgent\Log\InstallErrors.CU\%Computername%

[AbortMSIInst]
CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"
COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
Abort

[AbortMSIUnInst]
-Abort
-ErrorLogMsg %ErrorLogMessage% ErrorLevel: %ErrorLevel%
-COPY "%MSILogFile%" "%ErrorMsgSyncDir%\%MSILogFileName%"
-CALLHIDDEN %COMSPEC% /C MD "%ErrorMsgSyncDir%"

Anpassung in der Management Console

Der Zugriff auf das zentrale Log Verzeichnis eines Computers kann über einen „Rechtsklick“ auf den Computer geschehen. Die Konfiguration wird über die Management Console, Extras, Eigenschaften unter „Externe Programme“ vorgenommen.

• Zentrales Log Verzeichnis
• explorer \\%EmpirumServer%\configurator$\Log\InstallErrors.CU\%Computername%

Das gezeigte Beispiel nutzt die EmpirumServer Variable. Hier muss ggf. der zentrale EmpirumServer eingetragen werden und das Support-Personal zum Lesen berechtigt werden.

Bereinigung

Die zyklische Bereinigung des zentralen Log Verzeichnisses muss derzeit von Hand durchgeführt werden.

Der Beitrag Empirum: Einfacherer Zugriff auf detaillierte Fehler-Protokolle erschien zuerst auf Workplace Management Blog.

Voraussetzungen

• Es wird ein Benutzer mit administrativen Berechtigungen auf dem Zielsystem benötigt.
• Die Namensauflösung muss funktionieren!
• Die Admin$ Freigaben müssen vorhanden sein.
• Die Firewall muss SMB Verbindungen zulassen.
• Für Windows 7 muss die UAC mindestens dem Standard oder „lockerer“ entsprechen.
• Der Dienst „Remote-Registrierung“ muss aktiviert sein.
• Für Windows XP müssen die Terminal-Dienste aktiv sein, da der Empirum Advanced Agent Dienst davon abhängig ist.

Wer auf Nummer sicher bezüglich Neustarts bei der Agenten Verteilung gehen will, der setzt im matrix42\EmpirumAgent Paket den Reboot auf 2 (Reboot=2) und kommentiert die SetReboot 1 Befehle aus.

Zu guter letzt können einem nun noch übervorsichtige Virenscanner Probleme bei der Verteilung machen.

Kaspersky – Konfiguration von Vertrauenswürdigen Anwendungen bzw. Programmausnahmen auf:

1. %windir%\temp\EmpirumAgent_tmp\Install\Setup.exe
2. %windir%\temp\Setup64.exe

• Zu öffnende Dateien nicht untersuchen
• Programmaktivität nicht kontrollieren
• Netzwerkverkehr nicht untersuchen

und je nach Version

• Zugriff auf Registrierung nicht untersuchen
• Aktivität der Unterprogramme nicht untersuchen.

TrendMicro
Im Matrix42 Forum wurde das Thema auch bereits diskutiert. Dies zeigt auf, dass es kein Problem eines einzelnen Client-Management Herstellers ist. Hier geht es zur Forums Diskussion.

„Probleme“ mit dem Virenscanner kann man dem DebugView Log auf dem EmpirumServer entnehmen. Der Empirum Agent Push Dienst endet dann jeweils mit dem Setup.exe Aufruf auf dem entfernten System. Beim weiteren Versuch wird dann gemeldet, dass die Setup.exe bereits im Zugriff durch ein anderes Programm ist.
Wie sind Eure Erfahrungen?
Habt Ihr funktionierende Einstellungen mit anderen Virenscannern?

Ansonsten, Viel Erfolg!

Der Beitrag Empirum Agent Verteilung per Push erschien zuerst auf Workplace Management Blog.