System Center

Granularità assegnazione in Operations Manager 2007

Steve Rachui

In un riepilogo delle:

• Utilizzando una destinazione esistente
• Il problema di rilevamento di attributo
• Creazione di destinazioni con la console di modifica
• Individuazione basata su script

Contenuto

Utilizzo di un obiettivo esistente
Creazione di destinazioni con la console di creazione
Utilizzando una chiave del Registro di sistema
Il valore del Registro di sistema
Individuazione tramite script
Ulteriori considerazioni sulla

Creazione di oggetti personalizzati di monitoraggio (regole, monitor, gruppi e così via) è una parte normale di routine delle molti System Center Operations Manager (OpsMgr) 2007 amministratori. Per ogni oggetto che viene creato, è disponibile una domanda comune deve avere una risposta, quali destinazione da utilizzare.

Scelta della destinazione corretta per un oggetto è critico, ma l'approccio corretto potrebbe non essere sempre crittografato. OpsMgr fornisce una serie di opzioni per l'assegnazione. In questo articolo verrà esaminiamo diversi, con l'obiettivo di aiutare gli amministratori di scegliere il metodo appropriato per ogni scenario, e i termini "classe" e "destinazione verrà utilizzati in modo intercambiabile.

Seguito si presuppone un'applicazione interna denominata widget che devono essere monitorate. Tutte le specifiche di monitoraggio sono state definite e ha iniziato il lavoro per creare gli oggetti di monitoraggio per widget. Si rapidamente rileva, tuttavia, che non siano Nessuna destinazione precisa per widget. In base alle procedure OpsMgr consigliate, regole, monitor e così via deve essere assegnati all'oggetto più specifico possibile in per limitare l'ambito di distribuzione solo i sistemi di interesse. Opzioni quali sono disponibili in OpsMgr che consentono di soddisfa questo obiettivo dell'esercitazione migliore?

Utilizzo di un obiettivo esistente

Per impostazione predefinita, OpsMgr include un lungo elenco di destinazioni e l'elenco cresce come più management pack vengono importati. Quando si sta creando un nuovo management pack oggetto (MPO) e considerando la destinazione, esaminare innanzitutto gli elementi disponibili da verificare se uno dei destinatari preesistenti è sufficiente. Se si sta creando MPOs per estendere il monitoraggio del server System Management Server (SMS), ad esempio, è probabile che le destinazioni esistenti vengono importate insieme con il management pack server SMS predefinito possono essere riutilizzate per le MPO.

Utilizza destinazioni predefinite, tuttavia, non sempre funziona. Se le destinazioni disponibili non sono sufficientemente specifiche per MPO creato, è possibile aggirare la mancanza di una destinazione ottimale o creare un nuovo destinatario.

Un approccio comune (sebbene dispone inconvenienti) consiste nell'associare il nuovo MPO per il client Windows o una classe di server Windows o per qualsiasi altra classe base appropriata (anche in questo caso, essere come specifiche possibili) che include i destinatari necessari. Quando si esegue questo, accertarsi di creare il MPO in uno stato disattivato. È quindi possibile creare un gruppo contenente tutti i sistemi in cui questi MPOs necessario eseguire ed eseguire l'override MPOs disattivato in modo che il MPO è abilitato per solo gli agenti nel gruppo. In questo modo MPO da consegnare e gestirne solo gli agenti sono consentiti per l'override.

Che cosa sono gli svantaggi di questo approccio? L'utilizzo di questo metodo prima di tutto, destinato a più ampia classe di oggetti (Windows computer, ad esempio), in modo che tutti monitorati MPOs destinazione in questa presentazione modo i nell'oggetto di destinazione in Esplora dello stato (vedere la Figura 1 ).

Nella figura 1 Explorer dello stato per computer di destinazione per eseguire l'override fare clic su Immagine per una visualizzazione ingrandita

Si tratta realtà cosmetic, pertanto, potrebbe non essere un problema in un ambiente specifico. Ma assegnazione in questo modo determina lo stato di integrità dell'oggetto padre (ad esempio computer di Windows) per essere influenzato quando il monitor personalizzato è rallentare. Pertanto, se l'applicazione widget presenta un problema, dello stato dell'intero oggetto di destinazione potrebbe risentirne. A seconda di ciò che viene monitorato, questo può o non essere importanti.

