NWC Services Blog

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. 

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

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.