Da ich bereits in mehreren Kundenprojekten gefragt wurde wie man nun über die MEMCM Konsole am besten herausfinden kann welcher Client gerade über das CMG mit der Umgebung kommuniziert und da diese Information etwas versteckt zu finden ist, möchte ich in diesem Artikel kurz zwei Möglichkeiten aufzeigen wie diese Anforderung realisiert werden kann.

​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.

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.

Das Interesse an unserem im Sommer in Version 1.0 releasten Produkt „Packaging PowerBench" ist erfreulich hoch – die vielen Demo-Sessions, Eval-Anfragen und auch mehrere Neukunden in der letzten Zeit sind ein deutliches Zeichen dafür. Wir freuen uns sehr, dass unser Tool offensichtlich so gut ankommt und einen „Nerv" getroffen zu haben scheint, aber natürlich ruhen wir uns nicht auf unseren Lorbeeren aus und entwickeln sehr aktiv an einer neuen Version, die für das erste Quartal kommenden Jahres geplant ist.

Eines der neuen Features der Version 2.0 möchte ich in diesem Blog-Artikel kurz vorstellen.

Die meisten Leser dieses Blogs werden wahrscheinlich technisch orientierte User sein, die als Consultants, Administratoren, System Engineers oder Entwickler häufig „auf der Kommandozeile“ unterwegs sind. Die Verwendung der Eingabeaufforderung (cmd.exe) oder von Windows PowerShell gehört zu unserem Alltag und jeder kennt die Schwächen der Tools, die seit Jahrzehnten quasi identisch funktionieren und Verbesserungen und Weiterentwicklungen in maximal homöopathischen Dosen erfahren haben.

Mit der Neuentwicklung „Windows Terminal“, die auf GitHub als Open Source Software entwickelt wird, hat Microsoft einen neuen Anlauf gewagt, für die Windows-Welt ein zeitgemäßes Kommandozeilen-Interface zur Verfügung zu stellen.

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.

Die aktuelle Corona-Situation zwingt immer mehr Menschen ins Home Office und damit natürlich auch in die ein oder andere Videokonferenz. Bei einigen mag das "Home Office" vielleicht gar nicht mal in einem eigenen Büro sondern am Esstisch, Küche oder Wohnzimmertisch sein. Da kommt sehr schnell der Wunsch nach ein bisschen Professionalität bei Terminen mit Kunden oder Kollegen.

Aus diesem Grund gibt es seit letzter Woche nun auch in Microsoft Teams die Möglichkeit, neben dem bisher bekannten "Weichzeichnen", den Hintergrund durch mitgelieferte Bilder komplett zu ersetzen. Ebenfalls besteht die Möglichkeit die Auswahl der Bilder durch eigene zu Erweitern. Da diese Funktion jedoch nicht ganz intuitiv über die GUI lösbar ist, möchte ich hier kurz zeigen wie Sie eigene Bilder in Microsoft Teams einfügen können. 

Eines der mit Sicherheit spannendsten Features in SCCM 1906 ist das "Install Application" Feature mit dem der Administrator in der Lage ist, Software adhoc auf einem Gerät zu installieren. In diesem Beitrag möchte ich das neue Feature kurz etwas genauer beleuchten und starte zunächst mit den Voraussetzungen.

Die erste Voraussetzung ist sicherlich eine aktualisierte SCCM Umgebung mit Version 1906. Allerdings gibt es noch weitere Bedingungen die erfüllt sein müssen, bevor eine Applikation auf ein Gerät gepusht werden kann.

Voraussetzungen