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.

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.

Bei der Installation von Hyper-V VMs der Generation 2 per DSM unter Verwendung eines WinPE 4.0 kommt es dazu, dass während der OSD Phase die Tastatur innerhalb der VM nicht verwendbar ist. Dies kommt daher, dass es bei virtuellen Maschinen der Generation 2 keine emulierte Tastatur gibt. Des Weiteren ist der Software-Tastatur Treiber ebenfalls kein Bestandteil eines WinPE 4.0.

Bei einer funktionierenden Umgebung stellt dies in der Regel auch kein Problem dar. Kommt man nun aber z.B. an den Punkt, dass man im PE eine Eingabeaufforderung zum Debuggen starten möchte, kann es durchaus vorteilhaft sein wenn man per Tastatur dann auch Eingaben tätigen kann.

Um diese kleine Unschärfe zu beseitigen können die Hyper-V Integration Services direkt in das Bootenvironment integriert werden. Wie Sie dies machen können, möchte ich Ihnen hier kurz zeigen.

Nach einem Upgrade von enteo v6 auf DSM 7 können die bestehenden OSD Pakete weiter verwendet werden.

Allerdings empfiehlt es sich das WinPE Bootenvironment zu aktualisieren, um gleich die DSM 7 Client Binaries im WinPE zu haben.

Ansonsten wird erst ein v6 WinPE Client gestartet, der sich dann die aktuellsten Client Binaries aus dem Netz zieht um sich zu aktualisieren.

Das dauert pro Client ein paar Sekunden und kann durch die Option "Update OSD Client" beim WinPE Update umgangen werden.