computerwoche.de

Software-Infrastruktur

Aufgaben einfach automatisieren

PowerShell 4.0 im Überblick

01.05.2014
Von  und
Frank-Michael Schlede arbeitet seit den achtziger Jahren in der IT und ist seit 1990 als Trainer und Fachjournalist tätig. Nach unterschiedlichen Tätigkeiten als Redakteur und Chefredakteur in verschiedenen Verlagen arbeitet er seit Ende 2009 als freier IT-Journalist für verschiedene Online- und Print-Publikationen. Er lebt und arbeitet in Pfaffenhofen an der Ilm.
Alle Posts des Autors Email:
Thomas Bär, der seit Ende der neunziger Jahre in der IT tätig ist, bringt weit reichende Erfahrungen bei der Einführung und Umsetzung von IT-Prozessen im Gesundheitswesen mit. Dieses in der Praxis gewonnene Wissen hat er seit Anfang 2000 in zahlreichen Publikationen als Fachjournalist in einer großen Zahl von Artikeln umgesetzt. Er lebt und arbeitet in Günzburg.
Alle Posts des Autors Email:

Windows Defender voll im Griff mit PowerShell 4.0

Für die in Windows 8.1 enthaltende Sicherheitssoftware Windows Defender stehen mit dem aktuellen PowerShell-Release ebenfalls neue Cmdlets durch das Windows Defender Modul zur Verfügung. Die PowerShell 4.0 stellt diese Cmdlets damit natürlich auch auf dem Windows Server 2012 R2 zur Verfügung, allerdings sollten Administratoren dabei bedenken, dass der Windows Defender nur im Core-Modus des Servers automatisch mit installiert wird und entsprechend zur Verfügung steht - auf einem Windows Server 2012 oder 2012 R2 mit der vollen Windows-Oberfläche wird er nicht installiert.

Ein neues Modul in der PowerShell 4.0: Der Windows Defender kann komplett mit Hilfe der unterschiedlichen Kommandos lokal und auch auf Remote-Systemen gesteuert werden.
Ein neues Modul in der PowerShell 4.0: Der Windows Defender kann komplett mit Hilfe der unterschiedlichen Kommandos lokal und auch auf Remote-Systemen gesteuert werden.

Ist der Windows Defender nicht auf dem entsprechenden System installiert oder nicht aktiv, weil eine andere AV-Lösung diese Aufgaben übernimmt, so bricht die PowerShell leider mit der für den normalen Anwender wenig aussagekräftigen Meldung "Die extrinsische Methode konnte nicht ausgeführt werden" ab.

Wer sich zunächst einmal einen Überblick über die vorhandenen Cmdlets für die Arbeit mit dem Windows Defender verschaffen möchte, kann das leicht mit dem folgenden Kommando tun:

Get-Command -module Defender

Elf unterschiedliche Befehle werden dann angezeigt, wobei der einfachste Aufruf nach dem aktuellen Status der Maschine folgendermaßen aussieht:

Get-MpComputerStatus

Ein Aufruf, die eine ziemlich umfangreiche Liste von Informationen auf dem Bildschirm präsentiert. Übersichtlicher wird es da, wenn der Nutzer das Ergebnis entsprechend filtert. Zum Beispiel nach den Versionen der Signaturen und nach dem Datum der letzten Updates:

Get-MpComputerStatus | select *version, *updated

Stellt der Anwender dabei fest, dass die Signaturen nicht mehr auf dem aktuellen Stand sind, so ist auch deren Update direkt mittels eines PowerShell-Kommandos möglich:

Update-MpSignature

Schließlich kann auch der Scan mittels eines Kommandos aufgerufen werden. Hier kann der Nutzer dann mittels des Parameters "-ScanType" zwischen "FullScan", "CustomScan" oder "QuickScan" unterscheiden:

Start-MpScan -ScanType quick

Mit Hilfe dieser Kommandos ist beispielsweise eine Automatisierung der Windows Defender auf den unterschiedlichen Client-Maschinen recht schnell erstellt. Da alle Kommandos aus dem Defender-Modul auch den Parameter "-CimSession <CimSession[]" verwenden können, ist es für Administratoren beispielsweise möglich, eine CimSession anzulegen, die eine Verbindung zu einer ganzen Liste von Remote-Systeme aufbaut und ihm so die Statusinformation zu den dort installierten Defender-Versionen liefert.

CIM steht dabei für Common Information Modell. Bei einer solchen Session handelt es sich um Client-seitiges Objekt, das eine Verbindung zu einem lokalen oder einem Remote-System aufbaut. In einer solchen Session werden dann Informationen wie Computername oder auch das verwendete Verbindungsprotokoll hinterlegt. Hat ein Administrator ein solches CIM-Objekt mit allen Informationen für den Verbindungsaufbau angelegt, so wird diese Verbindung aber erst dann aufgebaut, wenn ein Cmdlet diese Session verwendet. Sie wird auch automatisch wieder geschlossen, wenn das Cmdlet beendet wird. Diese Verhaltensweise ist im praktischen Einsatz bei der Verwaltung und Betreuung von Remote-Systemen durchaus sinnvoll und unterscheidet die CIM-Sessions von den normalen PowerShell-Sessions. (mje)