Das Windows Preinstallation Environment in der Version 4.0, welches mit Einführung von Windows 8 bzw. Windows Server 2012 veröffentlicht wurde, bietet einige spannende Neuerungen in Bezug auf seinen Vorgänger. So ist es nun unter anderem möglich PowerShell 3 als optionale Komponente zu integrieren. Durch diesen Schritt ist es natürlich auch möglich per PSX Ihre DSM Umgebung bereits in der PreOS Phase anzusprechen, auszulesen und natürlich zu konfigurieren. In diesem Blog möchte ich Ihnen kurz zeigen wie Sie ihr Boot Environment zum einen PowerShell und zum anderen PSX Ready machen können.

Nachdem ich in letzter Zeit immer häufiger nach einer Möglichkeit gefragt wurde, ob man Software Policys einer bestehenden statischen oder dynamischen Gruppe auf einfachem Wege duplizieren, oder auch die Targetlist der bestehenden Policys erweitern kann, möchte ich kurz einen Weg aufzeigen mit welchem sich die gewünschte Aktion per PSX realisieren lässt.

Nachdem der Windows 8 Start Screen viele Unternehmen vor das Problem gestellt hat sowohl einen unternehmensweiten „Standard Screen“ zu definieren, diesen zu verwalten, Einstellungen zu setzen als auch zu verteilen, wurde nun mit Windows 8.1 auf dieses vermeintliche Problem reagiert. Im folgenden Artikel möchte ich kurz beschreiben wie eine benutzerdefinierte Start Screen Konfiguration erstellt, exportiert und angewendet werden kann.

Für DSM Umgebungen gibt es schon seit längerem ein kleines verstecktes Tool, dem durchaus mehr Beachtung geschenkt werden darf. Die Rede ist vom „Database Tuning Advisor“, der sich um die Pflege der DSM Datenbank kümmert, indem er nicht vorhandene Indizes anlegt, bzw. vorhandene neu erstellt, falls diese zu stark fragmentiert sind.

Seit DSM 7.2 hat es das Tool aus den DSM PowerToyZ direkt in das Produkt geschafft und befindet sich im Verzeichnis \\<server>\<dsm-share>\SSI\DSMDatabaseTuningAdvisor.
Über die Menüleiste lässt sich eine Verbindung zur DSM Datenbank aufbauen:

Beim Einsatz von Flex+ als Profilmanagement-Lösung werden oft sämtliche Links benutzerbezogen über Flex+ angelegt. Der Sinn dieses Vorgehens liegt auf der Hand: Links können aufgrund von Conditions (z.B. Gruppenmitgliedschaften) erzeugt werden, durch die asynchrone Abarbeitung verzögert sich nicht der Login Prozess, der DSM AutoInstaller Prozess wird "entschlackt". 

Allerdings kommt dabei ein Problem auf: Wird der Maschinenteil einer Anwendung via DSM installiert, hat der User seine Links erst zur Verfügung, wenn dieser sich ab- und wieder neu anmeldet, kurzum: die FlexEngine neu startet. Speziell beim Deployment einer Anwendung über den AutoInstaller ist die User-Experience daher eher "mau". 

SSON an einer Webite (Receiver for Web) funktioniert nicht mehr. Sobald man SSON als einzige Authentifizierungsmethode aktiviert, meldet Storefront "kein Zugriff möglich". Demnach widmet sich dieser Artikel ausschließlich SSON in Verbindung mit einer Service Site (Store).

Single Sign-On bedeutet die automatische Nutzung der lokalen Domain-Anmeldedaten für eine Citrix Sitzung. Wichtig ist der Hinweis, dass dies nicht zu verwechseln ist mit dem gleichnamigen Citrix Produkt, das ehemals als "PasswordManager" bezeichnet wurde und für das mittlerweile ebenfalls die Bezeichnung "Single Sign-on" benutzt wird.

Seit DSM 7.2.1 gibt es ja neben dem normalen Patch Management, das im Wesentlichen die Funktionalität bietet, die die Windows Server Update Services (besser bekannt als WSUS) auch bereitstellen, die erweiterte Variante des Avanced Patch Managements (APM).

Hauptmerkmal des APM ist, dass neben den üblichen Microsoft Produkten, die auch durch den WSUS mit Patches versorgt werden würden, eine große Anzahl von Dritthersteller-Produkten gepatcht werden kann. Fragt man jedoch, welche Produkte (oder zumindest wieviele) denn sonst noch mit Patchen versorgt werden können, erhält man oft ungenaue oder zum Teil sogar sich widersprechende Aussagen.

Da es sich beim APM um eine OEM-Version des Produkts "Shavlik Protect" handelt, kann man auf die Angaben des Herstellers zurückgreifen – sofern man diese findet...

Bei XenDesktop 4 und Metaframe XP SP2 FR1 bis XenApp 6.5 gab es außerhalb der Citrix Richtlinien die Möglichkeit, den XML Port mit dem Befehl ctxxmlss /R<port> zu wechseln. Überprüfen konnte man dies in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CtxHttp.

Diesen Befehl gibt es bei XenDesktop 5.x und XenDesktop 7.x nicht mehr, aber nach wie vor die Möglichkeit dies einzustellen und zu überprüfen.

Seit einiger Zeit bietet DSM die Möglichkeit, die Overall-Compliance sowie die Compliance von Patchen, Software und Treiber jeweils einzeln auszuwerten. Zu diesem Zweck bietet DSM eine Liste von Zahlenwerten in den jeweiligen Computer Eigenschaften, von denen 7 Werte als "Partly Compliance" gekennzeichnet sind. Hinter diesen Werten steckt folgende Aufschlüsselung: 

0 - Undefined
1 - Compliant
2 - NotCompliant
3 - Pending
4 - 12.5
5 - 25
6 - 37.5
7 - 50
8 - 62.5
9 - 75
10 -87.5