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.

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.