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

In letzter Zeit gewinnt die Versorgung und Verwaltung von Systemen in einer demilitarisierten Zone (DMZ) oder sogar über vollständig öffentliche Netze über DSM immer mehr an Bedeutung. Mobile Mitarbeiter, Heimarbeitsplätze und das Arbeiten von den unterschiedlichsten Orten sowie die steigende Anzahl von neuartigen Geräten wie beispielsweise den Windows Surface Tablets erzeugen den Bedarf, diese Systeme unabhängig von ihrem aktuellen Standort erfassen und verwalten zu können.

Die Implementierung einer solchen Infrastruktur ist alles andere als trivial. Während die meisten Systemadministratoren im Umgang mit (SMB-)Shares, NTFS-Berechtigungen und Active Directory Benutzerkonten erfahren und sicher sind, sind die für eine DMZ-unterstützende Konfiguration erforderlichen Technologien oftmals noch recht unbekannt beziehungsweise besteht wenig Erfahrung mit deren Umgang.

Es sind Themen wie die Internet-Protokolle http und https, Begriffe wie SSL und TLS, die Microsoft Internet Information Services (IIS), Zertifikate und Public Key Infrastrukturen (PKIs) oder auch Netzwerk-Infrastruktur Aspekte wie Firewalls oder TCP/IP-Ports relevant, um die Admins bisher oft einen großen Bogen gemacht haben oder für deren Beherrschung es einfach keine Notwendigkeit gab.

Bei einem Import eines PnP-Paketes in eine DSM 2014.1 Umgebung kann es zu einem Import-Fehler kommen.

Sie haben ein PnP-Paket welches aus einer älteren DSM / enteo V6 Umgebung exportiert wurde. In diesem PnP-Paket sind in der PnP-ID-Liste mehr als ein Gerät aufgelistet.

Kürzlich kam einer unserer Kunden auf mich zu mit dem Anliegen, dass er die bestehende ODS-Struktur seiner DSM-Produktionsumgebung auf eine Testumgebung übertragen möchte. Grundsätzlich ist es ja eine gute Idee, Test- und Produktionsumgebung möglichst identisch oder zumindest nahezu identisch zu halten und somit besteht die Notwendigkeit, diese Anforderung mit möglichst geringem Aufwand umzusetzen. Ein manuelle "Synchronisation" schied daher von vorneherein aus.

Die Vorstellung des Kunden war, sowohl die Domain- und OU-Struktur, sowie die statischen und dynamischen Gruppen zu übertragen. Als Kunde der PowerShell Extensions lag natürlich nahe, diese Aufgabe mittels eines PSX-basierten Scripts zu erledigen. Insbesondere bei der Übertragung der hierarchisch organisierten dynamischen Gruppen tat sich der Kunde jedoch schwer, und kam mit der Bitte um den ein oder anderen Tipp auf mich zu.

Da es sich um eine interessante und durchaus auch für andere Kunden relevante Aufgabenstellung handelt, möchte ich in diesem Artikel einen möglichen Ansatz bzw. eine einfach gehaltene Lösung zur Umsetzung dieser Anforderung vorstellen.

Vor kurzem haben wir die neue Version 3.0 der PowerShell Extensions für FrontRange DSM (PSX) freigegeben. Neben vielen internen Verbesserungen, wurden auch wieder eine ganze Reihe neuer Cmdlets aufgenommen, um die Verwaltung von DSM noch besser über die PSX steuern zu können.

Neben Cmdlets zur Erstellung, zum Abrufen und zum Löschen von Citrix-Objekten im DSM Organisationsverzeichnis, wurden insbesondere die mit DSM 2014.1 eingeführten neuen Möglichkeiten des Advanced Patch Managements (APM) adressiert und entsprechende Cmdlets implementiert.

Mit DSM 2014 wurden erstmals die Begriffe "Patch Kategorien" und "Patch Rollout Rules" eingeführt. Um diese neuen Konzepte zu verstehen, ist ersteinmal einiges herumprobieren notwendig. Der folgende Designvorschlag soll den Einstieg in dieses mittlerweile komplexe Thema erleichtern. Es wird folgend ausschliesslich auf die Konfiguration dieser neuen Features eingegangen. Für die vollständige Konfiguration von APM im jeweiligen DSM Umfeld müssen noch diverse weitere Dinge (Installationsreihenfolge von Patchen in Bezug auf Softwarepakete, Definition der Patchziele, Rolloutzyklen, Zusammenarbeit mit WSUS, etc.) betrachtet werden.

Ein Kunde von uns hatte die Anforderung, dass die Patches von Microsoft im späteren Workflow anders behandelt werden sollten als die Patches von Drittanbietern. Vereinfacht dargestellt sollten erstere auf eine Gruppe und die der Drittanbieter auf eine andere Computergruppe zugewiesen werden.

Der Patch Management Dienst ist so konfiguriert, dass alle Patches einer statischen Computergruppe namens "DownloadOnly" zugewiesen werden, die allerdings keine Computer enthält. Von da aus werden sie mittels Targetlistenerweiterung weiter an die Gruppen "Microsoft" bzw. "ThirdParty" verteilt.

Die Pilotgruppen sind hier ausser acht gelassen, es geht um die grundsätzliche Logik.