Diese Meldung erscheint, wenn kein passender Eintrag oder kein eindeutiger Eintrag in der DeviceMapping.xml gefunden werden kann. Die DeviceMapping.xml wird während der OS Installation hergenommen, um von den Hardwareeigenschaften (MAC oder UUID) auf den späteren Computernamen und Workgroup/Domain zu verweisen.

Die ersten Troubleshooting Schritte …

(1) Die Voraussetzung für einen Eintrag in der DeviceMapping.xml ist: Die Eigenschaft des Computerobjektes muss „PXE fähig“ markiert haben – er muss jedoch nicht unbedingt PXE aktiviert sein!

(2) Wo liegt die DeviceMapping.xml? Die Datei ist im folgenden Verzeichnis abgelegt: \\%EmpirumServer%\Configurator$\Empirum\Configurator\Values
Folgendes sollte geprüft werden: Ist die Datei aktuell bzw. so aktuell wie die letzte Änderung? Geschieht die OS Installation an einem SubDepot, so gilt dies für das SubDepot! Hier muss ggf. der DepotSync betrachtet werden, wenn die Datei am HauptServer anders bzw. vollständig ist. Ergo zuerst die Datei auf dem HauptServer und anschließend auf dem SubDepot prüfen.

(3) Ist die MAC-Adresse / UUID in der DeviceMapping.xml zu finden und nur einmal (1x) vorhanden? Dazu die Datei mittels eines Editors öffnen und darin nach den Werten (Computername, MAC, UUID) des Computerobjektes suchen.

(4) Falls der Computer, die MAC-Adresse oder die UUID nicht in der DeviceMapping.xml zu finden ist: „Empirum-Backend Task Queue Host (64 bit)“ Dienst prüfen, da er für die Erstellung der Datei zuständig ist. Ist der Dienst gestartet und läuft – funktioniert der Dienst einwandfrei? Die Log-Datei zum BTQH64 Dienst befindet sich hier: „C:\ProgramData\Matrix42\Logs\BackendTaskQueueHost64\BackendTaskQueueHost64.log“

Wird die MAC-Adresse oder UUID mehrfach gefunden, dann diese Informationen (Computernamen) nutzen und in der EMC an den Computerobjekten nachschauen.

Löschen doppelter UUIDs aus der Empirum Datenbank

Doppelte UUIDs aus der Empirum Datenbank können wie folgt gelöscht werden:
Empirum bzw. Matrix42 Management Console starten, Konfiguration, Boot Konfiguration – im Menü unter: Extras, Ungültige UUID’s
Suchen und Löschen der doppelten Einträge per Auswahl und Papierkorb Symbol. Bitte beachte die Hinweise, wenn ein Eintrag nicht gelöscht werden kann. Der Hinweis zeigt an, welche Computernamen die gleiche UUID eingetragen haben. Anhand der letzten Inventarisierung o.ä. kann man erörtern, welches das aktuelle Computerobjekt ist.

Wenn die zuvor genannten Hilfestellungen alle nicht geholfen haben …

Weitere Infos am Client (vor der Windows Installation)

Wenn die Meldung erscheint gelangt man direkt in das Log per Tastenkombination „STRG+L„. In der Log-Datei sucht man am besten nach „ComputerIdentification.ResolveComputername„. Nachfolgend ein beispielhafter Auszug:

[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Retries at copying DeviceMapping XML file: 10
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Copying DeviceMapping XML file (retry 0/10): Values\DeviceMapping.xml
[INFO] [ComputerIdentification.ResolveComputerName] SMBIOS UUID: 4c4c4544-004a-5710-8038-c8c04f335831
[INFO] [ComputerIdentification.ResolveComputerName] Physical addresses: 90B11C147953
[INFO] [ComputerIdentification.MapDevice] Solved computer name 'LABPC001' in domain 'IMAGOVERUM' for SMBIOS UUID '4c4c4544-004a-5710-8038-c8c04f335831'
[INFO] [PeAgent.ResolveComputerName] Resolve computer name: LABPC001 in domain IMAGOVERUM
[INFO] [PeAgent.CopyDeviceMappingXmlFileFromServer] Finished copying DeviceMapping.xml from the Empirum Server.

Weitere Infos am Client (nach der Windows Installation) …

ALT-TAB zum Wechseln in den Hintergrund und anmelden als Admin.
Höchstwahrscheinlich muss dieser Vorgang 2x getätigt werden, da man beim ersten Versuch durch einen Neustart schnell wieder abgemeldet wird.
Nun findet man die entsprechende Log-Datei im %Programdata%\Matrix42\Logs\UAF Ordner.
Die Stelle, nach der man sucht, ist identisch zu den oben aufgeführten Meldungen.

UUID anstatt MAC Adressen bevorzugen

Die Eindeutigkeit ist mit der Nutzung von UUIDs anstatt MAC Adresse (siehe PXE Dienst im Empirum DBUtil) prinzipiell besser.
Wenn aus Gründen …

• nur die MAC Adresse bekannt bzw. einfacher zu pflegen ist
• nur die MAC Adresse eindeutig ist, weil es mehrere Hardware mit identischer UUID gibt
• die MAC Adresse genutzt wird, …

gelten trotzdem die gleichen Regeln – Eindeutigkeit bei den MAC Adressen am Computerobjekt!

Falls man mehrere Notebooks mit einem externen USB zu Ethernet Netzwerkanschluß installieren möchte, muss man bei Bedarf die Netzwerkadresse am bereits installierten Gerät anpassen, falls die MAC-Adresse das führende Merkmal für die PXE-Installation ist.

Der Beitrag Empirum: Failed to copy a sufficient DeviceMapping.xml erschien zuerst auf Workplace Management Blog.

Da war es von Vorteil, dass man mit mehreren Kunden in Kontakt steht und ich ähnliches schon einmal gehört hatte. Meine Nachfrage hat ergeben, dass es dazu derzeit ein spezielles Firmware Update gibt, welches im besten Falle in Zukunft im BIOS Update erhalten sein wird.

Dieses Firmware Update (USB PD Firmware Update Tool V1.0C013.1) sollte bei der oben genannten Konstellation eingespielt werden. Zur Sicherheit sollte geprüft werden, ob diese Firmware nicht sogar in Zukunft im BIOS Update enthalten ist.

USB PD Firmware Update Tool (direkter Link) – dieses Tool sollte auch unter „Flash -Firmware“ bei den einzelnen Modellen aufgelistet sein.
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=8CA9F197-A6BF-4C0E-8DDA-E82ECF2FC2B0

Portreplikator
https://www.fujitsu.com/de/products/computing/peripheral/accessories/connectivity/usb-port-replicator-pr09.html

Wer das Device Update per Softwareverteilung installieren mag, dem sind die nachfolgenden Kommandozeilenparameter und Rückgabewerte ans Herz zu legen.

Parameter

/N für silent
/X für kein automatischr Reboot

ExitCodes

0 Normal end
1 Tool is already running
2 Invalid parameter
3 Capsule file is not found
4 Incorrect signature
5 Abnormality is found in Capsule file
6 AC adapter is not connected
7 Target device is not connected
8 Target device is not found
9 Failed to deploy driver
10 Failed to load driver
11 GABI API call error
12 Failed to proceed Capsule
13 Not Fujitsu PC
14 Battery capacity is not enough
15 FUJ0420, FUJ0430 Device Driver is not installed
16 FW version check error
17 FW GUID mismatch
255 Other error

Der Beitrag Fujitsu Lifebook E und Portreplikatoren Probleme erschien zuerst auf Workplace Management Blog.

Was passiert da?

Nachfragen, Recherchen und eigene Tests haben folgendes ergeben. Microsoft installiert direkt nach der Windows Installation ein Windows Update und führt direkt danach einen Neustart durch. Voraussetzung dafür ist: der Computer verfügt über eine Internet Verbindung und es liegt eine bestimmte Windows Version vor. Das Update, das installiert wird, ist das „KB5005716“. Mit diesem Update passt Microsoft die OOBE Phase an, um Windows 11 zu „promoten“.

Weitergehende Informationen

Bis dato sind keine Einstellungen bekannt das zu unterbinden. Wenn man den folgenden Artikel aufmerksam liest, wird das auch nicht geplant sein. Wie heißt es im nachfolgenden Link zu „Windows updates during Windows 10 OOBE“ so schön: „…Critical driver updates, and critical Windows zero-day patch (ZDP) updates, will begin downloading automatically during OOBE after the user has connected to a network. The user can’t opt-out of these critical updates as they are required for the device to operate properly. …“

Hier geht es zur KB5005716 Update Beschreibung

Weitere Meldungen aus dem Netz, auch Meldungen von SCCM Nutzern über Probleme:
https://www.reddit.com/r/SCCM/comments/q2msk7/kb5005716_breaks_osd/
https://www.borncity.com/blog/2021/10/09/windows-10-oobe-update-kb5005716/

Workaround / Lösung

Die Hinweise im Netz gehen in die Richtung, dass obige Update in seine Windows Quellen zu integrieren. Dies funktioniert, wie ich auch bereits erfahren habe. Ein Veränderung der Windows Quellen mache ich selbst ungern, da sich die Windows Quellen dann nicht so einfach austauschen lassen.

Das hat mich dazu gebracht, ein PreOS Paket zu erstellen, welches man direkt nach dem PxeOffAndReboot einreiht. Dies installiert „geplant“ das Update und führt einen gewollten Neustart durch. Somit wurde die Installation zuverlässig zu Ende geführt. Voraussetzung ist bis dato mindestens Windows 10 Build 20H2 (2009).

PreOS Paket

Install-MS-KB5005716_x64 (327 Downloads )
SHA256 Hash der Downloaddatei: C5E6E64DBFD4E654C9D2E1F4DA5036B6528F817449653A4D52211156DF81ECA0

Hilfestellung: Hinweise, wie man ein PreOS Paket einbindet, findet ihr hier.

Der Beitrag Ungeplante Neustarts während der Windows 10 Installation durch KB5005716 erschien zuerst auf Workplace Management Blog.

Empirum OS-Installer – die drei Phasen

Teilen wir die Probleme ein, in die drei Phasen der OS-Installation per Empirum WinPE.

• PXE-Boot
• WinPE
• Windows

PXE Boot

A.) Der PXE Boot funktioniert nicht bzw. hat noch nie funktioniert.
Die Switche bzw. VLANs müssen den Broadcast an den PXE-Server (zusätzlich zum DHCP Server) weiterleiten, gerne wird hier der Begriff „IP Helper“ aus der Cisco Welt hergenommen.
Die Windows Firewall muss den eingehenden Netzwerkverkehr auf den PXE- und TFTP-Ports zulassen. Die freizugebenen Ports sind abhängig von PXE Einstellungen. Wer auf Nummer sich gehen will, gibt die UDP Ports: 67,68,69,4011,10042 frei.

B.) Kein Computer führt mehr einen PXE-Boot durch, obschon dies vorher der Fall war.
In diesem Fall, schaut nach, ob Euer Empirum PXE-Dienst weiterhin läuft und erreichbar ist.

C.) Andere Computer starten einen PXE-Boot, doch dieser eine Computer nicht. Dies hat zumeist die folgenden Ursachen:

• Überprüft die beim Computer hinterlegte MAC/UUID mit den Werten die im BIOS angezeigt werden. Ausnahmen sind natürlich externe Docking-Stationen oder Netzwerkadapter.
• Wird MAC Passthrough genutzt und welche Einstellungen dazu bietet das BIOS. MAC Passthrough ist auch sehr abhängig vom Windows Treiber.
• Ist das Computerobjekt in den Eigenschaften als „PXE fähig“ markiert?
• Wenn dies alles passt, so führt bitte über Matrix42 DBUtil das SQL Script: „OS_CleanupNonUniqueDhcpEntries.sql“ aus dem Verzeichnis Empirum\Empirum DBUtil\Scripts\SQLServer\Custom aus. Mit der Ausführung dieses Skripts könnt ihr nichts kaputt machen! Es kann auch mehrfach ausgeführt werden.

D.) Wenn Sie diesen Bildschirm sehen, dann haben sie die vorgenannten Probleme nicht, nicht mehr oder erfolgreich gemeistert.

WinPE

Hast Du es in die WinPE Phase „geschafft“, sieht Du einen grauen Hintergrund oder gar das Matrix42 Logo, und eine Fortschrittsanzeige, wie hier abgebildet.

Die letzten drei Schritte in der Anzeige (wie in diesem Screenshot) bekommst Du erst mit der WinPE Umgebung neuer als 1.8.3 aufgelistet. Schlägt der „Connect to server“ fehl, dann muss man sich zumeist um die Einbindung der passenden Treiber kümmern (siehe Einbinden der WinPE Treiber). Alternativ kann es auch zu Problemen mit der Anmeldung (Benutzername und Kennwort) kommen. In das Log kommt man mit STRG+L. Dies kann man zur genaueren Analyse auch auf einen USB-Stick kopieren.

War die Verbindung erfolgreich und es erscheint die vorherige Meldung, dann liegt es daran, dass kein eindeutiger Eintrag (kein oder doppelter) in der DeviceMapping.xml (Empirum\Configurator\Values) vorhanden ist. Dazu kann man die DeviceMapping.xml mit einem Editor starten und prüfen, ob der Computername gefunden werden kann. Falls ja, nutzt die dazugehörige MAC Adresse oder UUID und sucht danach in der Datei – wahrscheinlich findet ihr einen weiteren Computer mit identischen Werten. Dieses Problem muss behoben werden!

Unabhängig der genannten Probleme, kann es sein, dass der EmpirumAgent Benutzer keine Schreibberechtigungen auf den Empirum\EmpInst\Wizard\OS\WinPEStatus Ordner hat.

Sind all diese Hürden genommen und es kommt trotzdem zu Problemen, dann liegt das zumeist an der Ausführung eines der WinPE Pakete. In seltenen Fällen sollte man prüfen, ob das Paket tatsächlich auf dem EmpirumServer oder dem SubDepot vorhanden ist. Ansonsten sind es dann Probleme bei der Parametrisierung der Pakete. Da hilft Euch jedoch das Log in WinPEStatus Order weiter bzw. sogar häufig das SWDepotLog in der Management Console.

Einbinden der WinPE Treiber

Für die WinPE Phase müssen die Treiber (zumeist nur Netzwerkkartentreiber) über die Management Console, Konfiguration, Boot Konfiguration eingebunden werden.
Dazu die Erweiterten Eigenschaften aktivieren (oben rechts) und bei Zusätzliche Treiberverzeichnisse ein Ordner angeben, in dem die Treiber abgelegt sind oder werden.Ich empfehle ein Ordner unterhalb von Empirum\EmpInst\DRV anzulegen und dort die Treiber ggf. nach Modell sortiert abzulegen. Die Treiber werden auch aus den Unterverzeichnissen (rekursiv) hinzugefügt, so muss man nicht pro Treiber ein Ordner in der Oberfläche angeben. Hast Du diesen Ordner bereits, brauchst Du die Treiber nur in diesem Ordner zusätzlich abzulegen und die Boot Konfiguration neu zu speichern, über den „Speichern“ Button (unten rechts).

Du kannst dann an Deiner Boot Konfiguration verschiedene Zustände feststellen – Sanduhr, Zahnräder und am Ende einen grünen Haken. Sobald die Boot Konfiguration erfolgreich neu erstellt wurde, kannst Du den nächsten Boot-Versuch starten.

Import-Certificate -FilePath "<EmpirumLaufwerk>:\Empirum\EmpInst\Sys\Images\WinPE\binaries\UAF\matrix42ag.Cer" -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

Möchtest Du nicht den Netzwerkartentreiber für die einzelnen Modelle raussuchen bzw. aus dem Windows 10 Treiberpaket entnehmen, so kannst Du auch ein komplettes WinPE Treiberpaket des jeweiligen Herstellers hinterlegen. Dazu jedoch immer erst das alte Verzeichnis löschen und anschließend das neue kopieren/ablegen.

Hier ein paar Beispiele:

• Dell Command | Deploy WinPE Driver Packs
• HP Client Windows PE Driver Packs

Windows

Mit den vorherigen Tipps sollte sich das Windows automatisiert installieren lassen. Ein weiterer häufiger Knackpunkt kommt im Anschluss an die Windows-Installation.
In der Management Console kann man noch eine erfolgreiche Installation von PxeOffAndReboot verzeichnen, jedoch schreitet die Installation nicht weiter voran.

Am Client sieht man dann eine durchlaufende Fortschrittsanzeige vor dem ausgeblendeten Windows-Hintergrund und das System führt alle 5 Minuten einen Neustart durch.
Ein weiterer Indiz ist, dass im PXE-Log des Computers während des DriverIntegration Pakets kein Treiber für das Model kopiert wurde. In diesem Fall fehlt in den meisten Fällen mindestens der Netzwerkkartentreiber für Windows bzw. das komplette Treiberpaket. Diese integriert man mit Hilfe des WinPEDriverAssistant’s aus dem Empirum\AddOns\WinPEDriverAssistant Ordner.

Die Treiber, ganz gleich ob *.zip, *.cab oder ein Ordner werden dann unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt. Du kannst die Treiber auch direkt dort ablegen und nur den Namen in das Treiberfeld einfügen – und nicht über das Ordner Symbol für den Import daneben gehen.

Dazu benötigt man die Hersteller und Modellbezeichnung und die entsprechenden Treiber.
Die Hersteller und Modellbezeichnung könnt ihr mit dem HardwareInfo Paket auslesen, oder wie gerade schon beschrieben, schaut ihr in das PXE-Log des Computers. Die erste Meldung ist „Using OS specific driver assignment for vendor …“.

Die Treiber dazu bekommst du bei den Herstellern. Dazu hatte ich bereits beim Beitrag für EPE die Seiten der Hersteller zusammengefasst.
Hast Du die Windows 10 Treiber eingebunden und das DriverIntegration Paket kopiert die Treiber, wie im zu vorigen Screenshot zu erkennen („Using the drivers: …), dann sollte es auch keine Probleme nach der Windows Installation geben.
Wenn es trotz Windows 10 Treiber nach dem PxeOffAndReboot nicht „weitergeht“, dann solltest Du schauen, dass du in Empirum DBUtil die UUID anstatt der MAC als „führendes“ Merkmal nutzt.

Mit diesen Tipps bin ich bester Dinge, dass Du eine erfolgreiche Windows Installation hinbekommst.

Als Grundlage solltest Du die anderen Blog Beiträge erfolgreich umgesetzt haben.
Zum Troubleshooting hatte ich bereits diesen Beitrag hier geschrieben.

Der Beitrag Empirum WinPE – neues Computermodell erschien zuerst auf Workplace Management Blog.

Der WinPE PXE-Boot bootet ein von Empirum modifiziertes bzw. ergänztes Windows PE. Das WinPE wurde im Bedarf um weitere Treiber ergänzt, aber auf jeden Fall um nützliche Libraries und den Matrix42 UAF Dienst. Letzterer führt die zugewiesenen PreOS-Packages (Powershell „Pakete“) aus und bedient sich der gesetzten Variablen. Diese zugewiesenen Pakete beschreiben die Art und Weise, wie z.B. die Betriebssystem-Installation stattfinden soll. Auf weitere Einzelheiten und Vergleiche mit dem EPE Boot werde ich an anderer Stelle eingehen.

So gliedert sich der WinPE PXE-Bootvorgang in:

• Laden und Ausführen der WinPE Umgebung
• Laden des Matrix42 UAF Dienstes
• Verarbeiten der PreOS-Packages

Nun zu möglichen Problemen und Maßnahmen/Hilfestellungen zur Bearbeitung.

Laden der Windows PE Umgebung

Schlägt bereits das Laden der WinPE Umgebung fehl, so könnte dies ggf. an der TFTP Blocksize liegen. Diese kann bis Empirum v19 global in der .config Datei des BTQH (Backend Task Queue Host Services) Dienstes eingestellt werden. Standardmäßig steht dieser Wert auf 4096. Mit größeren Werten kann man den Boot beschleunigen. Damit kann er jedoch unzuverlässiger werden. In einem Falle musste ich die Größe auf 1456 festsetzen, damit der Boot zuverlässig an allen Standorten funktioniert hat.

Windows PE ist gestartet

Sobald das Windows PE gestartet ist, kann mittels STRG+C auf die Kommandozeile und per STRG+L direkt auf die Log Datei des UAF Dienstes zugegriffen werden. Die Windows PE Umgebung befindet sich unter X:\. Der UAF Dienst liegt im Ordner X:\UAF. Das wpeinit.log unter X:\Windows\System32.

Herstellen einer Netzwerkverbindung

