NWC Services Blog
Blogs von Consultants der NWC Services GmbH
In einem früheren Blog-Artikel habe ich beschrieben, dass die kommende Packaging PowerBench 2.0 ein Feature beinhalten wird, um Pakete in das von Microsoft Intune verwendete Format zu konvertieren beziehungsweise zu exportieren. In diesem Artikel möchte ich nun beschreiben, wie Sie ein exportiertes Paket in Ihrem Intune-Mandanten registrieren und damit zur Verteilung an Ihre über Intune verwalteten Geräte bereitstellen können.
Das Interesse an unserem im Sommer in Version 1.0 releasten Produkt „Packaging PowerBench" ist erfreulich hoch – die vielen Demo-Sessions, Eval-Anfragen und auch mehrere Neukunden in der letzten Zeit sind ein deutliches Zeichen dafür. Wir freuen uns sehr, dass unser Tool offensichtlich so gut ankommt und einen „Nerv" getroffen zu haben scheint, aber natürlich ruhen wir uns nicht auf unseren Lorbeeren aus und entwickeln sehr aktiv an einer neuen Version, die für das erste Quartal kommenden Jahres geplant ist.
Eines der neuen Features der Version 2.0 möchte ich in diesem Blog-Artikel kurz vorstellen.
Die meisten Leser dieses Blogs werden wahrscheinlich technisch orientierte User sein, die als Consultants, Administratoren, System Engineers oder Entwickler häufig „auf der Kommandozeile“ unterwegs sind. Die Verwendung der Eingabeaufforderung (cmd.exe) oder von Windows PowerShell gehört zu unserem Alltag und jeder kennt die Schwächen der Tools, die seit Jahrzehnten quasi identisch funktionieren und Verbesserungen und Weiterentwicklungen in maximal homöopathischen Dosen erfahren haben.
Mit der Neuentwicklung „Windows Terminal“, die auf GitHub als Open Source Software entwickelt wird, hat Microsoft einen neuen Anlauf gewagt, für die Windows-Welt ein zeitgemäßes Kommandozeilen-Interface zur Verfügung zu stellen.
Auch in der kommenden Version 2017 wird es wieder etliche sinnvolle Neuerungen geben, die DSM noch flexibler und damit universeller einsetzbar machen. Dabei mausert sich das System mehr und mehr vom reinen Softwareverteilsystem zur zentralen Konsole, mit der typische administrative Aufgabenstellungen des täglichen Geschäfts erledigt werden können.
Eines dieser neuen Features möchte ich in diesem Artikel vorstellen, nämlich die Möglichkeit, benutzerdefinierte Aktionen lokal auf DSM-gemanageten Clients ausführen zu lassen. Der Phantasie sind bei den Anwendungsfällen kaum Grenzen gesetzt, beispielsweise lassen sich damit dezentral die Logfiles einsammeln oder es findet es eine Bereinigung des Festplattenspeichers statt oder ein Client wird bei Verdacht auf Virenbefall nach Schadsoftware gescannt oder oder oder...
Die Umsetzung des Anti-Malware Scans mit Windows Defender möchte ich in diesem Artikel beispielhaft beschreiben.
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.
| Update (23.12.2015): aufgrund des in diesem Artikel beschriebenen Problems, wurde der Download des Windows Management Frameworks 5.0 zurückgezogen. Details finden sich in folgendem Blogartikel des PowerShell-Teams: http://blogs.msdn.com/b/powershell/archive/2015/12/23/windows-management-framework-wmf-5-0-currently-removed-from-download-center.aspx. |
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:
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...