NWC Services Blog
Blogs von Consultants der NWC Services GmbH
Am heutigen 12.05.2022 wurde die neue Version 3.1 unserer NWC Packaging PowerBench veröffentlicht. Es handelt sich um einen Minor-Release, sodass sich die Änderungen gegenüber der Vorversion in Grenzen halten. Wir sind uns dennoch sicher, dass die Neuerungen bei Kunden und Interessenten gut ankommen und nützliche Anwendungsfälle adressieren. Dieser Blog-Artikel stellt die neuen Features vor.
Seit Version 2.0 erlaubt die Packaging PowerBench, Pakete direkt aus dem PPB-GUI heraus in SCCM zu registrieren. Damit entfällt die Notwendigkeit, nach der Erstellung eines Pakets, dies manuell in SCCM als Application anzulegen und sämtliche Eigenschaften manuell zu konfigurieren. Wenn Sie Ihre SCCM-Installation aber auf Version 2103 aktualisieren, erhalten Sie beim Verbindungstest auf die SCCM-Infrastruktur einen Fehler.
Dieser Blog-Artikel beschreibt die Ursache und den verfügbaren Workaround.
In einem früheren Blog-Artikel habe ich beschrieben, dass die kommende Packaging PowerBench 2.0 ein Feature beinhalten wird, um Pakete in das von Microsoft Intune verwendete Format zu konvertieren beziehungsweise zu exportieren. In diesem Artikel möchte ich nun beschreiben, wie Sie ein exportiertes Paket in Ihrem Intune-Mandanten registrieren und damit zur Verteilung an Ihre über Intune verwalteten Geräte bereitstellen können.
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.
Da bereits einige unserer Kunden mit DSM und der Verteilung von Windows 10 die ersten Erfahrungen sammeln, wurde ich vor kurzem auch darauf angesprochen ob es denn wieder einen "NWC Credential Provider" für Windows 10 geben würde, da die alte Version für Windows 7, den Login nur noch bedingt sperren würde bzw. man den gesperrten Login Screen sehr leicht durch drücken auf "Anderen Benutzer verwenden" entsperren könnte.
Aufgrund dieser Nachfrage möchte ich heute kurz zeigen wie Sie den "NWC Credential Provider" relativ einfach selbst, für Windows 10 fit machen können.
Hallo alle zusammen,
nach fast 3 Jahren hat der V6 Adminhelper nun endlich ein Update bekommen. Im Zuge dessen hat er auch direkt einen neuen passenderen Namen bekommen.
Nach der Installation starten Sie den neuen DSM Distrihelper einfach über das Startmenü wie bisher auch.
Eine kleine Bedienungsanleitung liegt der Installation bei. Ein Changelog ist im Anhang der Anleitung zu finden.
Als Nutzer des NWC Credential Providers ist es naheliegend, den Registry Key zum Sperren oder Entsperren des NWC Credential Providers über User-defined Tasks der DSMC zu steuern. Verwendet werden kann hier die Komponente reg.exe, die bei allen gängigen Windows Installation im Verzeichnis "%windir%\system32" zu finden ist. Allerdings ist dabei auf x64 Systemen zu beachten, dass die DSMC selbst ein 32-Bit Prozess ist und somit die korrekten Pfadangaben verwendet werden müssen, um die "richtige" 64-Bit reg.exe zu nutzen. Wird nämlich aufgrund der Windows Redirection die 32-Bit reg.exe verwendet, wird im Zielclient auch der 32-Bit Pfad (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node) genutzt, während der Credential Provider seinen Daten im 64-Bit Pfad der Registry ablegt.
Den Ausweg aus der Misere bietet der virtuelle Pfad "%windir%\sysnative" der ausschliesslich für 32-Bit Prozesse sichtbar ist und den Zugriff auf das 64-Bit-System32 Verzeichnis bietet. Die gesamte Konfiguration der 2 User defined Tasks zum entsperren und sperren des NWC Credential Provider sieht für ein x64-System wie folgt aus:
Vermutlich jeder NetInstall- / Enteo v6- / DSM 7-Administrator hat sich schonmal die Registry auf den gemanageten Clients unterhalb von Software\NetSupport\NetInstall\Installed Apps angeschaut, weil ja dort die ganzen Infos über die auf dieser Maschine bzw. für einen Benutzer ausgeführten Pakete hinterlegt sind.
Unter anderem gibt's dort auch einen Value LastInstallTime, in dem der Zeitpunkt der letzten Installation des jeweiligen Paketes hinterlegt ist. Allerdings ist dieser Wert vom Typ "Time_t" und wird in einem Byte-Array gespeichert, das die Anzahl der Sekunden seit dem 01.01.1970 angibt und ist damit für den durchschnittlich begabten Systemadministrator (oder Consultant – wie mich) eher nicht lesbar... ;-)
Ein in der Enteo/DSM-Welt immer wieder kontrovers disktuiertes Thema ist, ob im Anschluss an eine Betriebssystem-Installation über OSD ein sogenannter "AutoAdminLogon" durchgeführt werden soll oder nicht.
Unter NetInstall 5.x und OSD 3.x wurde standardmäßig ein solche automatische Anmeldung vorgenommen und über einen RunOnce-Eintrag sowohl der NetInstall-Client installiert als auch der NetInstall Agent und damit implizit der AutoInstaller gestartet.
Wird Enteo v6 bzw. DSM 7 und damit auch OSD in der entsprechenden Version eingesetzt, so findet standardmäßig keine automatische Anmeldung mehr statt. Stattdessen steht nach der Betriebssystem-Installation der zu installierende Rechner im Login-Bildschirm während im Hintergrund zunächst über ein Post OS Action Package der NetInstall-Client installiert wird und anschließend der Service-Installer die Applikationspakete installiert (aus diesem Grund ist auch die Standard-Ausführungseinstellung für Pakete auf "Egal, ob ein Benutzer angemeldet ist, oder nicht" gesetzt).
Unter Windows XP bzw. Windows Server 2003 und früheren Windows-Versionen war es problemlos möglich, durch Dienste ein Meldungsfenster auf dem Desktop darstellen zu lassen. Dies wurde - gerade auch in NetIntall-Umgebungen - auch durchaus regelmäßig angewendet, beispielsweise wenn durch den Service-Installer eine Installation ausgeführt wurde, die einen Neustart erforderte. Dann konnte man durch die NetInstall-Scriptbefehle "MessageBox" oder "MessageBoxEx" eine Meldung anzeigen lassen, und den Benutzer auf den bevorstehenden Neustart aufmerksam machen oder ihn fragen, ob der Neustart jetzt direkt ausgeführt werden sollte.
Seit Windows Vista können Dienste jedoch keine Meldungsfenster mehr anzeigen - die Ursache hierfür liegt in der sogenannten "Session 0 Isolation", auf die an dieser Stelle nicht näher eingangen werden soll. Sehr interessante Hintergrundinformationen dazu findet man beispielsweise unter http://windowsteamblog.com/windows/b/developers/archive/2009/10/01/session-0-isolation.aspx. Auf jeden Fall führt diese Session 0 Isolation dazu, dass das oben beschriebene Szenario mit dem Meldungsfenster, das fragt, ob ein Reboot ausgeführt werden darf, unter Windows Vista, Windows Server 2008 und höher nicht mehr funktioniert
Um nun diesem Problem zu begegnen, hat die NWC Services eine neue Version des Tools MSGBOXT entwickelt.