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:

Heute mal ein kurzer Hinweis auf einen anderen Blog: Markus Bäker, Systemingenieur bei einem Karlsruher Systemhaus, beschäftigt sich in letzter Zeit intensiv mit Enteo v6 / DSM 7 und automatisiert in einem großen Projekt viele administrative Aufgaben mit unseren PowerShell Extensions.

Über seine Erfahrungen, Beispiele sowie Tipps & Tricks berichtet er auf seinem Blog unter http://www.mbaeker.de/tag/enteo/.

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...

Hallo zusammen!

in diesem Blog möchte ich in kurzen Schritten beschreiben, wie man mit Enteo v6 oder DSM 7 bei einer Neuinstallation eines Computers, dessen CD-DVD Laufwerk einem anderem Laufwerksbuchstaben zuordnen kann.

Leider ist es nicht mehr ohne weiteres möglich, den RDP Client in der Version 7 auf einem Windows Server 2003 zu installieren, da der Installer (http://www.microsoft.com/downloads/en/details.aspx?FamilyId=72158b4e-b527-45e4-af24-d02938a95683&displaylang=en) dies aktiv verhindert. Es erscheint beim Aufruf die Meldung: "The version of windows you have installed does not match the update you are trying to install".

Leider ist die Modifikation der update.inf Datei, die die aktuelle OS Version prüft, nicht ohne weiteres möglich, da das Setup im Falle einer manuellen Änderung meldet, dass die Integrität der inf Datei nicht festgestellt werden kann. Glücklicherweise wird die Integritätsprüfung aber nur einmal beim Aufruf des Setups durchgeführt.

Nachdem dieses Tatsache einmal verstanden ist, kann dieses Verhalten wie folgt umgangen werden:

Im heutigen (recht kurzen) Blogeintrag soll es nun um das noch nicht beschriebene Cmdlet Get-NiInstParam gehen.

Mit diesem Cmdlet wird nicht – wie man anhand des Namens womöglich vermuten könnte (und wovon ich bei meinen ersten Tests auch ausgegangen bin) – der Wert eines für das entsprechende Paket definierten Installations-Parameters ermittelt...

Unsere allseits beliebten PowerShell Extensions für Enteo v6 / DSM 7 benötigen ja ein Lizenzfile, um ihre Arbeit aufzunehmen. Dieses wird in der Regel im Rahmen der Installation mit in das Installationsverzeichnis kopiert und somit von dem Snap-In auch automatisch gefunden.

Es gibt jedoch einige Kunden, die das Snap-In auf allen Client-Rechnern installieren, um von jedem Rechner aus PowerShell Scripts ausführen zu können und so beispielsweise Reinstallationen dezentral anzustoßen, Policy-Instanzen zurückzusetzen oder ähnliches.

In einem solchen Szenario ist es natürlich relativ aufwändig, z.B. nach einer Aufstockung der Lizenzen (der Kunde erhält ja dann ein neues Lizenzfile), die neue Lizenz zu verteilen. Natürlich lässt sich das mit einem einfachen NetInstall-Paket realisieren, aber gemacht werden muss es trotzdem.

Eine wenig bis garnicht bekannte Möglichkeit (mangels Dokumentation - mea culpa), ist die zentrale Ablage der Lizenzdatei. Diese Möglichkeit besteht seit PSX Version 1.1.