Reinstall Abbrechen – eine Gruppe

Wie bekommt man diese Reinstall-Untergruppe jedoch wieder entfernt, wenn die Reinstallation nicht mehr erfolgreich durchgeführt wird?  Natürlich ist es der beste Weg, wenn das Paket eine erfolgreiche Reinstallation durchführen kann. Falls nicht, kann man mit der rechten Maustaste auf die erstellte Gruppe „Reinstall“ gehen und „Abbrechen“ auswählen. Anschließend ist wieder alles wie zuvor.

Reinstall Abbrechen – mehrere Gruppen

Wie bekommt man jedoch mehrere Reinstall Gruppen entfernt? Muss man nun auf alle Gruppen einzeln den zuvor genannten Vorgang durchführen? Nein. Man kann auf die übergeordnete Gruppe die Aktion „Deaktivieren, Softwareverteilung, Entfernen der Software …“ durchführen und anschließend die Gruppe erneut aktivieren für Softwareinstallationen. Mit diesem Vorgang kann man mehrere Reinstall Gruppen in wenigen Schritten auflösen.

Schritt 1: Auswählen der Gruppe – Deaktivieren

Schritt 2: Softwareverteilung – Entfernen der Software aus der Konfigurationsdatei (DDC)

Schritt 3: Erneutes „Aktivieren“ der Gruppe für Softwareinstallationen

Der Beitrag Empirum – Reinstall Abbrechen erschien zuerst auf Workplace Management Blog.

Was ist das Problem?

Die Installation des WinPE Paketes „LanguagePacksInstallation“ läuft erfolgreich durch, jedoch befindet sich das LanguagePack anschließend nicht im installierten Windows.

Ergänzender Hinweis

Es gibt für Windows 10 1909 keine separaten LanguagePack Quellen. Das Build 1909 nutzt die gleichen Quellen wie das Build 1903. Das bezieht sich auch, wie ich schon festgestellt habe, auf das WADK – auch hier wird auf die Version 1903 verwiesen.

Lösungsvorschläge

Nun aber zu den Lösungsvorschlägen. Diese sind im Original auch in den Kommentaren zu nachzulesen. Da die Formatierung der Kommentare nur eingeschränkt ist, habe ich es hier nochmals zusammengefasst.

Zwei Lösungsmöglichkeiten

Es gibt zwei von Ingo getestete Lösungsvorschläge.

• Die Windows 10 Build 1909 Quellen auf einen neueren Stand bringen, der die Installation wieder erlaubt (gleich oder neuer als 18363.476). Das aktuelle Update gibt es im Matrix42 Patch-Management oder im Windows Catalog zum Download.
• Das Sprachpaket direkt in die Quellen integrieren.

Für beide Fälle ist eine Anpassung der Quellen notwendig (Sicherheitskopie anfertigen!). Dazu sollte man mit dem Umgang der DISM oder äquivalenten Powershell Befehle vertraut sein. Alternativ kann man es bestimmt auch mit DISM GUI oder DISM++ bewerkstelligen. Mit beiden genannten DISM GUI Tools habe ich leider noch keine Erfahrung gesammelt.

Grober Ablauf

• Passenden Index herausfinden. Da die Windows Images zumeist mehrere Editionen enthalten, muss man vor einer Anpassung wissen, welchen Index man nutzt.
• Mounten des Images/Index in einen Ordner
• Hinzufügen des Updates oder des Sprachpaketes (später Schritt 3)
• Dismounten des Images

Befehle

Die nachfolgenden Befehle beinhalten mitunter Platzhalter oder beispielhafte Verzeichnisse, Indizes uvm.

;Schritt 1: Auflisten der Indizes und Windows Editionen
DISM /Get-Imageinfo /Imagefile:<Pfad>\install.wim

;Schritt 2: Mounten des genutzten Index - hier 5 in den Ordner D:\mount
DISM /Mount-Image /Imagefile:<Pfad>\install.wim /Index:5 /MountDir:D:\mount

;Schritt 3a: Hinzufügen des Updates 
DISM /Image:D:\Mount /Add-Package /Packagepath:<Pfad>\<Update.msu> 
;Schritt 3b: Hinzufügen des Sprachpaketes
;DISM /Image:D:_mount /Add-ProvisionedAppxPackage /PackagePath:<Pfad>\LanguageExperiencePack.de-DE.Neutral.appx /LicensePath:<Pfad>\License.xml)

;Schritt 4: Dismounten des Images 
DISM /Unmount-Image /MountDir:D:\mount /commit

;Schritt 5: (optional) Aufräumen nach getaner Arbeit
DISM /Cleanup-Wim

Euch – viel Erfolg!
Ingo – vielen Dank für das Teilen der Erkenntnisse!

Der Beitrag LanguagePacks und Windows 10 Build 1909 erschien zuerst auf Workplace Management Blog.

PrepareDRVbyModel_Packages

Mein Ersatz bietet (meines Erachtens:)) einige Vorteile und weicht in den nachfolgenden Punkten von dem Matrix42 Grundgedanken ab:

• es ist „gesprächiger“ und man kann eher nachvollziehen, was es macht (siehe Screenshots am Ende des Beitrages)
• der Ablageort der Treiber kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• der Ablageort der Drivers.ini kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
• es kann festgelegt werden, ob die WinPE Installation weitergehen soll, auch wenn kein Eintrag in der drivers.ini, Treiber, etc. gefunden wurde.

Übersicht dieses Beitrages

• Import der OS-Packages
• Kurze Einführung: Hardware Model zu Treiber/Software Zuordnung per drivers.ini
• Möglichkeiten mit PrepareDRVbyModel_Packages
• Einführung PostOSInstallation Paket
• Download
• Fehlersuche
• Screenshots

Import der OS-Packages

Zuerst ist es notwendig, die zusätzlichen OS-Package über das Software-Depot zu importieren. Danach muss die Reihenfolge arrangiert werden, damit die richtige Abarbeitung während der OS-Installation gewährleistet ist:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• <PrepareDRVbyModel_Packages>
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• <PostOSInstallation> (optional aber empfohlen)
• EmpirumAgentSetup

Hardware Model zu Treiber/Software Zuordnung

Die Zuordnung Model zu Treiber geschieht wie bei dem Paket der Matrix42 über die drivers.ini Datei. Diese ist im Standard unter Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt.

Aufbau der Drivers.ini
[<WMI Manufacturer>]
<WMI Model>=<Ordner, *.ZIP, *.cab unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers>

z.B.
[Dell Inc.]
OptiPlex 7010=DellOptiplex7010
;alternativ OptiPlex 7010=DellOptiplex7010.zip
;alternativ OptiPlex 7010=DellOptiplex7010.cab

Möglichkeiten mit PrepareDRVbyModel_Packages

Nachfolgend sind die Möglichkeiten erläutert, die sich aufgrund der Anpassung und Erweiterung ergeben. Diese Möglichkeiten können über die Variablen in der Management Console gesteuert werden. Die aufgeführten Variablen sind alle unter der Variablen Sammlung „PrepareDRVbyModel_Packages“ zu finden.

DriversAreMandatory:
Das Matrix42 Paket drehte sich bis vor kurzem solange in der Schleife bis ein Treiber in der drivers.ini gefunden wurde.
Dies ist für eine produktive Umgebung, den Dienstleister etc. gut so.
Wenn man jedoch einen Computer ohne spezifische Treiber installieren will (zum Test), dann muss man im Matrix42 Falle einen drivers.ini Eintrag erzeugen mit einem Verweis auf ein leeres Verzeichnis.
Dieses Verhalten wurde mit dem DriverIntegration 2.6 Pakete verändert – man kann es jedoch nicht steuern.

Variablenwerte:
0, WinPE fährt mit der WindowsInstallation fort, auch wenn kein Treiber in der drivers.ini gefunden wurde.
1, Matrix42 Standardverhalten – das System läuft in der Schleife und führt die WindowsInstallation nicht fort.
Somit kann man für eine produktive Struktur (Konfigurationsgruppe) sicherstellen, dass die Installation nur mit bekannten Hardware-Typen durchgeführt wird.

DriversRootPath:
Die Idee, den DriversRootPath anpassbar zu machen, hatte mehrere Gründe:
Selektive Synchronisation der Treiber: Hiermit kann man die Treiber direkt unter Packages\Drivers ablegen und mit einem angepassten „ESubDepot_Packages“ SyncJob diese für bestimmte Standorte auslassen und mit einem selbsterstellten ESubDepot_PackagesDrivers diese separat synchronisieren lassen.
Treiber-Update Softwarepakete: Durch eine Erweiterung der Ablage um eine Setup.inf, DPInst.exe und xml kann man eine Aktualisierung der Treiber auf bestehenden Systemen durchführen und mass dazu die Treiber nicht mehrmals ablegen. Dies werde ich in einem späteren Beitrag nochmals aufgreifen.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Kommentar:
Hinweis: Man kann in der drivers.ini auch Teilpfade angeben.
Für eine Kopie eines Ordners zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP
Für die Nutzung einer ZIP Datei zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP\Optiplex7010.zip
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

