NWC Services Blog
Blogs von Consultants der NWC Services GmbH
Mit der Veröffentlichung von DSM 2022.1 wurde auch der neue Microsoft Intune Konnektor veröffentlicht. Dieser Konnektor, welcher mittels Azure App Registration über die Graph API mit Intune kommuniziert, ermöglicht unter anderem einen direkten Upload des DSM Agents zur Verteilung via Intune.
Prinzipiell bietet dieser Konnektor natürlich vor allem für hybride Client Management Ansätze ein sehr großes Potenzial. Da sich der Funktionsumfang der Seitens Ivanti zum aktuellen Zeitpunkt mitgeliefert wird jedoch noch in Grenzen hält, möchte ich heute zeigen wie Sie sich mit wenig Aufwand und DSM Bordmitteln auch jetzt bereits interessante Infos aus der Cloud in Ihre DSM Umgebung syncen können.
Aber was wäre denn interessant zu wissen? Ob es sich bei einem Client um ein AAD-Only oder ein Hybrid-Joined Gerät handelt? Oder vielleicht die Geräte-ID aus Intune? Kurz gesagt, eine Art "DSM Basis Inventarisierung" für Intune wäre doch toll.
Am gestrigen Dienstag, dem 15.12.2020, wurde die neue DSM-Version 2020.2 freigegeben. Neue Features wie Unterstützung für die Verteilung von MSIX-Paketen, PowerShell 7 Support, die Integration von Xtraction Reporting und weitere kleinere neue Optionen sowie natürlich die Behebung bekannter Probleme, lassen eine vielversprechende Version erwarten. Details finden Sie wie üblich in den offiziellen Release Notes, die Sie hier nachlesen können.
Allerdings möchte ich Sie mit diesem Blog-Artikel auf ein Problem aufmerksam machen, das sowohl in DSM 2020.1 als auch noch in der neuen Version 2020.2 besteht und das eventuell schwerwiegend genug ist, dass Sie aktuell von einem Update auf DSM 2020.x absehen sollten.
Einer der Hintergründe weshalb wir SmartShutdown entwickelt haben ist die Möglichkeit Software, Updates und dergleichen, beim Herunterfahren des PCs installieren zu können.
Vor Kurzem hatten wir von einem Kunden eine Supportanfrage erhalten das genau diese Funktionalität scheinbar nicht mehr gegeben ist und SmartShutdown immer nur nach einem Neustart des Rechners die zugewiesenen Pakete installiert.
Eine Analyse der DSM Logfiles konnte dieses Verhalten auch nur bestätigen, aber lieferte keinen genaueren Hinweis wieso sich SmartShutdown so verhält. Die Gruppenrichtlinien mit denen SmartShutdown gesteuert wird waren die erste Fehlerquelle die wir ausschließen konnten, gleiches galt auch für die eigentlichen SmartShutdown Skripte und Pakete.
Im Endeffekt bereitete uns eine eher nicht ganz so bekannte Windows Funktion namens Hiberboot bzw. Schnellstart die Probleme. Im Zuge der Windows 10 Implementierung wurde diese Funktion aktiviert und an alle Rechner per Gruppenrichtlinie verteilt, was bisher keinerlei Probleme verursachte. Bei SmartShutdown fiel es nun allerdings auf, da durch den Schnellstart der eigentliche Shutdown keiner mehr ist, sondern eher einem Neustart gleichzusetzen ist.
Über eine testweise Deaktivierung konnte dieses Verhalten reproduzierbar als Fehlerquelle identifiziert werden. Technisch passiert beim Schnellstart des Rechners folgendes im Hintergrund:
Vor dem Herunterfahren beendet Windows alle laufenden Anwendungen und schließt die Benutzersitzung. Dann wird aber der Windows-Kernel nicht, wie bei Windows 7, gestoppt, sondern das Betriebssystem schreibt während des Herunterfahrens Teile des Arbeitsspeichers mit dem Abbild des Kernels in eine Datei. Beim nächsten Booten werden der gesicherte Systemstatus (Speicherabbild, Prozessstatus) aus der Ruhezustandsdatei (hiberfil.sys) zurückgelesen und die Treiber ggf. neu initialisiert.
Um diesen Schnellstart Modus zu deaktivieren gibt es mehrere Möglichkeiten, zu Testzwecken wäre die Schnellste es über den aktuell ausgewählten Energiesparplan einzustellen. Hierzu gibt man „Energiesparplan" in die Suche der Taskleiste und klickt dann den Eintrag Energiesparplan auswählen an. Nun Links im Menü „Auswählen, was beim Drücken des Netzschalters geschehen soll" anklicken und im neuen Fenster oben auf „Einige Einstellungen sind momentan nicht verfügbar" klicken. Danach den Haken bei „Schnellstart aktivieren (Empfohlen)" entfernen und auf „Änderungen speichern" klicken.
Dies lässt sich zwar auf einigen wenigen Rechnern so einstellen, ist aber im Unternehmensumfeld wenig praktikabel. Hierzu ziehen wir wieder unsere Gruppenrichtlinien heran und setzen global die folgenden Werte:
Computer Configuration\Policies\Administrative Templates\System\Shutdown\Require use of fast startup -> Auf Disabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled -> Auf 0
Danach ist der Schnellstart deaktiviert und unser SmartShutdown lief wieder wie gewünscht mit all seinen Funktionalitäten. Laut diversen Foreneinträgen soll es auch in der Vergangenheit bereits bei Windows Build Updates vorgekommen sein das die Schnellstart Option wieder seitens Microsofts aktiviert wurde, was noch ein Grund wäre diese Einstellung per Gruppenrichtlinie zu verteilen.
Sollte ihr Interesse an SmartShutdown geweckt worden sein, oder treten bei ihnen ähnliche Probleme im Bezug auf SmartShutdown auf sprechen sie uns gerne jederzeit an.
Im Zuge einer Kundenanfrage zur Integration domänenfremder Clients in eine bestehende Umgebung kam die Frage auf wie man sicherstellen kann, dass die verschiedenen Benutzereinstellungen auf den neuen Clients bereitgestellt werden können.
Ivanti bietet hierzu mit dem Tool Migration Manager (ehemals DSM Migrate 7) eine recht charmante Lösung an. Hierbei handelt es sich um eine lizenzierte 3rd Party Applikation, welche um einige Funktionen und Scripte seitens Ivanti erweitert wurde und den Kunden dadurch einen erheblichen Mehrwert bietet.Der Migration Manger wird auf einem oder mehreren Management Point Servern installiert, über vorgefertigte DSM Pakete für den jeweiligen Einsatzzweck aufgerufen und bietet somit den Vorteil, dass auf die vorhandene DSM Infrastruktur zurückgegriffen werden kann.
Die 4 Kernfunktionen bestehen aus den Punkten:
• Extract Personality erlaubt die Auswahl von Einstellungen und Daten, die ihre persönliche "Computeridentität"ausmachen, und speichert diese an einem frei wählbare Speicherort.
• Inject Personality erlaubt die Auswahl und anschließende Übertragung einer zuvor gesicherten "Computeridentität" auf einen Ziel-Computer.
• Backup Personality Changes erlaubt die Ausführung inkrementeller Sicherungen der "Computeridentität".
• Restore Files erlaubt dem Benutzer oder dem Administrator, gezielt bestimmte Teile der "Computeridentität"zu suchen, zu prüfen und wiederherzustellen.
Quelle: Migration Manager User's Guide
In den vorgefertigten DSM Paketen werden über die bekannten Installations-Parameter unter anderem das Installationsverzeichnis des Migration Managers, Ablageort des Backups & Konfigurationsdatei referenziert:
• Extract Personality erlaubt die Auswahl von Einstellungen und Daten, die ihre persönliche "Computeridentität"ausmachen, und speichert diese an einem frei wählbare Speicherort.
• Inject Personality erlaubt die Auswahl und anschließende Übertragung einer zuvor gesicherten "Computeridentität" auf einen Ziel-Computer.
• Backup Personality Changes erlaubt die Ausführung inkrementeller Sicherungen der "Computeridentität".
• Restore Files erlaubt dem Benutzer oder dem Administrator, gezielt bestimmte Teile der "Computeridentität"zu suchen, zu prüfen und wiederherzustellen.
Quelle: Migration Manager User's Guide
In den vorgefertigten DSM Paketen werden über die bekannten Installations-Parameter unter anderem das Installationsverzeichnis des Migration Managers, Ablageort des Backups & Konfigurationsdatei referenziert:
Hier wird auf Benutzerdefinierte Variablen in der Infrastruktur verwiesen, um eine größtmögliche Flexibilität je nach Aufbau der eigenen DSM Infrastruktur gewährleisten zu können.
Um den Migration Manager nutzen zu können, müssen sie im Vorfeld definieren was genau an Benutzer-, Applikation-, Windowsdaten etc. berücksichtigt werden soll. Hierzu wird einfach die vorher installierte MigrationManager.exe aufgerufen, um die jeweiligen Einstellungen vorzunehmen:
Es besteht natürlich auch die Möglichkeit über die File- & Registry Regeln Aus- und Einschlüsse zu definieren, die je nach persönlicher Anforderung an die Sicherung von beispielsweise selbst erstellten Programmen angepasst werden können.
Wenn Sie die Konfiguration für ihre Umgebung definiert und in den DSM Paketen abgelegt haben, wird über diese Pakete der Backup und Restore Prozess angestoßen. Der Aufbau der Zuweisungen, Softwaregruppen muss im jeweiligen Fall natürlich gesondert betrachtet werden, da hier keine allgemeine Aussage getroffen werden kann wie es für sie „am besten passt".
Stark verallgemeinert kann man den Prozess so beschreiben das mit den Backup Paketen entweder „Alle" oder „dedizierte" Benutzer gesichert werden, gleiches gilt für den Restore Prozess. Zu beachten gilt das der Migration Manager in der Standard Konfiguration immer sogenannte „FullBackups" anlegt, für eine Inkrementelle Sicherung müssten die Scripte noch erweitert werden.
Bei der in der Einleitung genannten Kundenanfrage, konnte über den Migration Manager eine Migration der Benutzerdaten über unterschiedliche Domänen und Benutzernamen recht schnell und mit überschaubaren Anpassungen realisiert werden. Die automatische Migration über Domänen ist z.B.: schon ein Bestandteil der ursprünglichen Pakete.
Wenn wir ihr Interesse an diesem Produkt geweckt haben oder sie es bereits einsetzen und für ein spezifisches Projekt Unterstützung benötigen können sie natürlich gerne jederzeit auf uns zukommen.
Vor kurzem wurde ich wieder einmal von einem Kunden darauf angesprochen, dass bereits distribuierte Pakete nicht automatisch von Depots gelöscht werden, wenn man die Distributionziele am Paket bereinigt. Somit stellt sich vielen Kunden aber auch die Frage, wie man seine Depots demnach am besten aufräumen kann, da sich über die Jahre natürlich viele Daten ansammeln, die eigentlich nicht mehr gebraucht werden bzw. schon gar nicht mehr am ein oder anderen Depot liegen sollten.
Da diese Aussage jedoch seit DSM 2014.1 nur noch teilweise korrekt ist und man mithilfe einer neuen Infrastruktur Einstellung dieses Verhalten ändern kann, möchte ich in diesem Artikel kurz zeigen, wie man seine Pakete anhand der Job Definition automatisch bereinigen lassen kann.
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"...
Wie mein Kollege Frank Scholer bereits in seinem letzten Artikel schrieb, kommen mit der nächsten DSM Version (2017) die ja voraussichtlich Ende November erscheinen wird, wieder einige sehr interessante und nützliche Features in das Produkt DSM. Auch ich möchte deshalb in unserer kleinen Rubrik "Sneak Peek" ein weiteres neues Feature etwas genauer vorstellen.
Hierbei handelt es sich um die "Erweiterte Site Definition", mit der es ab sofort möglich ist, mehrere Site-Definitionen innerhalb einer einzigen Site anzugeben und nacheinander abarbeiten zu lassen. Die einzelnen Kriterien einer Site-Definition werden mit der neuen "Def-ID" gekennzeichnet. Dabei können mehrere oder auch nur eine einzige Site-Definition zutreffen und die Sitezugehörigkeit eines Clients bewirken.
Wie dieses Feature in der Praxis umgesetzt werden kann, möchte ich im folgenden Artikel etwas näher ausführen.
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.
Arbeitet man viel mit deaktivierten Policys / Policyinstanzen, hat man sich sicherlich schon des Öfteren gewünscht, dass diese ab und zu etwas deutlicher erkennbar wären. Generell werden Policyinstanzen von DSM in hellgrau dargestellt, was je nach Kontrast des Monitors oder mit zunehmender Feierabendmüdigkeit immer schwerer zu erkennen ist.
Da es seit DSM 2016.2 die Möglichkeit gibt deaktivierte Einträge bereits Out-Of-The-Box anzupassen, diese Funktion aber bei vielen Kunden nicht wirklich bekannt ist, möchte ich in diesem Artikel kurz zeigen, wie man die Anzeige hierfür anpassen kann.
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.
Dieser Ansatz bringt jedoch unter mehreren Gesichtspunkten Nachteile mit sich...