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.

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...

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:

Wir alle, die wir mit DSM arbeiten, sind sicherlich regelmäßige "Leser" der DSM Logfiles, von denen es ja jede Menge gibt. Die Schwierigkeit für Anfänger (und durchaus auch manchmal noch für Fortgeschrittene) beim Ergünden einer Problemursache besteht meistens nicht darin, das Problem im Logfile zu finden, sondern das richtige Logfile zu identifizieren, indem das (vermutete) Fehlverhalten protokolliert ist.

Obwohl ich doch jetzt schon ein paar Jahre DSM-Erfahrung auf dem Buckel habe, hat mir ein Kunde letztens ein paar Fragen zu Logfiles gestellt, die ich so aus dem Stehgreif auch nicht beantworten konnte. Der Support hat mir super-schnell und kompetent auf die Fragen geantwortet, aber da ich denke, dass diese Infos vielleicht auch bei anderen DSM-Anwendern nicht so bekannt sind, dachte ich, ich schreibe einen mehr oder weniger kurzen Blog-Artikel dazu.

Die Fragen des Kunden waren:

• Wann werden eigentlich alte Logfiles gelöscht und werden immer die ältesten gelöscht (hier hatte ich noch Infos aus NetInstall 5.x Zeiten, war mir aber nicht sicher, ob diese Mechanismen heute noch gültig sind)?
• Wieviele Logfiles werden eigentlich vorgehalten und lässt sich die Anzahl konfigurieren?
• Manche Logs werden ja in einem ZIP-Unterverzeichnis archiviert. Kann man das beeinflussen oder konfigurieren?

Wenn man in der DSM-Welt unterwegs ist – und ich nehme stark an, dass praktisch alle Leser dieses Blogs irgendwelche Berührungspunkte mit DSM haben – kommt man hin und wieder bestimmt in die Situation, dass man neue Hardware in die Umgebung einbinden muss. Das heißt, es müssen Treiber für das jeweilige Ziel-Betriebssystem paketiert werden, insbesondere für die Hardware-Komponten, für die Windows keine Treiber an Bord hat. Manchen Kunden möchten sogar, dass alle vom Hardware-Hersteller gelieferten Treiber paketiert und in DSM eingebunden werden.

Es gibt nun mehrere Möglichkeiten, wie man hier vorgehen kann. Und insbesondere seit Windows 8.1 und für die bevorstehenden Windows 10 Rollouts gibt es nun noch die Option, hier mit PowerShell aktiv zu werden, was mich im Endeffekt veranlasst hat, diesen Blog-Artikel zu schreiben...

In einem älteren Blogartikel (Testen von Netzwerk-Ports) habe ich beschrieben, wie man mit dem Tool "Telnet" prüfen kann, ob die Verbindung zu einem entfernten System auf einem bestimmten TCP/IP-Port möglich ist. Dort steht auch zu lesen, dass seit Windows 7 der Telnet-Client nicht mehr im Standard-Installationsumfang von Windows vorhanden ist und manuell hinzugefügt werden muss.

Seit Windows 8.1 beziehungsweise Windows Server 2012 R2 ist ja nun das Windows Management Framework 4.0 und damit die PowerShell 4.0 mit an Bord und damit auch wieder eine ganze Menge neuer Module und Cmdlets. Eins davon ist das neue Cmdlet Test-NetConnection (oder der - für interaktive Anwendung sehr viel kürzere und praktischere - Alias tnc), mit dem jede Menge "klassischer" Befehle aus dem Bereich der Netzwerkkonnektivität wie Ping, Tracert und eben auch Telnet ersetzt werden können.

Im einfachsten Fall wird durch simplen Aufruf von Test-NetConnection ohne weitere Parameter geprüft, ob eine Verbindung zum Internet besteht. Dabei wird versucht den Microsoft-Edge-Server internetbeacon.msedge.net zu kontaktieren.

Wir freuen uns sehr mit diesem Blog-Artikel mitteilen zu können, dass ab sofort die aktuelle Version 3.1 unserer PowerShell Extensions (PSX) verfügbar ist.

Da sich ja sowohl der Firmenname des DSM-Herstellers (von "FrontRange Solutions" zu "HEAT Software") als auch der Produktname selbst (von "DSM" zu "HEAT Client Management") geändert haben, heißt unser Produkt nun offiziell "PowerShell Extensions for HEAT Client Management".

Die zentralen neuen Features sind:

• Herstellung der vollständigen Kompatibilität zu HEAT Client Management 2015.1
• Unterstützung neuer Features von HEAT Client Management 2015.1 (beispielsweise Ausführung einzelner Policy-Instanzen)
• Technische Verbesserungen und Weiterentwicklungen auf Basis von Anregungen durch Partner und Kunden

Die PowerShell Extension 3.1 unterstützen die DSM-Versionen 2013.2 bis einschließlich 2015.1, sind also zu den vergangenen zwei Major-Releases abwärtskompatibel.

Im Folgenden die Neuerungen im Detail...

Wie bei jedem neuen Release, wird auch die DSM 2015.1 Version wieder eine Reihe sehr nützlicher neuer oder geänderter Features beinhalten. Zum Zeitpunkt der Erstellung dieses Artikels ist die Beta-Version aktuell, trotzdem möchte ich Ihnen bereits jetzt ein neues, sehr praktischen Feature vorstellen.

In der Vergangenheit war in DSM das Thema "Wartungszeitfenster" relativ kompliziert gelöst. Es gab verschiedene Zeitpläne, die für unterschiedliche System-Typen galten – namentlich Pläne für Arbeitsstationen, für Server, für Terminal-Server und für Citrix-Server. Diese Wartungspläne wurden über Konfigurations-Policies zugewiesen. Je nachdem von welchem Typ ein System war, wurde eine entsprechende Policy-Instanz erzeugt (sodass der Wartungsplan "zog") oder auch nicht. Insbesondere bei der Installation von Citrix-Servern wurden bis zu drei verschiedene Konfigurations-Policies benötigt, um eine vollständige Installation umzusetzen.

Außerdem war es durchaus möglich, dass über verschiedene Container verschiedene Wartungspläne zugewiesen wurden, sodass der effektive Wartungsplan schwierig zu bestimmen war oder es zu Problemen bei der Ausführung von Paketen kam.

Schließlich war eine sehr häufig geäußerte Anforderung von Kunden, dass es möglich sein sollte, Patches in einem anderen Wartungsfenster auszuführen als "normale" Software-Pakete – eine Anforderung, die bis dato nicht oder nur sehr eingeschränkt umsetzbar war.

Mit DSM 2015.1 werden hier Neuerungen eingeführt, die das Handling und die Flexibilität von Wartungsplänen und Wartungszeitfenstern deutlich erhöhen...