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.

Das neue Advanced Patch Management in DSM 7.2 ist in der Lage, 3rd Party Software zu patchen.
Die Hotfixe werden direkt von den Hersteller Servern heruntergeladen. Damit der Patchmanagement Dienst Internetzugriff bekommt, muss ggf. ein Proxyserver eingetragen werden. Dies geschieht direkt auf dem entsprechenden Managementpoint unter „Shared Infrastructure“.

Immer häufiger wird der Wunsch an mich herangetragen, neben der normalen Silent Installation auch die Verteilung via Imaging-Verfahren in DSM zu implementieren. Gründe hierfür sind ein schnelleres Deployment und die Unterstützung von VDI Plattformen. Dabei soll zudem die Installation des Master-Images möglichst automatisiert und den Richtlinien entsprechend durchgeführt werden.

Mit DSM 7.2 sind nun alle wesentlichen Funktionen verfügbar, um das Deployment von Betriebssystemen mit Imaging-Verfahren wirklich vollständig umzusetzen. Dabei spielt es keine Rolle, ob das mitgelieferte DriveSnapshot, ImageX oder eine VDI Technologie (die ja aus Sicht der Softwareverteilung nichts weiter als ein Imaging Verfahren darstellt) genutzt wird.

Folgender Artikel beschreibt nun den konzeptionellen Ansatz, um das Deployment von Betriebssystemen und Software mittels Imaging Verfahren in DSM 7.2 zu integrieren. Zum Verständnis dieses Artikel sind noch folgende Informationen von Bedeutung:

In einem älteren Blogartikel habe ich beschrieben, dass mit DSM 7 wieder das alte – aus NetInstall 5.x bekannte – Verhalten eingeführt wurde, dass letztlich die lokale Registry des gemanageten Clients entscheidend ist, ob Pakete installiert oder nicht installiert werden und der Status der zugehörigen Policy-Instanz nicht mehr die entscheidende Rolle spielt, wie das noch unter Enteo v6 der Fall war.

In einem konkreten Kundenszenario wurde nun aber kürzlich ein Verhalten beobachtet, dass Pakete doch nicht neu installiert wurden, wenn zur Reinstallation eines Clients ein Image zurückgespielt wurde und Pakete im Image nicht installiert waren, die vorher über DSM 7 verteilt worden waren und daher eine grüne Policy-Instanz besaßen.

Dies scheint dem beschriebenen Verhalten zu widersprechen. Und in der Tat wurde in diesem Zusammenhang eine Information bekannt, die so vorher nicht dokumentiert war...

Viele, vor allem größere, Kunden haben mehr als eine DSM Umgebung im Einsatz. Oftmals gibt es eine Entwicklungs- und Produktionsumgebung (oder auch mehr). Diese Umgebungen sind in aller Regel identisch aufgebaut.Sollten Administratoren gleichzeitig in mehreren Umgebungen arbeiten, ist die Gefahr groß, Aktionen in der „falschen“ Umgebung durchzuführen.

Um dies zu verhindern, gibt es seit der DSM 7.2 die Möglichkeit, die DSMC (DSM Konsole) farblich anzupassen, um auf den ersten Blick zu sehen, in welcher Umgebung aktuell gearbeitet wird.

In DSM 7 gibt es zwei Arten von Schemaerweiterungen. „StateInfo“ und „ManagementInfo“. „StateInfo“ werden vom DSM Client verwaltet. „ManagementInfo“ können nur über die DSMC verändert werden (oder über die PowerShell Extensions).

Mit DSM 7.1 wurde eine Funktion hinzugefügt, um auf einzelnen Clients den Wert einer „StateInfo“ Schemaerweiterung auch über die DSMC zu ändern. Dazu gibt es den Kontextmenüeintrag „Clientseitige benutzerdefinierte Eigenschaften ändern“.

Mit DSM 7.2 wurde dieses Verhalten deutlich erweitert.

Wie mein Kollege Michi Dönselmann bereits hier beschrieben hat gab es in früheren DSM Versionen eine nicht dokumentierte Möglichkeit um Abhängigkeiten bei Installationsparametern zu ermöglichen. Leider konnte das bisher nicht über die Konsole realisiert werden.

Seit DSM 7.2 kann man dies nun durch eine Eigenschaft am Installationsparameter direkt erreichen. Da dieses Feature (stand heute) ebenfalls eher unzureichend dokumentiert ist, kann die korrekte Vorgehensweise hier nachgelesen werden. 

Nach der erfoglreichen Paketierung eines Paketes erfolgt der Rollout eines Paketes. Genau wie der Paketierung, sind beim Rollout in einem Unternehmen viele verschiedene Einstellungen und organisatorische Tätigkeiten zu beachten. Um die Steuerung des Rollout möglichst effizient zu gestalten steht unter Services -> Downloads -> pdfpool -> services ein neues Dokument zur Verfügung, welches in Form einer Checkliste den Rollout-Manager dabei unterstützt eine Anwendung in den produktiven Betrieb zu überführen. 

Vor einiger Zeit habe ich beschrieben, wie es möglich ist, die DMSC direkt von einem lokalen Verzeichnis aus zu starten, ohne direkt auf den Share zuzugreifen. Der Eintrag ist hier zu finden. Leider ist diese Möglichkeit nur dafür nützlich, um die Performance der DSMC zu steigern, nicht aber um komplett ohne Zugriff auf den Share zu arbeiten. Hintergrund dafür ist, dass die DSMC immer versucht, die NCP Dateien direkt vom Share zu laden.

11:21:24.542 2 Loading configuration information from \\kngsvh01\koenig_dsm\NiCfgSrv.ncp...
11:21:24.549 1 Database file time: 11/29/12 10:43:14