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

Während prinzipbedingt die Infrastruktur von einer Veränderung auf dem Client (wie dem Zurücksetzen eines Snapshots) nichts bemerken kann, so hat der Client doch die Info, welche Pakete installiert sind und welche nicht.

Führt ein DSM 7 Client nun eine Synchronisation durch, so erhält er vom Business Logic Server gegebenenfalls immer noch die (falsche) Information, es wären keine Aktionen durchzuführen und der Systemstatus wäre compliant. Diese Information wird nun aber lokal verifiziert, indem  – wie unter NetInstall 5.x – die InstalledApps-Registryschlüssel überprüft werden. Ist ein Schlüssel nicht vorhanden oder hat falsche Werte, so werden der entsprechende Maschinen- oder Benutzerteil trotzdem erneut ausgeführt.

Diese Änderung ist ein wichtiger Schritt nach vorne und sorgt für einen deutlich erleichterten Umgang mit Testrechnern, virtuellen Maschinen und in Umgebungen, wo beispielsweise das Betriebssystem nicht über OSD installiert wird.

Aufgrund dieses neuen (alten) Verhaltens hat sich nun übrigens auch ein weiteres Problem "erledigt" – der "Umzug" von Policies. Unter Enteo v6 verhielt sich das System noch so, dass Pakete erneut ausgeführt wurden, wenn eine Policy ohne Deinstallation gelöscht und dasselbe Paket erneut zugewiesen wurde. Dies konnte zwar gegebenenfalls über eine IsInstalled-Bedingung verhindert werden, trotzdem war dieser Ansatz aus Aspekten der Betriebsführung und Benutzerfreundlichkeit nicht optimal.

In DSM 7 stellt der Client gegebenenfalls fest, nachdem er im Rahmen des Client-Sync mitgeteilt bekommen hat, dass ein Paket auszuführen sei, dass sowohl Benutzer- als auch Maschinenteil bereits installiert sind und setzt den Compliance-Status der entsprechenden Policy-Instanz ohne Aktionen durchzuführen auf compliant. Damit lässt sich eine Reorgansisation des Zuweisungskonzeptes nun viel leichter und mit weniger Auswirkungen auf die verwalteten Systeme umsetzen, indem die entsprechenden Policies einfach forciert gelöscht und auf die neuen Ziel-Objekte neue Policies erzeugt werden.

Es wird nichtsdestotrotz weiterhin empfohlen, die IsInstalled-Bedingungen der Pakete zu pflegen, da diese auch in anderen Situationen sehr nützlich sein können. Außerdem kann darüber beispielsweise ein erneutes Staging der Pakete verhindert werden, falls sich diese nicht mehr im Repository-Cache befinden.

Auf eine Situation sei aber noch hingewiesen: wenn eine Policy mit Deinstallation gelöscht und das entsprechende Paket erfolgreich deinstalliert wird, verschwindet die entsprechende Policy-Instanz oder sogar die ganze Policy, wenn es sich um die letzte Instanz gehandelt hat. Wird nun ein Client auf einen Status zurückgesetzt, in dem dieses Paket noch installiert ist, dann findet keine erneute Deinstallation statt, da auf dem BLS ja keinerlei Informationen über diese Zuweisung mehr existieren. Dies ist prinzipbedingt (die relevante Policy hätte ja auch forciert gelöscht werden können), stellt aber erfahrungsgemäß in produktiven Umgebungen kein größeres Problem dar.