Condividi tramite


Monitoraggio e risposta agli eventi con consumatori standard

È 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 consumatori standard WMI.

Consumatore standard Descrizione
ActiveScriptEventConsumer Esegue uno script quando riceve una notifica di evento. Per altre informazioni, vedere Eseguire 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 ulteriori informazioni, vedere Registrazione nel registro eventi NT basata su un evento.
SMTPEventConsumer Invia un messaggio di posta elettronica utilizzando SMTP ogni volta che viene recapitato un evento. Per altre informazioni, vedere Invio di messaggi di posta elettronica 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 consumatore standard

  1. Specificare il namespace in un file MOF usando il comando del preprocessore MOF #pragma namespace. In uno script o in un'applicazione, si deve 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 sono associate alle modifiche alle istanze della classe nello spazio dei nomi root\cimv2. Tuttavia, gli eventi del Registro di sistema come RegistryKeyChangeEvent vengono generati nello spazio dei nomi root\default dal provider del Registro di sistema .

    Un consumer può includere classi di evento situate in altri namespace, specificando il namespace nella proprietà EventNamespace nella query __EventFilter per gli eventi. Gli eventi intrinseci delle classi , come __InstanceOperationEvent, sono disponibili in ogni spazio dei nomi.

  2. Creare e popolare un'istanza di una classe consumatore standard.

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

    InsertionStringTemplates contiene il testo da inserire in un evento specificato da EventType. È possibile usare stringhe letterali o fare riferimento direttamente a una proprietà. Per ulteriori informazioni, vedere Usare i Modelli di Stringa Standard e Istruzione SELECT per le Query di Evento.

    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 di EventID pari a 8, indicato come .

    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"};
    };
    
  3. 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 quando il computer viene avviato.

    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";                       
    };
    
  4. Identificare un evento da monitorare e creare una query di evento.

    È possibile verificare se è presente un evento intrinseco o estrinsico che usa. Ad esempio, usare 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 Guida alla creazione 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
    
  5. Creare un'istanza di __FilterToConsumerBinding per associare il filtro e le classi consumatori. Questa istanza determina che quando si verifica un evento che corrisponde al filtro specificato, deve verificarsi l'azione specificata dal consumer. __EventFilter, __EventConsumere __FilterToConsumerBinding devono avere lo stesso identificatore di sicurezza (SID) nella proprietà CreatorSID. Per ulteriori informazioni, vedere Collegamento di un filtro eventi con un consumatore logico.

    Nell'esempio seguente viene illustrato come identificare un'istanza in base al percorso dell'oggetto o 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 alias.

    instance of __FilterToConsumerBinding
    {
        Filter = $FILTER;
        Consumer = $CONSUMER;
    
    };
    

    È possibile associare un filtro a diversi consumer, che indica che quando si verificano 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 non funziona, gli altri consumer che richiedono l'evento ricevono una notifica.
    • Se un evento viene eliminato, WMI genera __EventDroppedEvent .
    • Se ci si iscrive a questo evento, esso restituisce l'evento eliminato e un riferimento al __EventConsumer che 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 ulteriori informazioni, vedere Binding di un filtro eventi con un consumatore logico.

Esempio

Nell'esempio seguente viene illustrato il MOF per un'istanza di NTEventLogEventConsumer. Dopo aver compilato questo 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;
};

Ricevere eventi in modo sicuro