Wie viele andere meiner Kunden, würde auch ich gerne die DSM Eigenschaft "CurrentComputer.Computer.ComuterType" dafür nutzen, verschiedene Zuweisungen (wie z.B. VPN Client) zu steuern. Leider gibt es mit dieser Eigenschaft verschiedene Probleme, die eine sinnvolle Nutzung verhindern:

• Einmal gesetzte Computertypen werden i.d.R. nicht wieder verändert.
• Nicht alle virtualisierten Systeme werden als solche erkannt.
• Blades & Server werden zumeist gar nicht als solche erkannt.
• Ein Server kann auch gleichzeitig ein virtuelles System sein.
  
  

Mit DSM 7 haben auch die ODS Variablen Ihren Einstand gefeiert. Diese sind, im Gegensatz zu den benutzerdefinierten Variablen, nicht mehr siteabhängig, sondern hängen direkt am Client, egal wo dieser sich befindet.

Ein Vorteil gegenüber einer Schemaerweiterung ist die Vererbung. Ein gesetzter Wert wird von jeder Ebene aus nach unten weiter vererbt. Diesen Vorteil kann man sich beim JoinDomain zu Nutze machen.

Da Clients z.B. je nach Standort oder Typ im AD in unterschiedlichen OU´s verwaltet werden, benötigt man auch in der unattend.xml unterschiedliche LDAP Pfade.

Oft werden Pakete in die Paketierung gegeben, für die der Paketierer weder technisches noch fachliches KnowHow besitzt. Um die Paketierungszeit auf ein möglichstes zu verringern, wird speziell in grösseren Unternehmen eine fachlich verantwortliche Person definiert, die dafür zuständig ist, die Anwendung im Unternehmen zu betreuen (2nd/3th-Level Support).
Diese fachlich verantwortliche Personen sind Experten in dem Bereich der Anwendung. Sie kennen die grundsätzliche Konfiguration der Anwendungen, die verwendeten Backendserver und welche Unternehmensbezogenen Erweiterungen notwendig sind.

Mit DSM 7 besteht die Möglichkeit, seine Citrix Farm(en) komplett automatisiert zu betreiben.

Dazu gibt es das Modul „DSM Citrix Support“. Dieses Modul muss extra lizensiert werden.

Ich möchte heute das Publishen von Applikationen zeigen. Als Beispiel nehme ich mal die Software Ultra VNC. Diese wird erst mal als normales DSM Paket auf dem Server installiert. Jetzt geht es darum, einem bestimmten Benutzerkreis die Anwendung als Published Application zur Verfügung zu stellen.

Leser dieses Blogs kennen sicherlich das Verhalten von Enteo v6 und DSM 7, dass erst am Ende eines Installer-Laufs der Compliance-Status aller installierten Software-Pakete in der CMDB aktualisiert wird.

Gerade im Rahmen einer Grundinstallation kann es daher schonmal eine ganze Weile dauern, bis in der Konsole der aktuelle Status des Installations-Fortschritts zu sehen ist, weil viele Pakete "hintereinander weg" ausgeführt werden.

Für DSM 7 gibt es jedoch eine Möglichkeit, einen "Zwischen-Sync" ausführen zu lassen, sodass man zeitnah Compliance-Informationen in der Datenbank und in der DSMC erhält.

In vielen Umgebungen gibt es Standorte mit wenigen Clients. Oftmals werden dort keine eigenen DSM Server eingesetzt. Die vorhandenen Clients sollen aber mit Software versorgt werden. Wenn die WAN Verbindung nicht die allerbeste ist, kann es bei größeren Paketen schnell zu Problemen kommen, da jeder Client seine Massendaten einzeln über die Leitung beziehen muss. Wenn z.B. auch Citrix und VOIP die WAN Verbindung nutzen und priorisiert sind, kann sich so eine Installation unnötig in die Länge ziehen, und die Leitung stark belasten. Hierfür bieten sich NAS-Boxen als eigene Depots an.

Vor einiger Zeit habe ich Checklisten (siehe Paketier-Anforderung, Paketierungsrichtlinien und Paketabnahme) veröffentlicht, die beim Prozess der Paketierung unterstützen sollen.

Nach und nach häufen sich aufgrund des Artikels einige zusätzliche Fragen in meinem Notizbuch, denen ich im Folgenden nachkommen will. Ich möchte erst auf einige allgemeine Fragen eingehen, um dann konkrete und sehr technische Details zu beschreiben.

Allgemeingültige Anmerkungen/ Fragen

Wie viel Zeit verwende ich auf die reine Paketierung?

Grundsätzlich ist es schwer, eine verlässliche Aussage zu treffen. Die Zeiten für die Paketierung liegen bei 1-2 Stunden für einfache Pakete wie 7-Zip bis hin zu mehreren Wochen für komplexe Anwendungen. Die Komplexität liegt dabei selten in den technischen Details der Anwendung, sondern vielmehr in der Vielfalt der Konfigurationseinstellungen. Aber auch Anwendungen, die vom ersten Gefühl her relativ einfach erscheinen, können sich zu wahren Zeitfressern entwickeln. Ein Beispiel ist der Adobe Reader, der zusammen mit einem weiteren PDF Editor (z.B. Nuance) auf einem System betrieben werden soll. Dann müssen Paketübergreifende Dinge wie die Verknüpfung von Dateien mit  behandelt werden. Speziell bei Adobe Reader sind zudem die häufigen Updates eine Ursache für gesteigerte Aufwände/Feheinschätzungen bei der Paketierung. 

Noch leiser als Hotfix-Bundle 1, hat FrontRange schon Anfang dieses Monats das Hotfix-Bundle 2 released.

Dieses steht momentan nur auf dem FTP-Server zur Verfügung, für den aber ein separater Login angefordert werden muss. Interessierte Kunden müssen sich diesbezüglich an den FrontRange-Support wenden.

Gemäß den Release-Notes wurden im Vergleich zu Hotfix-Bundle 1 die folgenden Fehler behoben:

In der NetInstall 5.x-Welt war es ja so, dass der Client vollständig selbst entschieden hat, welche Projekte ausgeführt sollen und welche nicht (Assign&Delegate lassen wir jetzt mal außen vor ;-).

Das heißt, der Client hat die Registry unter HKEY_LOCAL_MACHINE\Software\NetSupport\NetInstall\InstalledApps, beziehungsweise im gleichen Pfad unter HKEY_CURRENT_USER, geprüft. Jedes dort registrierte Projekt – für jedes Projekt gab es einen Unterschlüssel, dessen Name die GUID des Projekts war – galt als installiert, jedes dort nicht erfasste Projekt, wurde als nicht installiert betrachtet.

Unter Enteo v6 ging diese Funktionalität verloren, da die "Intelligenz" vom Client auf den Business Logic Server verlagert wurde. Das führte dazu, dass der BLS zum Beispiel nach dem Zurücksetzen eines Snapshots einer virtuellen Maschine, dem Client die Info gab, es wäre nichts zu installlieren, da alle Policy-Instanzen den Status "compliant" hätten – und der Client hielt sich sklavisch daran, obwohl womöglich etliche Pakete hätten installiert werden müssen, um die Compliance herzustellen.

Mit DSM 7 gibt es nun erneut eine Veränderung im Verhalten...

Grundsätzlich ist die Aussage von FrontRange, dass sowohl die Distribution als auch die Softwareverteilung zum Client über http implementiert ist.

Diese Aussage stimmt zwar grundsätzlich, allerdings gibt es einige Stolpersteine, die einem die Einrichtung eines Depots in diesem Szenario zum persönlichen Jakobs-Weg machen. Daher nun folgend eine kleine Schritt-für-Schritt Anleitung als Abkürzung.

Hinweis: dieser Artikel setzt tiefgehende Kenntnisse über die DSM Infrastruktur, die Distribution, IP und DNS voraus. Sollten Sie unsicher in einem dieser Bereiche sein, nutzen Sie bitte die Unterstützung eines Consultants. 

Zielsetzung

Grundsätzliches Ziel dieses Artikels ist der Aufbau eines Depots in einer Außenstelle, das per Pull-Distribution über einen http-Port mit einem zentralen Depot abgeglichen wird. SMB ist dabei zwischen den beiden Lokationen nicht verfügbar.