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.

Mit dem am 29.04.2021 erschienenen Service Update 1 für Ivanti DSM 2020.2 wurde das neues Feature "DSM Remote Control 2021" freigegeben und weitere Fehlerbehebungen vorgenommen.
Eine ausführliche Aufstellung aller behobenen Probleme finden Sie in den Release-Notes auf Ivanti.com.

Leider hat sich ein neues Problem eingeschlichen, auf das ich näher eingehen möchte.

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.

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.

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.