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.

Was können Probleme bei der WindowsInstallation und danach sein?

WindowsInstallation Paket

Falls es zu Problemen bei der Ausführung des WindowsInstallation Paketes kommt, sollte man prüfen, ob ein Betriebssystemimport zugewiesen ist, oder der Computer in den Eigenschaften mit einer statischen IP-Adresse versehen ist.

DomainJoin

Bei Fehlern, die während des DomainJoin Paketes auftauchen, hilft ein Blick in das Log unter WinPEStatus. Häufig liegt es jedoch mit dem für den DomainJoin verwendeten Benutzer zusammen. Entweder hat er gar keine oder nicht die erforderlichen Berechtigungen, das Computerkonto zu erstellen oder ein bestehendes zu verändern. Testweise kann man das, vielleicht bereits vorhandene, Computerobjekt in der Domäne vor einer Installation löschen.

EmpirumAgentSetup

Das Paket wurde gerade in den aktuellen Versionen (2.8/2.9) der Empirum WinPE Erweiterung 1.9.0 (und neuer) wesentlich robuster aufgestellt. Falls es bei diesem Paket zu Problemen kommt, dann sollte man einen Blick auf die Variable „MX42_AGENT_PUSH_PACKAGE_FOLDER“ (Windows) legen. Ist die hier angegebene Version auf dem EmpirumServer bzw. dem zuständigen SubDepot unter „Empirum\Configurator\Packages\Matrix42\UEM Agent Windows“ abgelegt?

Keine Software-Installation nach der OS-Installation

Findet nach der OS-Installation keine Software-Installation statt, dann wurde in den meisten Fällen in den Eigenschaften des Computers bei Domäne der FQDN der Domäne anstatt der NetBIOS Name der Domäne angegeben. Wenn dies der Fall ist und angepasst wurde, reicht eine Aktivierung der Software (keine komplette Neu-Installation per PXE) aus. Zur Sicherheit startet man den Client-Computer einmal neu, damit er nach dem Neustart auf ausstehende Software-Installationen prüft.

Der Beitrag WinPE Installation und Troubleshooting 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.

Variablen

Nachfolgend sollten die meistgenutzten Variablen aufgeführt sein. Falls ihr eine Variable häufig nutzt, die hier nicht aufgeführt ist, so lasst es mich wissen.

Beispiele

Del "%CommonDesktop%\WinSCP.lnk"

Del "%CommonPrograms%\TotalCommander Repair und Uninstall.lnk"

Deltree "%ProgramFiles%\WinSCP"

Callhidden %ComSpec% /C Echo %%date%% %%time%% [Set:Product] Install or repair >>"%App%\Debug.log"

Copy "%Src%\filezilla.xml" "%App%\FileZilla.xml"

Copy "%App%\filezilla.xml" "%AppData%\FileZilla\FileZilla.xml"

Der Beitrag Empirum Setup.inf – Variablen 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.

Was wurde geändert?

Die ausführende Datei wurde aus dem C:\Windows\Empirum Verzeichnis passender nach C:\Programme\Matrix42\Personal Backup verschoben. Die Konfigurationsdateien werden nun im Verzeichnis C:\ProgramData\Matrix42\PBackup abgelegt und bei der Nutzung herangezogen. „Früher“, also vor der Änderung, wurden die Konfigurationsdateien direkt vom EmpirumServer herangezogen.

Warum wurde das geändert?

Die Programmdateien im Programme Verzeichnis abzulegen ist eine Korrektur, die schon lange hätte vollzogen werden können. Viel entscheidender ist die Ablage der Konfigurations- und Hilfsdateien in C:\ProgramData\Matrix42\PBackup.
Damit kann Personal Backup „standardmäßig“ genutzt werden und die Sicherheit von Empirum erhöht konfiguriert werden.
Stichworte sind hier die Absicherung des allgemeinen Zugriffes auf das lokalen EmpirumAgent\User und das zentrale Configurator\User Verzeichnis. Hier kann man nun soweit gehen, dass nur noch der EmpirumAgent Benutzer auf die beiden genannten Verzeichnisse zugreifen kann. Vielen Dank dafür Matrix42.

Der Beitrag Personal Backup – Breaking Changes 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.

Wie ist die Syntax zur Erstellung einer Verknüpfung?

Die Syntax bzw. Abfolge der Angaben ist wie folgt.

<Verknüpfung>, <Kommando>, <Argumente>, <Arbeitsverzeichnis>, <Beschreibung>, <Symboldatei>, <Symbolindex>, <Fensterzustand>, <Tastenkombination>

Es müssen nicht alle Angaben gesetzt werden, wie die nachfolgenden Beispiele zeigen.

Beispiele:

