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

Kürzlich kam ein Kunde auf mich zu mit der Frage, warum bei dem Versuch im Discovery ControlCenter das Ergebnis einer Abfrage zu exportieren, die Meldung "Keine zu exportierenden Daten vorhanden." ausgegeben wurde. Das konnte ja nicht sein, da der Kunde die Datensätze markiert und per Kontextmenü-Befehl "Daten exportieren..." den Export angestoßen hatte.

Desweiteren hat mir der Kunde glaubhaft berichtet, dass er ein ähnliches Phänomen bereits häufiger beobachtet hatte, nämlich dass erstellte Reports weniger Rechner-Objekte enthalten hätten, als die entsprechenden Abfragen im ControlCenter. Damit wären die Reports, seiner Aussage nach, unbrauchbar. Es ist verständlich, dass der Kunde hier auf Centennial "sauer war", die Lösung ist jedoch sehr einfach – wenn man sie weiß...

Im Enteo-Forum gab es kürzlich eine angeregte Diskussion über die Frage, ob es seit Enteo v6 und erst recht mit DSM 7 nicht sinnvoller wäre, für neue Repositories die Option "Nur eine Kopie des Paketverzeichnisses halten" zu aktivieren, da man damit jede Menge teuren Storage-Space sparen könnte. Was natürlich auf den ersten Blick wie eine hervorragende Idee aussieht, entpuppt sich (womöglich) bei näherer Betrachtung als "Schuss in den Ofen".

Da ich das ganze Thema schon länger mal komplett durchdenken wollte, habe ich die Forum-Diskussion zum Anlass genommen, diesen Artikel zu schreiben...

Es gibt ein neues "Feature" in DSM 7.1, das meines Wissens nach ebenfalls auch nicht dokumentiert ist. Und zwar macht DSM seit dem aktuellen Release eine aktive Lizenzprüfung und weist – halbwegs penetrant – auf eine bestehende Unterlizensierung hin.

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.

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

Trotz frei verfügbarer Angebote wie Oracle VirtualBox oder Microsoft Hyper-V Server erfreut sich VMware Workstation weiterhin großer Beliebtheit.

Allerdings ist in der neuen Version 8 ein bisher verfügbares Feature nicht mehr enthalten, das nicht nur ich schmerzlich vermisse: der sogenannte Quick Switch Mode. Bei dieser Ansicht handelte es sich defacto um eine Vollbild-Ansicht, bei der jedoch für jede offene virtuelle Maschine ein Tab am oberen Bildschirmrand eingeblendet wurde (man kennt diese Darstellung in ähnlicher Art von aktuellen Browsern). Dies erlaubte das schnelle und einfache Umschalten zwischen mehreren VMs und daher zügiges und effizientes Arbeiten.

Es gibt jedoch eine wenig bekannte Möglichkeit, auch mit VMware Workstation 8 zumindest recht nahe an die Ansicht des Quick Switch Modes zu kommen...

Seit kurzem ist jetzt die neue Version 2.0 unserer PowerShell Extensions für FrontRange DSM 7 (PSX 2.0) verfügbar.

Diese neue Version, die übrigens nicht mehr für die Verwaltung von Enteo v6 verwendet werden kann, führt eine Reihe von Neuerungen ein, die die PowerShell-basierte Verwaltung von DSM 7 Umgebungen weiter vereinfachen.

Anwender von OSD in Enteo v6 oder DSM 7 kennen das Fenster des Windows PE Binary Clients, in dem dieser seine Aktionen protokolliert.

Abhängig vom Loglevel, das ja über den Eintrag InfoLevel im Abschnitt [enteoconfig] der OSDCLNT.INI eingestellt werden kann, sind diese Informationen durchaus umfangreich und gerade bei Problemen auch wertvoll für das Troubleshooting.

Allerdings kann man aus dem Fenster des Binary Clients keine Einträge herauskopieren und für die spätere Analyse wegsichern. Außerdem verschwindet das Fenster nach dem Auftreten eines Fehlers häufig viel zu schnell, sodass man die enthaltenen Meldungen oft garnicht vollständig lesen und analysieren kann.

Was wenig bekannt (da meines Wissens nach auch nicht dokumentiert) ist, ist dass seit DSM 7 der Windows PE Binary Client diese Meldungen nicht nur in seinem Fenster ausgibt, sondern standardmäßig auch in ein Logfile schreibt.

Leser dieses Blogs kennen sicherlich das Verhalten von Enteo v6 und DSM 7, dass erst am Ende eines Installer-Laufs der Compliance-Status aller installierten Software-Pakete in der CMDB aktualisiert wird.

Gerade im Rahmen einer Grundinstallation kann es daher schonmal eine ganze Weile dauern, bis in der Konsole der aktuelle Status des Installations-Fortschritts zu sehen ist, weil viele Pakete "hintereinander weg" ausgeführt werden.

Für DSM 7 gibt es jedoch eine Möglichkeit, einen "Zwischen-Sync" ausführen zu lassen, sodass man zeitnah Compliance-Informationen in der Datenbank und in der DSMC erhält.