Für DSM Umgebungen gibt es schon seit längerem ein kleines verstecktes Tool, dem durchaus mehr Beachtung geschenkt werden darf. Die Rede ist vom „Database Tuning Advisor“, der sich um die Pflege der DSM Datenbank kümmert, indem er nicht vorhandene Indizes anlegt, bzw. vorhandene neu erstellt, falls diese zu stark fragmentiert sind.

Seit DSM 7.2 hat es das Tool aus den DSM PowerToyZ direkt in das Produkt geschafft und befindet sich im Verzeichnis \\<server>\<dsm-share>\SSI\DSMDatabaseTuningAdvisor.
Über die Menüleiste lässt sich eine Verbindung zur DSM Datenbank aufbauen:

Seit einiger Zeit bietet DSM die Möglichkeit, die Overall-Compliance sowie die Compliance von Patchen, Software und Treiber jeweils einzeln auszuwerten. Zu diesem Zweck bietet DSM eine Liste von Zahlenwerten in den jeweiligen Computer Eigenschaften, von denen 7 Werte als "Partly Compliance" gekennzeichnet sind. Hinter diesen Werten steckt folgende Aufschlüsselung: 

0 - Undefined
1 - Compliant
2 - NotCompliant
3 - Pending
4 - 12.5
5 - 25
6 - 37.5
7 - 50
8 - 62.5
9 - 75
10 -87.5

Immer wieder werden im Projekt heftige Dikussion um die CPU Bestückung des BLS geführt. Bei einem Blick in den Taskmanager zeigt dieser auf dem BLS oft nur eine Auslastung unter 50% an, was zu der Annahme verleitet, dass keine weiteren CPUs für den BLS mehr notwendig sind. Allerdings ist die Aussage des Taskmanager völlig unbrauchbar, das nicht die aktuelle Auslastung der CPU, sondern die Warteschlange vor der CPU den entscheidenen Messwert darstellt.

Rund um das Thema "Umzug des ORG-Master Depots" gibt es jede Menge Unsicherheit, Gerüchte und fast schon moderne Märchen. Ganz früher (zu NetInstall 5.0-Zeiten) war dafür zwingend der sogenannte RAW-Modus erforderlich, der aber weder supported noch offiziell dokumentiert war.

Um ein supportbares Szenario zu schaffen, wurde mit der Version NetInstall 5.54 der Schalter "/AllowSrvMove" geschaffen, mit dem der NetInstall-Manager gestartet werden musste. In solch einer Sitzung konnte dann der ORG-Master durch Auswahl des Kontextmenü-Befehls "Umbenennen" oder durch Drücken von F2 umbenannt werden.

Wie mein Kollege David König in einem – mittlerweile veralteten und daher von ihm offline-genommenen – Artikel beschrieben hatte, gab es auch vor einiger Zeit mal eine DSM-Version, wo die alleinige Verwendung des "/AllowSrvMove"-Parameters nicht (mehr) ausreichend war. Beim Versuch eine so modifizierte NCP-Datei abzuspeichern kam es zu einer Fehlermeldung und so musste damals eine Kombination aus RAW-Mode und Schalter verwenden werden.

Mittlerweile (zum Zeitpunkt der Erstellung dieses Artikels ist die DSM-Version 7.2.1.2123 aktuell) wurden  diesbezüglich erneut Änderungen vorgenommen...

Beim Aufbau einer DSM Umgebung gibt es Computer-Eigenschaften, die grundsätzlich immer wieder implementiert werden. Eine Übersicht der folgenden Eigenschaften, die in jeder Umgebung Sinn machen, sollen folgende vorgestellt werden. Es handelt sich hier um Best-Practices die sich im Laufe der Jahre herauskristallisiert haben.

Jeder, der Rollouts koordiniert und durchführt, kennt folgende Thematik: Wie teste ich am besten das Update einer bestehenden Installation, ohne es unkontrolliert auszurollen.

Eine weit verbreitete Möglichkeit ist, eine Policy unkritisch zu aktualisieren und einzelne Instanzen auf den aktuellen Revisionsstand der Policy zu heben. Das hat natürlich den Nachteil, dass bei einer Neuinstallation eines Clients möglicherweise die neueste Version installiert wird, obwohl diese noch gar nicht durch die Tests durch ist. Auch neue Instanzen verwenden die neueste, noch nicht final getestete, Revision.

Eine weitere Möglichkeit, die man auch in der Praxis findet, ist es, alle Instanzen zu deaktivieren, solange die Tests nicht abgeschlossen sind. Hierbei wird jedoch bei einer Neuinstallation das Paket ggfs. überhaupt nicht ausgeführt. Das kann unter Umständen zu Folgeproblemen führen.

Es gibt noch einen weiteren Lösungsansatz, welcher jedoch relativ unbekannt ist und keinen der zuvor genannten Nachteile mit sich bringt:

Unternehmen investieren mittlerweile viel Zeit und Geld darin, Ihre Softwarepakete so zu gestalten, dass nach der Installation eines Computers die Compliance in der DSMC eine reale Aussage über den Zustand der Software auf dem Computer widerspiegelt. Umso schlimmer ist die Tatsache, dass ich wiederholt auf das Problem stoße, dass die Compliance eines Computer der grade frisch installiert wurde, schlichtweg ignoriert und dieser Computer an den Kunden ausgeliefert wird. Konsequenzen sind erhöhte Kosten im Helpdesk durch Folgefehler und auch das (durchaus hohe) Investment in saubere und qualitative Paketierungsprozesse, ist nicht mehr ganz zu rechtfertigen.

Erste Maßnahme ist in diesem Fall Aufklärungsarbeit. Die Compliance Informationen müssen dem technischen Personal, welches für die Installation von Computern zuständig ist, zur Verfügung gestellt werden (in Form von DSM Web, Wimera oder einer Eigenentwicklung). Mehr als einmal habe ich erlebt, dass ein Mitarbeiter ohne Zugriff auf die Informationen in der DSM Datenbank gemahnt wurde, einen Computer mit einer fehlerhaften Installation doch nicht so an seine Kunden auszuliefern.

Der Service Installer in DSM wird eingesetzt, um Software im Hintergrund zu installieren.
Viele Kunden stört es, dass der End User dabei nicht sehen kann, was auf seinem Rechner installiert wird.
Eine Möglichkeit wäre jetzt natürlich, Pakete nur noch durch den AutoInstaller ausführen zu lassen.
Die Idee sollte jedoch schnell wieder verworfen werden, wenn Clients auch ohne angemeldeten Benutzer verwaltet werden sollen. Dies ist ausschließlich über den Service Installer möglich. Out of the Box könnte man sich die Balloon Tips zu Nutze machen. Allerdings zeigen die nur an, wenn der Service Installer gestartet wird und falls ein Paket fehlschlägt.
Vielleicht also auch nicht die charmanteste Lösung. Zum Glück bietet DSM 7.2 einige tolle Möglichkeiten um sich eigene Benachrichtigungen zu bauen.

Die meisten Leser dieses Blogs dürften sich bereits mehr oder weniger intensiv mit FrontRange DSM (oder Vorgängerversionen davon) beschäftigen. Daher wird im Regelfall auch die Möglichkeit bekannt sein, Einstellungen aus der Konfigurationstabelle lokal zu überschreiben.

Das bekannteste und sicherlich auch meistgenutzte Szenario ist dabei, das in der Konfigurationstabelle eingestellte Loglevel lokal so zu modifizieren, dass ausführlichere und damit aussagekräftigere Logs erzeugt werden. Diese geschieht in der Regel durch Aufruf des NetInstall Monitors (nimoni.exe) und Auswahl des Menübefehls Protokolldatei-Optionen > Detailtiefe der Protokollierung einstellen. Dass durch diese Aktion im Endeffekt nur der Registrywert LogLevel im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\LogFileSettings gesetzt wird, ist auch noch geläufig. Dieser „überschreibt“ dann den zentral über die NCP-Datei vorgegebenen Wert NcpLogLevel.

Nun könnte man die Hoffnung haben, dass sich alle über die Konfigurationstabelle getroffenen Einstellungen auf diese Art und Weise überschreiben lassen. Dem ist jedoch (leider) nicht so...

Seit Version 7.2.1 von FrontRange DSM werden ja einige Ansichtseinstellungen der DSMC nicht mehr in der CurrentUser-Registry gespeichert, sondern in der DSM-Datenbank. Im Einzelnen handelt es sich dabei um die Einstellungen für

• die ein- oder ausgeblendeten Fenster
• die angezeigten Tabs
• die angezeigten Eigenschaften und
• die Anzeigeeinstellungen des Patch Managements

Dies bietet natürlich insofern Vorteile, als dass diese Einstellungen auch ohne Roaming Profiles auf allen Admin-Arbeitsstationen verfügbar sind. Außerdem muss man ja doch zugeben, dass sich die meisten Einstellungen in der Registry nicht wirklich gut gemerkt wurden und deshalb oft die bestimmte Ansichten wiederholt ein- oder ausgeblendet werden mussten.