seit DSM 7.1 gibt es eine neue Möglichkeit, während der OSD Phase über z.B. ein PreOS Action Paket, den Wert einer Schemaerweiterung zu bearbeiten.

Ein Beispiel hierfür ist, den Installationsstatus zu definieren, welcher später für die Reboot Steuerung abgefragt werden kann.

So kann zu Beginn einer Installation der Wert „Grundinstallation“ in eine State Info Schemaerweiterung geschrieben werden. Solange dieser Wert gesetzt ist, kann der Client ohne Rücksicht auf Verluste rebootet werden. Mit dem letzten DSM Paket kann über den Befehl „ModifyObjectProperty“ der Wert auf „Produktiver Client“ gesetzt werden. Somit müssen gewisse Sachen geprüft werden, bevor ein Reboot durchgeführt werden kann.

Eine weitere bisher undokumentierte Neuerung in DSM 7.1 – wenn auch nicht ganz so spektakulär wie das von Michi hier beschriebene Feature – betrifft die Möglichkeit, einen Vorgabewert für den Kommentar anzugeben, der beim Freigeben eines Paketes eingetragen werden kann und sollte.

Im Normalfall stellt sich das Fenster beim Auswählen des "Paket freigeben" folgendermaßen dar:

Vermutlich wird es den meisten Lesern dieses Beitrags so ergehen, dass hier in der Regel nichts eingetragen wird. Seit DSM 7.1 ist es jedoch nun möglich, hier automatisch einen Vorgabe-Text eintragen zu lassen, um den Paketierern das Ausfüllen zu erleichtern oder ganz abzunehmen.

Mit Einführung der DSM 7, gibt es ein neues Feature, welches von den meisten Paketierern wohl sehnsüchtig erwartet wird.

Sobald ein neues eScript oder MSI Paket erstellt wird, sollten div. Informationen im Skript schon vorhanden sein. Dazu können ein Header, Return Code Variablen, Deinstallations Sektion usw. gehören.

Am einfachsten ist es, sich ein Referenz eScript zu erstellen und die dort vorhandene Script.inc aus dem Paketverzeichnis als Vorlage zu nehmen.

Jeder kennt die Arbeit, die auf einen zukommt, wenn in der DSM eine neue Revision eines Bootenvironments ansteht. Es müssen ggf. Folgerevisionen von Paketen und OS-Installation Sets angelegt werden.

Mit der DSM 7.1 wird diese Arbeit ganz erheblich vereinfacht. Für jeden Client ist jetzt individuell konfigurierbar, welches Bootenvironment in welcher Revision verwendet werden soll.

Einige Hersteller von Softwaremanagement Systemen (mitunter eben auch Frontrange mit DSM 7) stellen eine eigene Packaging Workbench und einen Satz von Skript-Befehlen zur Verfügung, die sich auf die Anforderung für die Verteilung von Software spezialisiert haben. Ein Nachteil dieser Lösungen ist, dass sie nicht portierbar sind, da die Skript-Befehle nicht in einer bekannten Sprache (MSI, VB-Script, Powershell, etc.) implementiert sind, sondern jeweils individuelle Lösungen darstellen. Daher werden immer wieder Empfehlungen von verschiedenen Seiten ausgesprochen, alle Softwarepakete doch zu standardisieren und die Softwaremanagement Umgebung nur noch für die reine Verteilung im Unternehmen zu nutzen. Dies ist auch der Ansatz, den Microsoft mit seinem hauseigenen Produkt SCCM verfolgt. So sinnvoll diese Aussage auf den ersten Blick auch zu sein scheint, gibt es oft gute Gründe, die nativen Skript-Systeme der Hersteller einzusetzen.

Wer sich schon einmal in DSM mit Installationsparametern beschäftigt hat, wird diese sicherlich sehr zu schätzen wissen und regelmäßig verwenden. Es gibt eine zugegebenermaßen etwas unbekannte aber dennoch nette Möglichkeit Abhängigkeiten von Installationsparametern zu definieren. FrontRange verwendet diese z.B. auch bei den PrePackaged Apps für Citrix XenApp. Wenn hier bei der Zuweisung der Wert „Neue Citrix Farm anlegen“ bei „Citrix Farm Selection“  gewählt wird, erscheint ein vorher nicht sichtbarer Installationsparameter. Dieser würde bei einem Farm Join auch keinen Sinn machen. Diese Abhängigkeiten können über die Konsole (stand Heute) nicht definiert werden. Mit ein klein wenig Fleißarbeit ist dies aber relativ leicht realisierbar.

Die UMTS Karten in HP Laptops (mein aktuelles Beispiel ist ein HP Elitebook 2540p mit einer Qualcomm un2420 Karte) haben einige Besonderheiten, die die Integration in DSM besonders erschweren.

• Das "unbekannte Gerät" im Gerätemanager hat eine andere Hardware-Id als das Gerät nach der manuellen Installation des Treibers. Dadurch kann nicht einfach der Treiber via DSM vom Gerät abegzogen werden, da dann im DSM Paket andere Hardware-Ids referenziert sind, als das "unknown device" auf einem frisch installierten Win7 Client hat.
• Das Gerät ist während der Installation eines Laptop ggfs. ausgeschaltet (Hardware-Schalter).
• Das Treiberpaket liegt nur als MSI File vor. Dieses MSI Setup lässt sich aber nur installieren, wenn das Gerät eingeschaltet ist.

Nun kann aber wie folgt vorgegangen werden, um dieses Device trotzdem sauber einzubinden:

Kürzlich hatte ich bei einem Kunden zwei Probleme:

Eins war schon unter DSM 7 RTM vorhanden, nämlich dass einige Admins beim Versuch mit der DSMC zu arbeiten, diesen unbekannten SOAP-Fehler #607 erhielten. Bei anderen Admins lief aber alles problemslos und wir konnten uns keinen wirklichen Reim auf das Verhalten machen.

Nachdem wir dann kürzlich auf DSM 7 Service Pack 2 aktualisiert hatten (und dabei auch gleich die PowerShell Extensions auf den aktuellen Release upgegradet haben), liefen auch einige Funktionen der PSX nicht mehr. Es wurde schon auf einen Bug in den PSX getippt, aber ein kurzer Test zeigte, dass die entsprechenden Funktionen in meiner Testumgebung problemlos funktionierten. Erstaunlicherweise konnte der Kunde die gleiche Funktion, die bei ihm über PSX Probleme machte und einen Fehler zurücklieferte, über die DSMC problemlos ausführen.

Mein Entwickler-Kollege kam dem Problem dann auf die Spur...

Um die Client-Server Kommunikation zu verschlüsseln, gibt es die Möglichkeit, die DSM Webservices (Client Webservice / Admin Webservice) über HTTPs laufen zu lassen.

Um die HTTP/HTTPs Funktionalität nutzen zu können, benötigen Sie zwingend die „DMZ Management Pack“ Lizenz.

Zusätzlich wird ein SSL Zertifikat benötigt. Dieses können Sie durch eine eigene CA erstellen lassen oder von einer der bekannten Zertifizierungsstellen kaufen.

In NetInstall 5.x war es durchaus üblich, eine Site zu definieren die immer am Ende der Infrastruktur stand (z.B. durch den Namen zzAusfallsite) und diese mit einer * - Definition zu versehen. Dadurch konnten alle Clients, die sich keiner Site zuordnen können, die aktuelle NCP vom Orgmaster holen. Speziell bei grösseren Umstrukturierungsmassnahmen war man auf diesem Wege immer sicher, dass die Clients bei einem versehentlichen Ausschluss immer wieder eine neue NCP ziehen konnten und somit zurück in die Sitestruktur fanden.