Assegnazione MPOs a gruppi non è in genere un approccio appropriato in OpsMgr, pertanto, perché questo lavoro? Si tenga presente che i gruppi in questi esempi vengono utilizzati come esegue l'override e non sono la destinazione effettiva del MPO.

Questo potrebbe sembrare semantica, ma pensare a gruppi in OpsMgr. I gruppi sono oggetti, come qualsiasi altro oggetto. Quando un oggetto viene scelto come destinazione, ciò significa che il MPO in questione sia da distribuito agli agenti che dispongono dell'oggetto di destinazione.

Pertanto, quale agente appartiene l'oggetto gruppo? Corretto, il server di gestione radice (RMS). Assegnazione a un gruppo causerà MPOs da consegnare all'agente che appartiene al gruppo, che significa che verranno distribuiti MPOs solo a RMS. Se un MPO è assegnato in modo appropriato, la fase è già impostata per MPOs da distribuire agli agenti corretti, ma disattivando il MPO è stata interrotta tale processo prima che possa iniziare.

Quando viene introdotto un override, la destinazione esistente è ancora la destinazione, l'override solo modifica lo disattivato stato per abilitato per alcuni agenti per appartenenza al gruppo. Ma gli agenti di cui è abilitato il MPO sono già parte la destinazione originale per il MPO. So che è un po'confusione inizialmente.

Ora Consideriamo uno scenario in cui non descritto finora è appropriato. Che cosa è necessario fare? Vi è solo un'opzione rimanente: creare una nuova destinazione specificamente per il MPOs, è possibile eseguire mediante il servizio monitoraggio modello nel Operations Console o creando una nuova destinazione nella console di modifica.

Prima si considerare quelli, tuttavia, che sta creando l'individuazione di un attributo? Si potrebbe pensare che questa è un'opzione possibile che è stato omesso. Prenda. È possibile creare un'individuazione di attributo che ottiene informazioni dal Registro di sistema o da WMI. Per lavorare, il rilevamento di attributo deve essere assegnato a una classe che contiene il Registro di sistema o voci WMI di interesse. Destinazioni comuni sono client Windows o le classi di Windows Server o anche la classe più generica di Windows del computer.

Si noti che il termine stesso, individuazione di attributo, ovvero implica effettivamente cosa sta succedendo: un nuovo attributo viene individuato e utilizzato per estendere una classe esistente. True, una nuova classe viene creata come risultato, ma è effettivamente la stessa classe precedente con tutti i membri stessi, solo con un nuovo attributo segnalato. Base di ciò, è possibile visualizzare che la creazione di un nuovo rilevamento di attributo non è uguale creazione di una destinazione veramente univoca.

Quanto riguarda un esempio? Si supponga che viene creato un nuovo rilevamento di attributo per trovare la chiave del Registro di sistema per il prodotto widget. Il rilevamento è assegnato a essere distribuiti in computer Windows in modo che includerà tutti gli agenti che potrebbero avere la chiave del Registro di sistema widget.

Dopo aver apportato questa scelta nella procedura guidata, viene visualizzato un avviso che la classe di Windows del computer non può essere estesa (si trova in un sealed management pack dopo tutto, se non sono un sealed management pack, non sarà tale avviso) e una classe di destinazione rinominato è presentata come una scelta è possibile utilizzare per continuare (vedere la Figura 2 ). Ciò accade perché l'obiettivo di individuazione di attributo è per estendere una classe esistente.

Nella figura 2 individuazione attributi doesn’t creare una classe univoca fare clic su Immagine per una visualizzazione ingrandita

Ora esaminiamo modelli di assistenza, che possono essere utilizzati per creare destinatari univoci per i sistemi che possono trovarsi basato su un servizio installato. I modelli di assistenza sono estremamente facili da utilizzare, nella Figura 3 viene illustrato un esempio.

Nella figura 3 un modello di servizio

Tenere, tuttavia, che il modello può comportare la creazione di MPOs aggiuntivi oltre a ciò che è possibile prevede o desidera. Dopo aver utilizzato il modello di servizio, consigliabile verificare e visualizzare gli altri oggetti sono stati creati e di stabilire se devono essere mantenuti (vedere la Figura 4 ).

Nella figura 4 oggetti creati quando un modello è stato utilizzato fare clic su Immagine per una visualizzazione ingrandita

Inoltre, i modelli di assistenza verranno creati un rilevamento e una nuova classe per ogni servizio. Ciò sia esattamente quello desiderato o potrebbe essere troppo granulare. Si supponga ad esempio, che l'applicazione personalizzata dispone di più servizi. In questo caso, una nuova classe e un nuovo monitor del servizio viene creati per ognuno. È probabile più che sia l'approccio di monitoraggio desiderato per una singola classe con ogni monitor del servizio destinazione solo tale classe.

Se non è possibile o non desidera utilizzare un modello di servizio, l'unica opzione rimanente consiste di utilizzare la creazione di console. Mostra una Panoramica documentazione la creazione di console che corretto utilizzo di questa funzionalità richiede una discussione approfondita molto, una portata rientra nello scopo di questo articolo.

Tuttavia, alcuni esempi di semplici utilizzare la creazione di console per creare e compilare una nuova destinazione in OpsMgr sono in ordine. Avrà a disposizione due esempi rivedere l'idea di utilizzo di una voce del Registro di sistema per identificare univocamente widget dell'applicazione e un terzo esempio che verrà illustrato individuazione dallo script.

Creazione di destinazioni con la console di creazione

In molti casi, è possibile analizzare il registro di sistema per un determinato valore o tasto che identificherà in modo univoco i server di interesse tale host di destinazione desiderata. Se una classe (destinazione) può essere creata e popolata con i sistemi in cui la chiave del Registro di sistema di widget è presente, che sarà un modo semplice per creare un destinatario univoco.

Il primo esempio illustra questo esaminando semplicemente per verificare l'esistenza di una chiave del Registro di sistema. Nel secondo esempio eseguirà la ricerca di un valore specifico associato la chiave del Registro di sistema. Si noti che sebbene sia possibile creare del Registro di sistema attributo individuazione regola (come illustrato in precedenza) e un rilevamento nella console di modifica, come illustrato negli esempi che seguono, i due non ottenere gli stessi risultati, il primo semplicemente estende una classe esistente mentre la seconda crea una nuova destinazione.

Utilizzando una chiave del Registro di sistema

Quando la creazione di console prima viene avviata, è necessario scegliere se caricare un management pack esistente o crearne uno nuovo. Quando si sceglie di creare un nuovo management pack, una procedura guidata viene visualizzata e consente di selezionare un modello per un vuoto management pack oppure per una gestione Windows Application (del Registro di sistema) pack (vedere Figure 5 ).

Nella figura 5 scelta di un modello per un nuovo management pack fare clic su Immagine per una visualizzazione ingrandita

A uno può essere utilizzato per ottenere gli stessi risultati, ma è possibile creare una nuova classe utilizzando il modello Windows Application (del Registro di sistema) in modo semplice. È necessario fornire semplicemente un nome e quindi selezionare il modello del Registro di sistema. Successivamente, è necessario specificare il nome e descrizione per il management pack nella schermata Nome e descrizione. Il valore per immettere in questo campo è il valore visualizzato del nodo management pack dell'interfaccia utente Gestione operazioni.

Quindi specificare una descrizione dell'applicazione nella finestra di applicazione Windows. Il valore immesso in questo campo sarà il valore visualizzato nel nodo di attributi dell'interfaccia utente di gestione di operazioni. Quindi configurare la frequenza con cui deve essere eseguita l'individuazione. Il valore predefinito è ogni 15 secondi, che è probabilmente troppo spesso. Bilanciare la necessità di individuazione rapida contro l'impatto sulle prestazioni che può verificarsi con rilevamento troppo frequente. Non è in genere necessario interessante affinché un rilevamento eseguita più volte al giorno.

Compilare ora i dettagli necessari per trovare la chiave del Registro di sistema/valore desiderato in. Vi sono disponibili più tipi di attributo; se si desidera verificare l'esistenza di una chiave, utilizzare il tipo bool.

Infine, creare l'espressione di query. Questo potrebbe sembrare lavoro duplicato, non sufficiente generare l'espressione query? In realtà, non. La schermata di configurazione di analisi del registro di sistema definisce la chiave del Registro di sistema per esaminare e viene illustrato come esaminarla. Finestra Espressione di filtro viene utilizzato per definire il valore è previsto.

BENE, tutto questo eseguita, che cosa effettivamente creati? È stata soddisfare l'obiettivo di creare una nuova classe Nella console di modifica, selezionare il nodo del modello di servizio quindi sulle classi. Si noti che è stata creata una nuova classe. Esaminare le proprietà per comprendere ulteriori informazioni su questa nuova classe.

Per quanto riguarda la definizione di rilevamento? Ricerca nel modello di integrità e osservare la regola di individuazione, esaminare le proprietà qui nonché per vedere come la regola viene effettivamente creata.

Il valore del Registro di sistema

La creazione di un'individuazione cerca un valore di Registro di sistema invece di una chiave del Registro di sistema è altrettanto semplice. Lavoro della procedura guidata nuovo, ma, questa volta, modificare l'input per recuperare un valore del Registro di sistema invece di una chiave.

Per avviare la procedura guidata una volta completata modello iniziale, passare modello dello stato | rilevamenti. Nel riquadro centrale, fare clic con il pulsante destro del mouse e scegliere nuovo | registro di sistema (filtrato). Le voci corrisponderà la prima ma, questa volta che viene specificato un valore del Registro di sistema.

È facile! Con destinazioni di nuove create, l'esempio verrà interrotta in questo campo. Si noti tuttavia che ulteriori operazioni ancora da eseguire per popolare il management pack con MPOs. MPOs oppure può essere creato tramite l'interfaccia utente Gestione operazioni o direttamente nella console di modifica, in entrambi i casi funziona correttamente.

È necessario ricordare, tuttavia, che se si apre un MPO nella console modifica creato nella console operatore, non avrà il nome originale che è stato assegnato automaticamente. Al contrario, il nome specificato verranno sostituito con una stringa a partire da UIGenerated. Mentre ciò non influisce la funzione DELL'MPO alcuno, può essere molto frustrante se si sono cercando un MPO specifico nella console di modifica.

Indipendentemente quale metodo si sceglie, è stata creata una nuova classe che può essere utilizzato per la fornitura di regole. Come si conosce questa nuova classe e individuazione funziona? È possibile osservare le informazioni di magazzino individuati per la nuova classe, la nuova classe anche e sono indicati i come una destinazione valida per un nuovo monitor (illustrato nella Figura 6 ).

Nella figura 6 la nuova classe è una destinazione valida per un monitor fare clic su Immagine per una visualizzazione ingrandita

Individuazione tramite script

Per creare un rilevamento basata su script in un management pack esistente, caricare questo management pack in console di modifica. Se si inizia da zero, aprire la creazione di console e scegliere per creare un nuovo management pack.

Poiché si tratta di un rilevamento basata su script, la scelta applicabile solo consiste nel creare un vuoto management pack. Il primo passaggio nel processo consiste nel definire la classe che verrà popolata con lo script, insieme alle proprietà di classe (attributi) di interesse. Nome file, FileDirectory e FileDescription sono disponibili le proprietà definite da questa classe può essere modificata nello script, si vedrà per l'utente a breve.

Inoltre, la proprietà DisplayName ereditata dalla classe System.Entity e può essere modificata da script. Si noti che solo attributi è presente nell'elenco può essere modificato tramite lo script di individuazione, quindi assicurarsi che tutti gli elementi di interesse siano visualizzati di seguito. Si noti inoltre che ogni proprietà (attributo) è selezionata, ulteriori informazioni sulla proprietà verranno visualizzati a destra. Assicurarsi di compilare la voce di nome visualizzato per ogni proprietà (attributo). Se vengono lasciati vuoti, verranno restituite le informazioni di individuazione ma le intestazioni di colonna nell'ambiente OpsMgr, ad esempio nella visualizzazione individuato magazzino sarà vuote.

Con la classe definita, è possibile creare il rilevamento basata su script. Passare a modello dello stato | rilevamenti. Fare clic con il pulsante destro del mouse e scegliere nuovo | script e creare l'individuazione. È disponibile una grande quantità di informazioni. In primo luogo, la scheda Generale consente il rilevamento di denominazione e fornisce una destinazione in cui deve essere eseguito il rilevamento. Tenere presente, come specifico possibile quando si definisce la destinazione.

Ai fini del presente articolo, Windows computer senso. Nella scheda tipi di individuato, configurare il tipo di oggetto per essere rilevati. Si noti che il nome del tipo individuato corrisponda il nome della classe definito in precedenza.

È quindi la scheda configurazione, che visualizza informazioni che viene generate automaticamente quando lo script è definito. Selezionare la configura per vedere lo script e l'ora programmata per l'esecuzione dello script. Si noti inoltre la casella di parametri (che è possibile accedere selezionando configurazione | script | parametri). Prendere esaminare i parametri elencati, farà riferimento a essi più avanti in questo articolo.

Lo script per il processo di rilevamento insieme di unità e inviare i risultati OpsMgr è illustrato nella Figura 7 . Si tratta di uno script molto semplice, ma fornisce il framework per gli elementi chiavi necessari per individuazione basata su script per l'utilizzo.

Nella figura 7 dello script di individuazione

Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are 
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject") 
If (oFSO.FolderExists("C:\WServer")) Then 

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all 
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties 
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.  
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.  
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined, 
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute) 
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If

Importazione di questo management pack in OpsMgr determina il sistema corretto da rilevati, come illustrato nella Figura 8 . Si noti che le proprietà (attributi) definite nello script siano visualizzati nell'interfaccia utente con i valori a essa associati.

Nella figura 8 Individuazione tramite uno script fare clic su Immagine per una visualizzazione ingrandita

Quando si esamina lo script, si noterà che è possibile passare il valore di un elemento individuato in modo esplicito o tramite una variabile. E mantenere presente che, come specificato in precedenza, se il campo nome visualizzato per la proprietà particolare (attributo) nella classe era stato lasciato vuoto, le intestazioni di colonna FileName, FileDirectory e FileDescription (vedere la Figura 8 ) sarebbe stato vuote nonché.

Ulteriori considerazioni sulla

Tieni traccia delle versioni Quando si lavora nella console di modifica, è comune a generare più revisioni prima di aver. È necessario assicurarsi che ogni revisione per l'utilizzo in OpsMgr viene salvata con il numero di versione incrementato.

Il numero di versione è accedere nella console di modifica selezionando file | proprietà di Management Pack. Problemi di incrementare il numero di versione può causare l'importazione di un nuovo management pack su uno esistente con stessi numeri di versione. Questo può causare confusione durante l'importazione.

sealed e dissigillate? Al termine il management pack, sarà necessario decidere se devono essere sealed per produzione a scopo o dissigillate a sinistra. Esistono vantaggi per lasciare il management pack dissigillate, ad esempio la capacità di memorizzare esegue l'override nel management pack direttamente. Ma esistono ulteriori motivi interessante per eseguire un pacchetto di gestione personalizzati prima di introdurre nell'ambiente di produzione:

• Sealing un personalizzato management pack per l'utilizzo in produzione è consigliabile.
• Sigillo consente di controllo della versione più e più controllo di modifica.
• Sigillo consente l'utilizzo delle stesse procedure operative personalizzate nonché esterna management pack. Richiedere procedure diverse, ad esempio la posizione esegue l'override per personalizzati e esterna management pack, presenta numerose confusione.
• Classi create in un pacchetto di gestione non sealed non saranno visibili e utilizzabile solo da altri MPOs memorizzati in stesso pacchetto di gestione. Sigillo consente di essere utilizzabili indipendentemente in cui è memorizzato il MPO di oggetti.
• È possibile gestire una raccolta di origine non sealed management pack nel controllo degli amministratori OpsMgr per evitare modifiche accidentali o involontarie.

Informazioni sulle destinazioni è completamente strumentale proficuo OpsMgr. Poster denominato regola e monitor assegnazione consigliate disponibile in formato PDF in go.microsoft.com/fwlink/?LinkId=125048. È disponibile da un riferimento molto utile per informazioni sulle diverse destinazioni e potrebbe essere opportuno utilizzare.

Steve Rachui è dedicata Engineer supporto con il più importante livello Progettazione campo gruppo di Microsoft. Ha supportato SMS sin dalla versione 1.2 e MOM dalla versione 2000. È possibile contattarlo in indirizzo steverac@microsoft.com.