Wie Frank hier schon beschrieben hat, werden seit der DSM 7.0 wieder die „InstalledApps“ Keys in der Registry geprüft.

Somit werden bereits ausgeführte Installationen vom DSM Client automatisch berücksichtig und ohne erneute Ausführung auf compliant gesetzt.

Zusätzlich gibt es aber auch noch die so genannten „IsPreInstalled“ Bedingungen. Diese sind nicht wirklich neu, hörten allerdings zu Pre 7.1 Zeiten noch auf den Namen „IsInstalled“. Hier stehen dem DSM Administrator etliche Kriterien zur Verfügung, um dem DSM Client mitzuteilen, dass eine Anwendung bereits installiert ist. Der Fokus der Bedingungen liegt hier jedoch außerhalb von DSM. Es kann geprüft werden, ob eine Software z.B. manuell oder durch ein „Mitbewerber Deployment Produkt“ installiert wurde. Bei einer erfolgreichen Prüfung setzt der DSM Client die Policyinstanz auf compliant, ohne das Paket auszuführen.

Der große Vorteil gegenüber der InstalledApps Key Prüfung ist hierbei , dass das Paket nicht erneut in den Repository Cache geladen werden muss, sollte es nicht mehr vorhanden sein. Sollten Sie mit Imaging, VDI oder XenApp Provisioning arbeiten (ohne Einsatz der DSM Imaging Option), können sie die jeweiligen Prozesse massiv beschleunigen, da ein Staging im hohen GigaByte Bereich obsolet wird. Zusätzlich wird das Netzwerk nicht unerheblich geschont.

Hierbei ist allerdings fraglich, ob das aktuelle Verhalten korrekt ist. Meiner Meinung nach sollte DSM bei einer erfolgreichen „InstalledApps“ Key Prüfung das Paket nicht erneut in den Repository Cache laden, sofern es nicht mehr vorhanden ist. Die „IsPreInstalled“ Bedingung sollte jetzt nicht ausschließlich für das verhindern des Stagings verwendet werden. Vielleicht äußert sich FRS in Form eines Kommentars oder einer eMail.

Der Name der „IsPreInstalled“ Bedingungen ist nicht die einzige Neuerung dieser Funktion. Zusätzlich kann diese optional für das neue Feature „Enforce Compliance“ genutzt werden.

In meinem Test Paket prüfe ich auf die Existenz der Datei „C:\temp\1\test.txt“

Sobald der DSM Client vom BLS die Information erhält, das Paket auszuführen, prüft dieser als erstes grundsätzlich, ob die eindeutige Paket GUID in der Registry unter den InstalledApps Keys zu finden ist.

Dies sieht man im Log des AutoInstallers oder des Service Installers in folgender Sektion:

15:12:34.047 1   SWMSRT: -------- Getting PolicyInstances ----------------------------------------------

15:12:34.051 0   SWMSRT: Open Key 'HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\Installed Apps'

15:12:34.052 0   SWMSRT:   - PackageMigrationDone = (null

15:12:34.053 0   SWMSRT: The package {F59E1398-AE16-4C73-B77E-20127806F8B5} doesn't need correction

15:12:34.053 0   SWMSRT: The package  doesn't need correction

15:12:34.054 0   SWMSRT: Received information about 0 packages

15:12:34.055 0   SWMSClntLib: Successfully deleted the executed list.

Wenn das Paket bereits installiert ist, prüft er dennoch auf eine gesetzte “IsPreInstalled” Bedingung. Sollte diese „Wahr“ sein, besteht keine Notwendigkeit das Paket in den Repository Cache zu laden. Im Log wird diese Aktion mit folgender Zeile protokolliert:

15:12:34.460 1    SWMSRT: --> No download needed or allowed

Der DSM Client kann somit die Policyinstanz auf compliant setzen.

Unter DSM 7.0 und früher hat man in der Regel für die IsInstalled Prüfung immer auf die eindeutige GUID des Pakets abgefragt. Dies war sehr einfach umzusetzen und hat zuverlässig funktioniert. Bei migrierten Paketen wurde diese Bedingung automatisch gesetzt. Technisch funktioniert diese Variante unter DSM 7.1 auch weiterhin. Beachtet man jedoch die neue Funktionalität „Enforce Compliance“ macht eine Prüfung auf eine Paket GUID keinen Sinn mehr.

Wird für ein Paket die Funktion „Enforce Compliance“ aktiviert, prüft der Service Installer bei jedem Polling Intervall, ob die konfigurierte Bedingung „wahr“ ist. Sollte dies nicht der Fall sein, kann die Policyinstanz des Pakets auf „rot“ gesetzt bzw. ein Reinstall ausgeführt werden. Das ist der Grund warum die Prüfung auf eine Paket GUID an dieser Stelle keinen Sinn macht. Dies sagt nämlich nicht aus, ob das Produkt tatsächlich sauber installiert ist oder nicht. Auch eine manuelle Deinstallation der Software bleibt so unbemerkt. Es ist also absolut wichtig, ein Kriterium zu verwenden, welches sich nutzen lässt um eine erneute Installation bzw. das Herunterladen der Massendaten zu vermeiden sowie die Ordnungsgemäße Installation festzustellen, um im Fehlerfall eine Aktion auszuführen.

Rein theoretisch lässt sich für „IsPreInstalled“ und „Enforce Compliance“ jeweils eine eigene Bedingung festlegen. Meiner Meinung nach lohnt es sich aber nur eine „IsPreInstalled“ Bedingung zu sezten, und diese auch für die Compliance Prüfung zu nutzen.

In folgendem Screenshot ist zu sehen wie dies eingerichtet wird.

Auf die detaillierte Funktionalität von „Enforce Compliance“ werde ich in diesem Blog nicht eingehen.