;---Erstellung einer einfachen Verknüpfung auf dem Desktop abhängig von CommonShellLinks
%Desktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer einfachen Verknüpfung auf dem Desktop aller Benutzer unabhängig von CommonShellLinks
%CommonDesktop%\Internet Explorer, %ProgramFiles%\Internet Explorer\iexplore.exe

;---Erstellung einer Verknüpfung auf dem Desktop aller Benutzer
%CommonDesktop%\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü abhängig von CommonShellLinks
ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

;---Erstellung einer Verknüpfung ServicePortal im Startmenü Ordner "MyComany" unabhängig von CommonShellLinks
%CommonPrograms%\MyCompany\ServicePortal, %ProgramFiles%\Internet Explorer\iexplore.exe, https://serviceportal.company.de/wm, Company ServicePortal

Besonderheiten

Die mittels Shell:Product erstellen Verknüpfungen werden beim Deinstallieren auch wieder entfernt. Möchte man beim Installieren Verknüpfungen entfernen, so geht das nur über den Del bzw. Deltree Befehl.

Beispiele:

;---löschen des Startmenü Ordners MyComany
Deltree "%CommonPrograms%\MyCompany"

;---löschen einer Verknüpfung vom Desktop aller Benutzer
Del "%CommonDesktop%\ServicePortal.lnk"

;---löschen einer Verknüpfung vom Desktop des jeweiligen angemeldeten Benutzers - Achtung: Das Paket muss mit /AW ausgeführt werden.
Del "%UserDesktop%\ServicePortal.lnk"

Abhängigkeiten

Die Shell:Product Ausführung ist von mindestens zwei Eigenschaften in der Application Sektion abhängig

CommonShellLinks=[1|0]
Wenn CommonShellLinks den Wert 1 hat, so ist die Variable %Desktop% gleichzusetzen mit %CommonDesktop%, genauso wie %Programs% mit %CommonPrograms%.
Ist der Wert 0, so ist %Desktop% gleichzusetzen mit %UserDesktop% und %Programs% mit %UserPrograms%.

ShellLinks=[0|1]
Ist der Wert 1, werden die Verknüpfungen erst am Ende der Installation, für jede Option der Abschnitt [Shell:<Option>], automatsich erzeugt ohne explizit aufgerufen zu werden. Ist der Wert 0, können Verknüpfungen auch durch den direkten Aufruf von #Shell:<Option> erstellt werden.

Der Beitrag Verknüpfungen / Links erstellen erschien zuerst auf Workplace Management Blog.

Los geht’s!

WADK

Eine Installation des WADK auf dem EmpirumServer ist eine Voraussetzung zur Erstellung der WinPE PXE-Images. Dazu habe ich bereits zwei Artikel geschrieben, die die Hintergründe und die Bereitstellung erläutern:

• Empirum: WinPE anstatt EPE als PXE-Image
• Microsoft WADK / WinPE Versionen

Matrix42 WinPE Erweiterung

Mit jeder neuen Empirum Version kommt auch ein Stand des WinPE PreBoot Supports in das Empirum System. Die PreBoot Support Entwicklung ist jedoch nahezu völlig von der Empirum Entwicklung entkoppelt. Man kann den jeweils aktuellsten WinPE PreBoot Support mit einer noch unterstützen Empirum Version einsetzen. Den aktuellen WinPE PreBoot Support gibt es im Matrix42 Marketplace zum Download.

Der WinPE PreBoot Support, der derzeit als EXE angeboten wird, entpackt, mit einem Doppelklick, im gleichen Ordner eine Empirum Struktur. Falls man in diesem Ordner in der Vergangenheit bereits einen WinPE PreBoot Support entpackt hat, sollte man das vorhandene Empirum Verzeichnis löschen. Nur zur Sicherheit: Nicht das produktiv genutzte Empirum Verzeichnis löschen! Alternativ kann man auch ein Komprimierungsprogramm (7-zip) nutzen, um es in einen Ordner des EXE Namens zu entpacken.

Die entpackte Struktur wird dann über die vorhandene produktive Empirum Struktur kopiert und bestehende Dateien werden ersetzt.
Laut Matrix42 wird ein Backup der produktiven Empirum Struktur empfohlen. Soweit bin ich bis dato noch nicht gegangen. Meines Erachtens vorteilhaft kann jedoch eine Sicherung des nachfolgenden Ordners sein: Empirum\EmpInst\Sys\Images\WinPE sein. Im zuvor angegebenen Ordner liegen die Matrix42 Quellen zur Erstellung des Empirum WinPE PXE-Images.

Konfiguration WinPE PXE-Image

Dazu wechselt man in der Management Console in den Bereich „Konfiguration\Boot Konfigurationen“. Mit einem Klick auf das „+ Neu“ (unten links) beginnt man mit der Erstellung eines neuen PXE-Images.

Dem PXE-Image gibt man einen Namen – der Dialog weißt einen schon darauf hin, welche Zeichen und Buchstaben erlaubt sind.
In der Beschreibung kann man für sich die Grundlage des WinPE PXE-Images festhalten.
Der Konfigurationstyp ist in diesem Fall natürlich: WinPE.

Die Auswahl des Agent-Templates hat folgende Funktion:
Aus dem Agent-Template werden die Informationen bzgl. des EmpirumAgent Benutzernamens, des Ausfall-Servers und ob DHCP Optionen genutzt. Diese Informationen werden vom erstellten PXE-Image genutzt, um während der Ausführung des WinPE die Verbindung zum EmpirumServer herzustellen.

Ab einem Hotfix für die Empirum Version 19.0.1 werden standardmäßig die „erweiterten Eigenschaften“ zur Erstellung ausgeblendet.

Mit der TFTP Blockgröße kann man „spielen“, um die Übertragung des WinPE zu beschleunigen bzw. auf Stabilität zu trimmen.

Zusätzliche Treiberverzeichnisse
Unter „Zusätzliche Treiberverzeichnisse“ gibt man eine Quelle für Treiber an, die in das WinPE eingebunden werden sollen.

• Das sind nicht alle Treiber die später für das zu installierende Windows genutzt werden:
• Zumeist werden hier Netzwerkkartentreiber für das WinPE auf Windows 10 Basis benötigt, damit das WinPE PXE-Image eine Verbindung zum EmpirumServer herstellen kann.
• Bis dato war nur einmal ein Storage Treiber notwendig – damit verfährt man jedoch in gleicher Weise.
• Ich nutze in der Abbildung ein selbst erstelltes Verzeichnis, was separat vom vorhandenen DRV Ordner liegt, da dies meines Erachtens in absehbarer Zeit überflüssig wird.
• Es werden alle Treiber, die in diesem Ordner und auch Unterordner liegen, in das WinPE eingebunden.
• Idealerweise generiert man im angegebenen Ordner Unterordner mit den Namen der Modelle oder Netzwerkkarten.

Erstellung PXE-Image

Bei der Erstellung des WinPE PXE-Images, mit Klick auf Speichern (unten rechts), werden dann die …

• Windows PE Quellen (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment)
• Matrix42 WinPE Erweiterung (Empirum\EmpInst\Sys\Images\WinPE)
• angegebene „Zusätzliche Treiberverzeichnisse“
• mit Hilfe des Skriptes (CreatePXEWinPEMultiPlatform.ps1)

zu einem PXE-Image zusammengeführt.

Status der Erstellung

Die Erstellung dauert ca. 15-20 Minuten. Den Status der Erstellung kann man am Symbol bei der Konfigurationsübersicht (oben links) oder unter Management im Menü „Info“ unter „Back-end tasks …“ einsehen.

In der Konfigurationsübersicht gibt es die:

• Sanduhr – warten das der BTQHx64 Dienst es verarbeitet
• Zahnräder – der BTQHx64 Dienst ist dabei, Dauer ca. 15-20min
• grüner Haken – erfolgreich erstellt
• rotes Kreuz – Fehler bei der Erstellung

Fertig!

Die erfolgreiche Fertigstellung kann, wie zuvor beschrieben, an mehreren Stellen eingesehen werden. Hier ein Auszug aus dem Back-end task Log:

Für technisch Interessierte: Das erstelle PXE-Image ist anschließend unter „Empirum\EmpInst\Wizard\Image\VirtualRoots\BootEnvironment\<PXE-ID>“ zu finden.

Einmalige Einrichtung ist getan. Was nun?

Wenn man sich für eine neue WinPE Erweiterung (siehe oben) entscheidet, muss das PXE-Image neu erstellt werden, da die neuen WinPE PreOS Packages zumeist auch auf Neuerungen im Empirum WinPE zurückgreifen. Ob man dazu eine neue Konfiguration erstellt, oder nur die vorhandene mittels „Speichern“ mit den neuen Quellen aktualisiert, muss man selbst entscheiden. Benötigt das vorhandene PXE-Image aufgrund einer noch nicht getesteten oder neuen Hardware einen zusätzlichen Netzwerkkartentreiber, so legt man den Treiber im oben genannten Ordner („Zusätzliche Treiberverzeichnisse“) ab und generiert durch „Speichern“ das PXE-Image neu.

Fehler bei der Erstellung …

Bei Fehlern bei der Erstellung kann man entweder in die Back-end task Verarbeitung schauen, oder direkt in das aktuelle Log des BTQHx64 Dienstes auf dem EmpirumServer unter
%ProgramData%\Matrix42\Logs\BackendTaskQueueHost64.

Der Beitrag Empirum WinPE – PXE-Image Erstellung erschien zuerst auf Workplace Management Blog.