Seit DSM 7.1 gibt es die Möglichkeit, den Runtime im Context des SYSTEM Users laufen zu lassen. Dies hat folgende Vorteile:

• Lokale Admins werden verringert
  Die Konfiguration eines Runtime Users kann komplett entfallen. Dies muss allerdings bei einer DSM 7.1 Neu-Installation nachträglich erfolgen, der Installations-Wizard ist noch nicht darauf angepasst.
   
• Mangement von Konfiguration auf die nur SYSTEM zugreifen darf
  Beispiel: Der Microsoft Forefront Client sollen nicht via GPO konfiguriert werden, sondern Ihre Settings via DSM Paket erhalten. In diesem Fall müssen die Exclusions unter "HKLMSoftwareMicrosoftMicrosoft ForefrontClient Security1.0AMExclusions" gepflegt werden. Auf diesen Registry Zweig hat aber nur SYSTEM Schreibzugriff. Auch ein vorhergehender "ChangeRegSecurity" hilft da nicht weiter, um dem Runtime Dienst Zugriff zu geben. 
   
• Management von Domain Controllern
  Wird ein Domain Controller mit einem DSM Client versehen, wurde der assoziierte User immer automatisch zum Domain Admin.

Soll dieses Feature eingesetzt werden, müssen folgende Dinge beachtet werden:

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.

Beim Upload der neuen Wimera Video (auch einsehbar unter www.nwc-services.de/wimera) auf Youtube ist mir die Idee gekommen, doch mal nach "Frontrange" zu suchen. Und welche angenehme Überraschung: Frontrange ist tatsächlich mit einem eigenen YouTube Channel unter https://www.youtube.com/user/frontrange?feature=watch präsent.

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.

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.

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: