System Center

Granular de identificación de Operations Manager 2007

Steve Rachui

En resumen:

• Con un destino existente
• El problema de detección de atributo
• Creación de destinos con la consola de creación
• Detección basada en secuencias de comandos

Contenido

Con un objetivo existente
Creación de destinos con la consola de creación
Uso de una clave del registro
Valor del registro
Detección mediante secuencias de comandos
Consideraciones adicionales

Crear objetos de supervisión personalizados (reglas, monitores, grupos y así sucesivamente) es una parte normal de rutinas de los administradores de muchos System Center Operations Manager (OpsMgr) 2007. Para todos los objetos que se creó, hay una pregunta común que debe responder a, ¿qué destino utilizar.

Elegir el destino correcto para un objeto es fundamental, pero el enfoque correcto no siempre es claro. OpsMgr proporciona una serie de opciones de destino. En este artículo se eche un vistazo varias, con el objetivo de ayudar a los administradores que elija el método apropiado para cada escenario; y la términos "clase" y "destino" utilizará indistintamente.

Supongamos que tiene una aplicación interna denominada widget que necesita para supervisar. Han definido todas las especificaciones de supervisión y ha comenzado el trabajo para crear los objetos de supervisión de este artículo. Rápidamente descubre, sin embargo, que hay ningún destino preciso para este artículo. Función para recomendaciones OpsMgr, todas las reglas, monitores etc. deben destinarse para que el objeto más específico posible para limitar el ámbito de distribución a sólo los sistemas de interés. ¿Qué son las opciones de OpsMgr que pueden ayudarle a cumplir este objetivo práctica mejor?

Con un objetivo existente

De forma predeterminada, OpsMgr incluye una lista larga de destinos y esa lista aumenta cuando se importan más paquetes de administración. Cuando se está creando un nuevo objeto de paquete de administración (MPO) y teniendo en cuenta el destino, en primer lugar revise los elementos disponibles para ver si uno de los destinos preexistentes es suficiente. Por ejemplo, si está creando MPOs para ampliar el servidor de supervisión de System Management Server (SMS), es probable que se pueden reutilizar los destinos existentes que se importan junto con el paquete de administración predeterminado servidor SMS para su MPO.

Sin con destinos predeterminados, embargo, no siempre funciona. Si los destinos disponibles no son lo suficientemente específicos para la MPO que se va a crear, puede solucionar la ausencia de un objetivo óptimo o crear un nuevo destino.

Un enfoque común (aunque tiene algunas desventajas) es asociar la nueva MPO para el cliente de Windows o la clase de servidor de Windows o cualquier otra clase de base correspondiente (de nuevo, ser tan específico como sea posible) que incluye los objetivos necesarios. Al realizar esto, asegúrese de crear el MPO en un estado deshabilitado. A continuación, se puede crear un grupo que contiene todos los sistemas que estos MPOs necesita ejecutar y reemplace los MPOs deshabilitados para la MPO está habilitado para sólo los agentes en el grupo. Esto permite la MPO se entregan y ejecutar en sólo los agentes que permiten el reemplazo.

¿Cuáles son los inconvenientes de este enfoque? En primer lugar, el uso de este método tiene como destino la clase más amplia de objetos (Windows equipo, por ejemplo), por lo que todos supervisan MPOs destinados de esta presentación forma hacia arriba bajo el objeto destino en el explorador de estado (consulte la figura 1 ).

La figura 1 explorador de estado de equipo de destino mediante reemplazar (haga clic en la imagen de una vista más grande)

Esto es realmente sólo cosmetic, por lo que no puede ser un problema en un entorno dado. Pero destino de esta forma hace que el estado del estado del objeto primario (como equipo de Windows) que se ven afectados cuando se ve afectado el monitor personalizado. Por lo tanto, si la aplicación de este artículo tiene un problema, el estado de todo el objeto de destino puede verse afectado. Dependiendo de lo que está supervisado, esto puede o no es notable.

MPOs se dirige a grupos no es normalmente un enfoque adecuado en OpsMgr, por lo que hace ¿por qué este trabajo? Recuerde que los grupos en estos ejemplos se utilizan como reemplaza y no son el destino real de la MPO.

Esto puede parecer semántica, pero piense en grupos de OpsMgr. Grupos son objetos, sólo como cualquier otro objeto. Cuando se selecciona un objeto como el destino, esto significa que la MPO en cuestión se está implementado en los agentes que posee el objeto de destino.

¿Por lo tanto, el agente posee el objeto de grupo? Correcto, el servidor de administración raíz (RMS). Identificación de un grupo, hará que MPOs van a entregar al agente que posee el grupo, lo que significa que se implementará MPOs sólo para el RMS! Si un MPO dirigido correctamente, la fase ya está establecida para que los MPOs para implementarse a los agentes correctos, pero, deshabilitando el MPO, ha detenido ese proceso antes de pueda comenzar.

Cuando se introduce un reemplazo, el destino existente todavía es el destino, el reemplazo sólo cambia el estado deshabilitado a habilitado para los agentes de unos por pertenencia al grupo. Pero los agentes que está habilitada la MPO ya forman parte del destino para la MPO original. Sé que es un poco confuso en primer lugar.

Ahora Imagine un escenario donde nada descritos hasta ahora es viable. ¿Qué puede hacer? Hay sólo una opción restante: crear un nuevo destino específicamente para MPOs, lo cual puede realizarse mediante el servicio de supervisión de plantilla en la Operations Console o creando un nuevo destino en la consola de creación.

Antes las, sin embargo, ¿qué va creando una detección de atributo ¿considerar? Se podría pensar que esto es una opción viable que se ha pasado por alto. Echemos un vistazo. Es posible generar una detección de atributo que obtiene información desde el registro o de WMI. Para trabajar, la detección de atributo se debe dirigida a una clase que contiene las entradas WMI de interés o del registro. Destinos comunes son de cliente de Windows o las clases de Windows Server o incluso la clase de equipo de Windows más genérica.

Tenga en cuenta que el término propio, detección de atributo, implica lo que realmente está ocurriendo: un nuevo atributo se descubre y utilizar para extender una clase existente. True, una nueva clase se crea como resultado, pero es realmente la misma clase antigua con todos los mismos miembros, sólo con un atributo nuevo notificado. En función de esto, puede ver que crear una nueva detección de atributo no es el mismo que crear un objetivo realmente único.

¿Qué es un ejemplo? Supongamos que se crea una nueva detección de atributo para encontrar la clave del registro para el producto widget. Esta detección está destinado para implementarse en el equipo de Windows para que incluirán todos los agentes que es posible que tenga la clave del registro para este artículo.

Después de realizar esta opción en el asistente, recibe una advertencia que se no se puede extender la clase de equipo de Windows (está en un módulo de administración sealed después de todo, si no fuera un paquete de administración sealed, no habría ninguna advertencia tal) y una clase de destino ha cambiado el nombre se presenta como una opción puede utilizar para poder continuar (consulte la figura 2 ). Esto sucede porque el objetivo de descubrimiento de atributo es ampliar una clase existente.

La Figura 2 atributo detección doesn’t crear una clase única (haga clic en la imagen de una vista más grande)

Ahora veamos plantillas de servicio, que pueden utilizarse para crear destinos únicos para sistemas que se pueden encontrar basado en un servicio instalado. Las plantillas de servicios son demasiado fácil de usar; figura 3 muestra un ejemplo.

La figura 3 una plantilla de servicio

Sin embargo, tener en cuenta, que es posible que lugar mediante la plantilla la creación de MPOs adicionales más allá lo es posible que piensa o desea. Después de utilizar la plantilla de servicio, es una buena idea comprobar y ver qué objetos adicionales se han creado y determinar si debe conservarse (consulte la figura 4 ).

La figura 4 se utilizó objetos que se crean cuando una plantilla (haga clic en la imagen de una vista más grande)

Además, las plantillas de servicios creará un proceso de descubrimiento y una clase nueva para cada uno de los servicios. Esto puede ser exactamente lo que desea, o puede ser muy granular. Por ejemplo, supongamos que su aplicación personalizada tiene varios servicios. En ese caso, una nueva clase y un nuevo monitor de servicio se crearán para cada uno. Es más probable que la solución de supervisión deseada sería tener una única clase con cada monitor servicio destinado a sólo esa clase.

Si no se puede o no desea utilizar una plantilla de servicio, su única opción restante es utilizar la consola de creación. Un vistazo la consola de creación de documentación de la muestra que uso correcto de esta característica requiere una explicación muy profunda, una que sea mucho más allá del alcance de este artículo.

No obstante, algunos ejemplos simples que utilizar la consola de creación para crear y rellenar un nuevo destino de OpsMgr están en orden. Proporcionará dos ejemplos que vuelva a visitar la idea de utilizar una entrada del registro para identificar de forma exclusiva el ejemplo de aplicación y una tercera widget que mostrará descubrimiento por secuencia de comandos.

Creación de destinos con la consola de creación

En muchos casos, es posible examinar el registro para un valor determinado o una clave que se identifican los servidores de interés que host el destino deseado. Si una clase (destino) se podría integrada y rellena con los sistemas donde la clave de registro de widget existe, que sería una forma sencilla de crear un único destino.

El primer ejemplo se recorre Esto simplemente buscando la existencia de una clave del registro. En el segundo ejemplo se buscará un valor específico asociado a la clave del registro. Tenga en cuenta que aunque el puede crear una regla de detección de atributo del registro (como se explicó anteriormente) y un descubrimiento en la consola de creación, como se muestra en los ejemplos siguientes, los dos no conseguir el mismo resultado, el primero simplemente extiende una clase existente mientras el último en realidad crea un nuevo destino.

Uso de una clave del registro

Cuando la consola de creación se inicia en primer lugar, debe elegir si se carga un módulo de administración existente o crear uno nuevo. Cuando elige crear un nuevo módulo de administración, un asistente aparecerá y le permite seleccionar una plantilla para un módulo de administración vacía o para una administración Windows Application (registro) paquete (consulte Figure 5 ).

La figura 5 elegir una plantilla para un nuevo módulo de administración (haga clic en la imagen de una vista más grande)

Ya sea uno se puede utilizar para obtener los mismos resultados, pero resulta fácil de crear una nueva clase con la plantilla Windows Application (registro). Debe simplemente proporcione un nombre y, a continuación, seleccionar la plantilla del registro. A continuación, tendrá que proporcione el nombre y descripción para el módulo de administración en la pantalla de nombre y descripción. El valor que especifique aquí es el valor mostrado en el nodo de paquetes de administración de la interfaz de usuario Operations Manager.

A continuación, proporcionar una descripción de la aplicación en la pantalla de aplicación de Windows. El valor especificado aquí será el valor mostrado en el nodo de atributos de la interfaz de usuario Operations Manager. A continuación, configure con qué frecuencia se debe ejecutar la detección. Aquí el valor predeterminado es cada 15 segundos, que suele probablemente demasiado. Equilibrar la necesidad de detección rápida contra el impacto de rendimiento que puede producirse con detección muy frecuente. Normalmente hay ningún motivo convincente para que una detección ejecutar varias veces al día.

Ahora, rellene los detalles necesarios para encontrar la clave del registro y valor que le interesa. Hay varios tipos de atributos disponible; si simplemente desea comprobar la existencia de una clave, utilice el tipo booleano.

Por último, crear la expresión de consulta. ¿Esto puede parecer que trabajo duplicado, no crear sólo la expresión de consulta? En realidad, no. La pantalla del registro sonda configuración define la clave del registro para ver y cómo examinar. La pantalla de expresión de filtro se utiliza para definir qué valor se espera.

De acuerdo, con todo esto se realiza, ¿qué ha realmente creado? ¿Se ha coincide con el objetivo de crear una nueva clase? En la consola de creación, seleccione el nodo de modelo de servicio y haga clic en las clases. Tenga en cuenta que se se crea una nueva clase. Examine las propiedades para obtener más información sobre esta nueva clase.

¿Qué ocurre con la definición de la detección? Busque en el modelo de estado y observe la regla de descubrimiento, revise las propiedades aquí también para ver cómo se genera en realidad la regla.

Valor del registro

Creación de un proceso de descubrimiento que busca un valor del registro en lugar de una clave del registro es igualmente sencilla. Trabajo con el asistente nuevo, pero, esta vez, modificar la entrada para extraer un valor de registro en lugar de una clave.

Para iniciar el asistente una vez completada la plantilla inicial, vaya al modelo de estado | detecciones. En el panel central, haga clic con el botón secundario del mouse y seleccione New | registro (filtrado). Las entradas será el mismo como antes excepto esta hora que se especifica un valor del registro.

Es fácil que! Con los destinos nuevos creados, en el ejemplo se detendrá aquí. Pero tenga en cuenta que trabajo adicional todavía debe hacerse para rellenar el paquete de administración con MPOs. MPOs pueden crearse o bien a través de la interfaz de usuario administrador de operaciones o directamente en la consola de creación, de cualquier manera funciona bien.

Debe recordar, sin embargo, que si abre un MPO en la consola de creación que ha creado en la consola de operaciones, no tendrá el nombre original que le asignó. En su lugar, el nombre dado será reemplazado por una cadena, comenzando con UIGenerated. Aunque esto no afecta a la función de la MPO absoluto, puede ser muy frustrante si se intenta buscar un MPO específico en la consola de creación.

No importa el método que elija, ha creado una nueva clase que puede utilizarse para proporcionar las reglas. ¿Cómo sabe este funciona de clase y el descubrimiento de nuevo? Se puede eche un vistazo la información de inventario descubiertos para la nueva clase, y la nueva clase también aparece como un destino válido para un nuevo monitor (se muestra en la figura 6 ).

Figura 6 la nueva clase es un destino válido para un monitor (haga clic en la imagen de una vista más grande)

Detección mediante secuencias de comandos

Para crear una detección basada en secuencias de comandos en un módulo de administración existente, cargar ese módulo de administración en la consola de creación. Si comienza desde el principio, abra la consola de creación y elija crear un nuevo módulo de administración.

Puesto que se trata de una detección basada en secuencias de comandos, la opción aplicable sólo es crear un paquete de administración en blanco. El primer paso de este proceso es definir la clase que se rellenará con la secuencia de comandos, junto con las propiedades de clase (atributos) de interés. FileName, FileDirectory y FileDescription son disponibles propiedades definidas por esta clase que se puede manipular en la secuencia de comandos, VOY a mostrar, más adelante.

Además, la propiedad DisplayName se hereda de la clase System.Entity y también se puede manipular por secuencia de comandos. Observe que sólo los atributos que aparecen en esta lista puede manipularse con la secuencia de descubrimiento, por lo que asegúrese de que los elementos de interés se muestran aquí. También observe que como cada propiedad (atributo) está seleccionada, detalles acerca de la propiedad aparecerá en la parte derecha. Asegúrese de rellenar la entrada de nombre para mostrar para cada propiedad (atributo). Si lo se dejan en blanco, se devolverá la información de detección pero los encabezados de columna en el entorno OpsMgr, como en la vista de inventario detectada, estará en blanco.

Con la clase definida, puede crear la detección basada en secuencias de comandos. Vaya al modelo de estado | detecciones. Haga clic con el botón secundario del mouse y seleccione New | secuencias de comandos y crear la detección. Hay una gran cantidad de información aquí. En primer lugar, la ficha general permite la detección de nomenclatura y proporciona un destino en el que se debe ejecutar la detección. Recuerde, ser tan específico como sea posible al definir el destino.

Para el propósito de este artículo, Windows, tiene sentido. En la ficha tipos de detectada, configure el tipo de objeto se detecte. Observe que el nombre del tipo detectado aquí coincide con el nombre de clase definido anteriormente.

El siguiente es la ficha Configuración, que muestra la información que se genera automáticamente cuando se define la secuencia de comandos. (Seleccione Configurar para ver la secuencia de comandos y el tiempo programado para ejecutar la secuencia de comandos). Además, observe el cuadro de parámetros (que puede obtener acceso al seleccionar configurar | secuencias de comandos | parámetros). Toma un vistazo a los parámetros enumerado, hará referencia a ellos más adelante en este artículo.

En la figura 7 se muestra el script para el proceso de recopilación de detección de unidad y enviar los resultados a OpsMgr. Esto es una secuencia de comandos muy básica, pero proporciona el marco para los elementos clave que son necesarios para la detección basada en secuencias de comandos trabajar.

La figura 7 detección de script

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

Importar este módulo de administración en OpsMgr da como resultado el sistema correcto encontrado, tal como se muestra en la figura 8 . Observe que cada una de las propiedades (atributos) definidas en la secuencia de comandos se muestran en la interfaz de usuario con los valores asociados.

Figura 8 descubrimiento mediante una secuencia de comandos (haga clic en la imagen de una vista más grande)

Al mirar la secuencia de comandos, verá que se puede pasar el valor de un elemento detectado explícitamente o a través de una variable. Y tenga en cuenta que, como se indicó anteriormente, si el campo Nombre para mostrar de la propiedad concreta (atributo) de la clase se había deja en blanco, los encabezados de columna FileName, FileDirectory y FileDescription (consulte la figura 8 ) habría sido en blanco así.

Consideraciones adicionales

realizar control de versiones Cuando se trabaja en la consola de creación, es habitual para generar varias revisiones antes de que haya terminado. Debe asegurarse que se guarda cada revisión para su uso en OpsMgr con incrementa el número de versión.

El número de versión está disponible en la consola de creación seleccionando archivo | propiedades del paquete de administración. No puede incrementar el número de versión puede ocasionar la importación de un nuevo módulo de administración a través de una existente con los mismos números de versión. Esto puede provocar confusión durante la importación.

sealed o Desellado? Cuando se complete el módulo de administración, deberá decidir si deben ser sealed para producción propósitos o desellado hacia la izquierda. Existen ventajas al dejar el paquete de administración desellado, como la posibilidad de almacenar anula en el módulo de administración directamente. Pero hay varias razones convincentes para sellar un paquete de administración personalizadas antes de introducir en el entorno de producción:

• Sellar un paquete de administración personalizadas para su uso en producción es una práctica recomendada.
• Sellado permite mayor control de versiones y un control de cambios más estricto.
• Sellado permite el uso de los mismos procedimientos operativos para paquetes de administración personalizado, así como comercial. Requerir distintos procedimientos, como dónde colocar reemplaza para personalizado frente a los paquetes de administración comercial, presenta una gran cantidad de confusión.
• Las clases creadas en un módulo de administración unsealed será visible y utilizar sólo por otros MPOs almacenados en el mismo paquete de administración. Sellado permite que se pueda usar independientemente de dónde se almacene el MPO los objetos.
• Una biblioteca de paquetes de administración unsealed "origen" se puede mantener bajo control de los administradores OpsMgr para evitar cambios accidentales o no deseados.

Totalmente los destinos de comprender es instrumental para el éxito con OpsMgr. Está disponible en formato PDF en un póster llamado reglas y prácticas recomendadas de identificación de Monitor go.microsoft.com/fwlink/?LinkId=125048. Lo encontrará que es una referencia muy útil para comprender diferentes destinos y cuándo pueden ser apropiados para utilizar.

Steve Rachui es dedicadas soporte técnico de ingeniero con el grupo Ingeniería de campo principal de Microsoft. Ha admitido SMS desde la versión 1.2 y MOM de la versión 2000. Puede ponerse Steve en steverac@Microsoft.com.