Trotzdem sind die nachfolgenden Informationen interessant und wichtig, wenn man vielleicht seinen vorhandenen EmpirumServer austauschen, umbenennen o.ä. mag. Handelt es sich um eine Umgebung mit mehreren Standorten oder einer größeren vierstelligen Anzahl an Clients, dann machen auch mehrere EmpirumServer Sinn bzw. werden benötigt. Weitere EmpirumServer nennt man im Empirum Sprachgebrauch „SubDepot“ – andere Hersteller nennen weitere Installations-Server z.B.: Repository, Sites, Distributed Installation Point.

EmpirumServer – SubDepots

Empirum SubDepots können mit der Hilfe von vorhandenen Empirum Software-Paketen und den passenden Variablen aus Windows Clients (Windows Server und Workstations) erstellt werden. In der Hauptsache ist ein Empirum SubDepot eine Kopie der Empirum Dateistruktur und den dazugehörigen Freigaben des Empirum Dienste-Servers. Das SubDepot tauscht, wie ein verwalteter Client (siehe oben): Software-Pakete, Auftrags-, Variablen-, Log- und Inventardateien mit dem überordneten EmpirumServer (zumeist Empirum Master Server) aus.

EmpirumServer – Verbindungsreihenfolge

Die Definition, mit welchem EmpirumServer der Client (UEM-Agent) sich verbindet, wird im Agent-Template (der Agenten-Konfiguration) vorgenommen. Wenn man das oder ein Agent-Template geöffnet hat, kann man die Versuche einer Verbindung, von oben nach unten, konfigurieren. Wenn ich Versuche schreibe, dann ist damit gemeint, das mit jeder nachfolgenden Konfiguration ein Verbindungsversuch gestartet wird. Wird eine Verbindung erfolgreich hergestellt, so wird diese genutzt. Die weiteren konfigurierten Optionen werden dann nicht mehr in Erwägung gezogen. Die Verbindungsversuche pro definierter Option und somit EmpirumServer werden jeweils auch mit den konfigurierten Protokollen durchgeführt.

DHCP Optionen verwenden (1)– nutzen des im DHCP-Bereich des Clients hinterlegten Computernamens z.B.: Depot1.MeineDomain.com oder Depot1. Weitergehende Informationen habe ich unten beschrieben.

Zugewiesene EmpirumServer verwenden (2)– nutzen der in der Management Console in den Eigenschaften der Konfigurations- bzw. Zuweisungsgruppe definierten EmpirumServer. Die eingerückten Optionen: Zufällige Reihenfolge verwenden bzw. Empirum Master Server ausschließen beziehen sich auf die „zugewiesenen EmpirumServer“. Den Empirum Master Server ausschließen macht deswegen Sinn, weil ein Computerobjekt immer den Master Server nochmals direkt am Computerobjekt zugewiesen bekommt. Diesen sollte man auch nicht aus der Zuweisung herausnehmen.

In der Reihenfolge der Verbindungsversuche folgt nun der in der Umgebungsvariable EmpirumServer (3) zwischengespeicherte EmpirumServer, mit dem zuletzt eine erfolgreiche Verbindung hergestellt wurde.

Zu guter letzt, wird eine Verbindung mit dem EmpirumServer im Feld Ausfall-Server (4) vorgenommen.

Das komplette Agent-Template wird dem Client als XML Datei zur Verfügung gestellt.

Weiterführende Informationen

Hier geht es zu einem Hilfe-Artikel der Matrix42 zu diesem Thema.

Nachfolgend zu den zuvor genannten Einstellungen ein paar mehr Informationen von meiner Seite …

DHCP Optionen verwenden – Reihenfolge der Konfiguration

DHCP Optionen verwenden – wenn die Option im Agent-Template aktiviert ist/wird, muss zuvor in Empirum DBUtil die EmpirumServer DHCP Option aktiviert und gesetzt sein. Welche Optionsnummer man verwendet ist in einem gewissen Rahmen, eigene Definitionssache. Es gibt einen Bereich, in dem benutzerdefinierte/kundenspezifische Werte gesetzt werden dürfen und dieser beginnt bei 128. Diese Optionsnummer muss dann wiederum im IP-Bereich des Clients ebenso aktiviert und gesetzt sein.

Vorgehensweise:
1) DHCP Server / IP-Bereich – prüfen, ob die Option 128,129, o.ä. frei ist.
2) Empirum DButil – Empirum-PXE, DHCP Optionen, EmpirumServer aktivieren und Option (z.B.: 128) definieren
3) Agenten-Template – Haken bei DHCP Optionen verwenden setzen und Agent-Template (neu) speichern.
4) DHCP Server / IP-Bereich – Option (z.B.: 128) aktivieren/erstellen und den für den Bereich passenden EmpirumServer eintragen.

Hier zwei Screenshots aus Empirum DBUtil …

Zugewiesene EmpirumServer

Der nachfolgende Screenshot zeigt die Eigenschaften eines Computerobjekts in Empirum. Wie zuvor beschrieben, seht ihr oben rechts unter „Ausgewählte Empirum Server“ den auf dieser Stufe ausgewählten EmpirumServer. Am Computerobjekt selbst ist im Standard immer der Master EmpirumServer eingetragen. Dies bitte unverändert lassen!
Unten rechts bei Gruppen Empirum Server seht ihr die vererbten Empirum Server der darüberliegenden Konfigurations- bzw. Zuweisungsgruppen. Die Reihenfolge der Verbindungsversuche wird von oben nach unten durchgeführt – dies unter Berücksichtigung der Konfiguration im Agent-Template.

Nachvollziehen / Troubleshooting

Wenn ihr schauen wollt, wie euer Client den EmpirumServer anhand eures Agent-Templates bestimmt, dann werft einen Blick in das UAF Log des Clients. Die Logs befinden sich im Verzeichnis: %ProgramData%\Matrix42\Logs\UAF. Die aktuelle Datei lautet: Matrix42.Platform.Service.Host.log. Die Logs werden je 10MB rollierend erstellt und somit kann ein Start- oder Verbindungsversuch in einer Datei mit einem Datumstempel vermerkt sein. Wenn ihr in der Datei nach der Zeichenfolge „Server Access List“ sucht, solltet ihr eine Liste angezeigt bekommen, die aus den obigen Konfigurationen und Zuweisungen resultiert. Hier könnt ihr entnehmen, in welcher Reihenfolge und mit welchen Protokollen der Client die Verbindungen versucht aufzubauen.

Sieger – Am Client könnt ihr den am Ende ausgewählten EmpirumServer mit einem Klick auf das UEM-Agent Symbol und „Info über ..“ oder der Umgebungsvariable „EmpirumServer“ angezeigt bekommen.

Der Beitrag Empirum UEM Agent – EmpirumServer Bestimmung erschien zuerst auf Workplace Management Blog.

Hier die Neuerungen im Überblick …

Software-Management

• EmpirumAgent: EmpirumServer FailOver und/oder LoadBalancing (Tokens) per zugeteiltem EmpirumServer aus der EMC (Reihenfolge, Zufällig, ohne MasterServer).
• Einfache SubDepot Einrichtung mit https Unterstützung mittels Paket
• Paketierung und Verteilung von Windows Store Apps

Patch-Management (v3)

• Optimierter Patch Prozess, Download der Quellen im Hintergrund vor dem „Fix“.

OS-Installer

• Variablen Nutzung in der PreBoot Phase
• Neuer Boot-Mechanismus für UEFI Boot mit neuen Möglichkeiten
• Optimierung des Betriebssystem-Imports, auch für weitere Sprachen als bisher.
• WinPE 5.1 Nutzung

EMC – Usability, DBUtil

• Suchen und Ersetzen von Software mit Übernahme der Verteilparameter
• Optimierung des Aktivierungsverhaltens
• Anzeige des Konfigurationspfades in der Statusleiste
• Installation des Aktivierungsdienstes ohne VDI Komponenten möglich

Der Beitrag Empirum V16 – Preview erschien zuerst auf Workplace Management Blog.

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

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

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

Am 06.11.2014 findet dieses Jahr das jährlich stattfindende Matrix42 Anwendertreffen in Frankfurt am Main statt. Matrix42 lädt dazu alle Bestandskunden ein und zeigt einen Tag lang eine Aussicht auf Neuerungen in den Produkten und ermöglicht in themabezogenen Hands-On Labs das eigene Wissen in den Produkten zu vertiefen bzw. vielleicht bisher ungenutzte Module kennen zu lernen.

Bei diesem Tag steht neben dem technischen Austausch natürlich auch der persönliche Kontakt im Vordergrund. Ich würde mich sehr freuen den ein oder anderen, mit dem ich hier bereits per Mail oder Kommentar in Kontakt stand, persönlich kennenzulernen. Sie finden mich am Matrix42 Partnerstand der Alright-IT GmbH.

Hier die wichtigsten Informationen nochmals zusammengefasst:

• Zielgruppe und Eintritt haben ausschließlich Matrix42 Bestandskunden!
• Termin: 06. November 2014, ab 8:30 Uhr
• Ort: Sheraton Frankfurt Airport Hotel & Conference Center, Hugo-Eckener-Ring 15, Flughafen/Terminal 1
• Hier geht es zur Agenda
• Hier geht es zur Anmeldung

Ich freue mich auf Dich bzw. Sie!

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

Feature Pack –  Windows 8.1 Support für Empirum 15.1

Windows 8.1 wird in Empirum v15.1 derzeit als Windows 8 mit Service Pack 1 gehandhabt. Die Dateien zum „Feature Pack“ sind im „Matrix42 Marketplace“ zu finden. Eine Anmeldekennung ist Voraussetzung. Das „Feature Pack“ wird dort als „Windows 8.1 Support für Empirum v15.1“ bezeichnet und ist im rechten Teil des Fensters unter „Abonnements“ zu finden. Eine beiliegende Installationsanleitung erläutert Schritt für Schritt, wie die Erweiterung implementiert wird. Im Wesentlichen handelt es sich um das Kopieren von Dateien (Katalog-Informationen), Zusammenführen der End_Winvista.eis und dem Ausführen einer SQL Datei).

Wenn die Windows 8.1 Erweiterung bereits als „Preview Version“ installiert wurde, sollte die Anleitung noch genauer beachtet werden, als sonst schon. Wurde die „Preview Version“ mit Patch 06 bereits implementiert, sollte das aktuelle „Feature Pack“ nach dem Patch 07 nochmals installiert werden.

[Update: Ab dem Patch 09 für die Empirum Version 15.1 wird Windows 8.1 ohne weitere Anpassungen unterstützt. Die im oben genannten Feature Pack angepasste End_Winvista.Eis kann auch wieder auf den vorherigen Stand zurückgesetzt werden.]

Windows 8.1 Quellen

Bei den bisherigen Implementierung ist derzeit nur folgendes aufgefallen – bei der Nutzung von englischen Betriebssystem Quellen beim Download von der Microsoft Seite nur „English“ und nicht „English-International“ auswählen!

Importieren der Betriebssystemquellen

Der Import der Betriebssystemquellen geschieht wie gehabt und hier in der Matrix42 Hilfe erläutert. Wichtig ist, dass für Windows 8 bzw. 8.1 das WADK bereits importiert sein muss! Wenn man das WADK für Windows 8.1 importiert, sollte man zur Sicherheit noch einen Registry Key im Anschluss anpassen. Dazu den Wert von „HKLM\Software\Wow6432Node\Microsoft\Windows Kits\Installed Roots“ „KitsRoot81“ kopieren und an gleicher Stelle unter „KitsRoot“ nochmals eingefügen.

Erstellen einer Betriebssystemvorlage (OS Template)

Bei der Erstellung der dazugehörigen Betriebssystemvorlage ist es wichtig, die richtige Windows Edition auswählen. Das bedeutet „Windows 8 Pro“ bzw. „Windows 8 Enterprise“ und nicht „Windows 8.1“.

EPE Version

Auch die EPE Version ist derzeit noch entscheidend.
Hier ist das EPE mit der Version 3.10.7 (CardID 02.019) zu nutzen und derzeit nur diese!

Software-Pakete unter Windows 8.1 installieren

Zur Installation der bereits vorhandenen Software-Pakete, die man gegebenenfalls schon für Windows 7 verteilt hat, müssen nun auch die Software-Register als auch die Software-Pakete selbst für Windows 8 freigeben werden.

.NET FX3.5 Integration

Viele Softwarekomponenten benötigen das .NET Framework 3.5. Dieses ist bereits Bestandteil der Windows 8 bzw. 8.1 Quellen. Damit dieses jedoch auch direkt nach der OS Installation vorhanden ist, muss man das entsprechende Windows „Feature“ auch aktivieren. Wie das geht, erläutere ich in einem separaten Blog Artikel.

Ansonsten – Viel Spaß mit Windows 8.1 und Matrix42 Physical Workplace Management (Empirum).

Der Beitrag Empirum und Windows 8.1 erschien zuerst auf Workplace Management Blog.

Aber wie macht man das?
Im Internet gibt es z.B. einen Online EpochConverter, der einem dabei hilft dies Ad-hoc umzurechnen und stellt darüber hinaus die Syntax und Formeln für die gängigen Scriptsprachen bereit.

So kann man z.B. herausfinden, wann ein Paket auf einen Client heruntergeladen wurde, oder wann das Paket aus dem Cache gelöscht wird:
Dies kann man in der Registry unter HKLM\Software\Matrix42\ComManager\Cache\Items\<Eintrag>\DownloadTime bzw. ExpirationTime einsehen und umrechnen bzw. umrechnen lassen.

Viel Spaß damit!

Der Beitrag Was ist 1390330593 für eine Zeitangabe? 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.

Die Wurzel stellt das Verzeichnis Empirum dar, das auch als Empirum$ freigegeben ist.

Darunter befinden sich die wichtigen Verzeichnisse:

• EmpInst (Alle Dateien des OS-Installers, auch als EmpInst$ freigegeben)
• Configurator (Alle Dateien des Software Managements, auch als Configurator$ freigegeben)
• EmpInv (Zielverzeichnis für die Inventarisierung, auch als EmpInv$ freigegeben)
• Backup (Zielverzeichnis für Personal Backup, auch als Backup$ freigegeben, dies ist jedoch nur ein Vorschlag)
• ERBackup (Zielverzeichnis für Easy Recovery, auch als ERBackup$ freigegeben, dies ist jedoch nur ein Vorschlag)
• Addons (Addons, Tools und Skripte liegen hier)

Gehen wir nun nachfolgend noch weiter auf die Verzeichnisse ein:

EmpInst hat die Unterverzeichnisse:

• DRV (Treiber, $OEM$, OS-PostCommands, etc)
• SYS (Quellen der zu verteilenden Betriebssysteme)
• WIZARD (Skripte, Datenbank-Extrakte in Form von INI Dateien, PXE-Images, Tools, OS Installationsaufträge!)

EmpInst\Wizard

• Scripts2\Custom (kundenspezifische Anpassungen an dem OS Installationsablauf)
• OS\Auto\<letzten 8 Stellen der MAC Adresse> (auch MAC8 genannt, hier liegen die OS-Installationsaufträge)

Configurator hat die Unterverzeichnisse:

• Log (Log-Dateien der Softwareverteilung)
• Packages (Ablage der zu verteilenden Softwarepakete)
• Values (auch als Values$ freigegeben, enthält die Softwareverteilaufträge und die Variablen pro Computer/Benutzer)
• Tokens (Tokenvergabe für die maximale Anzahl gleichzeitiger Softwareinstallationen)
• User (gemeinsame Dateien für die Softwareverteilung und Konfigurationsdateien für Inventory, Personal Backup und Easy Recovery, uvm.)

Die Funktionsweise der oben genannten Verzeichnisse sollte man verinnerlicht haben, wenn man täglich (oder nahezu täglich) mit Empirum als Werkzeug arbeitet.

Der Beitrag Verzeichnisse und Freigaben des Empirum Servers erschien zuerst auf Workplace Management Blog.

In Empirum gibt es einen Agenten mit dem Namen „Empirum Remote Installation Service“, kurz ERIS oder Advanced Agent und den „Empirum Agenten“ oder auch Legacy Agent genannt.

Warum zwei Agenten? In der „Historie“ von Empirum war zuerst der Legacy Agent vorhanden. Der Legacy Agent installiert die Software direkt von seinem zugeordneten Verwaltungsserver (EmpirumServer). Die macht ihn anfällig für mobile Endbenutzer. Mit diesem Hintergrund und der Änderungen, die mit dem zu verwaltenden Betriebssystem ab Microsoft Windows Vista einhergingen, wurde der Advanced Agent geschaffen. Dieser trägt den Anforderungen der neuen Betriebssysteme und der Mobilität Rechnung, indem er die Softwarepakete lokal zwischenspeichert und im SYSTEM Kontext ausführt. Welche Änderungen die beiden Agenten genau ausmachen lässt sich in der Hilfe zu Empirum nachsehen.

Die Verteilaufträge werden den zu verwaltenden Computern per „DDC“ Dateien dargereicht.

Diese Dateien beinhalten die Informationen, welches Software-Paket, wie und zu welchem Zeitpunkt installiert werden soll.

Die Software-Pakete werden wiederum in der DDS Datei beschrieben.

Dienst: ERIS bzw. SetupService (SetupSvc) Dienst

Auftrag: <Computername>.ddc

Paketinformationen: SWdepot.dds

Der Beitrag Softwareverteilung mit Empirum von Matrix42 erschien zuerst auf Workplace Management Blog.

• Welche bzw. wieviele Pakete haben wir?
• Wieviele Pakete davon sind bereits für Windows 7 freigegeben?
• Welche Pakete müssen neu erstellt werden bzw. sind zukünftig obsolet?

Um die meisten Fragen davon zu beantworten, habe ich ein kleines Tool geschrieben, dass die Informationen aus der SWDepot.dds ausliest. Ein paar Informationen sind hier nicht enthalten, was nicht bedeuten muss, dass dies das letzte Tool dieser Art ist. Die ausgelesenen Informationen werden in einer CSV Datei gespeichert. Beim Import bzw. Öffnen mit Microsoft Excel ist darauf zu achten, die Versionsspalte als „Text“ zu importieren, sonst kann es zu unschönen Optimierungen durch Microsoft Excel kommen.

Hier gibt es das Tool zum Download:
SWDepotInfo183 (2661 Downloads )
SHA256 Hash der Version 1.8.3: A133D895D75FE01EB50B5BFC78106C2793AE42A481E26955C64FBD69264A01DE

Der Beitrag Auslesen der verfügbaren Software-Pakete in Empirum erschien zuerst auf Workplace Management Blog.