Viele Kunden die DSM oder natürlich auch andere Applikationen über eigene Websites/Tools steuern, stehen spätestens immer wieder bei Updates vor der Situation, dass die Funktionen der Websites für den Zeitraum des Updates nicht verfügbar sind.

Hat man beispielsweise ein PSX basiertes Webinterface als Steuerungstool für DSM Funktionen, so wird das Webinterface solange nicht erreichbar sein, solange die Verbindung per PSX zum BLS nicht aufgebaut werden kann. Dies würde nicht nur bedeuten bis das Update abgeschloßen ist, sondern erfordert evtl. auch noch die Aktualisierung zusätzlicher Komponenten oder Module wie PSX und/oder der verwendeten Scripte. Versucht ein Anwender nun während der Downtime auf die Website zuzugreifen, erhält dieser unter Umständen Verbindungsfehler oder andere Meldungen, mit denen er wenig anfangen kann.

Ich möchte in diesem Artikel zwei einfache Möglichkeiten zeigen, wie Sie an Ihrem IIS entweder einer einzelnen Web Applikation oder einer kompletten Site eine "Wartungswebsite" vorschalten können.

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.

Für viele meiner Kunden ist der tägliche Umgang mit den DSM Log Files eher ein lästiges Übel als eine Freude. Dies ist vor allem darauf zurück zu führen, dass es zum einen eine große Vielfalt an verschiedenen Log Files zu den diversesten Aktionen gibt, als auch auf die einzelnen Log Files die oft mit sehr vielen Informationen gespickt sind und einem die Suche nach der gewünschten Information oft nicht leicht machen.

In diesem Blog möchte ich kurz auf eine Möglichkeit eingehen, sich mithilfe einer seit DSM 2016.1 angebotenen Sprach-XML für das Freeware Tool Notepad ++, die Arbeit mit den Log Files zu erleichtern und möchte kurz zeigen, wie man diese XML für seine eigenen Bedürfnisse anpassen kann.

Wer sich bereits mit Windows 10 beschäftigt hat, muss relativ schnell feststellen, dass selbst bei Windows 10 Enterprise sehr viele "Standard Apps" nach der Installation verfügbar sind, die man unter Umständen im Unternehmen nicht auf jedem Client zur Verfügung stellen möchte.

Im folgenden Artikel möchte ich kurz einen Weg beschreiben, wie bereits vor der Verteilung des Windows Images die Standard Apps deinstalliert werden können.

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.

Vor einiger Zeit habe ich bereits hier beschrieben wie man unter Windows 8.1 die Vorteile des Windows Server Features "Data-Deduplication" nutzen kann. Mit dem Update eines Data-Deduplication nutzenden Computers auf Windows 10, geht dieses Feature leider wieder verloren.

In diesem Blog möchte ich vor allem Wege aufzeigen, wie man ohne Datenverlust auf Windows 10 migrieren kann. Die Möglichkeit ansprechen, Data-Deduplication auch unter Windows 10 wieder zu implementieren und einen kleinen Ausblick in die Zukunft geben.

In diesem Artikel möchte ich ein etwas älteres Feature der DSM beschreiben (Bestandteil seit DSM 7.2.1), welches bei der Verwendung von Job-Scripts sehr hilfreich sein kann, jedoch relativ unbekannt ist. Das neu eingeführte Feature wurde zwar in den Release Notes erwähnt und ist auch in der Online-Hilfe dokumentiert, dennoch zeigt die Erfahrung, dass nur wenige DSM-Kunden Kenntnis über die Existenz oder Verwendung haben.

Es handelt sich um die Möglichkeit, in Job-Scripts auf die Werte von Variablen und Installationsparametern von Aufrufpaketen (Main Packages) zugreifen zu können.

Wer viel mit ODS Variablen arbeitet wird sicherlich schon einmal an dem Punkt angekommen sein an dem man sich die Frage stellt wo eine bestimmte Variable überhaupt überall gesetzt wurde. Leider ist dieser Verwendungsort über die DSMC nicht wirklich ersichtlich.

In folgendem Beitrag möchte ich einen Codeschnippsel erläutern, mit dem Sie die Zuweisungen der ODS Variable auslesen können.

In größeren Umgebungen mit vielen Administratoren die diverse Aufgaben innerhalb der DSM delegiert bekommen sollen, empfiehlt es sich oft schon wegen der reinen Übersichtlichkeit die User nicht alle einzeln zu berechtigen, sondern mit Berechtigungsgruppen für die Tätigkeitsgebiete zu arbeiten.

Entscheidet man sich hier z.B. für die Verwendung von externen Gruppen aus dem Active Directory reicht es oft aus, das Berechtigungskonzept einmal zu implementieren und alles weitere nur noch über die Gruppenmitgliedschaften des Users im AD zu regeln. An dieser Stelle sollte man sich allerdings entweder gut merken wo man seine Gruppen berechtigt hat oder man denkt über den Kauf von PSX (Powershell Extensions) nach, denn die DSM bietet leider nach wie vor keine Möglichkeit diese Informationen anzeigen zu lassen.

Ich möchte heute kurz zeigen wie Sie mit Hilfe der PSX schnell und einfach herausfinden können wo ihre Gruppe berechtigt ist, ohne dass Sie sich mühevoll durch unzählige Objekte klicken müssen.

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.