Monitoraggio e risposta agli eventi con consumer standard

Articolo
06/13/2023

È possibile usare le classi consumer standard installate per eseguire azioni basate su eventi in un sistema operativo. I consumer standard sono classi semplici già registrate e definiscono classi consumer permanenti. Ogni consumer standard esegue un'azione specifica dopo che riceve una notifica degli eventi. Ad esempio, è possibile definire un'istanza di ActiveScriptEventConsumer per eseguire uno script quando lo spazio libero su disco in un computer è diverso da una dimensione specificata.

WMI compila i consumer standard in spazi dei nomi predefiniti che dipendono dal sistema operativo, ad esempio:

In Windows Server 2003 tutti i consumer standard vengono compilati per impostazione predefinita nello spazio dei nomi "Root\Subscription".

Nota

Per gli spazi dei nomi e i sistemi operativi predefiniti specifici per ogni classe WMI, vedere le sezioni Osservazioni e requisiti di ogni argomento di classe.

La tabella seguente elenca e descrive i consumer standard WMI.

Consumer standard	Descrizione
ActiveScriptEventConsumer	Esegue uno script quando riceve una notifica degli eventi. Per altre informazioni, vedere Esecuzione di uno script basato su un evento.
LogFileEventConsumer	Scrive stringhe personalizzate in un file di log di testo quando riceve una notifica degli eventi. Per altre informazioni, vedere Scrittura in un file di log basato su un evento.
NTEventLogEventConsumer	Registra un messaggio specifico nel registro eventi dell'applicazione. Per altre informazioni, vedere Registrazione nel registro eventi NT in base a un evento.
SMTPEventConsumer	Invia un messaggio di posta elettronica utilizzando SMTP ogni volta che viene recapitato un evento. Per altre informazioni, vedere Invio di Email in base a un evento.
CommandLineEventConsumer	Avvia un processo quando un evento viene recapitato a un sistema locale. Il file eseguibile deve trovarsi in un percorso sicuro o protetto con un elenco di controllo di accesso sicuro (ACL) per impedire a un utente non autorizzato di sostituire il file eseguibile con un file eseguibile diverso. Per altre informazioni, vedere Esecuzione di un programma dalla riga di comando in base a un evento.

La procedura seguente descrive come monitorare e rispondere agli eventi usando un consumer standard. Si noti che la procedura è la stessa per un file MOF (Managed Object Format), uno script o un'applicazione.

Per monitorare e rispondere agli eventi con un consumer standard

Specificare lo spazio dei nomi in un file MOF usando il comando del preprocessore MOF #pragma spazio dei nomi. In uno script o in un'applicazione specificare lo spazio dei nomi nel codice che si connette a WMI.

Nell'esempio di codice MOF seguente viene illustrato come specificare lo spazio dei nomi root\subscription.
```
#pragma namespace ("\\\\.\\root\\subscription")
```
La maggior parte degli eventi intrinseci è associata alle modifiche alle istanze di classe nello spazio dei nomi root\cimv2. Tuttavia, gli eventi del Registro di sistema, ad esempio RegistryKeyChangeEvent , vengono attivati nello spazio dei nomi root\default dal provider del Registro di sistema.

Un consumer può includere classi di evento situate in altri spazi dei nomi specificando lo spazio dei nomi nella proprietà EventNamespace nella query __EventFilter per gli eventi. Le classi di eventi intrinseci , ad esempio __InstanceOperationEvent , sono disponibili in ogni spazio dei nomi.
Creare e popolare un'istanza di una classe consumer standard.

Questa istanza può avere un valore univoco nella proprietà Name . È possibile aggiornare un consumer esistente riutilizzando lo stesso nome.

InsertStringTemplates contiene il testo da inserire in un evento specificato in EventType. È possibile usare stringhe letterali o fare riferimento direttamente a una proprietà. Per altre informazioni, vedere Uso di modelli di stringa standard e istruzione SELECT per le query di eventi.

Usare un'origine esistente per il registro eventi che supporta una stringa di inserimento senza testo associato.

Nell'esempio di codice MOF seguente viene illustrato come usare un'origine esistente di WSH e un valore EventID pari a 8.
```
instance of NTEventLogEventConsumer as $Consumer
{
    Name = "RunKeyEventlogConsumer";
    SourceName = "WSH";               
    EventID = 8;
    // Warning                              
    EventType = 2;
    // One string supplies the entire message          
    NumberOfInsertionStrings = 1;             
    // the %Hive% and %KeyPath% are properties of
    // the RegistryKeyChangeEvent instance 
    InsertionStringTemplates = 
        {"The key %Hive%\\%RootPath% has been modified."
        "Check if the change is intentional"};
};
```

Creare un'istanza di __EventFilter e definire una query per gli eventi.

Nell'esempio seguente il filtro monitora la chiave del Registro di sistema in cui vengono registrati i programmi di avvio. Il monitoraggio di questa chiave del Registro di sistema può essere importante perché un programma non autorizzato può registrarsi sotto la chiave, causando l'avvio al momento dell'avvio del computer.

