Mit DSM 2016.2 wurde das Konzept des "User Centric Managements" in DSM vorgestellt. Dabei geht es unter anderem darum, dass Benutzer sogenannte "assoziierte Computer" haben können (und umgekehrt haben Computer natürlich auch assoziierte Benutzer). Bei der Zuweisung von Software-Paketen auf Benutzer oder Benutzergruppen kann dann festgelegt werden, dass die Pakete nicht mehr auf allen Maschinen, auf denen sich diese Benutzer anmelden, installiert werden, sondern nur noch auf den assoziierten Geräten. Damit wird der Wildwuchs und die unkontrollierte Installation von eventuell lizenzpflichtiger Software auf einer unbekannten Anzahl von Systemen unterbunden.

Die Frage ist aber nun, wie Computer- und Benutzer-Objekte in DSM assoziiert werden können und wie diese Assoziationen bei Bedarf automatisiert und über PSX-basierte PowerShell-Scripts gepflegt werden können.

Bereits seit Ende Januar 2017 ist die neue Version 4.0 unserer PowerShell Extensions for HEAT Client Management verfügbar - leider komme ich erst jetzt dazu, einen Blog-Artikel darüber zu schreiben, der die Neuerungen und Verbesserungen gegenüber der Vorgängerversion verdeutlicht. Neben 40 komplett neuen Cmdlets wurden sowohl zusätzliche Parameter für bereits bestehende Cmdlets, zusätzliche Methoden für Objekte und Performance-Verbesserungen implementiert. Außerdem wurden einige (wenige) interne Fehler behoben.

Dieser Blog-Artikel listet die Veränderungen im Detail.

In manchen Fällen kann es durchaus von Vorteil sein, wenn man sich ohne großen Aufwand selbst einen kleinen "Installer" basteln kann. Gerade für kleinere Aufgaben im Bereich der Automatisierung und vielleicht auch wenn man nicht unbedingt auf Deployment Tools wie DSM und Co. zurück greifen kann, lassen sich somit z.B. eigene Scripte inkl. der benötigter Dateien schnell und einfach in einem Archiv zusammen fassen, welches sich bei Ausführung selbst entpackt und die beinhaltenden Aktionen automatisch ausführt.

Wie Sie sich ein solches, selbst-extrahierendes Archiv mit dem Freeware Tool 7-Zip erzeugen können, möchte ich Ihnen in diesem Artikel nun zeigen.

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.

Beim Einsatz des aktuellen Windows 10 Anniversary Update (Version 1607) Enterprise in einer Active Directory-Umgebung tritt folgendes Problem auf: Der in die Notebooks eingebaute Fingerabdruck-Sensor kann trotz korrekt installierten Treibers nicht ohne Weiteres in Betrieb genommen werden. Unter "Einstellungen > Anmeldeoptionen" bleibt das Feld zum Aktivieren des Fingerabdruck-Sensors zunächst inaktiv; auch ein PIN für die Anmeldung kann nicht eingegeben werden.

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.

Kürzlich kam im deutschsprachigen DSM-Forum eine interessante Fragestellung auf, wie man denn in DSM bei Verwendung des Advanced Patch Managements mit den monatlichen Patches von Windows 10 umgehen könne. Die Diskussion ist unter http://forum.enteo.com/showthread.php?t=16367 nachzulesen.

Das dort angesprochene Problem besteht darin, dass wenn das APM nach Best Practices eingerichtet und betrieben wird, es passieren kann, dass ein neu zu installierender Rechner, keinerlei Windows 10 Patches erhält und daher völlig ungepatcht in die Produktion übergeben wird. Ein Zustand, den man natürlich tunlichst vermeiden sollte. Die Gründe, dass es zu diesem Problem kommen kann, sind in einer Kombination verschiedener Einstellungen und Randbedingungen zu suchen...

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.

Vor knapp einer Woche, am 16.12.2015, wurde die neue Version 5.0 des Windows Management Frameworks offiziell freigegeben, das ja als zentrale Komponente die Windows PowerShell 5.0 enthält. Dadurch sind jetzt auch die aktuellen in Windows 10 vorhandenen Funktionen wie das PackageManagement, PowerShellGet, PowerShell Klassen und anderes mehr für ältere Betriebssystem-Versionen verfügbar und unterstützt. Die Ankündigung ist im Windows PowerShell Blog unter http://blogs.msdn.com/b/powershell/archive/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available.aspx nachzulesen, die Downloads sind unter https://www.microsoft.com/en-us/download/details.aspx?id=50395 erreichbar.

Allerdings führt ein Bug im Installer dazu, dass nach der Installation das Laden des Moduls unserer PowerShell Extensions for HEAT Client Management (PSX) fehlschlägt. Aber nicht nur die PSX sind betroffen, sondern alle Module, die nicht in den Standard-Modulverzeichnissen installiert sind.

Der Versuch das PSX Modul oder jedes andere PowerShell Modul, das nicht in den Standardpfaden gefunden wird, zu laden führt zu der folgenden Fehlermeldung: