Eine der – weitgehend undokumentierten – Neuerungen in DSM 2013.2, ist die Möglichkeit im Rahmen des CSV-Imports von Objekten, diese gleich zu Mitgliedern statischer Gruppen im ODS zu machen.

Sinn und Zweck dieser Möglichkeit ist naheliegenderweise, dass ohne weitere manuelle Aktionen über die Mitgliedschaft in Softwarezuweisungs-Gruppen neuen Objekten (vermutlich in aller Regel Computer-Objekten) bestimmte Software-Pakete oder sogar ganze Sets an Standard-Paketen zugewiesen werden sollen. Damit lässt sich dann eine weitgehende Automatisierung von Rollouts oder Betriebssystem-Migrationen realisieren, wenn im Rahmen von Hardware-Tausch Szenarien, die Daten vom Lieferanten vorab bereitgestellt werden können.

Die Information beziehungsweise eine Dokumentation, welche Syntax das Import-File allerdings haben muss, um Objekte zu Mitgliedern statischer Gruppen zu machen, ist allerdings schwer zu finden...

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

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

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

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. 

 Die Installation der Microsoft Patche wird in den meisten Fällen mit 2 Job Policies auf den Patch Management Execution Packages (PMExec) getriggert. Ein Job steht auf wöchentlich und "Scan only" der andere Job auf täglich und "InstallAndScanIfNeeded". Dies sorgt dafür, dass der Scan eines Systems auf einmal wöchentlich begrenzt ist,die Installation der Patche durch den zweiten job aber relativ zeitnah geschieht. Für den produktiven Betrieb auch eine meist sinnvolle Konstellation. Um die Patch Installation während der OS Installation durchzuführen, wird i.d.R. ein dritter Job geschrieben, der als Schedule "Nach der OS Installation" eingetragen hat. Dies führt zwar zu einem Update der Betriebbsystemkomponenten, lässt aber die folgenden Anforderungen ausser Acht:

1) Alle Patche sollen auf einmal am Stück installiert werden.
2) Patche sollen zu einem definierten Zeitpunkt installiert werden. 
3) Die Patche sollen nach den Paketinstallation laufen. 
4) Es sollen alle Patche die freigegeben sind, auch auf dem PC installiert werden. 
5) Der Benutzer darf sich erst anmelden, wenn alle Patche installiert sind.

Die Setups einiger Hersteller führen während der Installation eine Prüfung verschiedener Informationen (meistens die Gültigkeit der Lizenzdaten) durch. Grundsätzlich sollte es das Ziel sein, eine solche Onlineprüfung abzuschalten, sei es durch eine spezielle Enterprise-Version der Software oder mittels einer Aufzeichnung der Installation via Snapshot.

In einigen Fällen erweist sich dies aber als unpraktikabel oder sogar undurchführbar. Einige Hersteller verwenden Daten, die pro Installation eindeutig / unique sind, andere bringen zu häufig neue Updates heraus, um die Software via Snapshot-Verfahren aktuell zu halten. In solchen Fällen führt kein Weg daran vorbei, die Onlineprüfung zuzulassen.

Nun stellt sich die Frage, ab welchem Zeitpunkt ein Client "online" (also in der Lage ist, beliebige Webseiten zu erreichen) ist. Oft ist dies im Rahmen der Installation noch nicht der Fall, sodass die Verbindungsaufnahme fehlschlägt.

Wer sich schon einmal aufmerksam durch die DSM Logs gearbeitet hat, wird schon mal auf die Variablen "_LAST_ERROR_TEXT" und "_ERROR_SEVERITY" gestossen sein. Diese Variablen werden ggf. gefüllt, wenn ein interner DSM Befehl nicht funktioniert hat. I.d.R. ist die Auswertung der internen DSM Befehle allerding nicht sonderlich relevant. Simple Befehle wie ein "InstallFileList" erkenne selber, wenn eine interne Funktion (z.B. aufgrund eines Filelocks) eine Fehler erzeugt hat. 

Allerdings gilt dies nicht für alle Befehle oder alle Konstellationen von Befehlen. Kann z.B. ein "LocalGroupAddMember" Befehl den User, der in die Gruppe hinzugefügt werden soll nicht auflösen, wird das eScript trotzdem mit "Erfolg" verlassen. Im Worst case erfährt der Administrator also niemals etwas davon, dass ein Paket fehlgeschlagen ist. Die beiden oben genannten Variablen helfen bei der Fehleranalyse. Im Beispiel des "LocalGroupAddMember" Befehls wird (bei Fehler) die "ERROR_SEVERITY" mit "3" befüllt, der "_LAST_ERROR_TEXT" mit einem Informationstext über die Ursache des Problems. Folgende Randbedingungen sind beim Einsatz dieser Variablen zu beachten: 

In vielen DSM Umgebung befindet sich mittlerweile mehr als ein BLS. Eine Multi-BLS Umgebung hat die Vorteile einer besseren Skalierbarkeit wenn sehr viele Clients verwaltet werden, sowie einer höheren Ausfallsicherheit. Ein Update einer DSM Umgebung verringert so auch die Downtime des Systems.

Die BLS Server teilen sich für Ihre Operationen die zentrale Datenbank (CMDB).

Der Primary BLS ist aktuell noch für die DSM Infrastruktur verantwortlich. Hier heißt es abwarten, was die DSM 7.2 bringt ;-)

Die Clients wählen sich Ihren BLS per Zufallsprinzip aus. Der Einsatz eines externen Load Balancers ist jedoch auch möglich.

Was passiert jedoch in z.B. Mandantenfähigen Umgebungen, in denen durch Firewall Regeln ein Zugriff auf alle eingesetzten Business Logic Server nicht möglich ist?