DriversINIPath:
Die Idee hierbei war, dass man eine zweite drivers.ini Datei, unabhängig von einer produktiv genutzten, einsetzen kann.
Darin kann man Einträge für eine bekannte Hardware auf einen anderen Pfad, ZIP, etc. setzen und somit vorab bzw. parallel testen.
Somit kann für eine bestimmte Konfigurationsgruppe ggf. der Wert: Matrix42\OsPackages\Drivers\Test sein.
In diesem Ordner muss dann die alternative drivers.ini abgelegt sein.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

Perfekt funktioniert PrepareDRVbyModel_Packages mit dem PostOsInstallation Paket von mir. Das genannte Paket prüft ob es eine C:\EmpirumAgent\Drivers\HWspecificSW\Setup.inf gibt und führt diese aus.

Möglichkeiten des PostOsInstallation

Das PostOSInstallation Paket ist einfach und ruft eine abgelegt PostOSInstall.bat auf.
Hinweis: Diese Datei solltet ihr vor der ersten Benutzung einsehen und anpassen!
Die Batch Datei hat heute mindestens drei Funktionen:

• Es importiert eine von dem PrepareDRVbyModel_Packages Paket erstellte Registry Datei, die ähnliche Werte in die Registry schreibt (HKLM\Matrix42\Installer), wie die EPE Installation.
• Es passt die durch Matrix42 vorgegebenen Firma, Benutzer, Support etc. Informationen in der Registry an, die man bei der EPE Installation in der Betriebssystemvorlage angegeben hat.
• Es führt eine Setup.inf aus dem C:\EmpirumAgent\Drivers\HWspecificSW Ordner aus, falls diese vorhanden ist. Somit kann man wieder im „Hardware-Profil“ Treiber per PNP und per EXE/MSI installieren.

Somit ist die PostOSInstall.bat eine Art Ersatz für die EmpirumAgent.bat/UEMAgent.bat.

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

PrepareDRVbyModel_Packages 1.5 (388 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (413 Downloads )
MD5 Hash der Downloaddatei: 0D3415555E6197DC510B02E946D96C5169FD8529

Los geht’s

Schritt 1:
Zuweisen der Pakete für eine Konfigurationsgruppe:

• <WinPE-D-2PXE> (optional aber empfohlen)
• DiskPartitioning
• PrepareDRVbyModel_Packages
• WindowsInstallation
• PxeOffAndReboot
• DomainJoin
• PostOSInstallation (optional aber empfohlen)
• EmpirumAgentSetup
• Betriebssystem (per Variable oder aus dem rechten Baum)
• WinPE (Bootkonfiguration)
• Agent-Template

Schritt 2:
Setzen der Variablen für die oben genannten Pakete (siehe hierzu ggf. auch das WinPE Dokument der Matrix42).
Zuordnung des Betriebssystems

Schritt 3:
Zuweisen eines Computers

Schritt 4:
Aktivieren von PXE und Software (OS.INI ist nicht notwendig!)
Achtung:nicht während einer aktiven WinPE Phase den Computer nochmals aktivieren (dies kann ab WinPE 1.4.11 wieder getan werden).

Rückmeldungen sind willkommen!

Fehlersuche:

• Erster Anlauf: In der Management Console auf dem entsprechenden Computer das PXE-Log ansehen
• Informationen zum Ablauf der OS-Packages befinden sich in Empirum\EmpInst\Wizard\OS\Auto\<MAC8> oder <UUID>\debug_Matrix42.Platform.Service.Host.log.
  Suchen nach [wpm-blog und darunter sollten weitere Informationen zu finden sein …

Beispielhafte Screenshots:

DriversAreMandatory = 0 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1, passende Zuordnung/Treiber in drivers.ini gefunden, abweichende DriversIniPath Variable, Treiber werden kopiert

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

Was hat mich gestört?

Thema 1: Das DriverIntegration Paket holt die Windows Treiber aus einem Ordner unterhalb von
\\<EmpirumServer>\Configurator$\Packages\Matrix42\PreOSPackages\Driver.
Dies bedingt zum einen das die Treiber nochmals für die Hardwaremodelle eingebunden werden müssen und zweitens, dass diese meines Erachtens dort unglücklich abgelegt werden. Besser gefallen hätte mir der Driver Ordner samt Struktur direkt im Packages Ordner. Somit hätte man einfacher Synchronisations-Ausnahmen bzw. Jobs definieren und mit einfachen Handgriffen die Ablage auch zur Verteilung der Treiber als Software-Pakete nutzen können. Somit gäbe es eine modelspezifische Treiber Ablage für die Nutzung für die OS Installation und Aktualisierung per Software-Management (gedanklich ergänzt um Setup.inf und DPInst.exe/xml). Ob das nun die „beste“ Lösung ist, sei mal dahingestellt, jedoch meines Erachtens besser als derzeit umgesetzt.

Thema 2: Für diejenigen wiederum die das WinPE erst einmal als mögliche Alternative zum EPE testen wollen, wäre ein Zugriff auf die bereits vorhandenen Treiber nützlich. Dieses Thema adressiert mein erstes PreOS Paket. Dieses Paket holt die Treiber aus dem Hardware-Profil Verzeichnis unterhalb von Empinst\DRV\Win8 oder Win10 und setzt die Windows Installation, je nach gesetzter Variable, fort wenn keine Treiber gefunden wurden.
Somit kann man für eine produktive Umgebung die Installation „anhalten“, wenn kein Hardware-Profil gefunden wurde und die Installation fortsetzen, wenn man noch am Testen ist, wie sich Windows ohne Treiber bereits auf einem System verhält.
In der ZIP Datei ist eine LiesMich.txt zur Einrichtung und Nutzung enthalten.

Warum hat das Paket die Version 0.8?

Ich selbst hätte gerne Rückmeldungen in das PXE-Log und ein optimiertes Handling, wenn kein Hardware-Profil gefunden wurde und die Variable so eingestellt ist, dass ein Hardware-Profil Voraussetzung ist. Hier stelle ich mir vor, dass am Bildschirm des Systems eine Meldung angezeigt wird und bei Bestätigung der Computer herunterfährt, sowie eine entsprechende Meldung im PXE-Log erscheint.

Generell strebe ich in Zukunft schon eine Ablage der nach dem unter Thema 1 genannten Muster an, deswegen hat das Paket auch das Suffix _EmpInst.

PrepareDRVbyModel_EmpInst_08 (402 Downloads )
MD5 Hash der Downloaddatei: 573D4580C7F9642EC89C3128176AF0CB

Der Beitrag Erstes Empirum PreOS-Paket und Anpassung erschien zuerst auf Workplace Management Blog.

Patch-Management (v3) Einstellungen – PM3Client

Das Empirum Patch-Management v2 konnte nicht so weitgehend konfiguriert werden, wie der aktuelle Matrix42 Patch-Management v3 Client. Die hier angesprochene Konfiguration wird über die Matrix42 Management Console vorgenommen und betrifft hauptsächlich das Verhalten der Patch-Management v3 Pakete bzw. der darin enthaltenen PM3Client.exe. Die Einstellungen werden weitestgehend über die Variablen entweder für einen einzelnen Computer oder über die Gruppen und deren Vererbung bzw. Übernahme der Werte gesetzt.

• Die Zuordnung der Patch-Management Gruppen geschieht per Drag & Drop in der Management Console.
• Das Verhalten der Matrix42 Patch-Management v3 Pakete bzw. der PM3Client.exe geschieht über die Empirum Variablen. Die Einstellungen sind in der Gruppe „MX42_PATCHMANAGEMENT“ zusammengefasst. Diese erreicht man mit einem Rechtsklick auf einen Computer, eine Konfigurations- oder Zuweisungsgruppe > „Variablen …“ > „MX42_PATCHMANAGEMENT“.

Übersicht über die getätigten PM3 Einstellungen

Eine Übersicht über die getätigten Einstellungen ist schwer zu bekommen. Das war mein Beweggrund den PM3ClientConfigExporter zu erstellen. Dieser exportiert die oben angesprochenen Einstellungen in eine CSV Datei zur weiteren Nutzung. Der PM3ClientConfigExporter erstellt zwei Export Dateien.

PM3ClientConfig_Export

Eine _Export enthält weitestgehend 1:1 die Einstellungen wie sie in der Management Console vorgenommen werden. Eine Ausnahme musste ich vornehmen. Das Trennzeichen für die CSV Datei ist ein Semikolon (;). Da dies laut Matrix42 auch bei den Variablen PATCH_POST_COMMANDS und ASK_KILL_PROCESSES vorkommen kann, habe ich dies im Export durch ein Komma (,) ersetzt.

PM3ClientConfig_Detailed

Die _Detailed Datei enthält die Einstellungen in nahezu leserlicher Variante, wie sie in der Matrix42 Hilfe beschrieben sind. Auch hier wurde die gleiche Ersetzung der Semikolons durch ein Komma bei den PATCH_POST_COMMANDS und ASK_KILL_PROCESSES Werten vorgenommen.

Historie

Die Version 1.0, die auch noch heruntergeladen werden kann, hat als generelles Trennzeichen das Komma (,) und somit auch andere Ersetzungen. Mehr dazu ist in der Readme.txt im Download zu finden. Ich habe das Trennzeichen in der Version 1.1 auf das Semikolon (;) geändert, damit es einfacher mit Excel geöffnet werden kann.

PM3ClientConfigExporter

Hier geht es zum Download der aktualisierten Version 1.1:
PM3ClientConfigExporter 1.1 (722 Downloads )
MD5 Hash der Downloaddatei: 6E76564715574D13CF9E81C7433804AA

Hier geht es zum Download:
PM3ClientConfigExporter (469 Downloads )
MD5 Hash der Downloaddatei: F584D2A5DC36DE678AA003DFE0EFB93A

[Update 09.08.2018] Es wurde eine neue Version des Tools für das aktualisierte Patch-Management bereitgestellt.

Der Beitrag Matrix42 Patch-Management v3 Einstellungen erschien zuerst auf Workplace Management Blog.

Dies kann mit den folgenden beiden Schritten behoben werden …

Schritt1: Sync-Job für Windows Server 2012R2 freigeben

Der nachfolgende Befehl ist auf die Standort Datenbank auszuführen:

Update Software Set OSSystems='101171616' Where Type='SYNC'

Schritt 2: Neuerstellung der SWDepot.dds

Anschließend muss die neue Erstellung der SwDepot.dds Datei durch das Speichern der Konfiguration bzw. einer Konfigurationsänderung in der Management Console unter Konfiguration, Software-Management, SoftwareDepot erzwungen werden.

Hinweis in eigener Sache

Dieses Vorgehen habe ich mit der Empirum V16.1 mehrmals erfolgreich durchgeführt. Teilweise waren selbst erstellte SYNC Jobs für alle Betriebssysteme freigegeben. Bei neueren Empirum Versionen ist zur Sicherheit zuvor zu prüfen, welchen OSSystems Wert andere SYNC Jobs haben:

select SoftwareName, OSSystems from Software where Type='SYNC'

Der Beitrag Empirum Sync-Job wird nicht auf Windows Server 2012R2 installiert erschien zuerst auf Workplace Management Blog.

Dafür gibt es unterschiedliche Herangehensweisen und Methoden.

• Matrix42 stellt bereits für einige Hardwaremodelle Treiber für diverse Betriebssysteme bereit.
• Darüber hinaus gibt es die im OS-Installer eingebaute Möglichkeit auf bereitgestellte Treiber der „Community“ zuzugreifen.
• Eine weitere Möglichkeit besteht darin, Treiber mit einem definierten Versionsstand selbst zu hinterlegen.

Wie der generelle Ablauf ausschaut habe ich bereits in diesem Artikel erläutert.

Wie kommt man „einfach“ an die benötigten Treiber?

Mit etwas Erfahrung greift man recht zielsicher zu den richtigen Dateien, doch auch hier gibt es immer wieder die ein oder andere Hürde.

Variante 1:
Einige Hersteller stellen mittlerweile Sets der Treiber zur Verfügung. Diese haben ggf. nicht den aktuellsten Stand, doch man erspart sich den Download von x verschiedenen einzelnen Treibern.

Variante 2:
Die Hersteller liefern die Geräte mit installierten Treibern und häufig auch Programmen zur Systemaktualisierung aus. Mit Hilfe dieser Systemaktualisierungsprogrammen bekommt man die installierten Treiber auf den aktuellsten Stand.

Wie kommt man nun an die Treiber für die Einbindung in Empirum?

Es gibt diverse Werkzeuge (Tools) die die Treiber aus einem bestehenden Windows System extrahieren können. Eine Übersicht zu diversen Tools gibt es hier.

Ich selbst habe recht gute Erfahrungen mit DoubleDriver gemacht, da es „portable“ ist und keine Installation benötigt. In diesem Programm gibt es auch die Möglichkeit, nur die zusätzlich installierten Treiber aus einem System zu sichern. Treiber die zusätzlich installiert wurden, sind über OEMxx.inf Dateien gekennzeichnet, da beim Installieren die Hersteller INF Datei in OEM<fortlaufende Nummer>.inf umbenannt wird. Nachdem man das Tool gestartet hat und das System über „Scan current System“ ausgelesen hat, sind die OEM Treiber bereits vorselektiert. Anschließend kann man über „Backup now“ und diese als „Structured Folder“ in ein Ziel seiner Wahl sichern. DoubleDriver erstellt dann, je nach Typus (Chipsatz, Security,…), ein eigenes Verzeichnis.

Wie bekomme ich nun diese Treiber in Empirum eingebunden?

Auch hier gibt es unterschiedliche Wege. Generell sollte man jedoch den Netzwerkkartentreiber auf jeden Fall ganz „klassisch“ wie eingangs beschrieben über den Hardware-Assistenten einbinden. Je nach „Geschmackssache“ macht man dies auch für den Grafikkartentreiber und alle weiteren „sonstigen“ Treiber. Alternativ erstellt man ein Hardwareprofil, samt Verzeichnisnamen und kopiert die erstellte Struktur in das Verzeichnis des Hardwareprofils. Dies geht ab Windows 7 und neuer, da diese Betriebssysteme auch Unterverzeichnisse nach passenden Plug&Play Treibern durchsuchen.

Achtung!

Nicht alle Treiber lassen sich darüber einbinden und funktionieren nach einer Installation sorgenfrei. Folgende Treiber installiert man am besten über die Installationsroutine des Herstellers:

• UMTS (WWAN) Treiber und Software, wie die Ericson oder GOBI Treiber
• Bluetooth Treiber und Software

Folgende Treiber „zicken“ auch ganz gerne einmal:

• Touchpad Treiber
• Medienkarten
• neue HECI (AMT Treiber)

Zusammengefasst hilft einem das Backup einfach an aktuelle bzw. funktionierende Treiber heranzukommen. Es ist jedoch nicht die alleinige und komplett „sorgenfreie“ Möglichkeit.

Gerade Notebooks, die über weitere spezifische Hardware verfügen, sind hier mit dem besonderen Augenmerk zu beachten. Desktop Computer sind hier weniger speziell und funktionieren zumeist mit den „gesicherten“ Treibern.

In Kürze folgt ein weiterer Beitrag über ein „optimiertes“ Treiberhandling.

Der Beitrag Treiberintegration – Einfacher gemacht (Teil 1) erschien zuerst auf Workplace Management Blog.

Wenn man nicht weiß, in welcher Datei sich die Einstellung niederschlägt bzw. in welcher Datei die Anpassung vorgenommen werden, kann man die Änderung mittels des PackageWizards und dem Differenzanalyseverfahren (Diff) festhalten.

Variante 1 – Diff bzw. Differenzanalyseverfahren

Das bedeutet, man startet den PackageWizard und wählt den Punkt „Systemanalyse vor und nach der Installation …“ und führt den PreScan durch. Ist der PreScan abgeschlossen, führt man seine Änderung der Einstellung durch bzw. kopiert eine Datei manuell in das Benutzerverzeichnis. Anschließend führt man den PostScan durch. Ist der PostScan erfolgreich abgeschlossen, führt man den PackageWizard Assistenten bis zum Ende durch. Kopieren Sie die Datei nicht auf den EmpirumServer. Wenn man den Haken bei Datei mit dem PackageEditor öffnen wählt, kann man sich die kommenden Schritte sparen.

Nun kann man die gerade erzeugte Setup.inf Datei öffnen. Geben Sie dazu %TEMP% im Windows Explorer ein. Hiermit landet man direkt im temporären Verzeichnis. Hier sollte ein Verzeichnis mit der Herstellerbezeichnung (aus der Eingabe im PackageWizard) vorhanden sein. Darunter befindet sich ein Verzeichnis mit dem Softwarenamen, dann der Version und dann „Install„. Im „Install“ Verzeichnis befindet sich die gerade erstellte Setup.inf.
Jetzt können Sie den Kopierbefehl, als auch die dazugehörige Datei in Ihr ggf. bereits vorhandenes Paket einfügen bzw. übernehmen.

Variante 2 – Empirum Kopierflag CLIENT (pro Benutzer):

Ergänzen der Setup.inf wie folgt. Eintragen eines Sektionsaufrufes unterhalb von [Product] in der passenden Reihenfolge. Vorteilhaft ist es, wenn man den benutzerspezifischen Teil nach der eigentlichen Installation des Programmes ausführt, hier mit Set:Product symbolisiert. Zusätzlich muss die benutzerspezifische Datei (hier: Freecommander.ini) im Ordner (hier: APPDATA\Freecommander) des Programmes unter „Source“ (hier: Packages\<Hersteller>\<Softwarename>\<Version>\) abgelegt werden.

Kopierflags

Die Datei wird in diesem Falle bei einer Deinstallation auch wieder vom Computer entfernt. Ist dies nicht gewünscht, da dann Einstellungen nicht zu einer neu installierten Version übernommen werden, so kann zu den vorhandenen Flags CLIENT ALWAYS auch noch das DONTDELETE hinzugefügt werden. Ein weiterer Blog Artikel zum Kopierbefehl kann hier eingesehen werden, alle Kopierflags sind hier aufgeführt.

ALWAYS

Das Flag ALWAYS überschreibt eine gegebenenfalls existierende Datei. Bei benutzerspezifischen Einstellungen sollte man das Flag ALWAYS immer setzen, da die installierten Programme zumeist eine vordefinierte Einstellungsdatei einrichten und diese hat dann das Datum der Installation der Software und die eigene Einstellungsdatei hätte ggf. ein älteres Datum und würde im Standard nicht installiert/kopiert werden. Mit ALWAYS stellt man somit sicher, dass die eigene Datei mit Einstellungen eine gegebenenfalls vorhandene Datei überschreibt!

[Product]
...
;---Beispiel für eine Installation, diese Zeile nicht übernehmen! 
#Set:Product 
...
#Benutzereinstellungen 
...

[Benutzereinstellungen]
1:APPDATA\Freecommander\Freecommander.ini, %APPDATA%, CLIENT ALWAYS, 0

Variante 3 – Empirum Kopierbefehl copy

Ergänzen der Setup.inf wie folgt. Eintragen zweier Sektionsaufrufe unterhalb von [Product] in der passenden Reihenfolge. Vorteilhaft ist es, wenn man den benutzerspezifischen Teil nach der eigentlichen Installation des Programmes ausführt, hier mit Set:Product symbolisiert. Die Sektion „BenutzereinstellungenMachine“ kopiert die Einstellungsdatei (hier wurde eine config.xml Datei angenommen) auf den Computer zur lokalen Ablage. Die Sektion „BenutzereinstellungenClient“ kopiert die Datei dann pro Benutzer in das angegebene Verzeichnis. Zusätzlich muss die benutzerspezifische Datei im Ordner des Programmes unter „Source“ (hier: Packages\<Hersteller>\<Softwarename>\<Version>) abgelegt werden.

[Product]
...
;---Beispiel für eine Installation, diese Zeile nicht übernehmen!
#Set:Product 
...
 #BenutzereinstellungenMachine, MACHINE 
#BenutzereinstellungenClient, CLIENT 
...

[BenutzereinstellungenMachine]
;---kopiert die Einstellungsdatei im Maschinenteil auf den Computer 
-DEL "%APP%\Config.xml"
Copy "%SRC%\Config.xml" "%APP%\Config.xml"

;---Alternative für einen anderen lokalen Ablageort der Konfigurationsdatei 
;-DEL "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml" 
;Copy "%SRC%\Config.xml" "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml"

[BenutzereinstellungenClient] 
;---kopiert die Einstellungsdatei im Benutzerteil von der lokalen Ablage in das benutzerspezifische Verzeichnis 
Copy "%APP%\Config.xml" "%AppData%\<Hersteller>\Config.xml"

;---Bei einem alternativen lokalen Ablageort der Konfigurationsdatei 
;Copy "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\Config.xml" "%AppData%\<Hersteller>\Config.xml"

;---Falls bei einer Deinstallation auch die Einstellungen wieder entfernt werden sollen. 
;---Achtung, somit werden Einstellungen nicht in eine neue Version übernommen, da die Config.xml beim Deinstallieren gelöscht wird. 
-DEL "%AppData%\Config.xml"

Setup.exe Aufruf

Als letztes ist es wichtig, dass dem Paket beim Einbinden in das SoftwareDepot auch mitgeteilt wird, das ein Benutzertzeil ausgeführt werden muss. Dies wird auf dem Reiter „Prüfung“ im Feld „Befehl“ vorgenommen. Weitere Informationen dazu sind in diesem Artikel vermerkt.

Der Beitrag Setup.inf – Datei pro Benutzer kopieren erschien zuerst auf Workplace Management Blog.

Die lokale Kopie wird im Bereich [Installer] vorgenommen. Wenn man den Zielort für die lokale Kopie verändern möchte, so muss man den Kopiervorgang unter [Installer] und den ReInstallString unter [Application] anpassen.

In dem hier aufgezeigten Beispiel wird die Setup.inf jeweils unter %WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\%SetupInfDir% abgelegt. Der gemeinsame Zielort kann sich je nach „Geschmack“ unterscheiden und kann z.B. auch %ProgramFiles%\_EmpirumPackages\%DeveloperName%\%ProductName%\%Version%\%SetupInfDir%\ sein.

[Application]
...
ReinstallString="%CommonSetupDir%\Setup.exe" "%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\%SetupInfDir%\Setup.inf"
...

[Installer]
...
1:%SetupInfDir%\Setup.inf,"%WINDIR%\EmPack\%DeveloperName%\%ProductName%\%Version%\"  , NORMAL, 0
...

Der Beitrag Anpassung Paketierungsvorlage – lokaler Setup.inf Ablageort erschien zuerst auf Workplace Management Blog.

Wichtig ist im ersten Schritt mindestens die folgenden Variablen der Setup.inf zu kennen.

• %SRC% entspricht dem Source-Directory (SrcDir=) – das Verzeichnis „auf Höhe“ des Install Verzeichnisses bzw. unter dem Versionverzeichnis. %SRC% = <Hersteller>\<Softwarename>\<Version>.
• %APP% entspricht dem %ApplicationDir% aus der Sektion [Application], zumeist das Zielverzeichnis für eine Installation.

Syntax

Hier nun die Syntax für den Kopierbefehl:
1:Quelldatei,Zielverzeichnis,Kopierflag,Größe

Beispiel

Diese Zeile:
1:WinCmd.exe, ,NORMAL, 123456
kopiert die Datei WinCmd.exe mit der Größe 123456 aus dem %SRC% Verzeichnis in das %ApplicationDir% Verzeichnis.

Quelldatei

Die Quelldatei wird am dem Verzeichnis %SRC% angegeben.

Zielverzeichnis

Ist beim Zielverzeichnis nichts angegeben, wird %ApplicationDir% gesetzt.

Kopierflag

Das einfachste Kopierflag ist NORMAL.

Dieses Kopierflag sorgt dafür, dass die aktuellste Datei im Ziel (auf dem Clientcomputer) „landet“. Ist bereits eine aktuellere Datei auf dem Computer als in der Quelle, so wird die Datei nicht vom Server (Empirum Paket) überschrieben.

Empirum bietet eine Fülle an Kopierflags.
Hier führe ich die häufigst genutzten Befehle auf. Eine komplette Übersicht ist jedoch hier wieder zu finden.

• NORMAL – Die Datei wird nur kopiert, wenn sie neuer ist als das Ziel.
• ALWAYS – Die Datei wird immer kopiert.
• CLIENT – Die Datei wird im Benutzerteil/Benutzerkontext kopiert.
• DONTDELETE – Die Datei wird beim Deinstallieren des Paketes nicht gelöscht.
• SHAREDDLL – Der Zähler bei gemeinsam genutzten DLLs auch hoch und runtergezählt.
• USEFILENAME – Die Datei wird ohne den Quellpfad in das Ziel kopiert.
• WINDOWS32 – nur bei Windows 32bit Betriebssystemen ausführen
• WINDOWS64 – nur bei Windows 64bit Betriebssystemen ausführen

Es können auch mehrere Kopierflags mit einem Leerzeichen getrennt angegeben werden.

Größe

Die Größe bestimmt, wie sich in einem Paket mit Empirum Kopierbefehlen der Fortschrittsbalken verhält. Man kann die Größe auch auf „0“ setzen, dann wird die Größe ignoriert.

Der Beitrag Empirum Kopierbefehl und Kopierflags erschien zuerst auf Workplace Management Blog.