Betriebssystem importieren

Der Start für den Importvorgang befindet sich unter Konfiguration, OS Installer, Import. Die im weiteren Verlauf des Beitrages gezeigten Abbildungen führen durch den Importvorgang und bedürfen nur wenigen Kommentaren. Die zu importierende Windows Quelle (ISO) können Sie entweder mittels Windows Bordmitteln „Bereitstellen“ oder per 7-zip o.ä. entpacken. Der Import Wizard kann leider nicht direkt auf eine ISO Datei zugreifen.

Auswahl des Quellverzeichnisses bzw. des Laufwerkes, in dem die Betriebssystemquellen vorliegen …

Nach der „Untersuchung“ der Quellen, schlägt Empirum vor, was es importieren kann. Nach der Auswahl des Suchergebnisses, kann im nachfolgenden Dialog der Name angepasst werden, was ich auch stark empfehle!

Nach der gewünschten Anpassung, erfolgt der tatsächliche Importvorgang, der auch einen Moment andauert …

Nach einer Weile, zeigt der grüne Text in der Zusammenfassung den Erfolg des Imports an!

Weiter geht’s!

Der Beitrag Empirum WinPE – Betriebssystem in Empirum importieren erschien zuerst auf Workplace Management Blog.

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

Danke und Grüße – Jochen

Prüfung auf ausstehenden Windows Reboot verhindern

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

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

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

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

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

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

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

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

Getaktete Verbindung erkennen (ab UEM Agent 1808)

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

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

Globaler Silent Level (UEM Agent)

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

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

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

InstallAtShutdown – Shutdown nach der OS Installation (UEM Agent)

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

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

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

Ausblenden der Option Installation beim Herunterfahren (UEM Agent)

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

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

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

Suspend Modus (UEM Agent)

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

Paket Validierung

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

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

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

Behandeln von fehlerhaften Paket Validierungen

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

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

Feedback URL ausschalten/anpassen (UEM Agent)

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

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

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

UEM Agent Autoupdate Zeitraum beeinflussen (ab UEM Agent 1811)

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

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

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

Anpassen der Berechtigungen auf den Agent Cache

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

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

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

Prüfung auf Scriptdateien für Kiosk Pakete

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

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

Zurücksetzen der fehlgeschlagenen Installationen

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

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

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

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

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

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

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

Neuer Treiber

Als erstes muss für das jeweilige Model der aktuelle Touchpad Treiber von Dell heruntergeladen werden. Dazu den Treiber samt Setup.exe herunterladen.

Vorgehensweise

Vor der Installation bzw. Reinstallation des Treibers muss jedoch ein Registry Baum gelöscht werden. Dazu den gesamten Baum unter HKLM\Software\Alps löschen. Anschließend den aktuellen Treiber per Setup.exe installieren und das Laptop neu starten. Nach dem Neustart wurde auch in dem Tasktray ein Touchpad Symbol sowie die Aktivitäten angezeigt und die Dell Touchpad Applikation hat die Konfiguration der Gesten ermöglicht.

Automatisierte Treiberinstallation per Empirum

Nun sollte die Installation nicht beaufsichtigt, sondern „unattended“ während der OS-Installation passieren. Dies haben wir dann wie folgt umgesetzt.

Callhidden reg delete HKLM\Software\Alps /f

Call "<Pfad>\DellTP\Setup.exe" /s /V"FORCE=true /qn"

Wie kann ich feststellen, ob bei mir die Touchpad Gesten funktionieren?

Rufen Sie die „Dell Touchpad“ Applikation über die Windows Suche auf. Diese sollte ihnen die Konfiguration der Gesten ermöglichen (links anzeigen). Im Standard sollte das Touchpad Symbol im Tasktray zu sehen sein.

Der Beitrag Dell Touchpad – Gesten funktionieren nicht erschien zuerst auf Workplace Management Blog.

Bis Empirum v18.0.2 konnte man mit Empirum nur WIM Dateien verarbeiten bzw. importieren. Das soll sich in Kürze ändern. Auf der anderen Seite werden dann ab der Empirum v18.0.2 alle in der WIM oder esd Datei befindlichen Produkteditionen in der Oberfläche angezeigt. Das könnte wiederum dem ein oder anderen Administratoren weniger gut gefallen, denn schlussendlich möchte man standardisierte Installationen durchführen und Fehler minimieren.

Muss man nun die esd in eine WIM Datei wandeln, oder eine Produktedition aus einem Datenträger mit mehreren Editionen extrahieren, so bedarf es einiger weniger DISM „Kniffe“.

Auslesen der in der WIM Datei enthaltenen Editionen

Das Auslesen geschieht über den nachfolgenden DISM Befehl.
Hierbei ist es wichtig, dass …

• die Kommandozeile als Administrator ausgeführt zu haben.
• die eingesetzte DISM Version die gleiche oder höhere Version des zu bearbeitenden Datenträgers besitzt.

Dism /Get-WimInfo

dism /Get-WimInfo /wimfile:install.wim
oder eben auch ...
dism /Get-WimInfo /wimfile:install.esd

Die Ausgabe sollte wie folgt aussehen und ggf. mehrere Einträge mit unterschiedlichen Index Werten besitzen:

...
Index: "1"
Name: "Windows 7 Professional"
Beschreibung: "Windows 7 Professional"
...

Extrahieren einer Windows Edition

Mit dem zweiten Befehl und dem passenden Index im Kopf extrahiert man nun die entsprechende Edition in eine einzelne separate Datei.

dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity
oder
dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:installproonly.wim /Compress:max /CheckIntegrity

Ersetzen in den Quellen

Vor dem Importieren in Empirum ersetzt man nun die install.wim im oben genannten „sources“ Ordner durch die neue install.wim. Die neue Datei im „sources“ Ordner sollte am Ende auch wieder install.wim heißen.

Wer sich mehr über das WIM Format aneignen möchte, wird hier fündig: Windows Imaging File Format (WIM)

Jetzt sollten die Befehle zur Hand sein, wenn es nötig wird ;).

Der Beitrag Install.esd umwandeln und einzelne Windows Edition extrahieren erschien zuerst auf Workplace Management Blog.

Windows 10 scheint das Windows Betriebssystem zu werden, dass sich viele Nutzer wünschen. Es verbindet die klassische Bedienlogik inklusive eines Startmenues und die touchoptimierte Bedienung, die mit Windows 8 Einzug gehalten hat. Windows 10 verbindet nicht nur die unterschiedlichen Bedienphilosophien, sondern bietet auch immer die optimale Oberfläche bei Geräten die Tablet und Notebook in einem sind, wie ein Microsoft Surface, Lenovo Yoga, etc..

Windows 10

Die Quellen zum jeweils aktuell veröffentlichten Stand von Windows 10 gibt es entweder im MSDN Bereich oder hier. Wenn man die Windows 10 Preview jedoch auch in der eigenen Empirum Umgebung schon mal testen möchte, muss man beachten das es derzeit nicht offiziell supported wird.

Schnellschuss mit Empirum v15.1

Mit den aktuellen Quellen von Windows 10 kann man auch einen „Schnellschuss“ versuchen.
Dazu muss man zuvor die äquivalente Windows 8.1 Quelle (Architektur, Sprache, Edition) importieren und anschließend die gerade importierten Quellen mit den Windows 10 Quellen ersetzen. Anschließend kopiert man eine passende Windows 8.1 Betriebssystemvorlage und verweist auf die neu importierten Quellen.

Hintergrundinformationen

Wenn das nicht wie gewünscht funktioniert, kann es noch an anderen Parametern liegen.
Da ich bereits ab der ersten verfügbaren Windows 10 Quelle mit Empirum v15.1 experimentiere, habe ich an der ein oder anderen Stelle im System bereits Anpassungen vorgenommen.

Was habe ich alles getan?
1. Aktuelles WADK eingebunden
2. Die Windows 10 Betriebssystemquellen müssen in Empirum eingebunden werden
3. Die unbeaufsichtigte Installation muss mit der ggf. unbekannten SKU zurecht kommen.
4. Betriebssystemvorlage erstellen.

Aktuelles WADK importieren

Zur Sicherheit habe ich das aktuelle WADK auf dem EmpirumServer installiert.
Das aktualisierte WADK gibt es hier.
Wenn man die neuere Version installieren möchte, muss man beachten, dass man zuvor die Vorgängerversion deinstalliert.
Ansonsten erscheint ein Hinweis, dass man bereits die aktuelle Version installiert hätte.

Einbindung der Quellen

Die Windows 10 Quellen kann man entweder über den gleichen Weg einbinden, wie die Windows 8.1 Quellen mit dem damals zur Verfügung gestellten Preview.
Dann wird im OS-Installer auch Windows 10 als importierte Quelle angezeigt. Dazu muss man den Importkatalog, die Datenbank als auch die Importskripte erstellen und in die eigene Umgebung einbauen. Alternativ kann man ein weiteres Windows 8.1, der gleichen Architektur, Sprache und Edition importieren und nachträglich die Windows Quellen unterhalb des SYS Ordners gegen die von Windows 10 austauschen (siehe oben).

SKU (Windows Versions und Editions Information)

Nun haben die Windows 10 Quellen, die ich mir betrachtet habe immer wieder unterschiedliche SKUs besessen. Die Angabe der richtigen SKU sorgt für die komplett unbeaufsichtige Installation. Stimmt die in der unattend.xml hinterlegte SKU nicht mit den eingebundenen Quellen überein, bleibt der Installationsdialog stehen und fragt welche Version von Windows installiert werden soll. Die letzten Windows 10 Enterprise Quellen mit dem Build 9926 hatten allesamt die SKU „Windows 8.1 Enterprise“ eingetragen. Somit müsste man nicht mal eine Anpassung der SKU vor der Installation mit Hilfe eines angepassten EIS Skriptes vornehmen (Empirum v15.1 Patch 09 oder Windows 8.1 Preview vorausgesetzt). Dies war jedoch bei den ersten Windows 10 Technical Previews noch anders.
Die gültige SKU kann mit dem Befehl:
dism /get-imageinfo /imagefile:<Pfad>\install.wim /index:1 
herausgefunden werden. Diese wird unter „Name:“ angezeigt.

ImageInfo.ini

Ist es doch eine andere SKU, so kann man mit der END_WINVISTA.EIS die SKU in der unattend.xml überschreiben.
Ich habe mir für diesen Zweck eine einfache aber vielfältige Methode ausgedacht, wie man für die importierte Quelle immer die richtige SKU hinterlegen kann.

Dazu wird im Verzeichnis
Empirum\EmpInst\SYS\Win8\<ServicePack>_{GUID}\<Sprache>
eine Datei ImageInfo.ini mit folgendem Inhalt erstellt.
Als Hinweis: In diesem Verzeichnis müsste auch die unattended.xml Vorlage liegen.

[ImageInfo]
;SKU=Windows 10 Technical Preview
SKU=Windows 8.1 Enterprise

end_Winvista.eis

Folgende end_winvista.eis Erweiterung sorgt für die Auswertung der ImageInfo.ini, falls diese vorhanden ist. Somit haben diese Zeilen auch für die bestehenden Installationen keine Auswirkung.

; ----------------------------------------------------------------------------
;SKU Override for non supported OS Versions
; ----------------------------------------------------------------------------
IFEXIST %E%Sys\%OS%\%LocARCH%%LocTYP%\%SP%%Language%\ImageInfo.ini THEN
   READINI %E%Sys\%OS%\%LocARCH%%LocTYP%\%SP%%Language%\ImageInfo.ini ImageInfo SKU valueSKU 
      IF "%valueSKU%"<>"" THEN
         §ECHO_MSG="10 Custom script: end_winvista-[SKU Override] executed"
         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
; ----------------------------------------------------------------------------

Betriebssystemvorlage erstellen

Wenn man bereits eine Windows 8 oder 8.1 Betriebssystemkonfiguration hat, so kopiert man diese und hinterlegt unter Allgemein\Sprache die neu eingebundenen Betriebssystemquellen. Speichern, Fertig!

Jetzt kann es losgehen …
Viel Spaß!

Der Beitrag Windows 10 mit Empirum v15.1 installieren erschien zuerst auf Workplace Management Blog.

Das Thema VDI (Virtual Desktop Infrastructure) ist in aller Munde. Häufig tritt das Thema in den Vordergrund, um den Mitarbeitern weitere Möglichkeiten zu bieten auf Unternehmensinformationen zuzugreifen.

Die Gründe für das Interesse sind zumeist die wachsende Mobilität und sich ändernde Endgeräte. Der Slogan den Zugriff „jederzeit, von jedem Ort und mit jedem Endgerät“ zur Verfügung zu stellen trifft die Thematik wahrscheinlich am besten, auch wenn auch schon etwas „abgenutzt“ ist.

Im nachfolgenden Text wird auf die Bereitstellung von Windows Arbeitsplätzen eingegangen. Dieser soll einen Überblick über Verfahren und teilweise auch Produkte geben – es besteht jedoch kein Anspruch auf Vollständigkeit! Auch wird auf das Thema Client-Management eingegangen, weil viele Entscheider denken, dass das Thema Client-Management hinfällig wird mit dem Einsatz einer VDI Lösung.

Wenn man von VDI spricht, wird im ersten Schritt nicht unterschieden, ob es um einen dedizierten virtuellen Desktop für einen Benutzer geht,  oder ob sich der Benutzer die physikalische bzw. virtuelle Ressource(n) mit anderen Benutzern teilt.

Shared Desktop

Das Nutzen einer gemeinsamen physikalischen oder virtuellen Ressource („Shared Desktop“) für einen Windows-Desktop ist bekannt durch:

• Microsoft Terminal Server oder
• Citrix XenApp (Metaframe)

die als Grundlage einen Microsoft Windows Server 2008 R2 bzw. 2012 besitzen.

Individual Desktop

Die Nutzung einer eigenen Desktop Umgebung wird auf unterschiedliche Art und Weise realisiert:

• einzelne Windows Installationen auf physikalischer oder virtueller Hardware auf die von der Ferne zugegriffen wird.
• Citrix XenDesktop bzw. VDI in a Box
• vmware Horizon View
• andere …

Als Grundlage dient hier die Windows Version, die für den jeweiligen Einsatzzweck die richtige ist.

Zuweisungsszenarien

Die gemeinsamen Windows-Desktops (Shared Desktops) werden zumeist in Gruppen oder sogenannten Farms bereitgestellt. Die generelle Bereitstellung von mehr Ressourcen als benötigt, ermöglicht eine Lasterverteilung und Ausfallsicherheit im Betrieb. Darüber hinaus können so auch einzelne Windows Server während der Nutzung aktualisiert oder angepasst werden.

Die Nutzung der eigenen Desktops wird wiederum in drei Zuweisungsszenarien unterschieden:

• Dedicated / Dedizierter Arbeitsplatz für einen Benutzer, zumeist liegt hier eine ganze Windows Installation für einen Benutzer vor
• Assigned / Zugewiesener Arbeitsplatz – der Benutzer bekommt beim ersten Zugriff eine VDI zugewiesen, die dann fortan nutzen kann
• Pooled / Der Benutzer bekommt einen Arbeitsplatz aus einem Pool von gleichartigen Arbeitsplätzen zugewiesen.

Bereitstellung der zugrundeliegenden Windows-Installation

Die zugrundliegende Windows Installation kann über mehrere Verfahren bereitgestellt werden und hat Einfluss auf die Wartung und Pflege. Zumeist werden gewisse Benutzer-Zuweisungsszenarien auch wiederum über die gleichen Bereitstellungsverfahren umgesetzt, eine „Faustformel“ gibt es hier jedoch nicht.

• Jeweilige Installation von Windows auf eine Hardware, gerne auch „Blech“ genannt.
• Jeweilige Installation von Windows auf einem Hypervisor (vmware ESX(i), XENServer, Hyper-V, uvm.)
• Nutzen einer gemeinsamen Installation (Master-Image) und speichern der Änderungen auf Basis eines Hypervisors (Linked Clone)
• Streaming einer gemeinsamen Installation (Master-Image) auf einen Hypervisor

Bereitstellung der darauf genutzten Software bzw. Applikationen

Zumeist hat die Bereitstellungsvariante und somit Notwendigkeit der Software Einfluss auf die Bereitstellung des Windows Systems. Bei der Bereitstellung der Software bzw. Applikationen gibt es die nachfolgenden Möglichkeiten:

• Jeweilige Installation der Software auf einem Windows Betriebssystem
• Anzeige der Software von einer anderen Windows Installation. Hier ist die sogenannte Anwendungspublizierung („Published Apps“) von XenApp, XenDesktop bzw. Terminal Server gemeint. Die Software selbst wird dann auch auf dem entfernten Windows ausgeführt und nur auf dem genutzten Arbeitsplatz angezeigt.
• Anwendungsvirtualisierung durch unterschiedliche Produkte und Methoden wie Microsoft App-V, vmware Thinstall/ThinApp, Citrix Streaming, uvm. Die Zuweisung der Applikation und der Zugriff darauf geschieht dabei in den meisten Fällen auf Basis von Windows Benutzergruppen.

Benutzerprofil Verwaltung

Wenn es nicht schon zu einem anderen Zeitpunkt geschehen ist, muss man sich spätestens bei dem Gedanken zur Einführung einer VDI Lösung Gedanken machen, wie die Benutzerprofile verwaltet werden.

Da der Benutzer nicht bei jedem Zugriff zwangsweise den gleichen Desktop nutzt, so sollte man gerade deswegen dem Benutzer den Zugriff auf seine individuellen Internet Favoriten, Software-Einstellungen und vieles mehr sicherstellen.

Eine Ausnahme stellt gegebenenfalls der Einsatz von vollinstallierten dedizierten Arbeitsplätzen dar. Alle anderen Szenarien verlangen nach einer zentralen Profilspeicherung bzw. Verwaltung. Auch hier gibt es neben den Lösungen von Microsoft wie Roaming Profiles, Folder Redirection und UE-V auch weitergehende Lösungen von Drittanbietern wie Citrix, Sepago, AppSense uvm.

Was ist nun die richtige Lösung für mich bzw. mein Unternehmen?

Diese Frage lässt sich leider nicht so einfach beantworten, wie einem so mancher Hersteller das suggeriert.

Somit ist eine Analyse notwendig, um ein VDI Projekt zielsicher und mit dem gewünschten Erfolg umzusetzen. Wobei in mancher Situation ein Testaufbau, der von den Grundlagen nicht einmal 100% sein muss, eine Abschätzung ermöglicht, ob die Lösung mit der benötigten Software funktioniert und die Akzeptanz bei den Schlüsselpersonen vorhanden ist.

Vorgehensweise

Ein VDI Projekt gliedert sich wie viele andere Projekte in die Phasen: Analyse, Pilot und Betrieb

Analyse

Die ersten Schritte in Richtung VDI bestehen u.a. aus den folgenden Aufgaben:

• Bestimmen und Analysieren der Benutzer-Kreise und Nutzung, der sogenannten Use-Cases.
• Bestimmen der dazu benötigten Software bzw. Applikationen. (Software-Inventarisierung)
• Werden die Anwendungen auch noch genutzt? (Software Nutzungsanalyse)
• Dokumentieren der Abhängigkeiten der Anwendungen in Form von Peripherie (USB,etc.) und Netzwerk- bzw. Datenbankzugriff?
• Gibt es für die Software Abhängigkeiten in Bezug auf die Lizenzierung?
• Analysieren der Kosten (Hardware, Software-(Lizenzen), Consulting, Training)

Der Analyse und Entscheidung folgt die Pilotierung und je nach Erfolg der Live-Betrieb.

Strategie, Vorteile und Bedenken …

Wenn die IT Strategie besagt, dass man die Arbeitsplätze in Zukunft zentral bereitstellen möchte,

so hat man sich für VDI entschieden und wird sich für jeweilige Nutzung auch eine Bereitstellung definieren. Die Lösung ist zumeist eine Mischung aus den oben vorgestellten Möglichkeiten.

In manchen Projekten betrachtet man von vornherein nur den VDI Einsatz für einen ganz bestimmten Einsatzzweck, in anderen Projekten ist das wiederum das Ergebnis der Analyse. Das ist zumeist dann der Fall, wenn man die Vorteile von VDI nutzen möchte, jedoch nicht zwanghaft alles virtualisieren möchte.

Der hier aufgeführte Wiki Artikel gibt einen guten Einblick bzgl. der Vor- und Nachteile in Bezug auf Terminal Server, der sich jedoch auch auf VDI anwenden lässt: http://de.wikipedia.org/wiki/Terminalserver

Was spricht absolut für VDI …

• Zentrale Arbeitsplatzbereitstellung und somit performanter Zugriff auf Unternehmensinformationen (Dokumente, Datenbanken, etc.).
• Sicherung der Unternehmensdaten in Form von zentraler Datensicherung und zentralem Zugriffsschutz.
• Zugriff von einer Vielfalt von Endgeräten von nahezu jedem Ort.

Was sind häufige Hürden …

• Viele individuelle Software machen den „Grundgedanken“, der Nutzung von Master-Images, „kaputt“.
• Peripherie-Hardware funktioniert nicht mit dem virtuellen Arbeitsplatz.
• Die Softwarefunktion muss auf dem virtuellen System gewährleistet sein.
• Nicht zuletzt stellt sogar in vielen Fällen die Akzeptanz der Endbenutzer eine Hürde dar. Diese sollte so früh als möglich eingeholt und getestet werden, wenn das VDI Projekt nicht von der Unternehmensführung als strategisch gesehen und unterstützt.
• Der Zugriff auf die Informationen und Software ist nur bei einer Verbindung in das Unternehmen möglich.

Nun ein paar Aussagen hinsichtlich VDI und Client-Management …

• Die Nutzung von Shared-Desktop Umgebungen und/oder Master-Images erlaubt die Aktualisierung auch außerhalb des Nutzungszeitraumes.
• Wenn Master-Images nicht zum Einsatz kommen, wird zur optimalen Verwaltung eine Client-Management Lösung benötigt.
• Auch Master-Images bedürfen regelmäßiger Aktualisierungen, gerade wenn, wie so häufig, darin auch noch die Adobe Produkte Reader und Flash, sowie Oracle JRE installiert sind.
• Wenn man eine Vielzahl an Master-Images vorhält, macht es Sinn einen Automatismus zu entwickeln der diese Master-Images aktualisiert.
• Bei tatsächlichen Installationen, sowohl von Software als auch Betriebssystemen, wird ein Client-Management auch in einer VDI Umgebung benötigt.
• Eine tatsächliche Installation ermöglicht auch in Ausnahmefällen die manuelle Installation einer Applikation.
• Viele tatsächliche Installationen nutzen den „teuren“ Festplattenplatz im Rechenzentrum.
• Applikations-Virtualisierung kann nur ca. 70% der Software tatsächlich virtualisieren.
• Der Shared Desktop stellt die günstigste VDI Variante dar.
• Eine VDI Lösung spart in den seltensten Fällen Geld ein, sondern stellt weitere Möglichkeiten zum Zugriff (Zeit, Ort oder Gerät) dar.
• Mit VDI gewinnt man an Flexibilität und kann häufig neue Bedarfe schneller bereitstellen.
• Eine optimale Nutzung von VDI („Use Case“) kann über die Zeit auch die Administration für diesen Anwendungsfall minimieren und somit Kosten einsparen.
• Ein VDI Projekt ist auch wieder ein guter Anlass, die eingesetzt Software bzw. deren häufige Vielfalt auf den Prüfstand zu stellen.
• Der Typ und die Anzahl der zugreifenden Endgeräte verlangt nach einer Lösung zur Verwaltung dieser Endgeräte: Client-Management, Mobile Device Management oder ThinClient Management.
• Bei nicht Shared Desktop wird eine Software-Inventarisierung als Grundlage für das Lizenz-Management benötigt.

Dieser Artikel ist in Zusammenarbeit mit Marco Hartmann entstanden.

Der Beitrag VDI und Client-Management erschien zuerst auf Workplace Management Blog.