NWC Services Blog
Blogs von Consultants der NWC Services GmbH
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.
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"...
Seit geraumer Zeit besteht in DSM die Möglichkeit, eine ODS Variable vom Typ "Zeitplan" zu erstellen. Da diese Variable im eScript über die "If"-Anweisung "IsInTimeframe" geprüft werden kann, ergeben sich hieraus gerade für Installationen viele neue Möglichkeiten. Somit wäre es denkbar einen Softwarerollout in mehrere "dynamische Phasen" (führe Aktion 1 aus wenn innerhalb Wartungszeitfenster und Aktion 2 wenn nicht) zu unterteilen, ohne das der DSM Administrator weitere Änderungen am eScript oder der Policy vornehmen muss, wie es oft bei der Verteilung von Patchen oder z.B. auch einer schleichenden Windows 10 Migration gewünscht ist. Ein "Aufschieben" oder "Erweitern" des Zeitplanes greift bei Ausführung des eScripts sofort.
Möchte man nun im eScript den "Beginn" oder das "Ende" des Wartungszeitplans herausfinden, gibt es für den Builtin DSM Wartungszeitplan den eScript Befehl "GetMaintenanceTimes". Leider ist es über diesen Befehl aber zum jetzigen Zeitpunkt nicht möglich einen eigenen Wartungsplan auszulesen um die gewünschten Informationen zu erhalten. Weist man den Wartungsplan einer DSM Variablen zu und lässt sich den Inhalt ausgeben, erscheint die Interpretation dieses codierten Strings auf den ersten Blick relativ schwierig.
Hier ein Custom Wartungszeitplan und der Inhalt der ODS Variablen als String:
1;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgP///z8AAAAA
In diesem Artikel möchte ich zeigen, wie der angezeigte String per PowerShell interpretiert und die darin enthaltene Information in DSM weiterverarbeitet werden kann. Dies würde sich sowohl mit als auch ohne PSX realisieren lassen.
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...
Vor kurzem wurde ich gefragt, wie man am besten damit umgeht, einen DSM gemanagten Client zu reinstallieren, der jedoch sein Betriebssystem nicht über OSD, sondern über ein anderes System Deployment Tool wie z.B. WDS bekommt.
Problem hierbei ist, dass bei einer "Reinstallation" von Policyinstanzen der Ausführungsmodus "Reinstallation" und nicht wie gewünscht "Installation" gesetzt wird, was natürlich zu unerwünschten Effekten führen kann sofern auch innerhalb der Scripte die unterschiedlichen Ausführungsmodi geprüft und mit verschiedenen Aktionen belegt werden.
Um während der OSD Phase im Fehlerfall Log Files einsehen zu können, haben viele unserer Kunden entweder mehrere Boot Environments mit unterschiedlichen Optionen (z.B. "Debug Mode" oder "Extended Logging") in ihrer Umgebung zur Verfügung gestellt oder haben die von uns angebotene und frei verfügbare Erweiterung "Pimp my Boot Environment" in die bestehenden Boot Environments integriert.
Da es aktuell im HEAT Forum zu diesem Thema eine Diskussion gab, wie man in der OSD Phase im Fehlerfall an die Log Files im PE heran kommt, möchte ich heute kurz eine sehr einfache und wahrscheinlich genauso unbekannte Möglichkeit zeigen wie man sein aktuell zugewiesenes PE ohne große Anpassungen dazu bringen kann, beim Start oder im Fehlerfall des OSD Clients eine Eingabeaufforderung zu starten.
Für viele meiner Kunden ist der tägliche Umgang mit den DSM Log Files eher ein lästiges Übel als eine Freude. Dies ist vor allem darauf zurück zu führen, dass es zum einen eine große Vielfalt an verschiedenen Log Files zu den diversesten Aktionen gibt, als auch auf die einzelnen Log Files die oft mit sehr vielen Informationen gespickt sind und einem die Suche nach der gewünschten Information oft nicht leicht machen.
In diesem Blog möchte ich kurz auf eine Möglichkeit eingehen, sich mithilfe einer seit DSM 2016.1 angebotenen Sprach-XML für das Freeware Tool Notepad ++, die Arbeit mit den Log Files zu erleichtern und möchte kurz zeigen, wie man diese XML für seine eigenen Bedürfnisse anpassen kann.