Optionale Installation

Warum gibt es nun die optionale Installation. Da müssen wir in der Empirum Agent „Historie“ etwas zurück gehen. Mit dem UEM Agent, als Nachfolger vom Advanced Agent, hielt eine neue reduzierte und weniger technische Oberfläche Einzug, die sich auf die Einfachheit für den Anwender konzentriert. Wenn eine oder mehrere Installationen mit der Verteiloption „Verschieben“ anstehen, wird der kleinste Nenner (z.B. 1 Tag) dem Anwender zum Verschieben angezeigt und nicht wie zuvor, jede Software mit ihrer aktuellen Verschiebemöglichkeit (eine Software 5 Tage, eine andere 1 Tag).
An dieser Stelle greift die optionale Installation „wieder“ ein. Die Optionale Installation ermöglicht es die Ausführung von vielleicht nicht sicherheitskritischen, jedoch lang andauernden Installationen von kurzen sicherheitskritischen (erforderlichen) Installationen zu entkoppeln. Als zusätzliches Merkmal kann man nun auch im Software Depot in den Paketeigenschaften einem Paket mitgeben, ob ein Neustart „möglich, nicht oder auf jeden Fall erforderlich“ ist.

Verteilungsoptionen

Optionale Installation, mit der „Option“ eines Zieldatums.

Paketeigenschaften

Neustart erforderlich: Nein, Ja, Möglich (falls die Setup.inf das in Laufzeit bestimmt).

Anzeige beim Anwender

Steht nun ein „optionales“ Windows 11 Upgrade und ein viel kleineres Paket, wie hier ein 7-zip zur Verteilung an, wird das wie folgt angezeigt …

Mit einem Klick auf „Zeige Details“ landet man in der folgenden Anzeige …Die optionalen Installationen muss man auf der Detail Seite bewusst zur Installation aktivieren.

Der Beitrag Matrix42 UEM Agent – neues Gesicht, neue Möglichkeiten erschien zuerst auf Workplace Management Blog.

wpm-Blog WinPE-Extension-Pack 1.3

Aufgrund der Windows 11 Implementierung und Unterscheidung im OS-Installer habe das PrepareDRVbyModel_Packages Paket überarbeiten „müssen“. Der Vorteil für Euch – auch eine weitere Funktion ist nun für alle nutzbar. Es ist die CommonDrivers Funktion. Ein Ordner mit Treibern wird für alle Modelle kopiert. So könnt ihr in diesem Ordner, die (neuen?) Dockingstation oder USB-Netzwerkadapter Treiber ablegen und müsst dazu nicht alle Modellpakete erneut anpassen. Es gibt einen Standard-Ordner (CommonDrivers) der kopiert wird, alternativ könnt ihr per Variable einen anderen Namen angeben. Den Gedanke hatte ich auch schon einmal und ein Nutzer hat mich da noch etwas „geschuppst“ – jetzt steht es Euch allen zur Verfügung. Ich hoffe, es gefällt Euch.

Das Paket, dass den Hotfix installiert, damit Windows 10 Pro keine ungewollten Neustart direkt nach WinPE Phase durchführt, habe ich in das Extension Pack aufgenommen. Ihr könnt selbst entscheiden, ob ihr es benötigt, oder nicht.

Das aktuelle wpm-Blog WinPE-Extension-Pack bekommt ihr hier.

innomea WinPE Extension Pack

Neben den WinPE Erweiterungen die ihr hier auf meinem Blog seht, arbeite ich auch den WinPE Erweiterungen der innomea mit. Die Erweiterungen der innomea sind hauptsächlich Ergänzungen zu den Paketen die Matrix42 anbietet. Mit den Ergänzungspaketen (HardwareProfileValidator und CommonDrivers) sollen annährend die Funktionen bereitgestellt werden, die z.B. hier mit PrepareDrvByModel_Packages erreicht werden.

Das innomea PostWindowsInstallation Paket wiederum ist eine starke Weiterentwicklung des hier angebotenen PostOSInstallation. Dieses Paket ermöglicht viele Anpassungen an der Windows Installation, die einige von Euch noch von den Betriebssystemvorlagen her kennen. Dabei wurde teilweise auch auf Einträge im Matrix42 ideas Portal eingegangen.

Hier ein kleiner Auszug der Funktionen, die ihr zum Großen Teil per Variablen steuern könnt: Installation von Treibern per EXE/MSI, Firewall Modifikationen, Festplatte/Partition C: umbenennen, Support, Besitzer Informationen hinterlegen, EmpirumServer der OS-Installation als Umgebungsvariable setzen, „Kennwort läuft nicht ab“ für den zusätzlichen lokalen Admin setzen, uvm.

Den kompletten Umfang und die weiteren Pakete könnt ihr hier einsehen.

Matrix42 DomainJoin Paket

Das Matrix42 DomainJoin Paket wird in Kürze auch eine neue Version erhalten, dessen Vorteil einige zu nutzen wissen werden. Vielen Dank an die Beteiligten der Matrix42 für eure offene Kommunikation und Umsetzung!

Beyond Empirum WinPE

Natürlich dreht sich die hier zumeist angesprochene Matrix42 Empirum Welt nicht nur um WinPE. Jedoch kann man ganz gut erkennen, dass diese mir sehr viel Spaß bereitet. Matrix42 ist dabei eine größere Änderung im UEM-Agent vorzunehmen. Darauf werde ich mit Euch in Kürze schauen.

Stay save!

Wer mich kennt, weiß wie sehr ich versuche „Anglizismen“, wenn möglich, zu umgehen. Es gibt meines Erachtens jedoch einige Situationen bei diesen diese Worte oder Sätze einfach kürzer und treffender sind. Wie auch immer: Bleibt weiterhin gesund in dieser „unbekannten“ und noch „verrückteren“ Zeit!

Der Beitrag Aktualisierungen Frühjahr 2022 erschien zuerst auf Workplace Management Blog.

Bei der Erweiterung des Tools habe ich direkt noch weitere kleinere nützliche Anpassungen „unter der Haube“ vorgenommen. Die Rückmeldung war positiv, doch ich habe es trotzdem „verbummelt“ es auch hier bereitzustellen. Nach der Aktualisierung von SWDepotInfo steht nun auch die aktuelle Version von SetComputerOwner bereit. Das Tool als auch die Handhabung habe ich im ursprünglichen Beitrag hinterlegt.

Der Beitrag Hauptbenutzer auslesen – Update verfügbar erschien zuerst auf Workplace Management Blog.

Übersicht Windows 10 Versionen und Wartungsoptionen

Zurück zu den Vorteilen. Als Administrator kann man nun einfacher herausfinden, welchen Sicherheits- und Qualitätsstand ein Windows 10 entspricht. Microsoft stellt auf der folgenden Seite eine Übersicht der veröffentlichten und aktuellen Windows 10 Stände der verschiedenen Versionen und Wartungsoptionen (CB, CBB, LTSB) zur Verfügung: https://technet.microsoft.com/de-de/windows/release-info.aspx

Empirum Inventory Standard

Im Empirum Inventory wird heute bereits in den Computereigenschaften, Inventory, Computer, Betriebssystemversion die Windows 10 Buildnummer (z.B. 14393) angezeigt. Um die inventarisierte Windows 10 Version noch besser mit der oben genannten Tabelle vergleichen zu können, benötigen wir jedoch auch die Unterversionen der zuvor genannten Buildnummer. Diese können wir uns über eine Anpassung der Inventarisierungskonfiguration in die Empirum Datenbank bzw. Management Console holen.

Windows 10 Build – Speicherort?

Woher bekommen wir denn die Werte, die uns interessieren?
Diese stehen in der Registrierung unter: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

Empirum Inventory Anpassung

Generelle Hinweise zur Anpassung der Empirum Inventory Konfiguration habe im Artikel „Ermittlung installierter Versionen“ bereits gegeben. Diesmal wird jedoch nicht die Dateisuche, sondern „Benutzerdefinierter Wert“ angepasst.
Wenn wir nun den OS Build identisch zur oben genannten Microsoft Seite in der Datenbank abgespeichert haben wollen, muss der Benutzerdefinierte Wert wie folgt eingegeben und gespeichert werden.

Windows10_OSBuild
%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","CurrentBuild"%.%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","UBR"%

Möchte man jedoch einen Filter bauen, indem man einfacher auf „größer“ oder „kleiner“ Wert prüfen möchte, kann eine Aufteilung auf zwei Werte sinnvoll sein.

Windows10_OSMajorBuild
%HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","CurrentBuild"%

Windows10_OSMinorBuild
 %HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","UBR"%

Wo und wie wird es in der Empirum Management Console angezeigt?

Im folgenden Screenshot kann man sehen, wo und wie es in der Management Console angezeigt wird. In diesem Beispiel habe ich den Windows10_OSBuild Wert als einen zusammengesetzten Wert eingelesen.

Der Beitrag Windows 10 Buildversion in Empirum Inventory erschien zuerst auf Workplace Management Blog.

Das Update enthält Detailverbesserungen und Erweiterungen in den Bereichen:

• MAC OS X Unterstützung
• Silverback Integration in Empirum
• Sicherheit
• WebConsole
• Inventory Erweiterung bzgl. SQL und Exchange Server Editionen
• Empirum SubDepot Services (Offline PXE/WOL)

Persönlich finde ich die Verbesserungen im Bereich Sicherheit und SubDepot Services am interessantesten. Gerade für letzteres wurden mit dem Update auf die Empirum Version 16.1.1 nochmals Veränderungen durchgeführt.

SubDepot Services (Offline PXE/WOL)

So wird ab der Version 16.1.1 das SubDepot Services Paket durch separate SubDepot PXE Service und SubDepot WOL Service Paket ersetzt. Damit hat man die Komplexität aus dem bekannten SubDepot Services Paket herausgenommen und kann die Installation der genannten Dienste nun sehr schön über die separaten Pakete durchführen. Gerade in Empirum Umgebungen mit einer Vielzahl an SubDepots ist damit eine Aktualisierung dieser Komponenten wesentlich einfacher geworden.

Leider hatten sich bei der Umsetzung der neuen Funktionen noch kleinere Fehler eingeschlichen. Es wurden bereits Hotfixe für diese Probleme veröffentlicht und können mit dem aktuellen Hotfix Installer vom 06.12.2016 installiert werden. Die Installation der Hotfixe kann ich für Umgebungen die die Offline PXE/WOL Funktionen nutzen nur empfehlen.

Hinweis: Der Hotfix Installer benötigt PowerShell 3.0 oder neuer auf dem EmpirumServer installiert.

Sicherheit

Wer alle Empirum Komponenten auf die Version 16.1 aktualisiert hat, kann die Sicherheit beim Einsatz von Empirum weiter erhöhen. Zur Umsetzung dieser Änderungen empfehle ich die Dokumentation bzw. das dazugehörige „New Features and Changes“ Dokument.

Empirum Version 16.1.2

Zu dem Zeitpunkt, als ich diesen Artikel geschrieben habe, ist die Version 16.1.2 erschienen. Hierzu werde ich in Kürze etwas schreiben.

Der Beitrag Empirum V16.1.1 und Updates erschien zuerst auf Workplace Management Blog.

EDIT 09.01.2018: Die Erfahrung hat gezeigt, dass die Nutzung bzw. das Setzen des Wertes auf 1 für Windows 10 problemlos funktioniert. Windows 7 wiederum bleibt ab und zu bei der OS Installation mit dem gesetzten Wert stehen. Hier sollte man von der Optimierung absehen.

Die Variable WINPE_WIMBOOT befindet sich als Sammlung unterhalb von INTERNAL_OS_INSTALLER_CONFIG.

An dieser Stelle kann man mittlerweile auch diverse Kernel-Parameter bzw. Variablen setzen, wie den rot eingezeichneten Wert EIS_REINSTALLALLOW.

Der Beitrag Kleiner Boost für die OS-Installation erschien zuerst auf Workplace Management Blog.

Die Neuerungen lassen sich in die nachfolgenden Punkte gliedern. Für die „großen“ Ankündigungen habe ich Links zu weiterführenden Informationen hinterlegt. Dem Vortrag zur Empirum V16 Version konnte ich beiwohnen. Hier schreibe ich Euch in einem separaten Blog-Beitrag welche Funktionen u.a. in diesem Release enthalten sein sollen.

• Matrix42 übernimmt den Enterprise-Mobility-Management-Anbieter Silverback (Link)
• Ein Passwort für alle Matrix42 Service – und bald noch mehr … (Link)
• Der „neue“ Matrix42 Marketplace (BETA) – Die Plattform für Erweiterungen zu den Matrix42 Lösungen (Link)
• Ausblick auf Workspace Management 7.2
• Anstehendes Empirum V15.1 Feature Pack (UEFI)
• Ausblick auf Empirum v16

Der Beitrag Matrix42 CustomerDay 2014 Nachlese erschien zuerst auf Workplace Management Blog.

Der Blog wird „alt“ – Neuerung seit Empirum v14.2

Vergleich der Versionsnummer: Ist die Version im Abschnitt [Setup] der Setup.inf GRÖSSER GLEICH 14.2 gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt bis zum nächsten Punkt als komplette Zahl verglichen (45 kleiner 100). Daher ist die Version 1.100 höherwertiger als die Version 1.45 .

Ist die Version im Abschnitt [Setup] der Setup.inf KLEINER 14.2 (z.B. 10.5) gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt Spaltenweise verglichen. Daher ist die Version 1.45 höherwertiger als die Version 1.100. Die Zahlen nach dem ersten Punkt werden nicht als eine Zahl verglichen (45 kleiner 100), sondern Zahlenweise (4 ist größer 1 und 5 ist größer 0). Da die erste Zahl 4 nach dem Punkt bereits größer als die Zahl 1 ist, wird nicht geprüft.

Quelle: Matrix42 Online Hilfe

Ab hier folgt nun die Erläuterung zu [Setup] Version=10.5 …

Martin Niemann hat dies sehr anschaulich und ausführlich auf seinem Blog erläutert. Beim Treffen auf dem vor wenigen Tagen stattgefundenen Matrix42 CustomerDay habe ich in darauf angesprochen, ob ich seinen Eintrag samt Quellenverweis hierher übernehmen darf. Vielen Dank Martin für Deine Erlaubnis!

So hier nun die Erläuterung:

Fast ein jeder wunderte sich schon, wieso die neue Version 4.10 des Paketes von Empirum nicht als höherwertig identifiziert wurde, als das alte 4.9er Paket – „die Zehn ich doch höher als die Neun!“

Hierzu muss man wissen, das in Empirum nur die Zahl vor dem ersten Punkt als ganze Zahl verstanden wird. Alle Werte danach werden Ziffer für Ziffer verglichen.

Hier eine Liste von Versionsnummer in absteigender Reihenfolge:

Die grauen Zahlen zeigen, wie man sich beim Vergleichen von Versionsnummern diese Vorstellen sollte. Vergleicht man nun eine 3.10 mit einer 3.90, ist die 3.9 selbstverständlich höher als die 3.10.

Um zukünftig nicht an die Grenzen der Versionierung zu stoßen, empfiehlt es sich die Versionsnummern nach einem einheitlichen Schema zu erstellen: Die Hauptversion kann aus einer beliebigen Zahl bestehen – bei der Nebenversion sollte man mindestens “zweistellig” vorgehen. Anstelle einer 3.1 sollte man daher besser eine 3.01 verwenden. So ist es später problemlos möglich, nach der 3.09 noch weitere Versionen anzubieten. Vorsichtigere Naturen verwenden für die Nebenversion sogar eine dreistellige Zahl: 3.009. Dies sollte man jedoch nur bei Paketen vornehmen, von denen man weiß, dass sie sich häufig verändern und die Erhöhung der Revisionsnummer nicht verwendet werden kann. Ist man jedoch in die “.9-Falle” getreten, empfiehlt es sich für die neue Version einen weiteren Zahlenblock anzuhängen: 3.9.01. Das sieht zwar nicht so schön aus, rettet einen jedoch aus der misslichen Lage die Version 4.00 einzuführen.

Autor: Martin Niemann

Der Beitrag Empirum Paket Versionen – Früher an später denken? erschien zuerst auf Workplace Management Blog.

Zweiteres kann man über die Logik der Revisionserhöhung realisieren. Möchte bei einem bereits verteilten Paket mit einer MSI oder Unattended Installation nun noch ein paar Dateien oder Registry Einträge austauschen/hinzufügen, so kann man den nachfolgend erläuterten Mechanismus nutzen. Dieser Mechanismus ermöglicht, dass bei bereits vorhandenen Installationen mit der Revision=0 nur minimale Änderungen durchgeführt werden und bei Neuinstallationen, die komplette Installation zuzüglich der nachträglichen Änderung.

[Product]
#CheckRevisionChanges, DONTDELETE
...
;<Installationslogik MSI / Unattended>
;<z.B.: Set:Product>
;<z.B.: Set:Installation>
#DoMinorUpdate

[CheckRevisionChanges]
Set LocalRevision=%%HKLM,Software\%MachineKeyName%\Setup,Revision%%
ReplaceEnv LocalRevision
IF "%LocalRevision%" < "%Revision%" & "%LocalRevision%" <> "" THEN "OnlyDoRevisionUpdate" EndIf

[OnlyDoRevisionUpdate]
#DoMinorUpdate
Exit

[DoMinorUpdate]
;Examples / Beispiele
;#CopyAdditionalFiles
;#Reg:Changes

Der Beitrag Empirum Paket – Revisionserhöhung bei „großen“ Installationen erschien zuerst auf Workplace Management Blog.

Der Empirum Agent prüft bei einem Verteilauftrag anhand der %Computername%.DDC und SWDepot.DDS Einträge, ob die Installation für diesen Computer ausgeführt werden muss. Sind die Voraussetzungen bzgl. Berechtigungen, Betriebssystem, etc. erfüllt, wird der MachineKeyName Eintrag aus der DDS Datei in der Registry überprüft.

Registry Eintrag nicht vorhanden
Ist der Eintrag in der Registry nicht vorhanden, wird die Installation (Voraussetzungen erfüllt!) gestartet.

Registry Eintrag vorhanden – Registry Version gleich wie im SoftwareDepot, Revision
Ist der Eintrag mit der entsprechenden Version vorhanden, wird die Revision (Version der Version) überprüft. Ist die Revision in der Software Depot.DDS höher als in der Registry, wird die Installation gestartet.

Registry Eintrag vorhanden – Registry Version kleiner als im SoftwareDepot
Ist ein Eintrag vorhanden und nur die Version weicht ab, so wird die Installation gestartet, wenn die Version in der SoftwareDepot.DDS höher bzw. größer ist.

Deinstallation der Altversion
Ob nun vor der Installation der neueren Version eine zu vorige Deinstallation des „älteren“ Paketes durchgeführt wird, wird über den Eintrag AskUninstallOld= in der [Application] Sektion gesteuert. Ist der Wert 1, so wird eine Deinstallation der kleineren/älteren Version durchgeführt. Ist der Wert 0 so wird direkt die Installation des höheren/neueren Version durchgeführt.

Der Beitrag Empirum Paket – Registry, SoftwareDepot, Version erschien zuerst auf Workplace Management Blog.