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.

Matrix42 Management Console (Administration.dll)

Empirum Agent

Empirum Inventory

Empirum Application Usage Tracking (AUT)

Matrix42 Patch-Management Client

Das Programm zum Auslesen der verfügbaren Empirum Versionen von deinem EmpirumServer findest du im folgenden Blog-Artikel Matrix42 Empirum Version und Dateiversionen. Falls Du Versionen im Einsatz hast, die hier noch fehlen, so lasse mir die Ausgabedatei des Tools und Hinweise zu deiner Version zukommen. Danke!

Der Beitrag Empirum Versionsinformationen 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.