Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

Release der Packaging PowerBench 3.1

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. 

Weiterlesen
  3096 Aufrufe

Fehlermeldung beim Registrieren von PPB-Paketen in SCCM 2103

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.

Weiterlesen
  4602 Aufrufe

Sneak Peek auf neue PPB Features: Paket-Publishing nach Intune

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


Weiterlesen
  6007 Aufrufe

SmartShutdown und der Hiberboot

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.

Weiterlesen
  7920 Aufrufe

NWC Credential Provider für Windows 10 fit machen

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.

Weiterlesen
  13609 Aufrufe

Neue Version von Wimera

Eine neue Version von Wimera ist verfügbar und kann auf der NWC-Services Website heruntergeladen werden. Für den Betrieb von Wimera ist ein explizites Lizenfile notwendig, eine Demo Lizenz kann unter Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! oder https://www.nwc-services.de/service/wimera-trial-lizenz-beantragen-2 beantragt werden. 

Neben einigen kleineren Neuerungen und Bugfixes sind einige wesentliche neue Features eingeflossen: 

  • Ein umfangreicher Namensgenerator auf Basis von konfigurierbaren Schemas und der DSM Datenbank
  • Verschieben von Computern
  • Umbenennen von Computern
  • Protokollierung von Reinstall-Vorgängen
  • Update von Policyinstanzen

Detaillierte Informationen zu Wimera im Allgemeinen und die Erläuterung der neue Funktionen können unter https://www.nwc-services.de/produkte/wimera in Form von Text, Bild und Videos abgerufen werden. Die Videos sind ebenfalls in YouTube unter dem Suchbegriff "Wimera" oder in meinem YouTube Channel http://www.youtube.com/user/davidkoenig09/videos verfügbar. 

Weiterlesen
  4446 Aufrufe

DSM Distrihelper 1.2.0.4 verfügbar!

DSM Distrihelper 1.2.0.4 verfügbar!

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.

Download

 

 

 

Weiterlesen
  7079 Aufrufe

Steuern des NWC Credential Providers über User-defined Tasks

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:

Weiterlesen
  8964 Aufrufe

Installationszeitpunkt von DSM Paketen

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... ;-)

Weiterlesen
  8587 Aufrufe

Sperren der lokalen Anmeldung

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

Weiterlesen
  19650 Aufrufe