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

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

Als Nutzer des NWC Credential Providers ist es naheliegend, den Registry Key zum Sperren oder Entsperren des NWC Credential Providers über User-defined Tasks der DSMC zu steuern. Verwendet werden kann hier die Komponente reg.exe, die bei allen gängigen Windows Installation im Verzeichnis "%windir%\system32" zu finden ist. Allerdings ist dabei auf x64 Systemen zu beachten, dass die DSMC selbst ein 32-Bit Prozess ist und somit die korrekten Pfadangaben verwendet werden müssen, um die "richtige" 64-Bit reg.exe zu nutzen. Wird nämlich aufgrund der Windows Redirection die 32-Bit reg.exe verwendet, wird im Zielclient auch der 32-Bit Pfad (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node) genutzt, während der Credential Provider seinen Daten im 64-Bit Pfad der Registry ablegt.

Den Ausweg aus der Misere bietet der virtuelle Pfad "%windir%\sysnative" der ausschliesslich für 32-Bit Prozesse sichtbar ist und den Zugriff auf das 64-Bit-System32 Verzeichnis bietet. Die gesamte Konfiguration der 2 User defined Tasks zum entsperren und sperren des NWC Credential Provider sieht für ein x64-System wie folgt aus:

In einem älteren Blogartikel habe ich beschrieben, dass mit DSM 7 wieder das alte – aus NetInstall 5.x bekannte – Verhalten eingeführt wurde, dass letztlich die lokale Registry des gemanageten Clients entscheidend ist, ob Pakete installiert oder nicht installiert werden und der Status der zugehörigen Policy-Instanz nicht mehr die entscheidende Rolle spielt, wie das noch unter Enteo v6 der Fall war.

In einem konkreten Kundenszenario wurde nun aber kürzlich ein Verhalten beobachtet, dass Pakete doch nicht neu installiert wurden, wenn zur Reinstallation eines Clients ein Image zurückgespielt wurde und Pakete im Image nicht installiert waren, die vorher über DSM 7 verteilt worden waren und daher eine grüne Policy-Instanz besaßen.

Dies scheint dem beschriebenen Verhalten zu widersprechen. Und in der Tat wurde in diesem Zusammenhang eine Information bekannt, die so vorher nicht dokumentiert war...

Wer sich schon einmal aufmerksam durch die DSM Logs gearbeitet hat, wird schon mal auf die Variablen "_LAST_ERROR_TEXT" und "_ERROR_SEVERITY" gestossen sein. Diese Variablen werden ggf. gefüllt, wenn ein interner DSM Befehl nicht funktioniert hat. I.d.R. ist die Auswertung der internen DSM Befehle allerding nicht sonderlich relevant. Simple Befehle wie ein "InstallFileList" erkenne selber, wenn eine interne Funktion (z.B. aufgrund eines Filelocks) eine Fehler erzeugt hat. 

Allerdings gilt dies nicht für alle Befehle oder alle Konstellationen von Befehlen. Kann z.B. ein "LocalGroupAddMember" Befehl den User, der in die Gruppe hinzugefügt werden soll nicht auflösen, wird das eScript trotzdem mit "Erfolg" verlassen. Im Worst case erfährt der Administrator also niemals etwas davon, dass ein Paket fehlgeschlagen ist. Die beiden oben genannten Variablen helfen bei der Fehleranalyse. Im Beispiel des "LocalGroupAddMember" Befehls wird (bei Fehler) die "ERROR_SEVERITY" mit "3" befüllt, der "_LAST_ERROR_TEXT" mit einem Informationstext über die Ursache des Problems. Folgende Randbedingungen sind beim Einsatz dieser Variablen zu beachten: 

In vielen DSM Umgebung befindet sich mittlerweile mehr als ein BLS. Eine Multi-BLS Umgebung hat die Vorteile einer besseren Skalierbarkeit wenn sehr viele Clients verwaltet werden, sowie einer höheren Ausfallsicherheit. Ein Update einer DSM Umgebung verringert so auch die Downtime des Systems.

Die BLS Server teilen sich für Ihre Operationen die zentrale Datenbank (CMDB).

Der Primary BLS ist aktuell noch für die DSM Infrastruktur verantwortlich. Hier heißt es abwarten, was die DSM 7.2 bringt ;-)

Die Clients wählen sich Ihren BLS per Zufallsprinzip aus. Der Einsatz eines externen Load Balancers ist jedoch auch möglich.

Was passiert jedoch in z.B. Mandantenfähigen Umgebungen, in denen durch Firewall Regeln ein Zugriff auf alle eingesetzten Business Logic Server nicht möglich ist?

Mein Kollege Michael Jeske und ich haben uns in einem gemeinsamen Projekt intensive Gedanken darum gemacht, wie ein Windows 7 Client optimal über die DSM Datenbank in internationalen agierenden Unternehmen auf seine regionalen Bedürfnisse hin präpariert wird. Folgende Ziele haben wir uns dabei gesteckt: 

• Es müssen alle regionsspezifischen Werte (Währung, Tausender-Trennzeichen, Papiergrösse, Datumsformate, Zeitzone, etc.) und das Tastaturlayout konfiguriert werden.
• Die Sprachen werden unabhängig von den regionalen Einstellungen verwaltet / zugewiesen.
• Im Sinne der Anwendung der DSM Datenbank als CMDB, sollen alle regionalen Einstellungen in der DSM Datenbank verwaltet werden. 
• Wechselt ein Client seinen primären Standort, müssen die regionalen Einstellungen ebenfalls automatisiert angepasst werden. 
• Das Keyboard-Layout muss statisch auf das Land konfiguriert werden (und kann später durch eine Einstellung im Benutzerprofil überschrieben werden). 
• Alle Einstellungen werden rein Computer-bezogen betrachtet. Benutzer-bezogene Konfiguration sollte im ersten Schritt aus dem Standardprofil heraus erfolgen (und nicht via DSM, GPO, etc.)
• Da es sich in unserem Fall um ein deutsches Unternehmen handelt, soll neben englisch die deutsche Sprache und Konfiguration immer, unabhängig vom Standort verfügbar sein, sofern dies Sinn macht.

Im Enteo-Forum gab es kürzlich eine angeregte Diskussion über die Frage, ob es seit Enteo v6 und erst recht mit DSM 7 nicht sinnvoller wäre, für neue Repositories die Option "Nur eine Kopie des Paketverzeichnisses halten" zu aktivieren, da man damit jede Menge teuren Storage-Space sparen könnte. Was natürlich auf den ersten Blick wie eine hervorragende Idee aussieht, entpuppt sich (womöglich) bei näherer Betrachtung als "Schuss in den Ofen".

Da ich das ganze Thema schon länger mal komplett durchdenken wollte, habe ich die Forum-Diskussion zum Anlass genommen, diesen Artikel zu schreiben...

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.