NWC Services Blog
Blogs von Consultants der NWC Services GmbH
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.
In jüngerer Vergangenheit sind wir von einigen Anwendern unserer PowerShell Extensions für FrontRange DSM (PSX) darauf aufmerksam gemacht worden, dass es beim Absetzen von PSX-Kommandos die fehlschlagen, zu einer kryptischen Fehlermeldung kommt, die nur besagt dass das es sich bei der Antwort um nicht-wohlgeformtes XML handeln würde.
Dies ist natürlich wenig aussagekräftig und hilft bei der Ergründung der Fehlerursache nicht weiter.
Im oben dargestellten Fall kann man vielleicht noch selbst darauf kommen, dass es schlicht nicht möglich ist, eine Software-Kategorie unterhalb von "Managed Users & Computers" zu erstellen – in aller Regel wird man jedoch auf die konkrete Fehlermeldung angewiesen sein, um die Ursache des Problems erkennen und beheben zu können.
Das beobachtete Verhalten tritt im Übrigen nur auf, wenn die Umgebung schon auf DSM 2013.2 (oder neuer) aktualisiert wurde.
Eine der – weitgehend undokumentierten – Neuerungen in DSM 2013.2, ist die Möglichkeit im Rahmen des CSV-Imports von Objekten, diese gleich zu Mitgliedern statischer Gruppen im ODS zu machen.
Sinn und Zweck dieser Möglichkeit ist naheliegenderweise, dass ohne weitere manuelle Aktionen über die Mitgliedschaft in Softwarezuweisungs-Gruppen neuen Objekten (vermutlich in aller Regel Computer-Objekten) bestimmte Software-Pakete oder sogar ganze Sets an Standard-Paketen zugewiesen werden sollen. Damit lässt sich dann eine weitgehende Automatisierung von Rollouts oder Betriebssystem-Migrationen realisieren, wenn im Rahmen von Hardware-Tausch Szenarien, die Daten vom Lieferanten vorab bereitgestellt werden können.
Die Information beziehungsweise eine Dokumentation, welche Syntax das Import-File allerdings haben muss, um Objekte zu Mitgliedern statischer Gruppen zu machen, ist allerdings schwer zu finden...
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.
Seit vergangenem Dezember ist die neue Version FrontRange HEAT DSM 2013.2 verfügbar und spätestens mit dem Release des ersten Hotfix-Bundles vor wenigen Tagen, stehen mehr und mehr Kunden vor der Umstellung auf die neue Version.
Wie mit jedem neuen Release, gab es auch diesmal etliche Änderungen am User-Interface, neue Möglichkeiten und neuen Infrastruktur-Optionen. Hinter den Kulissen wurde aber natürlich auch wieder viel geändert, unter anderem auch am Administration Webservice - der Schnittstelle, über die unsere PowerShell Extensions mit der DSM Infrastruktur kommunizieren. Das bedeutet, dass die Version 2.1 der PSX nicht vollständig kompatibel zum neuesten DSM-Release ist.
Wir freuen uns daher, Ihnen mitteilen zu können, dass seit heute der Kompatiblitäts-Release PSX 2.1.1 zur Verfügung steht, mit dem die vollständige Kompatibilität zur aktuellen Version wiederhergestellt wird.
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:
