Übersetzung vorschlagen

Andere Vorschläge:

Keine anderen Vorschläge

TechNet Magazine > Home > Alle Ausgaben > 2010 > TechNet Magazine August 2010 > Windows-PoweShell: Reagieren auf WMI-Ereignisse...

Inhalt anzeigen: Englisch mit deutscher Übersetzung

Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.

Windows PowerShell: Responding to WMI Events

Tracking, notifying and responding to system-level events is something Windows does well, but you can also do that with Windows PowerShell.

Don Jones

One of the neat things about the Windows OS is its support for events. Whenever something occurs in the OS, it generates an event. Bits of code, such as applications, can register to be notified of specific events so they can respond with some action. For example, when you click on a button in a dialog box, the application receives notification of a “click” event, and knows to do whatever it’s supposed to do when someone clicks that button.

Windows Management Instrumentation (WMI) can also produce events, and you can register Windows PowerShell v2 to receive those events. You can then use the shell to execute whatever commands you prefer in response to those events. WMI will typically raise one of a fairly small number of events, but it can do so for a huge range of different WMI classes.

There are three key points to using WMI events:

knowing which event you want
knowing the class for which you want the event
using the Register-WMIEvent cmdlet to register for event notifications

Simple Events

Some WMI classes generate events. For example, the Win32_ProcessStartTrace class generates events whenever a process starts. It will also do so in other situations. When the event for a new process is raised, it has a source identifier of “Process Started.” To register for events, you would run this command:

Register-WmiEvent –class "Win32_ProcessStartTrace" 
–sourceIdentifier "Process Started"

Of course, simply knowing that a process started isn’t useful. You will probably want to define some action to log the process, send an e-mail or even kill the process.

Run Get-EventSubscriber to see the event notification subscription you just created. To remove all event registrations, run Get-EventSubscriber | Unregister-Event. You can also use Unregister-Event to remove a specific subscription by ID number.

Better Events

Some of the system-level events WMI can produce are even more useful. For example, an event called __instancecreationevent is fired whenever a new instance of a WMI class is created; __instancedeletionevent fires whenever an instance is deleted. This might not seem useful, but think about it, almost every element of the OS and computer hardware is represented by some instance of a WMI class. For example, Win32_LogicalDisk will get a new instance when you attach a removable storage device. Win32_Process will lose an instance when a process quits.

Want to display a message when users insert a new USB drive?

Register-wmievent –query "select * from __instancecreationevent within 5 where targetinstance isa 'win32_logicaldisk'" –action { Write "You had better not put any proprietary information on that!" }

That query can be pretty difficult to break down, so here’s what it’s doing:

SELECT * FROM __instancecreationevent (that’s two underscores in the event name, by the way) simply specifies that all properties from that event should be retrieved.
WITHIN 5 indicates that we only want to check for events every five seconds. Don’t set this number too low or you’ll end up with a lot of computing power spent on constantly checking for updates.
WHERE TARGET INSTANCE ISA 'Win32_LogicalDisk' tells WMI that we only want events that created a new instance of the Win32_LogicalDisk class.

Finally, the –action parameter is a script block—enclosed in {braces}—that contains the action we want to occur when the event is raised.

Using the –computerName parameter to register for events that occur on a remote computer is a neat trick. You need to be a local Administrator on the remote computer, and the action will happen on your computer, not on the remote one.

As an aside, don’t be tempted to register for instance creation events on the CIM_DataFile class that represents files on disk. WMI isn’t very efficient at monitoring new file creation. It will likely miss events, and can impose some pretty heavy overhead in trying to catch everything.

Caveats and Tricks

Of course, responses to your events will only continue for as long as the shell is running. When you close the shell or it closes on its own for some reason, the event registration is gone.

That makes WMI events somewhat less useful for running on users’ machines, because you’re unlikely to have the shell up and running on everyone’s computer at all times. This can be a very useful trick, though, for monitoring processes or other elements on servers where you have more control

Within the –action scriptblock, you have access to an automatic variable called $args, which contains any arguments that are passed from the event. Use Write $args in your –action scriptblock to see what arguments exist for a given WMI event.

Read a bit more about WMI events, and related shell commands, on the TechNet WMI Event Monitoring page.

Don Jones is a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at ConcentratedTech.com. He’s also an author for Nexus.Realtimepublishers.com, which makes many of his books available as free electronic editions through his web site.

Windows PowerShell: Reagieren auf WMI-Ereignisse

Das Nachverfolgen, Überwachen und Reagieren auf Systemereignisse gelingt mit Windows gut, aber probieren Sie es einmal mit Windows PowerShell.

Don Jones

Eines der Dinge praktische Informationen über das Windows-Betriebssystem ist die Unterstützung für Ereignisse. Wenn Sie etwas in das Betriebssystem auftritt, wird ein Ereignis generiert. Bit-Code, z. B. Anwendungen, können registrieren, um bestimmte Ereignisse benachrichtigt werden, so dass Sie mit einer Aktion reagieren können. Z. B. Wenn Sie auf eine Schaltfläche in einem Dialogfeld klicken, die Anwendung empfängt die Benachrichtigung von “ Klickereignis ” und weiß um zu tun, was es um zu tun, wenn ein Benutzer auf diese Schaltfläche klickt vorgesehen hat.

Windows-Verwaltungsinstrumentation (WMI) können Ereignisse auch erstellen, und Sie können Windows PowerShell v2 empfangen Ereignisse registrieren. Die Shell können Sie beliebige Befehle, die Sie als Reaktion auf diese Ereignisse ausgeführt. WMI wird i. d. r. eine eine relativ kleine Anzahl von Ereignissen ausgelöst, aber Sie können dies tun, für einen großen Bereich von anderen WMI-Klassen.

Es gibt drei wichtige Punkte mithilfe der WMI-Ereignisse:

Sie möchten wissen, welches Ereignis
kennen die Klasse das Ereignis soll
verwenden das Cmdlet Register WMIEvent Ereignisbenachrichtigungen zu registrieren

Einfache Ereignisse

Einige WMI-Klassen werden Ereignisse generieren. Die Klasse Win32_ProcessStartTrace generiert z. B. Ereignisse, wenn ein Prozess gestartet wird. Es wird auch in anderen Situationen geschehen. Wenn das Ereignis für einen neuen Prozess ausgelöst wird, hat es eine Quell-ID “ Process Started ”. Um Ereignisse zu registrieren, würden Sie diesen Befehl ausführen:

Register-WmiEvent –class "Win32_ProcessStartTrace" 
–sourceIdentifier "Process Started"

Natürlich lediglich wissen, dass ein Prozess gestartet nicht hilfreich ist. Wahrscheinlich werden Sie definieren eine Aktion zum Protokollieren des Prozess, eine e-Mail-Nachricht senden oder auch den Prozess zu beenden.

Führen Sie die Get-EventSubscriber das Ereignisabonnement-Benachrichtigung sehen, das Sie gerade erstellt haben. Führen Sie zum Entfernen aller Ereignisregistrierungen Get EventSubscriber | ' Registrierung aufheben '-Ereignis. Registrierung-Ereignis können auch um ein bestimmtes Abonnement durch die ID-Nummer zu entfernen.

Verbesserte Ereignisse

Einige der WMI erzeugen kann Ereignisse auf Systemebene sind sogar noch nützlicher. Ein Ereignis mit der Bezeichnung __instancecreationevent wird z. B. ausgelöst, sobald eine neue Instanz einer WMI-Klasse erstellt wird;__InstanceDeletionEvent wird ausgelöst, wenn eine Instanz gelöscht wird. Dies mag nicht nützlich, aber denke über es fast jedes Element der Hardware Betriebssystem- und Computer durch bestimmte Instanz einer WMI-Klasse dargestellt wird. Beispielsweise erhalten Win32_LogicalDisk eine neue Instanz, wenn Sie einen austauschbaren Datenträger anhängen. Win32_Process verlieren eine Instanz, wenn ein Prozess beendet wird.

Um eine Meldung anzuzeigen, wenn Benutzer ein neues USB-Laufwerk einfügen möchten?

Register-wmievent –query "select * from __instancecreationevent within 5 where targetinstance isa 'win32_logicaldisk'" –action { Write "You had better not put any proprietary information on that!" }

Diese Abfrage kann aufzuschlüsseln, ziemlich schwierig sein, so sieht, wie es funktioniert:

SELECT * FROM __instancecreationevent (die zwei unterstrichen im Ereignis Name die Art und Weise ist) einfach gibt an, dass alle Eigenschaften, die von diesem Ereignis abgerufen werden soll.
WITHIN 5 gibt an, dass wir nur Ereignisse alle fünf Sekunden überprüfen möchten. Keine dieser Wert zu niedrig festgelegt oder mit sehr viel Rechenleistung für regelmäßig nach Updates gesucht aufgewendete landen werde.
WHERE TARGET INSTANCE ISA "Win32_LogicalDisk"teilt WMI, dass wir nur Ereignisse sollen, die eine neue Instanz der Win32_LogicalDisk-Klasse erstellt.

Schließlich ist der Parameter –action einen Skriptblock – {geschweiften Klammern} eingeschlossen – enthält die Aktion, die auftreten, wenn das Ereignis ausgelöst werden soll.

Mit dem –computerName-Parameter zum Registrieren für Ereignisse, die auf einem Remotecomputer auftreten, ist eine praktische Stich. Müssen Sie ein lokaler Administrator auf dem Remotecomputer sein, und die Aktion auf dem Computer nicht auf das remote geschieht.

Übrigens nicht sein, z. B. Erstellungsereignisse für die CIM_DataFile-Klasse zu registrieren, die Dateien auf der Festplatte dazu verleitet. WMI ist nicht sehr effizient zur Dateierstellung einer neuen zu überwachen. Es wird wahrscheinlich verpassen Sie Ereignisse und kann sehr hohen Verwaltungsaufwand in versuchen, alles catch aufzuerlegen.

Vorsichtsmaßnahmen und Tricks

Antworten auf Ihre Ereignisse werden natürlich nur für fortgesetzt werden, solange die Shell ausgeführt wird. Wenn Sie die Shell schließen oder eigenständig aus irgendeinem Grund schließt, wird die Ereignisregistrierung nicht mehr angezeigt.

Stellt WMI-Ereignisse für die Ausführung auf Computern Benutzer weniger nützlich, weil Sie wahrscheinlich auf die Shell nach oben und auf alle Benutzer des Computers ausgeführt überhaupt sind ständig. Dies kann ein sehr nützliches Trick, jedoch werden für die Überwachung von Prozessen oder anderen Elementen auf dem Server, auf dem Sie mehr Kontrolle haben

Innerhalb des Skriptblocks –action haben Sie Zugriff auf eine automatische Variablen namens $-Argumente, die Argumente enthält, die vom Ereignis übergeben werden. Verwenden Sie schreiben $ Args in Ihrem –action Skriptblock, welche Argumente für einen bestimmten WMI-vorhanden sind.

Lesen Sie etwas mehr über WMI-Ereignisse und beziehen Sie Shell-Befehle auf der Seite TechNet WMI Event Monitoring .

Don Jones ist ein Gründer von Concentrated Technology und Antworten Fragen zu Windows PowerShell und andere Technologien am ConcentratedTech.com. Außerdem ist er Autor für Nexus.Realtimepublishers.com, wodurch viele seinen Büchern als kostenloser elektronischer Editionen über seine Website verfügbar sind.