Damit der im WinPE implementierte UAF Dienst seine Aufträge abarbeiten kann, bedarf es einer grundlegenden Netzwerkverbindung. Diese Verbindung wird durch Laden und Starten des Netzwerk-Stacks durch die  X:\Windows\StartNet.cmd und nachvollziehbar durch die wpeinit.log  vorgenommen (QueryAdapterStatus ist hier das passende Suchwort). Kann das WinPE keine Netzwerkverbindung aufbauen, kann es notwendig sein, das WinPE mit Netzwerk- und/oder Speicherverwaltungs-Treibern (Storage) zu versorgen. Dies geht über die Bootkonfiguration und wird in einem anderen Beitrag erläutert.

DeviceMapping.xml

Die DeviceMapping.xml im \\%EmpirumServer%\Values$ Verzeichnis stellt die Verbindung MAC-Adresse bzw. UUID zum Computernamen her. Somit darf jede MAC Adresse bzw. UUID auch nur einmal in der DeviceMapping.xml vorhanden sein. Beim Einsatz von SubDepots muss zusätzlich beachtet werden, dass es für die DeviceMapping Datei einen separaten SyncJob (ESubdepot_DeviceMapping) gibt, der zugewiesenen werden muss.

UAF – Auftragsverarbeitung

Das Vorgehen des UAF Dienstes wird im Matrix42.Platform.Service.Host.log festgehalten. Wie zuvor beschrieben, kann dies per STRG+L geöffnet werden. Um Neuerungen mitzubekommen, muss man ggf. das Fenster schließen und erneut aufrufen. Nach einer UAF Sitzung wird das Log auf den EmpirumServer zurückgeschrieben. In Empirum v18 bzw. WinPE 1.4.14 ist das das Verzeichnis \\%EmpirumServer%\EmpInst$\Wizard\OS\Auto\<letzten8 Stellen der MAC-Adrese> bzw. <UUID>.

PXE-Image / WADK Version

Wenn man die neuen WinPE Versionen einsetzt, sollte man wie ein Blog-Leser zusätzlich darauf hingewiesen hat, sicherstellen, dass man die aktuelle WADK Version auf dem EmpirumServer installiert hat. Matrix42 empfiehlt den Einsatz der WADK Version 1903 (eine Version 1909 wird nicht von Microsoft bereitgestellt). Mit dem WADK 1903 habe ich bis dato keine schlechten Erfahrungen gemacht, ganz gleich ob Windows 10 Enterprise 2016 LTSB oder Windows 10 Build 1909 installiert wurde. Zusätzlich sollte man darauf achten, dass die PXE-Image Erstellung (unter Konfiguration\Boot-Konfiguration) erfolgreich ist. Die aktualisierten PreOS Pakete funktionieren auch nur zuverlässig mit einer zu der Version passenden Boot-Konfiguration bzw. aktualisierten PXE-Image.

Der Beitrag Empirum WinPE Boot Troubleshooting 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.

Möglichkeit 1 – Der Endbenutzer darf seine Netzwerkeinstellungen verändern Ist ein Benutzer Mitglied der Gruppe „Network Configuration Operators“, so kann er die Netzwerkeinstellungen selbst verändern.

Möglichkeit 2 – Der Endbenutzer darf lokale Drucker installieren Damit ein Windows Benutzer auch lokale Drucker installieren darf, ist die Konfiguration einer Windows Gruppenrichtlinie (GPO) notwendig. Gruppenrichtlinien sind zumeist eine Veränderung von Registry Werten. Beispiele zur Veränderung der Registry sind unten aufgeführt.

Hier geht es zu weiterführenden Informationen zu diesem Thema:
Configure Computer Policy to Allow Non-Administrators to Install Specific Devices
http://technet.microsoft.com/en-us/library/cc725772(v=ws.10).aspx#bkmk_1

System-Defined Device Setup Classes Available to Vendors (Windows Drivers)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx

Hier ein Registry Auszug, um dem Endbenutzer zu erlauben Drucker zu installieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions]
 "AllowUserDeviceClasses"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses]
 "1"="{4D36E979-E325-11CE-BFC1-08002BE10318}"

Der Beitrag Druckerinstallation für Windows Benutzer erschien zuerst auf Workplace Management Blog.

• Microsoft Remote Connectivity Analyzer
• AccessMyLan ActiveSyncTester

Diese Werkzeuge bieten neben der Prüfung auch Hinweise, wie ein gegebenenfalls vorhandenes Problem behoben werden kann.

Der Beitrag ActiveSync Funktionstest – E-Mails für mobile Endgeräte erschien zuerst auf Workplace Management Blog.