Login

Franks Blog zu diesem und jenem technischen Gedöns

Hier blogge ich über Themen, die mich - und vielleicht auch andere - interessieren (könnten)

Frank Scholer

Frank Scholer

Geschäftsführer (verantwortlich für den technischen Bereich) bei der NWC Services GmbH

Veröffentlicht von am in DSM

Bei der Paketierung in DSM gibt es ja verschiedene Möglichkeiten, dafür zu sorgen, dass Pakete nur unter bestimmten Bedingungen und Voraussetzungen auf den gemanagten Clients installiert werden. Zu nennen wären hier (ohne Anspruch auf Vollständigkeit):

  • unterstützte Plattformen
  • serverseitige Voraussetzungen
  • clientseitige Voraussetzungen
  • Bedingungen für vorhandene Installationen

Die Bedingungen für unterstützte Plattformen sollten klar sein: es werden nur für die Policy-Ziele auch Policy-Instanzen erzeugt, die eine der von dem Paket unterstützten Plattformen verwenden. Ebenso verhält es sich mit serverseitigen Voraussetzungen, auch hier wird eine Policy-Instanz nur dann erzeugt, wenn der Business Logic Server erkennt, dass die angegebenen Voraussetzungen von einem Policy-Ziel erfüllt sind.

Anders verhält es sich jedoch bei clientseitigen Voraussetzungen: für die Policy-Ziele werden auf jeden Fall Policy-Instanzen erzeugt (sofern die Plattform-Einstellungen und serverseitigen Voraussetzungen dem nicht widersprechen). Da DSM aber nicht alle erdenklichen Zustände über die verwalteten Clients in seiner Datenbank speichern kann, werden solche clientseitigen Voraussetzungen erst zur Laufzeit auf den Endgeräten geprüft und dann entschieden, ob die Installation ausgeführt wird oder nicht.

Ein naheliegender Anwendungsfall für die Verwendung von clientseitigen Voraussetzungen ist daher beispielsweise die Prüfung, ob genug freier Speicherplatz für die Installation eines Pakets zur Verfügung steht oder ob die Installation durch die Existenz eines Flags in der Registry oder im Dateisystem erlaubt ist. Bei diesem Vorgehen lauert jedoch "eine böse Falle"...

Auch in der kommenden Version 2017 wird es wieder etliche sinnvolle Neuerungen geben, die DSM noch flexibler und damit universeller einsetzbar machen. Dabei mausert sich das System mehr und mehr vom reinen Softwareverteilsystem zur zentralen Konsole, mit der typische administrative Aufgabenstellungen des täglichen Geschäfts erledigt werden können.

Eines dieser neuen Features möchte ich in diesem Artikel vorstellen, nämlich die Möglichkeit, benutzerdefinierte Aktionen lokal auf DSM-gemanageten Clients ausführen zu lassen. Der Phantasie sind bei den Anwendungsfällen kaum Grenzen gesetzt, beispielsweise lassen sich damit dezentral die Logfiles einsammeln oder es findet es eine Bereinigung des Festplattenspeichers statt oder ein Client wird bei Verdacht auf Virenbefall nach Schadsoftware gescannt oder oder oder...

Die Umsetzung des Anti-Malware Scans mit Windows Defender möchte ich in diesem Artikel beispielhaft beschreiben.

Veröffentlicht von am in DSM

Seit DSM-Version 2015.1 ist es ja möglich, das System ohne clientseitige Konten zu betreiben – der Service-Installer kann im Kontext des LocalSystem-Accounts ausgeführt werden und auch der Zugriff auf das Depot für das Staging der Pakete kann in Active Directory Umgebungen mit dem Computerkonto erfolgen. Somit sind in der Konfigurationsdatenbank nur noch die Credentials von Management Point Konten gespeichert, die aber durch die asynchrone Verschlüsselung wirksam geschützt sind.

Trotzdem ist es immer wieder erforderlich, Setup-Programme oder andere Aktionen im Rahmen von DSM-Scripts in einem definierten Benutzerkontext auszuführen, um Zugriff auf Netzwerkressourcen wie Back-End Systeme, Datenbanken, Fileserver oder ähnliches zu haben. Hierfür wird in aller Regel innerhalb der eScripts der Befehl RunAsEx verwendet und dort der Benutzername und das zugehörige Kennwort angegeben.

b2ap3_thumbnail_RunAsEx_AccountSpecified.png

Dieser Ansatz bringt jedoch unter mehreren Gesichtspunkten Nachteile mit sich...

 

Es besteht meiner Erfahrung nach große Unsicherheit, wie man Windows bei Verwendung von Advanced Patch Management (APM) oder PatchLink (PL) konfigurieren soll, damit es nicht auf die Idee kommt, auf den Microsoft Servern selbständig nach Updates zu suchen, diese herunterzuladen und – insbesondere unter Windows 10 – zu einem völlig willkürlichen Zeitpunkt zu installieren. 

Die empfohlenen Einstellungen waren auch schon das ein oder andere mal Thema im DSM Forum, beispielsweise in diesem oder diesem Thread.

Während man bei Windows 7 und Windows 8.1 noch einfach über Gruppenrichtlinien den ungewollten Zugriff auf die Microsoft Upate Server unterbinden kann, stellt sich die Sache bei Windows 10 – auch für Clients, die für die Verwendung eines internen WSUS-Servers konfiguriert sind – etwas anders dar...

Immer noch erfreut sich Windows 7 im Business-Bereich großer Beliebtheit. Um das in die Tage gekommene Client-Betriebssystem auf einen aktuellen Stand zu bringen, müssen jedoch zahlreiche Patches nachinstalliert werden, da das letzte offiziell von Microsoft verfügbare Image Windows 7 mit integriertem Service Pack 1 mittlerweile sechs Jahre "auf dem Buckel" hat. Zwar hat Microsoft im letzten Oktober die Patch-Strategie an den Windows 10 Mechanismus angepasst, sodass es seitdem nur noch kumulative monatliche Updates gibt, trotzdem ist die Zahl der nachzuinstallierenden Patch-Pakete auf einer "nackten" Windows 7 SP1 Installation exorbitant.

b2ap3_thumbnail_Windows-Update-nach-Windows-7-Installation.png

 

Wird also ein Original Microsoft-Image für die Grundinstallation von Rechnern verwendet, so führt dies zu extrem langen Installations-Zeiten. Daher sind mittlerweile Maßnahmen, ein benutzerdefiniertes Windows 7 Referenz-Image zu erstellen und für die Betriebssystem-Installation zu verwenden, nicht mehr – wie früher – optional, sondern beinahe "Pflicht geworden".

Veröffentlicht von am in PowerShell Extensions / PSX

Mit DSM 2016.2 wurde das Konzept des "User Centric Managements" in DSM vorgestellt. Dabei geht es unter anderem darum, dass Benutzer sogenannte "assoziierte Computer" haben können (und umgekehrt haben Computer natürlich auch assoziierte Benutzer). Bei der Zuweisung von Software-Paketen auf Benutzer oder Benutzergruppen kann dann festgelegt werden, dass die Pakete nicht mehr auf allen Maschinen, auf denen sich diese Benutzer anmelden, installiert werden, sondern nur noch auf den assoziierten Geräten. Damit wird der Wildwuchs und die unkontrollierte Installation von eventuell lizenzpflichtiger Software auf einer unbekannten Anzahl von Systemen unterbunden.

b2ap3_thumbnail_AssociatedUserPolicy.png

Die Frage ist aber nun, wie Computer- und Benutzer-Objekte in DSM assoziiert werden können und wie diese Assoziationen bei Bedarf automatisiert und über PSX-basierte PowerShell-Scripts gepflegt werden können.

Veröffentlicht von am in PowerShell Extensions / PSX

Bereits seit Ende Januar 2017 ist die neue Version 4.0 unserer PowerShell Extensions for HEAT Client Management verfügbar - leider komme ich erst jetzt dazu, einen Blog-Artikel darüber zu schreiben, der die Neuerungen und Verbesserungen gegenüber der Vorgängerversion verdeutlicht. Neben 40 komplett neuen Cmdlets wurden sowohl zusätzliche Parameter für bereits bestehende Cmdlets, zusätzliche Methoden für Objekte und Performance-Verbesserungen implementiert. Außerdem wurden einige (wenige) interne Fehler behoben.

Dieser Blog-Artikel listet die Veränderungen im Detail.

Markiert in: DSM 2016.2 PowerShell PSX

Kürzlich kam im deutschsprachigen DSM-Forum eine interessante Fragestellung auf, wie man denn in DSM bei Verwendung des Advanced Patch Managements mit den monatlichen Patches von Windows 10 umgehen könne. Die Diskussion ist unter http://forum.enteo.com/showthread.php?t=16367 nachzulesen.

Das dort angesprochene Problem besteht darin, dass wenn das APM nach Best Practices eingerichtet und betrieben wird, es passieren kann, dass ein neu zu installierender Rechner, keinerlei Windows 10 Patches erhält und daher völlig ungepatcht in die Produktion übergeben wird. Ein Zustand, den man natürlich tunlichst vermeiden sollte. Die Gründe, dass es zu diesem Problem kommen kann, sind in einer Kombination verschiedener Einstellungen und Randbedingungen zu suchen...

Veröffentlicht von am in PowerShell Extensions / PSX

 

Update (23.12.2015): aufgrund des in diesem Artikel beschriebenen Problems, wurde der Download des Windows Management Frameworks 5.0 zurückgezogen. Details finden sich in folgendem Blogartikel des PowerShell-Teams: http://blogs.msdn.com/b/powershell/archive/2015/12/23/windows-management-framework-wmf-5-0-currently-removed-from-download-center.aspx.

 

Vor knapp einer Woche, am 16.12.2015, wurde die neue Version 5.0 des Windows Management Frameworks offiziell freigegeben, das ja als zentrale Komponente die Windows PowerShell 5.0 enthält. Dadurch sind jetzt auch die aktuellen in Windows 10 vorhandenen Funktionen wie das PackageManagement, PowerShellGet, PowerShell Klassen und anderes mehr für ältere Betriebssystem-Versionen verfügbar und unterstützt. Die Ankündigung ist im Windows PowerShell Blog unter http://blogs.msdn.com/b/powershell/archive/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available.aspx nachzulesen, die Downloads sind unter https://www.microsoft.com/en-us/download/details.aspx?id=50395 erreichbar.

Allerdings führt ein Bug im Installer dazu, dass nach der Installation das Laden des Moduls unserer PowerShell Extensions for HEAT Client Management (PSX) fehlschlägt. Aber nicht nur die PSX sind betroffen, sondern alle Module, die nicht in den Standard-Modulverzeichnissen installiert sind.

Der Versuch das PSX Modul oder jedes andere PowerShell Modul, das nicht in den Standardpfaden gefunden wird, zu laden führt zu der folgenden Fehlermeldung:

b2ap3_thumbnail_PSXLoadError.png

Veröffentlicht von am in DSM

Wir alle, die wir mit DSM arbeiten, sind sicherlich regelmäßige "Leser" der DSM Logfiles, von denen es ja jede Menge gibt. Die Schwierigkeit für Anfänger (und durchaus auch manchmal noch für Fortgeschrittene) beim Ergünden einer Problemursache besteht meistens nicht darin, das Problem im Logfile zu finden, sondern das richtige Logfile zu identifizieren, indem das (vermutete) Fehlverhalten protokolliert ist.

Obwohl ich doch jetzt schon ein paar Jahre DSM-Erfahrung auf dem Buckel habe, hat mir ein Kunde letztens ein paar Fragen zu Logfiles gestellt, die ich so aus dem Stehgreif auch nicht beantworten konnte. Der Support hat mir super-schnell und kompetent auf die Fragen geantwortet, aber da ich denke, dass diese Infos vielleicht auch bei anderen DSM-Anwendern nicht so bekannt sind, dachte ich, ich schreibe einen mehr oder weniger kurzen Blog-Artikel dazu.

Die Fragen des Kunden waren:

  • Wann werden eigentlich alte Logfiles gelöscht und werden immer die ältesten gelöscht (hier hatte ich noch Infos aus NetInstall 5.x Zeiten, war mir aber nicht sicher, ob diese Mechanismen heute noch gültig sind)?
  • Wieviele Logfiles werden eigentlich vorgehalten und lässt sich die Anzahl konfigurieren?
  • Manche Logs werden ja in einem ZIP-Unterverzeichnis archiviert. Kann man das beeinflussen oder konfigurieren?
Zum Seitenanfang

Cookies erleichtern die Bereitstellung der Webseite. Mit der Nutzung dieser Webseite erklären Sie das sie damit einverstanden sind, dass wir Cookies verwenden.