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.

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.

Was ist so anders bei Office 365?

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

Die häufigsten Fragen

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

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

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

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

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

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

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

Office 365 Updates

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

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

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

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

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

Protokollierung

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

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

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

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

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

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

Empirum OS-Installer – die drei Phasen

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

• PXE-Boot
• WinPE
• Windows

PXE Boot

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

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

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

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

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

WinPE

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

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

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

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

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

Einbinden der WinPE Treiber

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

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

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

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

Hier ein paar Beispiele:

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

Windows

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

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

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

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

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

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

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

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

UEM Agent Einführung und Funktionen

Ein Vorteil des UEM Agenten ist, das er unabhängig von der eingesetzten Empirum Version ist. So muss man nicht warten bis eine neue Empirum Version erscheint, um neue Empirum Agenten Funktionen nutzen zu können. Eine Übersicht über die Neuerungen und die jeweils aktuelle Version steht im Marketplace bereit.

UEM Agent Rollout

So sollte der Advanced Agent durch den UEM Agent ersetzt werden, wenn dies noch nicht geschehen ist. Der Rollout kann unter anderem durch die Neu-Installation des Windows 10 geschehen. Die Vielzahl der Agenten Aktualisierungen passieren jedoch im laufenden Windows Betrieb. Dies wird durch die Zuweisung des UEM Agenten per Paket erledigt.
Der Austausch des gerade laufenden Agenten ist bis zu einem gewissen Teil „Operation am Herzen“. Damit meine ich, wenn die „Operation“ fehlschlägt, verliert man mit unter Verbindung zum Endgerät und somit das Endgerät aus der aktiven Verwaltung.

Fehlerprävention

Wie sich bei den letzten Empirum Agent Updates herausgestellt hat, sollte man vor der Aktualisierung des UEM Agents sicherstellen, dass der Client über das .NET Frameworks 4.7.2 oder neuer verfügt. Dazu empfiehlt es sich das .NET Framework bereits vor dem UEM Agenten zu aktualisieren – besser noch eine Abhängigkeit des UEM Agenten auf die .NET Framework Version vorzunehmen. Diese Abhängigkeit setzt man als erweitere Bedingung im UEM Agent Paket. Wie das geht, habe ich in folgendem Artikel erklärt. Die Release Nummern des .NET Frameworks wiederum sind auf dieser Seite aufgelistet.

Fehleranalyse

Die Aktualisierung des UEM Agenten wird im nachfolgenden Log auf dem entsprechenden Endgerät aufgezeichnet: „%ProgramData%\Matrix42\Logs\UEM Agent Update\UEMAgentUpdate.log“. Hier kann man Hinweise für die fehlgeschlagene Aktualisierung finden bzw. sollte diese Datei für den Support sichern.

Möglichkeiten der Reparatur

Eine Reparatur einer gestrandeten Aktualisierung kann per Agent-Push geschehen, wenn der Computer erreichbar ist und diverse Voraussetzungen erfüllt sind. Wer es noch nicht kennt, den Agent-Push erreicht man über das Kontextmenü des Computers bzw. der Gruppe: Experte\Push Agent …
Weiterführende Informationen sind in der Matrix42 Hilfe zu finden:
Die wichtigsten Voraussetzungen habe ich bereits im Artikel „Empirum Agent Verteilung per Push“ beschrieben.

Agent Push

Möchte man mehrere Clients mit dem Agent Push erreichen, so kann man sich eine Zuweisunggruppe mit den betroffenen Systemen erstellen. Zusätzlich muss ein passendes Agent-Template zugewiesen sein und die Variable „MX42_AGENT_PUSH_PACKAGE_FOLDER“ auf die zu pushende Agent Version gesetzt sein. Um eine definierte UEM Agent Version zu installieren, ist es erforderlich, die Variable MX42_AGENT_PUSH_PACKAGE_FOLDER mit dem Pfad zur gewünschten UEM Agent Version zu belegen. Beispiel: UEM Agent Windows\2006.4

Bestimmen der Systeme …

Wenn eine Installation fehlschlägt, so verbleibt gerne die Installation des UEM Agents mit dem Status Running im SWDepot-Log. Diese fehlgeschlagenen Updates kann man mittels eines Filters in in der Rollout-Koordination oder im SWDepot-Log bestimmen. Für eine andere Art der Übersicht, habe ich einen Filter erstellt, der per Empirum DBUtil erstellt werden kann. Dieser Filter enthält alle Computer, die einen „Install“ Eintrag zum „UEM Agent“ mit dem Status „Running“ haben. Falls es nachfolgende erfolgreiche Installationen gibt, so sind diese derzeit trotzdem in diesem Filter enthalten. Dieser Filter kann also „false positive“ Ergebnisse beinhalten.

Dazu die angehängte Datei entpacken und über die Empirum Struktur kopieren. Nachdem das SQL Script „SW_UEM-Agent_Install_Running“ aus dem Unterordner Custom über Empirum DBUtil ausgeführt wurde, steht der Filter in der Management Console zur Verfügung.

Download

SW_UEM-Agent_Install_Running (584 Downloads )
MD5 Hash der Downloaddatei: B27EAA30786436633DBB1AB63409353F

Der Beitrag UEM Agent Rollout erschien zuerst auf Workplace Management Blog.

Die nachfolgende Auflistung enthält zumeist eine Kurzbeschreibung, den Registry Wert in der .reg und Setup.inf Syntax und einen möglichen Quellenverweis.
Falls Ihr noch Werte kennt, die hier fehlen, so nutzt bitte die Kommentarfunktion oder schickt mir eine E-Mail.

Danke und Grüße – Jochen

Prüfung auf ausstehenden Windows Reboot verhindern

In der Registry kann festgelegt werden, dass der Agent die Überprüfung ausstehender Windows Reboots (z.B. vorhandene Pending.xml) nicht durchführt und anstehende Software Management-Aktionen durchführt. Die Prüfung kann durch Setzen des Registry Wertes WindowsUpdateRebootCheck unter dem Schlüssel HKLM,Software\Matrix42\Agent auf 0 deaktiviert werden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“WindowsUpdateRebootCheck“,0x00010001,0

Weiterführende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2017/Matrix42_Empirum_17.0_New_Features_and_Changes_DE.pdf

Erweiterungen zur Neustart Steuerung (UEM Agent 2009.x und neuer)
Der Wert „2“ ist der neue „Standard“, wie wenn kein Wert gesetzt ist. Nach einer Verzögerung erscheint ein UEM Agent Fenster, das den Benutzer zu einem Neustart auffordert. Wem dieses Verhalten nicht gefällt, kann den Wert auf „1“ setzen, welches dem alten Standard entspricht (keine UEM Agent Aktivitäten bis ein Neustart durch den Anwender durchgeführt wurde).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootCheck“=dword:00000002

Das „neue“ Reboot-Verhalten wird verzögert initiiert. Wer möchte kann den Verzögerungswert (in Sekunden) anpassen. Wenn kein Wert gesetzt ist, ist der Standardwert 15 Minuten (900 Sekunden).

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„WindowsUpdateRebootDelaySeconds“=dword:00000120

Weiterführende Informationen: https://marketplace.matrix42.com/details/uem-agent-windows-release/

Getaktete Verbindung erkennen (ab UEM Agent 1808)

Der UEM Agent Windows erkennt eine getaktete Verbindung und schreibt am Anfang des Pollings einen Registry Schlüssel:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
“ NetworkCostType“ (DWORD) = Wert der Microsoft API
Mögliche Werte:
0 – Unknown: Cost information is not available.
1 – Unrestricted: The connection is unlimited and has unrestricted usage charges and capacity constraints.
2 – Fixed: The use of this connection is unrestricted up to a specific limit.
3 – Variable: The connection is costed on a per-byte basis.

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Globaler Silent Level (UEM Agent)

Alle zu installierenden Software-Pakete werden mit einem Silent Wert ausgeführt. Es greifen keine paketspezifischen Werte aus dem Feld „Befehl“ der Paketeigenschaft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„GlobalSilentLevel“=dword:00000004
Einschränkungen aktuell: Pakete, die eine Eingabe erfordern, funktionieren nicht mit dem Modus “0” und “1”.
Wenn der Eintrag (GlobalSilentLevel) nicht vorhanden ist, funktioniert es wie unter dem Advanced Agent und die individuellen Paket Parameter werden angezogen.

HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“,0x00010001,4
oder
-HKLM,“SOFTWARE\Matrix42\Agent“,“GlobalSilentLevel“

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

InstallAtShutdown – Shutdown nach der OS Installation (UEM Agent)

Wenn der untenstehende Registry Key auf 1 steht, dann ist der „InstallAtShutdown“ Modus für den Agent aktiv.
Der Wert kann jedoch auch gezielt gesetzt werden, um die Funktionalität zu nutzen.
Dieser Wert kann beispielsweise in der UEMAgent.bat gesetzt werden um den Computer nach der OS Installation komplett auszuschalten.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„InstallAtShutdown“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“InstallAtShutdown“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Ausblenden der Option Installation beim Herunterfahren (UEM Agent)

Die Funktion „Installation beim Herunterfahren“ kann für Anwender verborgen werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„AllowPostponeUntilShutdown „=dword:00000000

HKLM,“SOFTWARE\Matrix42\Agent“,“AllowPostponeUntilShutdown“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Suspend Modus (UEM Agent)

Mit einem Registry-Key kann der UEM Agent in einen Modus versetzt werden, in dem
keinerlei Polling-, Download- oder Installationsaktionen durchgeführt werden. Intern wird
dieser Modus für den Auto Update verwendet. Bei Bedarf kann man diesen Modus
beispielsweise verwenden um beim Aufbau einer VPN-Verbindung über ein Satellitentelefon
den möglichen Datenverbrauch des Agent zu unterbinden.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Suspenduntil“ (Typ: STRING) = Endedatum des Suspendmodes
Der Wert gibt den Termin zur Beendigung des Suspendmode an. Beispielsweise 2018-12-
24T18:00. Jeder angegebene Wert, der nicht vom Agent als ISO Zeit-Wert in der
Vergangenheit erkannt wird, wird den Agent pausieren

Paket Validierung

Validierung von Paketen für UEM Agent aktivieren (UEM Agent 1903)
Um die Validierung von Software Paketen auf Client-Seite zu aktivieren setzten Sie „CheckPackageHash“ als DWORD auf einen Wert größer 0 in der Registry.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„CheckPackageHash“=dword:00000001

HKLM,“SOFTWARE\Matrix42\Agent“,“CheckPackageHash“,0x00010001,1

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

Behandeln von fehlerhaften Paket Validierungen

Stellt die Paketvalidierung einen Unterschied der Hashwerte auf dem Server zu dem auf dem Client fest, wird für dieses Paket der Zähler FailedInstallationRetries hochgezählt.
Dieses Verhalten lässt sich mit dem Schlüssel CountHashValidationErrors als DWORD gezielt steuern. Existiert der Eintrag nicht oder besitzt einen Wert ungleich „1“, so wird der Zähler nicht hochgezählt (Standard). Existiert der Eintrag und hat den Wert „1“, so wird der FailedInstallationRetries Zähler hochgezählt.

HKLM,“SOFTWARE\Matrix42\Agent“,“CountHashValidationErrors“,0x00010001,1

Feedback URL ausschalten/anpassen (UEM Agent)

Die Anzeige des Icons und der Link zum Matrix42 Feedback Portal ausschalten.
Wenn man eine URL angibt, kann man auf ein eigenes Portal bzw. Internetseite verzweigen.
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„Feedback_URL“=““

HKLM,“SOFTWARE\Matrix42\Agent“,“Feedback_URL“,0x00000000,““

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2019/Matrix42_UEM_Agent_Windows_DE.pdf

UEM Agent Autoupdate Zeitraum beeinflussen (ab UEM Agent 1811)

Wenn man die UEM Agent Autoupdate Funktion nutzt, so kann man den Zeitraum des automatischen Updates beeinflussen.
Dazu gibt es zwei Einträge, die eine Angabe von Minuten (Typ: DWORD) annehmen.

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\Agent]
„MinAutoUpdateDelayAfterSystemStart“=dword:00000015
„MaxAutoUpdateDelayAfterProcessStart“=dword:00000030

HKLM,“SOFTWARE\Matrix42\Agent“,“MinAutoUpdateDelayAfterSystemStart“,0x00010001,15
HKLM,“SOFTWARE\Matrix42\Agent“,“MaxAutoUpdateDelayAfterProcessStart“,0x00010001,30

Anpassen der Berechtigungen auf den Agent Cache

Um eine größtmögliche Sicherheit zu gewährleisten setzten der Advanced und der UEM Agent die lokalen NTFS Berechtigungen bei jedem Start des Agent nach den Matrix42 Vorgaben auf den Empirum Agent Cache (zumeist C:\EmpirumAgent). Um Kunden spezielle Szenarien zu ermöglichen kann dieses Verhalten mit einem Registry-Wert unterbunden werden, wenn beispielsweise der lokale Benutzer Zugriff auf Dateien im Cache-Verzeichnis benötigt.
Registry Schlüssel „HKLM\SOFTWARE\Matrix42\Agent,SetNTFSCacheRights“, 0 = Keine Anpassung der NTFS Rechte, 1 oder nicht vorhanden (Standard) = Anpassung der NTFS Rechte, 2 = Der Agent setzt die Standard Zugriffsrechte, jedoch keine Zugriffsrechte für „Jeder“ auf das „User“-Verzeichnis (ab UEM-Agent SFR 2011.1.2 )

HKLM,“SOFTWARE\Matrix42\Agent“,“SetNTFSCacheRights“,0x00010001,0

Weitergehende Informationen: https://helpfiles.matrix42-web.de/EXT/UEM_2018/Matrix42_Empirum_18.0_Update2_New_Features_and_Changes_DE.pdf

Prüfung auf Scriptdateien für Kiosk Pakete

Ab dem UEM Agent 2009.1.2 findet für Pakete im Kiosk keine Prüfung auf Existenz der Scriptdateien auf dem Server statt. Dies führt auf den Depotservern zu einer deutlichen Lastreduzierung, insbesondere bei Verwendung von http(s). Die Prüfung der Scriptdateien auf dem Depotserver kann über folgenden Registry Key wieder aktiviert werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„UseCheckFileForKiosk“=dword:00000001

Zurücksetzen der fehlgeschlagenen Installationen

Die Anzahl der auf dem Computer fehlgeschlagenen Softwareinstallationen werden unter dem Registry Baum „HKLM\SOFTWARE\Matrix42\Agent\software“ abgelegt.
Diese Pakete werden beim Erreichen des jeweiligen Maximalwertes nicht erneut ausgeführt. Damit die Pakete erneut ausgeführt werden, muss man entweder das Paket auf dem entsprechenden Computer „reinstallieren“, oder den Wert im Agent-Template erhöhen – das gilt dann jedoch für alle fehlgeschlagenen Installationen. Wenn man den Computer „zwingen“ möchte, die Ausführung der Installation aller fehlgeschlagenen Pakete nochmals zu starten, kann man alternativ den nachfolgend genannten Registry-Baum löschen.
Es besteht die Möglichkeit das per Paket, oder auch als externes Programm in der Management Console (erforderliche Rechte vorausgesetzt), einzubinden.

Beispiel für einen Eintrag in einem Software Paket:
-HKLM,“SOFTWARE\Matrix42\Agent\software“

Beispiel für einen externen Aufruf:
reg delete \\%Computername%\HKLM\SOFTWARE\Matrix42\Agent\software /f

Verhalten bei Problemen beim Paket-Download (ab UEM Agent 2203.1.2 SFR)

Sollte es beim Herunterladen eines Paketes zu Problemen kommen (z. B. temporäre Netzwerkfehler, Zugriffsprobleme), dann kann der Agent veranlassen, dass der Vorgang automatisch wiederholt werden soll. Hierfür kann man die Anzahl der erneuten Versuche (Standard: 5) sowie die Pause zwischen den Versuchen in Sekunden (Standard: 60) einstellen. Der Standard kann in der Registry überschrieben werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Matrix42\AGENT]
„RetryTransferRepetitionLimit“=dword:00000005
„RetryTransferPause“=dword:00000060

Weitergehende Informationen: https://m42marketplacemediathek.blob.core.windows.net/matrix42-ag-pub/2022/03/Matrix42-UEM-Agent-Windows-2203_1_2-SFR-EN.pdf

Der Beitrag Empirum Agent Steuerung per Registry erschien zuerst auf Workplace Management Blog.

Wo findet man das aktuelle Windows ADK / WADK?

Eine Einstiegsseite mit den passenden und verfügbaren ADKs gibt es hier.

Welche Funktionen des WADK muss ich im Zusammenhang mit Empirum installieren?

Auf dem EmpirumServer sind mindestens die Bereitstellungstools und die Vorinstallationsumgebung (Windows PE) zu installieren.

Empirum PreInstallation Environment (EPE) Boot (Linux)

Wer das EPE zum Starten einer OS-Installation nutzt, muss zusätzlich das WADK in Empirum importieren. Dazu ist es ausreichend das WADK des zur verteilenden Windows 8/10 zu importieren (x64/x86). Die Windows PE Dateien werden nach dem Import unterhalb von Empirum\EmpInst\SYS\WinPE abgelegt.

WinPE Boot

Wer sich bereits mit dem WinPE Boot von Empirum auseinandersetzt, muss das WADK nicht importieren, jedoch eine Bootkonfiguration (EMC\Konfiguration\Boot Konfigurationen) mit Hilfe der WinPE Quellen erstellen. Dieser Vorgang greift dann auf das zur lokal auf dem EmpirumServer installierte WADK / Windows PE zurück.

Der Beitrag Empirum und Windows 10 WADK erschien zuerst auf Workplace Management Blog.

Es gibt jedoch Besonderheiten bei diesem Befehl. Die For … Next Schleife wird beim Install als auch beim Uninstall ausgeführt und benötigt kein „-„. Beim Uninstall zählt die For Schleife jedoch „umgekehrt“. Dies ist in der Hilfe so nicht näher erläutert. Anbei findet Ihr die Erläuterung aus der Matrix42 Hilfe, als auch ein Empirum Setup.inf Ausschnitt mit zwei Beispielen.

Auszug aus der Online Hilfe

For <Var>,<LB>,<UB>,<Inc>,<Abschnitt>

Führt eine FOR-Schleife aus. Die Zählvariable ist <Var> wird von der Untergrenze <LB> zur Obergrenze <UB> in <Inc> Schritten hoch gezählt. Jedes Mal wird der Abschnitt <Abschnitt> aufgerufen. Die Zahlen dürfen auch negativ sein sowie Ober- und Untergrenze vertauscht werden (Abwärtsschleife). Wird <Inc> leer gelassen, wird 1 bzw. -1 angenommen.

Beispiel: For Counter,1,3,,UpSection

Setup.inf Beispiel

[Environment]
VALUE1=Hello
VALUE2=World
VALUE3=!

[Product]
#Set:Installation, DONTDELETE
#Set:Deinstallation, DELETE

[SET:Installation]
FOR counter,1,5,,ECHOCounter
FOR counter,1,3,,ECHOValues

[ECHOCounter]
ECHO Installation : %Counter%
-ECHO DeInstallation : %Counter%

[ECHOValues]
SET EchoVALUE=%%Value%Counter%%%
ReplaceEnv EchoValue
ECHO %EchoValue%

[SET:Deinstallation]
;--This counts from 5 to 1 during UNINSTALL!
FOR counter,1,5,,ECHOCounter
-ECHO FOR counter,1,5,,ECHOCounter

;--This counts from 1 to 5 during UNINSTALL!
FOR counter,5,1,-1,ECHOCounter
-ECHO FOR counter,5,1,-1,ECHOCounter

Der Beitrag Empirum und For – Next Schleife erschien zuerst auf Workplace Management Blog.

Windows 10

Seit nun fast einem Monat ist Windows 10 offiziell freigegeben. Ich hatte bereits einen Artikel veröffentlicht, wie man mit Empirum Windows 10 Technical Preview verteilen kann. Noch vor der eigentlichen Veröffentlichung durch Microsoft hat Matrix42 bereits mit dem Update 1 für die Empirum Version 16 die Unterstützung für Windows 10 bekanntgegeben.

Empirum V16 Update 1

Das Update 1 für Empirum V16 wird auch Windows 10 Feature Pack genannt. Diese Version enthält bereits in allen Modulen die Unterstützung von Windows 10.

Windows 10 LTSB

Da sich Microsoft lange mit den LTSB Versionen zurückgehalten hat, sind diese SKUs noch nicht im Update 1 enthalten. Die Einbindung und Verteilung funktioniert trotz alledem. Hier muss man sich ggf. dem Trick mit der ImageInfo.ini bedienen, den ich im oben genannten Artikel bereits eingeführt habe. Dazu muss eine INI Datei mit dem Namen ImageInfo.ini bei den Betriebssystemquellen, im Verzeichnis (Empirum\EmpInst\SYS\Win10\<ServicePack>_{GUID}\<Sprache>) in dem auch die unattend.xml abgelegt ist, erstellt werden. Diese ImageInfo.ini sieht beispielhaft wie folgt aus:

[ImageInfo]
SKU=Windows 10 Enterprise 2015 LTSB

Diese ImageInfo.ini Datei wird, wenn vorhanden, von der end_winvista.eis Anpassung ausgelesen. Da sich jedoch die Variablen ab der Version 16 etwas geändert haben, muss hier in der end_winvista.eis eine Anpassung, gegenüber dem Artikel zur Empirum Version 15.1.9, vorgenommen werden. Die Anpassungen stehen unten auch zum Download bereit.

; ----------------------------------------------------------------------------
;SKU Override for non supported OS Versions
; ----------------------------------------------------------------------------
IFEXIST %E%%SysPath%\ImageInfo.ini THEN
READINI %E%%SysPath%\ImageInfo.ini ImageInfo SKU valueSKU 
IF "%valueSKU%"<>"" THEN
§ECHO_MSG="10 Custom script: end_winvista-[SKU Override] executed - ImageInfo.ini SKU value found"
GOSUB LINUX_ECHO

§SKU_LONG="%valueSKU%"
XMLSET %XMLWinPEPath%ImageInstall/OSImage/InstallFrom/MetaData[wcm:action="add"]/Key="/IMAGE/NAME"
XMLSET %XMLWinPEPath%ImageInstall/OSImage/InstallFrom/MetaData[wcm:action="add"]/Value="%SKU_LONG%"
§ECHO_MSG="10 Custom script: end_winvista-[SKU Override] SKU changed to: %SKU_LONG%"
GOSUB LINUX_ECHO
ENDIF
ENDIF
; ----------------------------------------------------------------------------

Windows 10 Treiberablage in Empirum

Wer die Release Notes zum Update 1 sorgfältig gelesen hat, hat festgestellt, dass die Windows 10 Treiber vorerst in der Windows 8 Struktur abgelegt werden. Dies sollte für den Großteil der Empirum Nutzer, die direkt von Windows 7 in Richtung 10 schielen kein Problem darstellen. Wenn man die Treibereinbindung über die Hardwareprofilverzeichnisse vornimmt, wie ich das in meinen anderen Artikel Empirum Treiberintegration – einfacher gemacht! erläutert habe, so kann man sich die Windows 10 Treiberstruktur auch analog zu den vorhandenen Treiberstrukturen befüllen. Die Einbindung der Treiber über die Empirum Management Console in die Win10 Verzeichnisstruktur wird von mir, als auch derzeit der Matrix42, nicht unterstützt!

Auch diese Anpassung geschieht über die end_winvista.eis.

Ich habe eine exemplarische und funktionierende end_winvista.eis Datei zum Download angehängt. Diese Datei funktioniert ab Empirum Version 16 und mit den Windows 10 Verzeichnissen und enthält somit beide oben genannten Anpassungen. Wenn man in der end_winvista.eis noch mehr Anpassungen durchgeführt hat, so sind die Änderungen zusammenzuführen.

Hier geht es zum Download:  end_winvista.eis.v16.0.1 (1960 Downloads )

Der Beitrag Mit Empirum Windows 10 verteilen erschien zuerst auf Workplace Management Blog.

Wo wird die Anpassung vorgenommen?

Die Anpassung dieser Anzeige geschieht über ein Custom EIS Skript. Alle Custom EIS Skripte, also die Empirum Installer Skripte die man als Kunde anpassen darf, liegen im Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\Scripts2\Custom. In diesem Falle ist die showosinfo.eis die passende Datei für die Anzeige von Informationen betreffend der Betriebssysteminstallation.

Inhalte

Im Anhang befindet sich die von mir angepasste Version. Hier kann auch jeder selbst für sich entscheiden, welche Informationen er gerne dabei hätte oder welche nicht. Der Aufbau und die Quelle der Informationen sollte leicht zu verstehen sein. Somit könnt Ihr die Informationen zusätzlich zur Anzeige bringen, die euch interessieren. Das müssen ja nicht alle Werte sein, die in der zum Download angebotenen Datei sind. Die Syntax und weiteres zur EIS Skript Anpassung findet ihr unter OS Installer EIS Dokumentation in der Empirum Hilfe.

Fertige Datei

Eine fertige showosinfo.eis findet ihr hier zum Download: showosinfo.eis (1439 Downloads )

Im ersten Schritt solltet ihr eine Sicherungskopie der vorhandenen Datei vornehmen! Im Anschluß daran die angepasste showosinfo.eis Datei in das oben genannte Verzeichnis ablegen bzw. den Inhalt ersetzen. Falls ihr SubDepots im Einsatz habt, so müsst ihr die Datei noch an alle Standorte synchronisieren. Dann sollte bei der nächsten OS Installation das PXE-Log ein paar Zeilen mehr haben – die mit euren Änderungen!

Viel Spaß und gutes Gelingen!
Jochen

Der Beitrag Empirum PXE Log Anzeige erschien zuerst auf Workplace Management Blog.