NWC Services Blog
Blogs von Consultants der NWC Services GmbH
Wird Flex+ genutzt um die Windows Profile zu konfigurieren, soll einem User u.U. die eine oder andere Anwendung schon gleich in die Superbar (Taskbar) oder das Startmenü gelegt werden. Leider liefert Flex+ keinen vorgefertigten Befehl aus, aber mit einem kleinen Powershell Script lässt sich diese Anforderung schnell erledigen. Zu allererst muss überlegt werden, wie das Powershell Script auf jeden Zielclient verfügbar gemacht werden kann. Steht eine DSM Umgebung zur Vefügung, bietet es sich an, das Paket zur Verteilung des Flex+ Clients um das kopieren von definierten Scripts zu erweitern oder ein eigenes Paket für die Aufgabe zur Verfügung zu stellen.
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".
Immer wieder werden im Projekt heftige Dikussion um die CPU Bestückung des BLS geführt. Bei einem Blick in den Taskmanager zeigt dieser auf dem BLS oft nur eine Auslastung unter 50% an, was zu der Annahme verleitet, dass keine weiteren CPUs für den BLS mehr notwendig sind. Allerdings ist die Aussage des Taskmanager völlig unbrauchbar, das nicht die aktuelle Auslastung der CPU, sondern die Warteschlange vor der CPU den entscheidenen Messwert darstellt.
Beim Aufbau einer DSM Umgebung gibt es Computer-Eigenschaften, die grundsätzlich immer wieder implementiert werden. Eine Übersicht der folgenden Eigenschaften, die in jeder Umgebung Sinn machen, sollen folgende vorgestellt werden. Es handelt sich hier um Best-Practices die sich im Laufe der Jahre herauskristallisiert haben.
Wer im Firmenumfeld Bitlocker einsetzt, kann den Schutz der verschlüsselten Geräte durch den Einsatz eines Startup Pins deutlich erhöhen. Ohne Pin greift nur noch der Windows Passwort Schutz. Jedoch gibt es auch beim Einsatz von Startup Pins ein paar Punkte zu bedenken.
1. Wie lange sollte der Pin sein?
2. Haben alle Geräte den gleichen Pin?
3. Wie lässt sich ein Pin ändern, ohne dem User administrative Rechte zu geben?
Nach der erfoglreichen Paketierung eines Paketes erfolgt der Rollout eines Paketes. Genau wie der Paketierung, sind beim Rollout in einem Unternehmen viele verschiedene Einstellungen und organisatorische Tätigkeiten zu beachten. Um die Steuerung des Rollout möglichst effizient zu gestalten steht unter Services -> Downloads -> pdfpool -> services ein neues Dokument zur Verfügung, welches in Form einer Checkliste den Rollout-Manager dabei unterstützt eine Anwendung in den produktiven Betrieb zu überführen.
Vor einiger Zeit habe ich beschrieben, wie es möglich ist, die DMSC direkt von einem lokalen Verzeichnis aus zu starten, ohne direkt auf den Share zuzugreifen. Der Eintrag ist hier zu finden. Leider ist diese Möglichkeit nur dafür nützlich, um die Performance der DSMC zu steigern, nicht aber um komplett ohne Zugriff auf den Share zu arbeiten. Hintergrund dafür ist, dass die DSMC immer versucht, die NCP Dateien direkt vom Share zu laden.
11:21:24.542 2 Loading configuration information from \\kngsvh01\koenig_dsm\NiCfgSrv.ncp...
11:21:24.549 1 Database file time: 11/29/12 10:43:14
In der Vergangenheit habe ich die drei folgenden Formulare vorgestellt, die dabei helfen den Paketierungsprozess zu optimieren:
Neben den Checklisten, die die Qualität der einzelnen Schitte in einem Paketierungsprozess sicherstellen, ist es wichtig den Überlick über alle Pakete, die an diesem Prozess beteiligt sind, zu behalten.
Die Installation der Microsoft Patche wird in den meisten Fällen mit 2 Job Policies auf den Patch Management Execution Packages (PMExec) getriggert. Ein Job steht auf wöchentlich und "Scan only" der andere Job auf täglich und "InstallAndScanIfNeeded". Dies sorgt dafür, dass der Scan eines Systems auf einmal wöchentlich begrenzt ist,die Installation der Patche durch den zweiten job aber relativ zeitnah geschieht. Für den produktiven Betrieb auch eine meist sinnvolle Konstellation. Um die Patch Installation während der OS Installation durchzuführen, wird i.d.R. ein dritter Job geschrieben, der als Schedule "Nach der OS Installation" eingetragen hat. Dies führt zwar zu einem Update der Betriebbsystemkomponenten, lässt aber die folgenden Anforderungen ausser Acht:
1) Alle Patche sollen auf einmal am Stück installiert werden.
2) Patche sollen zu einem definierten Zeitpunkt installiert werden.
3) Die Patche sollen nach den Paketinstallation laufen.
4) Es sollen alle Patche die freigegeben sind, auch auf dem PC installiert werden.
5) Der Benutzer darf sich erst anmelden, wenn alle Patche installiert sind.
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: