ClearAllDisks Variable erstellen

Möchte man die vorgenannte Funktion nutzen, so erstellt man die Variable „ClearAllDisks“ vom Typ Zahl in der Variablendefinition: DiskPartitioning.
Dazu wählt man in der Matrix42 Management Console, Administration, Extras, Variablendefinitionen … aus und navigiert zur vorhandenen Variablendefinition „DiskPartitioning“.
Durch einen Doppelklick oder der Auswahl und Bearbeiten, landet man in den Eigenschaften der Variablengruppe DiskPartitioning.
Hier fügt man die Variable mit einem Klick auf das „+“ Symbol hinzu.

Setzen der Variable

Anschließend setzt man diese Variable für einen Computer, eine Konfigurations- oder Zuweisungsgruppe.
Weitergehende Informationen zur Übernahme des Wertes für untergeordnete Objekte findet man hier.

Matrix42 Hilfe

Anbei der Text aus der Empirum Hilfe. Über diese Variable, die Sie selbst hinzufügen müssen, können Sie beim Ausführen des DiskPartitioning Paketes alle Festplatten bereinigen.
Hierzu muss man in der EMC > Administration unter „Extras > Variablendefinitionen“ die Variable „ClearAllDisks“ als Zahl zu DiskPartitioning hinzufügen und diese auf 1 setzen.

Der Beitrag Empirum WinPE – Löschen von Partitionen erschien zuerst auf Workplace Management Blog.

Prüfmöglichkeiten

Die neuen Vorbedingungen sind „universal“ einsetzbar und können folgende Eigenschaften prüfen:

• Registrierung
• WMI
• Datei
• Ordner

Ideen

Nachfolgend möchte ich nicht auf alle Möglichkeiten eingehen, euch jedoch ein paar Anregungen geben, die ich schon genutzt habe.

• Ist das .NET Framework in einer bestimmten Version oder neuer installiert?
• Hat das Windows einen bestimmten Versionsstand?
• Handelt es sich um einen bestimmten Hardwaretyp?
• Ist eine VPN Verbindung aktiv?

Ihr könnt auch mehrer Bedingungen „UND“ oder „ODER“ verknüpfen, wie ich das schon für Treiber gemacht habe. Vielleicht habt ihr auch coole Ideen oder Einsatzmöglichkeiten für Euch erkannt und wollt diese hier teilen. Ich bin gespannt und freue mich auf Feedback!

Beispiel

Zumeist habe ich bis dato auf Registry Werte geprüft, wie beim nachfolgenden detaillierteren Beispiel: „Ist das .NET Framework in einer bestimmten Version oder neuer installiert?“

Hier nochmals die Werte für eine einfachere Eingabe:

Registry Wert vergleichen
Registry Pfad: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\V4\Full
Wert Name: Release
Vergleichstyp: Nummer
Operator: Größer als oder gleich
Wert: 461808

Übertragen von Vorbedingungen

Die Vorbedingungen, wie z.B. eine .NET Framework Voraussetzung beim UEM Agent Paket, müssen bei einer neuen Versionen eines Paketes nicht auch erneut eingeben werden. Zur einfachen Übernahme der vorhandenen Vorbedingungen könnt ihr die Funktion: „Vorbedingungen kopieren“ und „Vorbedingungen einfügen“ nutzen.

Matrix42 Hilfe

Da ich hier jetzt nicht alle Möglichkeiten eingehen werde und eingegangen bin, möchte ich Euch den Eintrag in der Matrix42 Hilfe natürlich nicht vorenthalten.

Der Beitrag Erweiterte Paketvoraussetzungen erschien zuerst auf Workplace Management Blog.

Was ist drin?

Im Empirum WinPE Extension Pack 1.0 sind enthalten:

• WinPE-D-2PXE 1.6
• PrepareDRVbyModel_Packages 1.7
• InstallNetFX3 1.2
• PostOSInstallation 1.2

Was hat sich geändert?

Nachfolgend gehe ich auf die wesentlichen Änderungen in den Paketen ein. Wie ich sehe, hat sich am meisten im WinPE-D-2PXE getan. Dieses Paket hilft immer wieder beim Troubleshooting, da es u.a. schon immer die WADK Version und nun auch die Empirum WinPE Version ausgibt.

WinPE-D-2PXE
liefert Informationen über den Computer und Umgebung

