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.

Was verbindet viele große Multinationale Konzerne mit Paketierern an verschiedenen Standorten, mit ebenso vielen Mittelständischen Unternehmen in denen die Paketierleistung durch ein kleines 2-Mann Team gestemmt wird? Es passieren Fehler. Es wird wenig bis gar nichts dokumentiert. Übergaben funktionieren oft nicht. Abteilungsübergreifendes Arbeiten an Paketen erinnert mehr an Krieg als an Zusammenarbeit, Testprozesse (nur der User weiß, wie die Anwendung funktionieren muss) ist eine Farce. Natürlich ist dies nicht die Regel, aber einige der genannten Punkte sind sicherlich in fast jedem Unternehmen wiederzufinden.

Anwender von NetInstall 5 werden das Verhalten kennen: im Rahmen der Freigabe eines Projekts, wurde vor der Komprimierung eine Konsistenzprüfung durchgeführt, die prüfte, ob alle in dem Projekt referenzierten Dateien auch an dem entsprechenden Ort vorhanden waren.

Waren eine oder mehrere Dateien dies nicht – was durchaus sinnvoll und gewollt sein konnte, etwa wenn ein dynamisches Batch-Script erzeugt wurde, das anschließend aufgerufen wurde – so öffnete sich ein Dialog, der auf die fehlenden Dateien hinwies. In diesem Dialog konnte dies dann ignoriert oder die Freigabe des Projekts konnte abgebrochen werden.

In Enteo v6 ging diese Funktionalität verloren, da ja das Vorbereiten der Distribution (das Pendant zur Aktion "Freigeben" in NetInstall 5.x) nun nicht mehr von der Konsole, sondern von einem Distributionsdienst ausgeführt wurde.

Dies war zwar insofern praktisch, als die eMMC nicht während der für das Komprimieren benötigen Zeit blockiert war (wie das in NetInstall 5 der Fall war), allerdings konnte es dadurch auch leichter zu fehlerhaften Paketen kommen, da eventuell für die erfolgreiche Ausführung benötigte Dateien nicht vorhanden waren.

In DSM 7 wurde das Feature nun wieder implementiert – allerdings muss es explizit aktiviert werden und ist standardmäßig nicht aktiv.

Heute mal ein ganz kurzer Eintrag:

Sollte jemand in die Situation geraten, einen NVIDIA Grafikkartentreiber in NetInstall/enteo v6/DSM zu paketieren, wird er feststellen, dass egal wie er das anstellt, das Treiberpaket nicht funktioniert. Hintergrund ist, dass NVIDIA irgendwelche Calls auf Dateien macht, die so nicht direkt in der inf Datei referenziert sind (und somit nicht mit im Treiberpaket landen). Einfache Abhilfe schafft es, den NVIDIA Treiber (z.B. mit 7-Zip) zu entpacken und alle Dateien aus dem Verzeichnis "Display.Drivers" mit in das Paketverzeichnis des Treiber zu kopieren. Weiterhin ist für die saubere Installation weiterer NVIDIA Komponenten (3D, CPLs,...) ein Reboot notwendig.

Nach einem Upgrade von enteo v6 auf DSM 7 können die bestehenden OSD Pakete weiter verwendet werden.

Allerdings empfiehlt es sich das WinPE Bootenvironment zu aktualisieren, um gleich die DSM 7 Client Binaries im WinPE zu haben.

Ansonsten wird erst ein v6 WinPE Client gestartet, der sich dann die aktuellsten Client Binaries aus dem Netz zieht um sich zu aktualisieren.

Das dauert pro Client ein paar Sekunden und kann durch die Option "Update OSD Client" beim WinPE Update umgangen werden.

Vor kurzem habe ich bei einem findigen Kunden gesehen, wie er den Konsolenschalter "/ALS" dafür genutzt hat, den Start der Konsole deutlich zu beschleunigen - dieser (undokumentierte) Schalter steht für "Allow  Local Start". Kurzum procmon zur Hand genommen und ein kleines Batchfile geschrieben, das die wichtigsten Daten der Konsole auf die lokale Festplatte kopiert und die eMMC (oder eben DSMC) ausführt.

Leise, still und heimlich hat FrontRange heute am 04.05.2011 das erste Hotfix-Bundle für DSM 7 veröffentlicht. Die Desktop und Servermanagement Suite wird damit auf Build 1131 aktualisiert.

Laut Release-Notes werden damit – nur 5 Wochen nach dem Release der Version 7 – etliche Fehler behoben beziehungsweise teilweise auch neue Features eingeführt: