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

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.

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.

Mit der Umstellung seiner Serverlandschaft auf aktuellere Betriebsysteme wie Windows Server 2008 R2 mit SQL Server 2008 R2 oder Austausch von Serverhardware steht man auch vor dem Umzug seiner Datenbanken. 

Anders als bei der DSMDB gibt es bei der Discovery Datenbank einige Punkte zu beachten um einen reibungslosen Umzug zu gewährleisten.

Der Folgende Artikel beschreibt die nötigen Schritte die beim Umzug der Discovery Datenbank beachtet werden müssen.

Mit DSM 7 besteht die Möglichkeit, seine Citrix Farm(en) komplett automatisiert zu betreiben.

Dazu gibt es das Modul „DSM Citrix Support“. Dieses Modul muss extra lizensiert werden.

Ich möchte heute das Publishen von Applikationen zeigen. Als Beispiel nehme ich mal die Software Ultra VNC. Diese wird erst mal als normales DSM Paket auf dem Server installiert. Jetzt geht es darum, einem bestimmten Benutzerkreis die Anwendung als Published Application zur Verfügung zu stellen.

In vielen Umgebungen gibt es Standorte mit wenigen Clients. Oftmals werden dort keine eigenen DSM Server eingesetzt. Die vorhandenen Clients sollen aber mit Software versorgt werden. Wenn die WAN Verbindung nicht die allerbeste ist, kann es bei größeren Paketen schnell zu Problemen kommen, da jeder Client seine Massendaten einzeln über die Leitung beziehen muss. Wenn z.B. auch Citrix und VOIP die WAN Verbindung nutzen und priorisiert sind, kann sich so eine Installation unnötig in die Länge ziehen, und die Leitung stark belasten. Hierfür bieten sich NAS-Boxen als eigene Depots an.

In der NetInstall 5.x-Welt war es ja so, dass der Client vollständig selbst entschieden hat, welche Projekte ausgeführt sollen und welche nicht (Assign&Delegate lassen wir jetzt mal außen vor ;-).

Das heißt, der Client hat die Registry unter HKEY_LOCAL_MACHINE\Software\NetSupport\NetInstall\InstalledApps, beziehungsweise im gleichen Pfad unter HKEY_CURRENT_USER, geprüft. Jedes dort registrierte Projekt – für jedes Projekt gab es einen Unterschlüssel, dessen Name die GUID des Projekts war – galt als installiert, jedes dort nicht erfasste Projekt, wurde als nicht installiert betrachtet.

Unter Enteo v6 ging diese Funktionalität verloren, da die "Intelligenz" vom Client auf den Business Logic Server verlagert wurde. Das führte dazu, dass der BLS zum Beispiel nach dem Zurücksetzen eines Snapshots einer virtuellen Maschine, dem Client die Info gab, es wäre nichts zu installlieren, da alle Policy-Instanzen den Status "compliant" hätten – und der Client hielt sich sklavisch daran, obwohl womöglich etliche Pakete hätten installiert werden müssen, um die Compliance herzustellen.

Mit DSM 7 gibt es nun erneut eine Veränderung im Verhalten...

Nach einem Upgrade von enteo v6 auf DSM 7 können die bestehenden OSD Pakete weiter verwendet werden.

Allerdings empfiehlt es sich das WinPE Bootenvironment zu aktualisieren, um gleich die DSM 7 Client Binaries im WinPE zu haben.

Ansonsten wird erst ein v6 WinPE Client gestartet, der sich dann die aktuellsten Client Binaries aus dem Netz zieht um sich zu aktualisieren.

Das dauert pro Client ein paar Sekunden und kann durch die Option "Update OSD Client" beim WinPE Update umgangen werden.

In Enteo v6 wurde das Konzept von Paket-Revisionen eingeführt, womit es möglich wurde, verschiedene Versionen eines Pakets vorzuhalten, zu verteilen und zu installieren.

Die verschiedenen Revisionen eines Pakets wurden (und werden auch noch in DSM 7) in Unterverzeichnissen des Paketverzeichnisses namens "REV\" abgelegt. Für Revisionen größer 1 wurden dabei in den jeweiligen REV-Unterverzeichnissen nur die gegenüber den Vorgänger-Revisionen geänderten Dateien gespeichert.

Dieser Ansatz führte in Enteo v6 dazu, dass ein Client sich in seinem lokalen Repository-Cache ein "vollständiges Paketverzeichnis zusammenbauen musste" (wofür die Informationen in der File-Package-Index-Datei package.fpi ausgewertet wurden), bevor das Paket installiert werden konnte.

Da aber das aus NetInstall 5.x bekannte Konzept der Ausführung direkt aus dem NetInstall-Share durchaus in vielen Umgebungen ein adäquater und stabil funktionierender Ansatz war, wurde in DSM 7 eine Möglichkeit geschaffen, für jede Paket-Revision ein vollständiges Paketverzeichnis bereitzustellen. Damit kann – wenn gewünscht – auf das Staging von Paketen im lokalen Repository-Cache verzichtet werden, da auf dem Server alle Dateien in der erwarteten Verzeichnisstruktur vorhanden sind (zur Deaktivierung des Stagings siehe unten).

Unter Server 2008 R2 kann es unter Umständen dazu kommen, dass bei einem Server Neustart die Enteo\Frontrange Dienste nicht sauber gestartet werden.

Das liegt an einer Konfigurationsänderung des Servers.