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.

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.

Zutaten zusammenführen

Die Zutaten habt ihr bestenfalls mit Hilfe der zuvor getätigten Beschreibungen bereits vorbereitet. In diesem Blog-Eintrag geht es darum, die letzten Schritte vorzunehmen.
Nun werden die Zutaten in der Management Console (EMC), von der rechten Seite zur Mitte, in einer Konfigurations- oder Zuweisungsgruppe zusammengeführt:

• PreOS Pakete bzw. die erstellte UND-Klasse zuweisen
• WinPE PXE-Image zuweisen
• Betriebssystem zuweisen
• Agent-Template zuweisen
• die Variablen auf die Gruppe setzen und übertragen

Variablen setzen

Die Variablen übernehmen die Definition der kundenspezifischen Windows Installation. Die zu setzenden Variablen(gruppen) heißen identisch wie die genutzten PreOS Pakete.
Am besten geht man die Liste der zugewiesenen Pakete namentlich durch und stellt die für sich passenden Werte ein. Viele Variablen sind bereits vorbelegt und können auf den vordefinierten Werten belassen werden.

Somit konzentriere ich mich hier auf die meines Erachtens wichtigen Werte für eine Windows Installation in deutscher Sprache inklusive Domain Join.

• DiskPartitioning\PreferFastDisk
• WindowsInstallation\LocalUserName
• WindowsInstallation\LocalUserPassword
• WindowsInstallation\LocalUserDisplayName
• WindowsInstallation\SetupUILanguage
• WindowsInstallation\InputLocale
• WindowsInstallation\SystemLocale
• WindowsInstallation\UILanguage
• WindowsInstallation\UserLocale
• DomainJoin\DomainJoinCredentialsUser
• DomainJoin\DomainJoinCredentialsPassword

Zusätzlich sind die nachfolgenden Variablen, die nicht so lauten wie die zugewiesenen Pakete, wichtig anzusehen bzw. zu setzen:

• FQDN – WindowsInstallation, DomainJoin
• ORGANIZATIONAL_UNIT (optional) – DomainJoin
• TIMEZONE – WindowsInstallation
• MX42_AGENT_PUSH_PACKAGE_FOLDER\Windows – EmpirumAgentSetup

Aktivieren

Anschließend wird das Computerobjekt der Gruppe hinzugefügt und aktiviert. Beim Aktivieren für eine WinPE basierte Windows Installation braucht keine „Betriebssystemkonfiguration (OS.INI)“ mehr erstellt werden. Diese Aufgabe übernehmen die PreOS Packages samt der gesetzten Variablen.

Et voilà

Nun den Computer vom Netzwerk booten lassen und nach ca. 20 min ist das frisch installierte Windows fertig angerichtet!

Besonderheiten

Bis zu diesem Punkt wurde beschrieben, dass sich die PreOS Pakete wie herkömmliche Software Pakete verhalten. Es gibt (Stand Oktober 2019 – WinPE 1.6.6) jedoch ein paar Besonderheiten:

• es werden alle zugewiesenen Pakete ausgeführt, nicht nur die aktuellste/höhere Version
• mittels einer Verteilungsoption „Uninstall“ kann die Verarbeitung von Paketen nicht verhindert werden
• PreOS Pakete, die vor dem DiskPartitioning Paket ausgeführt werden, werden aus dem SWDepot-Log gelöscht und der Status bleibt „undefiniert = gelb“

Der Beitrag Empirum WinPE – Windows Installation erschien zuerst auf Workplace Management Blog.

Was muss man tun, um es zu nutzen?

WinPE Erweiterung installieren.

Zu aller erst muss man die WinPE Erweiterung installieren. Wie zuvor beschrieben gibt es die WinPE Booterweiterung im Matrix42 Marketplace. Diese Erweiterung musst Du in Deine Empirum Umgebung installieren/kopieren. Dazu liegt dem Download ein PDF bei, dass die Installation beschreibt.

Installation des WADK auf dem EmpirumServer

Auf dem EmpirumServer muss das WADK (möglichst aktuell) installiert sein. Die WinPE Erweiterung bedient sich dem installierten WADK und nicht dem in Empirum importierten WADK. Die Installation des WADK habe ich im Beitrag „Matrix42 OS Deployment mit WinPE – Vorausetzungen“ bereits beschrieben.

Erstellen einer Bootkonfiguration

Anschließend muss eine Bootkonfiguration vom Typ „WinPE“ anstatt „EPE“ erstellt werden. Dabei wird das PXE-Image mit dem Inhalt des WinPE erstellt. Die Besonderheiten bzgl. der Optionen EFI und BIOS sind ebenfalls in dem WinPE HowTo PDF Dokument erläutert.

WinPE PXE-Image

Das erstellte WinPE PXE-Image enthält den Matrix42 UAF (Universal Agent Framework). Der UAF wird dazu benutzt die PreOS-Pakete (Empirum Pakete für die WinPE Verarbeitung) auszuführen. Matrix42 liefert einige WinPE Beispielspakete mit. Schlußendlich bestimmen mehrere einzelne PreOS-Pakete die WinPE Auftragsabfolge bis der PXE-Boot deaktiviert wird.
Zum Beispiel kann man mit den folgenden drei Paketen eine Windows 10 Installation durchführen.

• DiskPartitioning (Vorbereiten/Partitionieren der Festplatte)
• DriverIntegration (Ablegen der Hardware-Modell spezifischen Treiber)
• WindowsInstallation (Installation von Windows 10 unter Nutzung der abgelegten Treiber)

Gesteuert werden diese Pakete über dazugehörige Variablen die pro Gruppe oder Computer gesetzt werden. Hier muss man etwas umdenken, da man keine Betriebssystemvorlage mehr erstellt und zuweist, sondern die PreOS-Pakete zuweist und die dazugehörigen Variablen setzt.

Bei der zuvor genannten Abfolge muss nicht Schluß sein. So kann man vor der OS Installation ggf. auch das BIOS aktualisieren und konfigurieren uvm. Für die BIOS Aktualisierung hat Matrix42 auch bereits ein Paket bereitgestellt.

Mein Fazit

Die Idee WinPE zum Starten und Verarbeiten von Befehlen per PXE birgt viel Potential für die Zukunft, da u.a. die Basis Windows anstatt Linux und die genutzte Skript-Sprache powershell anstatt „EIS“ ist. Von den bereitgestellten PreOS-Paketen bin ich jedoch etwas enttäuscht. Das DriverIntegration, WindowsInstallation und BIOSUpdate Paket kann man meines Erachtens als Grundlage und erahnen der Möglichkeiten nutzen bzw. auf deren Grundlage eigene Pakete erstellen. Die Nutzung dieser Pakete zur produktiven Installation von Windows 10 Systemen stehe ich jedoch noch kritisch gegenüber. Mehr dazu in Kürze.

Wenn Du es bereits getestet hast – wie ist Dein bisheriges Fazit?

Der Beitrag Empirum: WinPE anstatt EPE als PXE-Image 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 (1976 Downloads )

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

Hier die Neuerungen im Überblick …

Software-Management

• EmpirumAgent: EmpirumServer FailOver und/oder LoadBalancing (Tokens) per zugeteiltem EmpirumServer aus der EMC (Reihenfolge, Zufällig, ohne MasterServer).
• Einfache SubDepot Einrichtung mit https Unterstützung mittels Paket
• Paketierung und Verteilung von Windows Store Apps

Patch-Management (v3)

• Optimierter Patch Prozess, Download der Quellen im Hintergrund vor dem „Fix“.

OS-Installer

• Variablen Nutzung in der PreBoot Phase
• Neuer Boot-Mechanismus für UEFI Boot mit neuen Möglichkeiten
• Optimierung des Betriebssystem-Imports, auch für weitere Sprachen als bisher.
• WinPE 5.1 Nutzung

EMC – Usability, DBUtil

• Suchen und Ersetzen von Software mit Übernahme der Verteilparameter
• Optimierung des Aktivierungsverhaltens
• Anzeige des Konfigurationspfades in der Statusleiste
• Installation des Aktivierungsdienstes ohne VDI Komponenten möglich

Der Beitrag Empirum V16 – Preview erschien zuerst auf Workplace Management Blog.

Viel Spaß damit!

Set Bandwith=ReadXmlText("%System%\Empirum\AgentConfig.xml","/AgentTemplate/Transport/Protocols/CommonParameters/MinBandwidth")
ECHO %Bandwith%

Set LocalDirPackage=ReadXmlText("%System%\Empirum\AgentConfig.xml","/AgentTemplate/Transport/Protocols/CommonParameters/LocalDirPackage[@Platform='Windows']")
ECHO %LocalDirPackage%

Set InstalledOSVersion=ReadXmlText("%System%\Empirum\%ComputerName%.xml", "/InventoryData/Table[@Name='InvLicenseKey']/Column[@Name='ProductName'])
ECHO %InstalledOSVersion%

Der Beitrag XML Wert in eine Variable erschien zuerst auf Workplace Management Blog.

Die Empirum Setup.inf Skriptsprache ermöglicht einem jedoch weitere Möglichkeiten.

• Vornehmen von benutzerspezifischen Einstellungen
• Kopieren von Dateien pro Benutzer
• Abfragen von Werten auf dem Zielcomputer und „reagieren“ im Software-Paket, wie z.B. Prozessor-Architektur, Registrierungseinträge, Dateien, Dateiversionen, offene Prozesse, uvm.
• Nutzen von Variablen aus der EMC und steuern der Installation
• uvm.

Um Veränderungen an den vorhandenen Software-Paketen vorzunehmen, muss man zuerst verstehen, an welcher Stelle man die Veränderung vornehmen kann und welche Befehle und somit Möglichkeiten einem zur Verfügung stehen.

Gehen wir zuerst auf die Abfolge in der Setup.inf ein.

Die meisten Software-Pakete bzw. Vorlagen enthalten die unten stehenden Zeilen (am Ende dieses Blogeintrages), die für die Erläuterung der Abfolge herangezogen werden. Für die Erläuterungen habe ich jedoch ein paar Befehle bereits in die Vorlage eingebaut, um die Funktionsweise besser zu verdeutlichen.

Das Semikolon (;) sagt aus, dass diese Zeile nicht verarbeitet wird und ein Kommentar darstellt.

Das Hash Zeichen (#) oder von manchem auch Lattenzaun genannt, ist gleichzusetzen mit einem GOSUB aus Basic oder einem Prozedur Aufruf aus anderen Sprachen. Das bedeutet die entsprechende Sektion wird aufgerufen und nach der Beendigung springt die Verarbeitung wieder zurück und geht eine Zeile weiter.

Installationsabfolge

Es wird die Sektion [Product] als „Hauptprogramm“ ausgeführt und die dort angegebenen Sektionen der Reihe nach (von oben nach unten) angesprungen bzw. verarbeitet.

1. Die erste Zeile ohne Kommentar ist der Aufruf der #Set:Product Zeile. Hiermit wird die [Set:Product] Sektion angesprungen.
2. Es wird „Es geht los“ ausgegeben.
3. Die Datei Datei.exe wird in das Verzeichnis „%ProgramFiles%\Hersteller Software\“ kopiert. Ist kein Ziel nach der Datei.exe angegeben, dann enspricht das Ziel dem Wert von ApplicationDir=.
4. Jetzt ist die Sektion [Set:Product] fertig und es wird die Zeile
5. #Reg:OnUninstallProduct, DELETE angesprungen. Diese wird jedoch nicht verarbeitet, da diese das Flag „DELETE“ besitzt, was aussagt, dass die Sektion nur bei der Deinstallation ausgeführt wird.
6. Jetzt wird die Zeile #Reg:Product, DONTDELETE angesprungen. Diese wird ausgeführt, und das nur bei der Installation, da die Sektion das Flag „DONTDELETE“ besitzt.
7. Es wird der Registry Eintrag Version = 2 unter HKLM\Software\Hersteller\Software vom Typ REG_SZ gesetzt.
8. Anschließend wird die Sektion [INI:Product] und danach
9. [Security:Product] angesprungen. In beiden Fällen gibt es nichts zu tun.
10. Als letztes, obwohl es nicht unter [Product] aufgeführt ist, wird die Sektion [Shell:Product] ausgeführt.

Die Installation ist fertig, es gibt eine Verknüpfung auf dem Desktop, dass das Programm „Datei.exe“ startet.

Deinstallationsabfolge

Die Deinstallation wird in umgekehrter Reihenfolge verarbeitet und startet somit von unten in der [Product] Sektion.

1. Ähnlich wie die Ausnahme, dass [Shell:Product] beim Installieren als letztes aufgerufen wird, wird diese Zeile beim Deinstallieren zuerst ausgeführt. Die Verknüpfung wird entfernt.
2. Nun werden die Sektionen in der Reihenfolge von unten nach oben angesprungen, und dann ausgeführt wenn die Sektion kein FLAG (nach einem Komma) besitzen, oder das Flag „DELETE“ gesetzt haben.
3. So wird bei der Deinstallation der Registry Eintrag Version = 1 unter HKLM\Software\Hersteller\Software vom Typ REG_SZ gesetzt, da die Sektion [Reg:OnUninstallProduct] verarbeitet wird.
4. Nun wird als letztes die Sektion [Set:Product] verarbeitet.
5. Hier wird nun der Kopiervorgang „1:…“ rückgängig gemacht und die Datei gelöscht. Bestimmten Befehlen muss ein „-“ vorangestellt werden, damit diese bei der Deinstallation ausgeführt werden.

Die Deinstallation ist nun abgeschlossen.

Wenn man sich das selbst einmal anschauen möchte, so kann man den Empirum Package Editor starten, in die „Erweiterte Ansicht“ wechseln und die Setup.inf im Einzelschrittmodus durchlaufen.

Auszug aus einer Setup.inf

...
[Product]
;#FileCheckMachine, MACHINE
;#FileCheckClient, CLIENT
;ReplaceEnv <Variable>
#Set:Product
#Reg:OnUninstallProduct, DELETE
#Reg:Product, DONTDELETE
#Ini:Product, DONTDELETE
#Security:Product

[Set:Product]
ECHO "Es geht los"
1:Datei.exe,%ProgramFiles%\Hersteller Software\, NORMAL, 12345

[Reg:OnUninstallProduct]
HKLM,"Software\Hersteller\Software","Version",0x00000000,1

[Reg:Product]
HKLM,"Software\Hersteller\Software","Version",0x00000000,2

[Ini:Product]

[Security:Product]
;Hier könnten Veränderungen an den Berechtigungen im Dateisystem, der Registry, etc. stattfinden

[Shell:Product]
%Desktop%\Dateiaufruf, Datei.exe

Der Beitrag Setup.inf Abarbeitung erschien zuerst auf Workplace Management Blog.

Hier Beispiele für die wichtigsten Variablen:

• %SystemDrive%, Systemlaufwerk, zumeist C:
• %WinDir%, Windows Ordner, zumeist C:\Windows
• %ProgramFiles%, Programmverzeichnis, im deutschen zumeist C:\Programme
• %Computername%, aktueller Computername
• %Username%, aktuell angemeldeter Benutzer

Alle Variablen, die von der jeweiligen Betriebssystemversion genutzt werden und wie diese gesetzt sind, kann man mittels dem Befehl SET auf der Kommandozeile einsehen.
Je nach Installationsstand des Computers können hier auch Programme Variablen abgelegt haben.
Empirum setzt z.B. die Variable EmpirumServer

Der Beitrag Umgebungsvariablen erschien zuerst auf Workplace Management Blog.

Wenn das Thema „Softwareverteilung“ genannt wird, spricht man im gleichen Atemzug auch immer von Software-Paketierung bzw. Repaketierung.

Was ist darunter zu verstehen?

Unter Paketierung versteht man, eine Software-Installation so anzupassen, so dass sie ohne Eingriff durch den Endbenutzer installiert wird. In den meisten Fällen werden dabei auch noch spezifische Anpassungen für die eigene Umgebung vorgenommen.

So wird bei einem Software-Paket für eine Terminal Emulation zumeist auch gleich der genutzte Host mit eingerichtet. Heute bieten bereits viele Hersteller eine sogenannte „silent“ bzw. „unattended“ Installation ihrer Software an, die einen Benutzereingriff während der Installation nicht notwendig macht. Dies erübrigt dann dem Administrator die „Repaketierung“.

Eine „Repaketierung“ ist zumeist dann notwendig, wenn der Hersteller keine „silent“ Installation ermöglicht und man die Installation der Software „aufzeichnet“ und die originale Installation „nachstellt“. Eine Repaketierung geschieht zumeist mit einem Vorher und Nachher Abbild des Computerinstallationszustandes und dem Erstellen einer Differenz. Dieses Vorgehen wird weitläufig als Differenz- (kurz Diff) oder auch Snapshot-Verfahren bezeichnet.

Bei einem Differenzverfahren sollte das Resultat möglichst „variabel“ sein und zumindest Systemvariablen zur Installation nutzen. Nur so ist eine Aufzeichnung und Wiedergabe auf unterschiedlichen Betriebssystemversionen und ggf. Sprachen möglich.

Der Beitrag Software-Paketierung / Repaketierung erschien zuerst auf Workplace Management Blog.