• neben den PXE-Einträgen wird auch eine Log-Datei mit den gleichen Informationen erstellt
• eine Import-Datei für den Matrix42WinPEDriverAssistant wird erzeugt
• die Dateien werden bereits nach dem WinPE 1.8.0 Verfahren übertragen
• die genutzte Empirum WinPE Version wird ausgegeben
• die erkannten eingebauten Festplatten und Netzwerkkarten werden ausgegeben

PrepareDRVbyModel_Packages
ist eine Alternative zum DriverIntegration Paket der Matrix42

• Kosmetik und anpassen von Ausgaben
• kann nun auch für Hardware genutzt werden, die keine Hersteller oder Modell-Information per WMI liefert

InstallNetFx3
installiert/aktiviert das .NET Framework 3.5 aus den zugewiesenen Betriebssystemquellen

• … hatte ich noch nicht veröffentlicht

PostOSInstallation
führt eine Batch Datei nach der Betriebssysteminstallation aus, die als Ersatz für die EmpirumAgent/UEMAgent.bat dienen kann. Diese Batch-Datei spielt auch mit dem PrepareDRVbyModel_Packages Paket zusammen.

• kann nun auch mit der %EmpirumServer% Variable in der PostOSInstall.bat umgehen
  
• öffnet den Firewall Port für den Push von Software Pakete

Weitere Vereinfachung

Die nachfolgende ZIP-Datei enthält nun eine Empirum Struktur, wie ihr die von Matrix42 Hotfixen und der WinPE Erweiterung bereits kennt, und kann „einfach“ in/über die Empirum Struktur kopiert werden.
Zusätzlich habe ich im „Empirum\Configurator\Packages\Matrix42\OSPackages\Drivers“ Ordner eine beispielhafte Verzeichnisstruktur und Setup.inf abgelegt, um mit PrepareDRVbyModel_Packages und PostOSInstallation Treiber nach der Betriebssysteminstallation zu installieren. Das ging schon immer, hat jedoch auch immer wieder nachfragen aufgeworfen, da ich dies nicht genug erläutert und dokumentiert habe. Ich hoffe, es ist nun einfacher aufzugreifen und zu nutzen.

Falls nicht, so gebt mir per Kommentar oder Mail eine Rückmeldung.
Wie immer – viel Spaß und gutes Gelingen!

Empirum WinPE Extension Pack 1.3 (319 Downloads )
SHA256 der Downloaddatei: EE118815DBD4DC80D6CBBFB9855C44C6639D08F63C0B8AE6779104176FB462A2

Empirum WinPE Extension Pack 1.2 (468 Downloads )
MD5 Hash der Downloaddatei: E10E01545793D0C4326D041CC1931FDD920CEAA0

Empirum WinPE Extension Pack 1.1 (551 Downloads )
MD5 Hash der Downloaddatei: 15A1A232F6D0C9124DB85CB14456C5D1D96F6BCA

Der Beitrag Empirum WinPE Extension Pack erschien zuerst auf Workplace Management Blog.

Dazu habe ich von den mir zumeist angetroffenen Anbietern eine Liste zusammengestellt. Die Liste wurde nach keinen Kriterien sortiert! Falls ihr von weiteren Übersichten und Tabellen von Herstellern wisst, so fügt diese doch per Kommentar hinzu. Danke!

• TrendMicro
• McAfee
• Kaspersky
• Sophos
• Sophos Safeguard
• Symantec
• Eset

Der Beitrag Sicherheitssoftware und Windows 10 Kompatibilität erschien zuerst auf Workplace Management Blog.

Empirum PE (Linux)

Das EPE (Empirum PreInstallation Environment) auf Linux Basis verarbeitet mittels des EIS Interpreters die zugewiesenen Jobs (EIS Skripte), die per OS.INI im MAC8 Verzeichnis (letzten 8 Stellen der MAC-Adresse) zugewiesen werden. Die Abfolge der Aufträge sind durch das EIS Skript weitestgehend vorgegeben. An definierten Punkten kann man mittels der Custom EIS Skripte in den Ablauf eingreifen. Bei einer Betriebssysteminstallation werden das Windows PE und die Betriebssystemquellen auf die lokale Festplatte übertragen und von dort die Windows Installation per Windows PE gestartet. Die Installation wird mittels der Betriebssystemvorlage (OS.INI) beschrieben und parametrisiert (Windows Einstellungen, Lizenz-Schlüssel, Partitionierung, Domain-Join, uvm.). Am Ende einer Betriebssysteminstallation wird mittels des Parameters „Befehl“ der Empirum Agent installiert und der Übergang zur Softwareverteilung bereitet.

Empirum WinPE (Windows PE)

Das Empirum WinPE wird ebenso über die Management Console, Konfiguration, Bootkonfiguration erstellt. Bei der Erstellung bedient sich Empirum dem auf dem EmpirumServer installierten WADK (C:\Program Files (x86)\…), nicht dem in Empirum importieren WADK. Das erstellte Empirum WinPE beinhaltet einen EmpirumAgenten (Matrix42 UAF) und diverse WinPE Erweiterungen. Der im WinPE integrierte UAF Agent verarbeitet die zugewiesenen PreOS Pakete (aus der %Computername%.DDC).

Hier gilt die Reihenfolge, von oben nach unten, wie sie im SoftwareDepot festgelegt wurde. Die WinPE Pakete (auf Basis von powershell) werden über die EMC Variablen parametrisiert und nicht mehr über die OS.INI. Deswegen muss bei einer Aktivierung auch kein Haken mehr bei „Betriebssystemkonfiguration (OS.INI) erstellen“ gesetzt werden. Die Variablen bzw. die Variablengruppierungen sind nach den zugewiesenen Paketen benannt (z.B. DiskPartitioning, WindowsInstallation). Im Paket WindowsInstallation wird ebenso ein minimaler Matrix42 UAF Dienst installiert, der nach dem Paket „PxeOffAndReboot“ bis zur Installation des eigentlichen Matrix42 Windows Agenten durch das Paket EmpirumAgentSetup aktiv ist. Somit werden die PreOSPakete bis zum PxeOffAndReboot im Kontext des WinPE ausgeführt und im Anschluss im Kontext des installierten Windows. In dem Installations-Vorgang mittels WinPE stellt die erfolgreiche Ausführung des EmpirumAgentSetup Paketes den Übergang zur Softwareverteilung dar. Eigene PreOS Pakete können mittels Powershell Kenntnissen und dem PreOS Package Editors erzeugt und in die Abfolge eingebaut werden.

PreOS Paket Variablen

Die folgende Variablen bzw. Variablengruppen müssen für eine erfolgreiche Installation per WinPE gesetzt werden.

• DiskPartitioning (optional)
• DriverIntegration (optional)
• WindowsInstallation
• FQDN
• ORGANIZATIONAL_UNIT
• TimeZone
• DomainJoin
• MX42_AGENT_PUSH_PACKAGE_FOLDER

Zu diesem Thema werde ich in Kürze einen gesonderten Artikel erstellen. Wer nicht warten mag, sollte das PDF, dass der Empirum WinPE Erweiterung beiliegt, nutzen.

Vorteil der PreOS Pakete

Die sogenannten PreOS Pakete kann man, wie oben beschrieben, auch selbst erstellen. Damit man die Pakete in Empirum importieren und nutzen kann, muss man diese mit dem PreOS Package Editor erstellen. Durch das beschriebene Konstrukt kommen die Vorteile des WinPE Boots und der einzelnen Pakete erst richtig zum Vorschein. Beispielhaft, kann man bei einer Windows 7 zu Windows 10 Migration direkt auch das BIOS aktualisieren, auf UEFI umstellen, uvm. Diese Möglichkeiten waren mit dem EPE und der EIS basierten Installation nicht bis schwer umzusetzen.

Beispiele selbsterstellter PreOS Pakete

In Kundenumgebungen habe ich bereits Pakete wie:

• BIOS Update
• BIOS Konfiguration in unterschiedlicher Art und Weise
• UEFISecureBootValidator
• PostOSInstallation

erstellt und genutzt.
Einen Teil der Pakete hatte ich bereits veröffentlicht.

In Kürze werde ich ein Update der gesammelten und universellen Werke bereitstellen.

Der Beitrag Empirum WinPE – EPE Gegenüberstellung erschien zuerst auf Workplace Management Blog.

Welche Windows 10 Version ist nun die richtige bzw. passende?

So wie es viele von Windows 7 kennen, gibt es Windows 10 auch in den Editionen Home, Pro, Enterprise und Education. Im Hinblick auf Convertibles, Notebooks und Desktops lasse ich an dieser Stelle die Versionen Mobile und Mobile Enterprise mal unter den Tisch fallen. Für den professionellen Bereich, ergo Unternehmen und Institutionen, wird die Wahl dann logischerweise schnell zwischen Pro oder Enterprise eingeschränkt. Der Funktionsumfang und somit die Unterschiede zwischen Pro und Enterprise sind in der nachfolgenden Tabelle übersichtlich dargestellt. Auffällig ist in dieser Übersicht, dass Bitlocker nun in der Pro Edition bereits enthalten ist dafür einige neue Sicherheitsfunktionen und Virtualisierungsfunktionen erst in der Enterprise Edition verfügbar sind.
Die Entscheidung für die passende Version wird jedoch noch von weiteren Kriterien beeinflusst …

CBB oder LTSB, und was ist das überhaupt?

Einge Personen haben schon davon gehört und sich damit auseinandergesetzt, andere schauen erst einmal verdutzt. Ich fange mal damit an, die Abkürzungen auszuschreiben :).

CBB steht für Current Branch for Business und besagt, dass es alle verfügbaren Windows 10 Funktionen nach erscheinen erhält.

LTSB steht dagegen für Long-Term Servicing Branch und enthält im Gegensatz zu CBB wiederum nicht alle „schönen neuen“ Windows 10 Funktionen.

Current Branch for Business

Current Branch for Business beinhaltet, grob beschrieben, die Funktionen und verhält sich so, wie es der Anwender von „zu Hause“ her kennt. Denn mit der Windows 10 Home Edition wird der Anwender der „Current Branch“ Servicing Option zugeteilt. So bekommt diese Windows 10 Edition neben den Sicherheitsaktualisierungen auch neue Funktionen per Update eingespielt (per Microsoft Definition: Upgrade und Updates). Was das bedeutet, haben Windows 10 Benutzer mindestens zweimal (mit den Builds 1511 und 1607) bereits erlebt. Es wird eine „Neuinstallation“ von Windows 10 durchgeführt und (möglichst) alle Einstellungen und Programme übernommen. Das ich das „möglichst“ in Klammern geschrieben habe, hat auch seinen Grund, da schon mal die ein oder andere Einstellung nach dem Upgrade verloren gegangen ist. Diese Upgrades benötigen zum einen Zeit, Datenübertragungsvolumen und Festplattenplatz.

Long Term Servicing Branch (LTSB)

Die Long Term Servicing Option von Windows 10 enthält im Gegensatz zum zuvor genannten CBB …

• keinen Windows Store (Zugriff auf Apps)
• kein Cortana (Sprachassistenz)
• keinen Edge Browser (neuer Microsoft Internet Bowser)

Dies sind alles neue Windows 10 Funktionen, an denen Microsoft in kürzeren Abständen Neuerungen oder Änderungen einbringen möchte. Die LTSB Versionen erscheinen jährlich mit einem definierten Funktionsumfang und beinhalten deswegen auch zusätzlich die Jahreszahl als Kennung (LTSB 2015, LTSB 2016). Die jeweilige Version wird seitens Microsoft 10 Jahre lang unterstützt (supported) und bekommt nur Sicherheitsaktualisierungen (Updates) zur Verfügung gestellt. Microsoft schränkt die Nutzung bzw. die Wahl der LTSB Option ein, indem diese ausschließlich für Windows 10 Enterprise verfügbar ist. Darüber hinaus gibt es die LTSB Edition von Windows 10 Enterprise nicht normal zu kaufen, sondern nur in Verbund mit einem Volumenlizenz-Vertrag oder MSDN-Abonnement. Bildlich gesprochen, erkläre ich die LTSB Variante immer mit: stellen sie sich ein Windows 7 mit neuem Unterbau bzw. Motor und neuem Startmenü vor und es enthält nicht die von Windows 8.x bekannte „Kacheloberfläche“.

Eine genauere Beschreibung der Servicing Branches und Definitionen findet man unter folgendem Technet Artikel.

Also, welches ist nun die passende Version?

Stand heute wäre ich geneigt zu sagen, Windows 10 Enterprise LTSB ist die „geeignetere“ Edition für Unternehmen. Aber ja, es sieht nicht genauso aus wie zu Hause. Wer hat es nicht schon mindestens einmal gehört „Liebe IT Abteilung, zu Hause habe ich aber …“
Bei den oben genannten Funktionen: Windows Store und den darin verfügbaren Apps, Cortana und Edge sehe ich persönlich heute keinen praktischen Nutzen für die Anwender – deswegen meine Aussage. Aber … was passiert vielleicht schon mit der kommenden Version? Microsoft verhält sich seit dem Erscheinen von Windows 10 sehr agil und teilweise auch rigoros. So hat Microsoft „mal eben“ mit dem „Anniversary Update“ in 2016 auch eine Unterscheidung der Wirkungsweise der Gruppenrichtlinien für die jeweilige Windows Edition eingeführt (Link). Aber vielleicht kommen in Zukunft die Upgrades auch „smarter“ in das Windows 10 System als es heute der Fall ist und „stören“ dann weniger?
Der nächste fragt sich, warum soll ich die Funktionen wie Windows Store, Cortana, Edge installieren, um sie im nächsten Schritt zu deaktivieren, weil ich sie nicht benötige und vielleicht auch vertraue, um sie dann doch zyklisch zeitaufwendig zu aktualisieren.

Entscheidung!

Diese Frage kann ich leider keinem eindeutig beantworten und muss schlussendlich jeder für sich fällen. Jeder bzw. jedes Team muss somit eine Entscheidung unter Berücksichtigung der Rahmenparameter und der Informationen, die ihm zu dieser Zeit zur Verfügung stehen, fällen. Ich weiß, diese Entscheidung ist nicht einfach und ich hoffe, ich kann zumindest mit den aufgelisteten Informationen zur Entscheidungsfindung beitragen.

In diesem Zusammenhang vielleicht auch eine Frage.
Würde Euch eine hier stattfindende Umfrage und das Publizieren der Ergebnisse zur eingesetzten Windows Version, Edition und Planung interessieren?
Ich bin auf Euer Feedback gespannt!

Der Beitrag Windows 10 – Welches ist die richtige Edition? erschien zuerst auf Workplace Management Blog.

SSD Erkennung per Tool

Dazu muss man das Rad nicht neu erfinden. Es gibt bereits fertige Tools wie dieses hier. An dieser Stelle ist auch beschrieben bzw. auf einen Microsoft Artikel verwiesen, welche Kriterien alles für eine SSD Erkennung herangezogen werden.

Wie nutze ich das Tool?

Der Aufruf geschieht wie folgt:
IsSSD.exe <Laufwerksbuchstabe>, z.B.: IsSSD.exe C:

Wie nutze ich es in der Empirum Setup.inf?

Hier ein Beispiel:

[Set:Product]
CALL "%SRC%\IsSSD.exe" C:
IF "%ErrorLevel%" == "1" THEN "IsSSD" Else "IsNoSSD" EndIf

[IsSSD]
Echo SSD installed!

[IsNoSSD]
Echo No SSD installed!

Wie nutze ich es in einer Batch Datei?

Auch dazu ein kleines Beispiel:

:Begin_SSD_Check
IsSSD.exe C:
IF "%ERRORLEVEL%" == "1" goto Hdd_is_SSD
Echo Hdd is not a SSD Drive!
Goto End_SSD_Check
:Hdd_is_SSD
Echo Hdd is a SSD Drive!
:End_SSD_Check

Gutes gelingen und viel Spaß damit!

Der Beitrag SSD Festplatten Erkennung im Script erschien zuerst auf Workplace Management Blog.

Reihenfolge und Abhängigkeiten

Bezüglich der Reihenfolge der Verteilung hat die Reihenfolge (von oben nach unten) der Pakete im SoftwareDepot grundlegenden Einfluss. Diese Reihenfolge kann mit der Option „Reihenfolge“ auf dem Reiter „Version“ überschrieben werden. Hier werden die Software Pakete angegeben, die vor dieser Software installiert werden muss. Im Dialog „Abhängigkeiten“ können Pakete angegeben werden, die installiert sein müssen, damit diese Software auch installiert wird. Hierüber können auch „Verbote“ definiert werden. Dieses Paket wird nicht installiert, wenn bereits Software xy bereits installier ist. (Bespiele sind die Matrix42 Pakete SubDepot Services und DataCollector).

Betriebssystem Freigabe

Auf diesem Reiter werden die Betriebssysteme „angehakt“, auf denen die Setup.inf erfolgreich ausgeführt wird und getestet ist. Ist ein Paket nur für Windows 7 freigegeben und wird einem Windows XP Computer in der EMC zugewiesen, wird die Setup.inf erst gar nicht „angestartet“, da das Paket nicht dafür freigegeben wurde.

Computerumgebung 

Die Einstellungen auf dem Reiter Computerumgebung wirken sich genauso auf die Verteilung aus, wie auf dem Reiter Betriebssystem. Hier können jedoch Rahmenbedingungen bzgl. RAM, Festplattenplatz, etc. definiert werden. Sind die Rahmenbedingungen nicht erfüllt, startet die Installation erst gar nicht. Die „nicht erfüllte Voraussetzung“ wird mit einer „Requirement“ Meldung im SoftwareDepot Log dokumentiert.

Sonstiges

Wie der Name schon sagt, vereinen sich auf dem Reiter „Sonstiges“ alle weiteren Einstellungen.  Die Einstellungen „Externes Installationsprogramm“ und „Installationsprogramm asynchron aufrufen“ werden in den allermeisten Fällen nicht genutzt und haben mehr eine „historische“ Bedeutung. Beim zweiten Falle, werden die Pakete nicht in einer Stapelverarbeitung eins nach dem anderen installiert, sondern eine weitere Installation wird bereits gestartet. Dies führt in den überwiegenden Fällen zu Installationsproblemen!

„Nur bei Verteilung“ benutzen steuert, ob eine Software im Kiosk sichtbar ist oder nicht, oder nur mittels EMC/EWC verteilt werden kann. „Erlaube Deinstallation“ hat auch nur Einfluss auf das Kiosk und ermöglicht dem Endbenutzer nur eine Deinstallation einer Software zu starten, wenn dies hiermit „erlaubt“ wird.

„Installation weiterer Pakete nicht fortsetzen“ ist interessant zu nutzen, wenn eine abhängige Software-Installation einen Neustart oder ähnlich voraussetzt. Sehr häufig ist dies nach einem Windows Service Pack oder Internet Explorer Update nötig, damit die nachfolgenden Installationen die richtige Version erkennen (mittlerweile auch durch den Wert SetReboot 5 in der Setup.inf steuerbar).

Die Option „Installationskontext“ erlaubt einem einzustellen, ob das Paket nur vor oder nach der Anmeldung ausgeführt werden darf, oder ob es „immer“ installiert werden kann. Wenn das Paket auf eine Abfrage vom Benutzer warten soll, so wäre „Nur nach der Benutzeranmeldung“ passend.

„Installationsdauer“ wird dem Benutzer vor bzw. während der Installation im sogenannten Z-Dialog angezeigt. Der Z-Dialog zeigt die anstehenden Installationen an und gibt ggf. die Möglichkeit  die Installation zu verschieben (je nach Agenten-Konfiguration und Verteilungsoption des Software-Paketes).

„Lizenzen“ – diese Eingabe kann komplett „vergessen“ werden und wird nicht mehr unterstützt.

„Sync. Bandbreite“ bezieht sich auf die Synchronisation der Pakete auf den Client. So kann hier für ein großes Software-Paket eine minimale verfügbare Bandbreite zur Synchronisation der Quellen auf den Client angegeben werden.

Die Eigenschaft „Pakettyp“ ist für die Zusammenarbeit mit dem Matrix42 Service Store relevant. Somit können die Pakettypen beim Import bereits unterschieden werden, wie diese weiter im Service Store zur Verfügung stehen bzw. „verarbeitet“ werden.

Prüfung

Auf diesem Reiter ist der Wert für Prüfdatei/Prüfwert noch sehr interessant. Nur wenn diese Kriterien erfüllt sind, findet die Ausführung des Software-Paketes statt. Hier lohnt sich ein Blick in die Matrix42 Pakete “Patch-Management (Install) bzw (Fix)“.

SetupInfo

Die Nutzung der Paketinformationen durch den bzw. die Paketierer habe ich hier bereits erklärt.

Registrierung

Auf dem Reiter Registrierung wird beim Import der Wert für Schlüssel aus der Setup.inf und der Eigenschaft „MachineKeyName“ übernommen. Dazu sind die bereits vorhandenen Blog Beiträge wichtig zu lesen:

• Anpassung Paketierungsvorlage – Empirum Paket Informationen in der Registry
• Empirum Paket – Registry, SoftwareDepot, Version

AUT

Auf dem Reiter AUT kann eine zu „überwachende“ EXE Datei einem Software-Paket zugeordnet werden. Damit wird die Zuordnung und Erkennung auf dem Eigenschaften Reiter eines Computerobjektes vorgenommen.

Variablen

Hier werden Variablen, die zu dem Softwarepaket gehören und mit der Setup.inf importiert wurden angezeigt.

Der Beitrag Einbinden eines Software-Paketes in Empirum (Erweitert). 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.