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.

Nach der kleinen Einführung und dem richtigen Connect zur DSM via PSX wollen wir uns als nächstes einige sehr oft genutzte Features der DSM ansehen und uns hierfür weitere kleine Codeschnipsel erstellen. So kommen wir zunächst zu einem der wohl am meisten genutzten Features. Dem "Computer neu installieren"-Dialog.

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.

Mit der DSM 7.0 Patch 2 wurde die Citrix Management Suite um XenApp 6.x Support erweitert. Das Publishing läuft jetzt über Power Shell Skripte. Nach wie vor kümmert sich der BLS um das Publishing. Damit der BLS Remote auf den XenApp Server zugreifen kann, muss das Remoting auf allen Zielsystemen aktiviert werden. Hierfür gibt es eine Prepackaged App um diese Anforderung mit DSM zu erledigen.

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.

Wie schon angekündigt starten wir unsere "Schnipseljagd" relativ einfach damit, dass wir uns mit der EMDB verbinden und anschließend hierfür ein eigenes kleines PowerShell Profil erstellen, welches beim Starten der PowerShell sofort geladen wird. Dieser Schritt wird eine grundlegende Voraussetzung für alle weiteren Codeschnipsel werden, weshalb ich diesen nun etwas genauer beschreiben möchte.

Seit einiger Zeit bietet die Firma NWC Services eine PowerShell Erweiterung (PSX) zur Automatisierung und Steuerung der DSM Umgebung an. So können z.B. Tätigkeiten oder Aufgaben, die vielleicht einen erhöhten Klick- oder Zeitaufwand mit sich bringen, durch einfache PowerShell Scripte abgebildet werden.

Da sehr viele Kunden den Funktionsumfang der PSX nicht wirklich einschätzen können oder vielleicht in Sachen Scripting nicht die größte Erfahrung haben, rückt dieses mächtige Werkzeug meist schnell von der "Must-Have" auf die "Nice-To-Have" Liste.

Seit Windows 7 gibt es ein kleines unauffälliges Tool, welches ich heute vorstellen möchte.

Jeder kennt das Problem mit Softwarefehlern, die nur bei bestimmten Aktionen auftreten. Oder man möchte einem Kollegen zeigen, wie ein bestimmtes Feature zu nutzen ist.

Hier können wir uns den Microsoft Problem Step Recorder (PSR) zu Nutze machen. Damit wird eine umständliche Formulierung unnötig. Dieses kleine Helferlein zeichnet jede Aktion, die ausgeführt wird, auf, erstellt entsprechende Screenshots und dokumentiert diese auch gleich mit.

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