instance of __EventFilter as $Filter
{
Name = "RunKeyFilter";
QueryLanguage = "WQL"; 
Query = "Select * from RegistryTreeChangeEvent"
    " where (Hive = \"HKEY_LOCAL_MACHINE\" and "
    "RootPath = \"Software\\\\Microsoft\\\\Windows"
    "\\\\CurrentVersion\\\\Run\")";

// RegistryTreeChangeEvents only fire in root\default namespace
EventNamespace = "root\\default";                       
};

Identificare un evento da monitorare e creare una query di evento.

È possibile verificare se è presente un evento intrinseco o estrinsico che usa. Ad esempio, utilizzare la classe RegistryTreeChangeEvent del provider del Registro di sistema per monitorare le modifiche apportate al Registro di sistema.

Se una classe non esiste che descrive un evento che è necessario monitorare, è necessario creare un provider di eventi personalizzato e definire nuove classi di evento estrinsiche. Per altre informazioni, vedere Scrittura di un provider di eventi.

In un file MOF è possibile definire un alias per il filtro e il consumer, che offre un modo semplice per descrivere i percorsi dell'istanza.

Nell'esempio seguente viene illustrato come definire un alias per il filtro e il consumer.
```
instance of __EventFilter as $FILTER
instance of LogFileEventConsumer as $CONSUMER
```
Creare un'istanza di __FilterToConsumerBinding per associare il filtro e le classi consumer. Questa istanza determina che quando si verifica un evento che corrisponde al filtro specificato, deve verificarsi l'azione specificata dal consumer. __EventFilter, __EventConsumer e __FilterToConsumerBinding devono avere lo stesso IDENTIFICATORe di sicurezza (SID) nella proprietà CreatorSID . Per altre informazioni, vedere Associazione di un filtro eventi con un consumer logico.

Nell'esempio seguente viene illustrato come identificare un'istanza in base al percorso dell'oggetto oppure usare un alias come espressione abbreviata per il percorso dell'oggetto.
```
instance of __EventFilter as $FILTER
instance of NTEventLogEventConsumer as $CONSUMER
```
Nell'esempio seguente il filtro viene associato al consumer usando gli alias.
```
instance of __FilterToConsumerBinding
{
    Filter = $FILTER;
    Consumer = $CONSUMER;

};
```
È possibile associare un filtro a più consumer, che indica che quando si verificano gli eventi corrispondenti, è necessario eseguire diverse azioni; oppure è possibile associare un consumer a diversi filtri, che indica che l'azione deve essere eseguita quando si verificano eventi che corrispondono a uno dei filtri.

Le azioni seguenti vengono eseguite in base alla condizione dei consumer e degli eventi:
- Se uno dei consumer permanenti ha esito negativo, altri consumer che richiedono la notifica di ricezione dell'evento.
- Se viene eliminato un evento, WMI viene generato __EventDroppedEvent.
- Se si sottoscrive questo evento, restituisce l'evento eliminato e un riferimento al __EventConsumer rappresenta il consumer non riuscito.
- Se un consumer ha esito negativo, WMI genera __ConsumerFailureEvent, che può contenere altre informazioni nelle proprietà ErrorCode, ErrorDescription e ErrorObject .
Per altre informazioni, vedere Associazione di un filtro eventi con un consumer logico.

Esempio

Nell'esempio seguente viene illustrato il file MOF per un'istanza di NTEventLogEventConsumer. Dopo aver compilato il file MOF, qualsiasi tentativo di creare, eliminare o modificare un valore nel percorso del Registro di sistema HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows\CurrentVersion\Run registra una voce nel registro eventi dell'applicazione, sotto l'origine "WSH".

#pragma namespace ("\\\\.\\root\\subscription")
 
instance of __EventFilter as $Filter
{
    Name = "RunKeyFilter";
    QueryLanguage = "WQL";
    Query = "Select * from RegistryTreeChangeEvent"
            " where (Hive = \"HKEY_LOCAL_MACHINE\" and "
            "KeyPath = \"Software\\\\Microsoft\\\\Windows"
            "\\\\CurrentVersion\\\\Run\")";

    // RegistryTreeChangeEvents only fire
    // in root\default namespace
    EventNamespace = "root\\default";   
};
 
instance of NTEventLogEventConsumer as $Consumer
{
    Name = "RunKeyEventlogConsumer";
    SourceName = "WSH";               
    EventID = 8;
    EventType = 2;                            // Warning
    Category = 0;
    NumberOfInsertionStrings = 1;

    // the %Hive% and %KeyPath% are properties
    // of the RegistryKeyChangeEvent instance 
    InsertionStringTemplates = {"The key %Hive%\\%RootPath% "
        "has been modified. Check if the change is intentional"};
};
 

// Bind the filter to the consumer
instance of __FilterToConsumerBinding
{
    Filter = $Filter;
    Consumer = $Consumer;
};

Ricezione sicura di eventi

Monitoraggio e risposta agli eventi con consumer standard

Esempio

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive

Monitoraggio e risposta agli eventi con consumer standard

Esempio

Argomenti correlati

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive