Trotzdem sind die nachfolgenden Informationen interessant und wichtig, wenn man vielleicht seinen vorhandenen EmpirumServer austauschen, umbenennen o.ä. mag. Handelt es sich um eine Umgebung mit mehreren Standorten oder einer größeren vierstelligen Anzahl an Clients, dann machen auch mehrere EmpirumServer Sinn bzw. werden benötigt. Weitere EmpirumServer nennt man im Empirum Sprachgebrauch „SubDepot“ – andere Hersteller nennen weitere Installations-Server z.B.: Repository, Sites, Distributed Installation Point.

EmpirumServer – SubDepots

Empirum SubDepots können mit der Hilfe von vorhandenen Empirum Software-Paketen und den passenden Variablen aus Windows Clients (Windows Server und Workstations) erstellt werden. In der Hauptsache ist ein Empirum SubDepot eine Kopie der Empirum Dateistruktur und den dazugehörigen Freigaben des Empirum Dienste-Servers. Das SubDepot tauscht, wie ein verwalteter Client (siehe oben): Software-Pakete, Auftrags-, Variablen-, Log- und Inventardateien mit dem überordneten EmpirumServer (zumeist Empirum Master Server) aus.

EmpirumServer – Verbindungsreihenfolge

Die Definition, mit welchem EmpirumServer der Client (UEM-Agent) sich verbindet, wird im Agent-Template (der Agenten-Konfiguration) vorgenommen. Wenn man das oder ein Agent-Template geöffnet hat, kann man die Versuche einer Verbindung, von oben nach unten, konfigurieren. Wenn ich Versuche schreibe, dann ist damit gemeint, das mit jeder nachfolgenden Konfiguration ein Verbindungsversuch gestartet wird. Wird eine Verbindung erfolgreich hergestellt, so wird diese genutzt. Die weiteren konfigurierten Optionen werden dann nicht mehr in Erwägung gezogen. Die Verbindungsversuche pro definierter Option und somit EmpirumServer werden jeweils auch mit den konfigurierten Protokollen durchgeführt.

DHCP Optionen verwenden (1)– nutzen des im DHCP-Bereich des Clients hinterlegten Computernamens z.B.: Depot1.MeineDomain.com oder Depot1. Weitergehende Informationen habe ich unten beschrieben.

Zugewiesene EmpirumServer verwenden (2)– nutzen der in der Management Console in den Eigenschaften der Konfigurations- bzw. Zuweisungsgruppe definierten EmpirumServer. Die eingerückten Optionen: Zufällige Reihenfolge verwenden bzw. Empirum Master Server ausschließen beziehen sich auf die „zugewiesenen EmpirumServer“. Den Empirum Master Server ausschließen macht deswegen Sinn, weil ein Computerobjekt immer den Master Server nochmals direkt am Computerobjekt zugewiesen bekommt. Diesen sollte man auch nicht aus der Zuweisung herausnehmen.

In der Reihenfolge der Verbindungsversuche folgt nun der in der Umgebungsvariable EmpirumServer (3) zwischengespeicherte EmpirumServer, mit dem zuletzt eine erfolgreiche Verbindung hergestellt wurde.

Zu guter letzt, wird eine Verbindung mit dem EmpirumServer im Feld Ausfall-Server (4) vorgenommen.

Das komplette Agent-Template wird dem Client als XML Datei zur Verfügung gestellt.

Weiterführende Informationen

Hier geht es zu einem Hilfe-Artikel der Matrix42 zu diesem Thema.

Nachfolgend zu den zuvor genannten Einstellungen ein paar mehr Informationen von meiner Seite …

DHCP Optionen verwenden – Reihenfolge der Konfiguration

DHCP Optionen verwenden – wenn die Option im Agent-Template aktiviert ist/wird, muss zuvor in Empirum DBUtil die EmpirumServer DHCP Option aktiviert und gesetzt sein. Welche Optionsnummer man verwendet ist in einem gewissen Rahmen, eigene Definitionssache. Es gibt einen Bereich, in dem benutzerdefinierte/kundenspezifische Werte gesetzt werden dürfen und dieser beginnt bei 128. Diese Optionsnummer muss dann wiederum im IP-Bereich des Clients ebenso aktiviert und gesetzt sein.

Vorgehensweise:
1) DHCP Server / IP-Bereich – prüfen, ob die Option 128,129, o.ä. frei ist.
2) Empirum DButil – Empirum-PXE, DHCP Optionen, EmpirumServer aktivieren und Option (z.B.: 128) definieren
3) Agenten-Template – Haken bei DHCP Optionen verwenden setzen und Agent-Template (neu) speichern.
4) DHCP Server / IP-Bereich – Option (z.B.: 128) aktivieren/erstellen und den für den Bereich passenden EmpirumServer eintragen.

Hier zwei Screenshots aus Empirum DBUtil …

Zugewiesene EmpirumServer

Der nachfolgende Screenshot zeigt die Eigenschaften eines Computerobjekts in Empirum. Wie zuvor beschrieben, seht ihr oben rechts unter „Ausgewählte Empirum Server“ den auf dieser Stufe ausgewählten EmpirumServer. Am Computerobjekt selbst ist im Standard immer der Master EmpirumServer eingetragen. Dies bitte unverändert lassen!
Unten rechts bei Gruppen Empirum Server seht ihr die vererbten Empirum Server der darüberliegenden Konfigurations- bzw. Zuweisungsgruppen. Die Reihenfolge der Verbindungsversuche wird von oben nach unten durchgeführt – dies unter Berücksichtigung der Konfiguration im Agent-Template.

Nachvollziehen / Troubleshooting

Wenn ihr schauen wollt, wie euer Client den EmpirumServer anhand eures Agent-Templates bestimmt, dann werft einen Blick in das UAF Log des Clients. Die Logs befinden sich im Verzeichnis: %ProgramData%\Matrix42\Logs\UAF. Die aktuelle Datei lautet: Matrix42.Platform.Service.Host.log. Die Logs werden je 10MB rollierend erstellt und somit kann ein Start- oder Verbindungsversuch in einer Datei mit einem Datumstempel vermerkt sein. Wenn ihr in der Datei nach der Zeichenfolge „Server Access List“ sucht, solltet ihr eine Liste angezeigt bekommen, die aus den obigen Konfigurationen und Zuweisungen resultiert. Hier könnt ihr entnehmen, in welcher Reihenfolge und mit welchen Protokollen der Client die Verbindungen versucht aufzubauen.

Sieger – Am Client könnt ihr den am Ende ausgewählten EmpirumServer mit einem Klick auf das UEM-Agent Symbol und „Info über ..“ oder der Umgebungsvariable „EmpirumServer“ angezeigt bekommen.

Der Beitrag Empirum UEM Agent – EmpirumServer Bestimmung erschien zuerst auf Workplace Management Blog.

Reboot Möglichkeiten

Fangen wir vorne an. Es gibt in der Empirum Setup.inf mindestens zwei Möglichkeiten einen Neustart aus dem Paket heraus anzufordern. Wie das Ganze dann vom Empirum UEM Agenten dann verarbeitet wird, liegt dann zusätzlich an den Agenten Einstellungen, dem Agent-Template.
In der [Application] Sektion gibt es den Paramter Reboot=[Wert von 1 bis 5] für die Anforderung eines Neustarts. Zusätzlich kann man im Verlauf der Setup.inf mit dem Befehl SetReboot [Wert] eine Reboot-Anforderung setzen.

Wo ist der Unterschied?

In der [Application] Sektion setzt man einen Wert für die Installation und Deinstallation, ganz gleich, wie der Verlauf des Paketes ist. Mit dem Befehl SetReboot wiederum kann man fallweise eine Neustart-Anforderung platzieren. Dies kann man sich z.B. bei Paketen basierend auf der MSI Vorlage ansehen. Falls sich ein MSI Paket mit einem ReturnCode 3010 beendet (erfolgreich, jedoch Neustart notwendig), dann wird in der Sektion [RebootRequired] ein SetReboot 1 ausgeführt.

Welchen Wert nutzen?

Wie oben bereits geschrieben, gibt es Werte von 0 bis 5 mit unterschiedlicher Ausprägung und Funktion. Dabei bedeutet der Wert 0 nicht, dass dieses Paket keinen Neustart benötigt, wie zumeist angenommen. Der Wert 0 steht vielmehr für den „Automatikmodus“. Kann zum Beispiel eine Datei im Paketablauf (Ablauf der Setup.inf) nicht ersetzt oder gelöscht werden, fordert beim Wert 0 das Software-Paket trotzdem einen Reboot einen, um beim Neustart, wenn die Datei nicht in Benutzung ist, zu ersetzen oder zu löschen. Möchte man einen Neustart des Paketes unterbinden, so muss man Reboot=2 setzen. Dagegen ist der Wert 1, wie man es sich schon denken konnte, eine direkte Anforderung eines Neustarts. Neben den genannten Werten, wir dann noch häufig der Wert 5 genutzt. Dieser bestimmt, dass nach der Beendigung dieses Paketes ein Neustart angefordert wird (wie bei 1), jedoch auch keine weiteren Pakete zur Ausführung kommen. Die weiteren Pakete werden dann nach dem ausgeführten Reboot durchgeführt.

Wer einen Neustart in gewisser Weise erzwingen mag, kann sich auch meinen Beitrag zum SystemShutdown anlesen.

Komplette Übersicht

Da nun die Eigenschaften für 3 und 4 unter den Tisch gefallen sind, möchte ich diese zur Vollständigkeit hier auch noch erläutern:

• 0 – startet das System nach der Installation neu, wenn ein Neustart erforderlich ist, weil z.B. Dateien überschrieben/gelöscht werden müssen, die in Benutzung sind.
• 1 – startet das System in jedem Fall neu
• 2 – startet das System nicht neu
• 3 – abmelden des Benutzers
• 4 – Herunterfahren (kein Neustart)
• 5 – nach der Installation kein weiteres Paket installiert und zwingend ein Neustart durchgeführt. Dies entspricht dem Verhalten der Option „Installation weiterer Pakete nicht fortsetzen“ in den Paketeigenschaften

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

Suchen und Ersetzen Tools

In diesem Artikel geht es um Tools zum Suchen und Ersetzen mit einer grafischen Oberfläche. Bereits im allerersten Empirum Projekt habe ich das Serach&Replace von Funduc lizenziert, da ich damals kein anderes ähnlich geartetes Tool gefunden hatte. Dieses Tool leistet mir noch heute verlässliche Dienste. Im Laufe der Zeit habe ich bei Kunden auch den Agent Ransack kennengelernt, der eine ähnliche Funktion hat. Mittlerweile zähle ich die freien Tools dnGrep und grepWin dazu. Wer das letztgenannte grepWin herunterladen möchte, wechselt am besten direkt auf github, um den Werbe- und Downloadbannern zu anderen ungewünschten Angeboten aus dem Weg zu gehen. Auch der bei vielen beliebte Editor „Notepad++“ bietet im Menü unter Search/Suchen eine Funktion zum Durchsuchen von Dateien an.

Funktionsumfang

Auf die Funktionen und Unterschiede der verschiedenen Tools, werde ich an dieser Stelle nicht eingehen. Generell bieten jedoch alle Tools, das Suchen …

• in einem definierten Pfad
• nach definierten Dateiendungen und teilweise auch in Archiven
• nach einer Zeichenkette
• Speichern des angezeigten Ergebnisses als Text oder HTML Datei

Warum Suchen und Ersetzen?

Nun, diese Tools nutze ich aus verschiedenen Gründen.

1. Durchsuchen der Empirum Pakete nach bestimmten Befehlen, Aufrufen, absoluten EmpirumServer Einträgen, Benutzern und Gruppen.
2. Durchsuchen der gesamten Empirum Partition nach bestimmten Benutzern und Gruppen in Bezug auf Verbesserung der Sicherheit
3. Das Ergebnis des Durchsuchens bildet zumeist die Grundlage für weitere Aufgaben (Anpassen, Testen, schaffen von neuen Lösungen).
4. Teilweise kann die Lösung ein Ersetzen der gefundenen Zeichenkette, durch eine neue sein.

Dein Tool der Wahl?

Welches Tool nutzt Du für diesen Zweck oder hast eine Empfehlung für die Leser des Blogs. Schreib doch Dein Suchen & Ersetzen Lieblingstool in den Kommentar. Danke, Grüße und bis bald – Jochen

Der Beitrag Suchen und Ersetzen Tools erschien zuerst auf Workplace Management Blog.

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.

Wie können wir darauf in der Softwareverteilung bzw. der Paketierung darauf reagieren?
Wie kann ich das in der Matrix42 Empirum Setup.inf handhaben?

Die harte Methode

Wenn also ein geöffnetes Programm stört, dann beenden wir es halt vor der Installation. Nehmen wir für die nächsten Beispiele an, es geht um Microsoft Visio. Man kann das in Windows enthaltene Tool TaskKill.exe nutzen und damit den Prozess beenden. In der Empirum Setup.inf würde der Befehl grob wie folgt ausschauen:
Callhidden TaskKill.exe /IM visio.exe /F
Es gibt jedoch auch einen Setup.inf eigenen Befehl:
Killprocess visio.exe
Beide haben gemeinsam, sie beenden sofort den laufenden Prozess und gehen in der Installationsabfolge weiter. Was aber, wenn der Benutzer gerade die letzten Minuten oder Stunden Änderungen in seinem Visio-Diagramm vorgenommen hat? Diese Änderungen „darf“ der Benutzer höchstwahrscheinlich mit der neuen Visio Version erneut durchführen.

Sanftere Methoden

Die sanftere Methode ist, mit dem Benutzer zu interagieren. Dies geht in der Empirum Setup.inf über den Befehl AsKillProcesses und der dazugehörigen [Processes] Sektion. In der [Processes] Sektion wird konfiguriert, bei welchem Prozess, welcher Name in der GUI angezeigt wird und wie nach dem Ablauf des Timeouts (des AskKillProcesses  Befehls) verfahren werden soll. Während des TimeOut’s hat der Benutzer die Möglichkeit die Anwendung selbsttätig zu schließen. Die Installation wird direkt nach dem Schließen durch den Anwender fortgesetzt. Reagiert der Benutzer während der Timeout Zeit nicht auf den angezeigten Dialog zum Schließen der Anwendung, bestimmt der Parameter CONTINUE oder ABORT, ob das Paket „Abgebrochen“ wird, oder die Installation fortgesetzt wird. Bei einem Abbruch wird dies auch mit der entsprechenden Meldung in der Management Console signalisiert.

[Processes]
;---beenden des Processes visio.exe nach dem Timeout (hier 300) und mit der Installation voranschreiten
VisioProc=visio.exe, Microsoft Visio, KILLPROCESS CONTINUE
;---Alternativ: KEIN beenden des Processes visio.exe nach dem Timeout (hier 300) und Abbrechen der Installation
;VisioProc=visio.exe, Microsoft Visio, KILLPROCESS ABORT

[CheckOpenProcesses]
AskKillProcesses 300, VisioProc
-AskKillProcesses 300, VisioProc

[Product]
#CheckOpenProcesses, DONTDELETE
...
#CheckOpenProcesses, DELETE

Weitere Hilfe

Man kann auch auf einen Fenstertitel reagieren und anschließend das entsprechende Fenster schließen, etc. Dies ist in der Empirum Online Hilfe ausgiebig erläutert.

Der Beitrag Dialog zum Schließen von Programmen 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.

Fehlende Treiber hinzufügen

Die Surface Tastatur funktioniert deswegen nicht, weil dem WinPE ein paar Treiber fehlen. Welche Treiber das sind, könnt ihr hier nachschlagen. Einbinden müsst ihr diese Treiber dann in der Management Console und Konfiguration\Boot Konfigurationen – Zusätzliche Treiberverzeichnisse. Wie das geht und wo ihr das findet, habe ich wiederum bereits in diesem Artikel beschrieben.

Wie komme ich an die genannten Treiber?

Jetzt liegen die Microsoft Surface Treiber jedoch als MSI Dateien vor. Wie kommt man nun an die einzelnen, oben genannten, Gerätetreiber?  Dazu ruft ihr die MSI Datei wie folgt auf:

MSIEXEC /a <Pfad und Dateiname zur heruntergeladenden Treiberdatei>.msi TARGETDIR=<Ausgabe Ordner> /qn

Beispielhafter Aufruf:
MSIEXEC /a SurfacePro8_Win10_19042_22.011.9738.0.msi TARGETDIR=C:\Temp\SurfacePro8Drivers /qn

Das Entpacken dauert einen Moment, also nicht zu ungeduldig sein.

Nebeneffekt

Das entpackte Verzeichnis könnt ihr auch für den Treiber-Import für die Windows Installation nutzen. Dazu packt ihr es jedoch am besten wieder als ZIP Datei.

Der Beitrag Surface Tastaturen während der WinPE Phase 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.

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 (454 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.

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 (322 Downloads )
SHA256 der Downloaddatei: EE118815DBD4DC80D6CBBFB9855C44C6639D08F63C0B8AE6779104176FB462A2

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

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

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