Arbeitet man viel mit deaktivierten Policys / Policyinstanzen, hat man sich sicherlich schon des Öfteren gewünscht, dass diese ab und zu etwas deutlicher erkennbar wären. Generell werden Policyinstanzen von DSM in hellgrau dargestellt, was je nach Kontrast des Monitors oder mit zunehmender Feierabendmüdigkeit immer schwerer zu erkennen ist.

Da es seit DSM 2016.2 die Möglichkeit gibt deaktivierte Einträge bereits Out-Of-The-Box anzupassen, diese Funktion aber bei vielen Kunden nicht wirklich bekannt ist, möchte ich in diesem Artikel kurz zeigen, wie man die Anzeige hierfür anpassen kann.

Seit DSM-Version 2015.1 ist es ja möglich, das System ohne clientseitige Konten zu betreiben – der Service-Installer kann im Kontext des LocalSystem-Accounts ausgeführt werden und auch der Zugriff auf das Depot für das Staging der Pakete kann in Active Directory Umgebungen mit dem Computerkonto erfolgen. Somit sind in der Konfigurationsdatenbank nur noch die Credentials von Management Point Konten gespeichert, die aber durch die asynchrone Verschlüsselung wirksam geschützt sind.

Trotzdem ist es immer wieder erforderlich, Setup-Programme oder andere Aktionen im Rahmen von DSM-Scripts in einem definierten Benutzerkontext auszuführen, um Zugriff auf Netzwerkressourcen wie Back-End Systeme, Datenbanken, Fileserver oder ähnliches zu haben. Hierfür wird in aller Regel innerhalb der eScripts der Befehl RunAsEx verwendet und dort der Benutzername und das zugehörige Kennwort angegeben.

Dieser Ansatz bringt jedoch unter mehreren Gesichtspunkten Nachteile mit sich...

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.

Es besteht meiner Erfahrung nach große Unsicherheit, wie man Windows bei Verwendung von Advanced Patch Management (APM) oder PatchLink (PL) konfigurieren soll, damit es nicht auf die Idee kommt, auf den Microsoft Servern selbständig nach Updates zu suchen, diese herunterzuladen und – insbesondere unter Windows 10 – zu einem völlig willkürlichen Zeitpunkt zu installieren. 

Die empfohlenen Einstellungen waren auch schon das ein oder andere mal Thema im DSM Forum, beispielsweise in diesem oder diesem Thread.

Während man bei Windows 7 und Windows 8.1 noch einfach über Gruppenrichtlinien den ungewollten Zugriff auf die Microsoft Upate Server unterbinden kann, stellt sich die Sache bei Windows 10 – auch für Clients, die für die Verwendung eines internen WSUS-Servers konfiguriert sind – etwas anders dar...

Immer noch erfreut sich Windows 7 im Business-Bereich großer Beliebtheit. Um das in die Tage gekommene Client-Betriebssystem auf einen aktuellen Stand zu bringen, müssen jedoch zahlreiche Patches nachinstalliert werden, da das letzte offiziell von Microsoft verfügbare Image Windows 7 mit integriertem Service Pack 1 mittlerweile sechs Jahre "auf dem Buckel" hat. Zwar hat Microsoft im letzten Oktober die Patch-Strategie an den Windows 10 Mechanismus angepasst, sodass es seitdem nur noch kumulative monatliche Updates gibt, trotzdem ist die Zahl der nachzuinstallierenden Patch-Pakete auf einer "nackten" Windows 7 SP1 Installation exorbitant.

Wird also ein Original Microsoft-Image für die Grundinstallation von Rechnern verwendet, so führt dies zu extrem langen Installations-Zeiten. Daher sind mittlerweile Maßnahmen, ein benutzerdefiniertes Windows 7 Referenz-Image zu erstellen und für die Betriebssystem-Installation zu verwenden, nicht mehr – wie früher – optional, sondern beinahe "Pflicht geworden".

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.