Oft stellt sich beim Kunden die Frage „Wo werden die Paket Dokumentationen abgelegt“? Idealerweise wird heutzutage der SharePoint-Server zur Dateiablage verwendet, es gibt allerdings noch viele Umgebungen, in denen es noch keine Content Management Systeme gibt.

Somit bietet es sich auch an, die Paketdokumentationen im Paketverzeichnis des DSM Packages abzulegen. In diesem Zusammenhang hat sich der Hersteller schon ganz früh das Verzeichnis Intern$ einfallen lassen. Dieses Verzeichnis dient genau dem Zweck, Dateien mit ins Paketverzeichnis abzulegen, welche – um nicht unnötig kostbaren Plattenplatz zu verschwenden – von der Distribution ausgeschlossen sind.

Wie Sie dieses Verzeichnis sinnvoll und einfach nutzen können, erkläre ich am folgenden Beispiel:

Ich verwende hierfür das Application Template und lege im Paketverzeichnis neben dem Extern$-Unterverzeichnis (zur Ablage der Installationsquellen) zusätzlich das Intern$-Unterverzeichnis an, in dem ein Template für die Paket-Dokumentation abgelegt wird. Das hat den Vorteil, dass bei der Erstellung eines neuen Software Pakets ein einheitliches Dokument verwendet wird.

Mit DSM 2014 wurden erstmals die Begriffe "Patch Kategorien" und "Patch Rollout Rules" eingeführt. Um diese neuen Konzepte zu verstehen, ist ersteinmal einiges herumprobieren notwendig. Der folgende Designvorschlag soll den Einstieg in dieses mittlerweile komplexe Thema erleichtern. Es wird folgend ausschliesslich auf die Konfiguration dieser neuen Features eingegangen. Für die vollständige Konfiguration von APM im jeweiligen DSM Umfeld müssen noch diverse weitere Dinge (Installationsreihenfolge von Patchen in Bezug auf Softwarepakete, Definition der Patchziele, Rolloutzyklen, Zusammenarbeit mit WSUS, etc.) betrachtet werden.

Ein Kunde von uns hatte die Anforderung, dass die Patches von Microsoft im späteren Workflow anders behandelt werden sollten als die Patches von Drittanbietern. Vereinfacht dargestellt sollten erstere auf eine Gruppe und die der Drittanbieter auf eine andere Computergruppe zugewiesen werden.

Der Patch Management Dienst ist so konfiguriert, dass alle Patches einer statischen Computergruppe namens "DownloadOnly" zugewiesen werden, die allerdings keine Computer enthält. Von da aus werden sie mittels Targetlistenerweiterung weiter an die Gruppen "Microsoft" bzw. "ThirdParty" verteilt.

Die Pilotgruppen sind hier ausser acht gelassen, es geht um die grundsätzliche Logik.

Während des Imports von Patches lädt der Patch Management Dienst die Patches herunter und entpackt diese in den temporärer Ordner "SPDTemp". Dieses Verzeichnis liegt standardmäßig im Verzeichnis "%CommonProgramFiles%\enteo", welches über die Infrastruktureinstellung "Directory on the computer for runtime data" (Site Einstellung) konfigurierbar ist.

In den letzten Jahren habe ich sehr viele kundenspezifische Programme entwickelt, die über die SOAP Schnittstelle auf die DSM-Umgebung zugreifen. Es handelte sich dabei vielfach um Windows Dienste, die spezielle Aufgaben durchführten. Dazu zählten unter anderem:

• ein Abgleich der Computerkonten zwischen Active Directory, DSM und Discovery
• ein Patch Management Prozess, bei dem Policies nach einem Regelwerk verschoben / erweitert werden
• Policyinstanzen, die nicht compliant sind auf "Reinstallation" zu setzen und ggf. noch auf den Stand der Policy bringen 
• und viele verschiedene mehr.

Darüber hinaus habe ich auch reine Kommandozeilenprogramme entwickelt, die z.B. Computerobjekte anlegen, Gruppenmitgliedschaften und Policies verwalten sowie andere DSM Verwaltungsaufgaben durchführen. Bei allen Entwicklungen ging es entweder um die Integration der Aufgabe in bestehende / neue Prozesse oder um die Automatisierung von Standardaufgaben.

Alle Programme wurden in C# mit Visual Studio als Entwicklungsumgebung erstellt.

Seit gut einem Monat bin ich Senior Consultant im Team der NWC Services GmbH und habe die PowerShell Extensions für DSM 7 (PSX) (https://www.nwc-services.de/produkte/psx) kennen gelernt, die viele unserer Kunden einsetzen. Mittlerweile sind die PSX zum Standard geworden, wenn Anforderungen, wie sie oben genannt sind, umgesetzt werden sollen. Aber was sind die Gründe dafür?       

Viele Unternehmen scheuen das Update des Internet Explorer 8 auf eine neue Version, da viele (speziell unternehmensinterne) Websites genau auf die Version 8 zugeschnitten sind und damit ein erheblicher Aufwand beim Update des Browsers zu erwarten ist.

Mit Einführung des Enterprise Mode mit Internet Explorer 11 und der Verfügbarkeit des IE 11 auf Windows 7 hat Microsoft nun auf diese Problematik reagiert. Der Enterprise Mode gestattet es der zentralen IT, eine Liste von Websites zu pflegen, für die der Internet Explorer automatisch in einen IE 8 Kompatibilitätsmodus schaltet.

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.

Anfang des Jahres hat Immidio sein neues Helpdesk Support Tool released, was es ausgwählten Administratoren ermöglicht, Benutzereinstellungen wieder auf einen definierten Stand zurückzusetzen. Dieses Szenario ist eine immer wiederkehrende Anforderungen im täglichen Betrieb. Werden Benutzereinstellungen durch Störungen in der Infrastruktur oder durch falsche Bedienung durch den Benutzer selber zerstört, müssen diese komfortabel wieder hergestellt werden. Zwar existiert dazu das Flex+ Selfservice Tool, erfordert aber einen interaktiven Eingriff durch den Benutzer und somit auch mindestens eine angemeldete Benutzersession. 

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