System Center Service Manager: El Dashboard

 

De nada vale que tengamos la mejor gestión del servicio del mundo si no podemos explotar la información fácilmente de forma que podamos mejorar el servicio.

El objetivo final no es ser capaz de gestionar miles de incidencias y resolverlas en unos tiempos determinados, o gestionar los cambios simplemente por burocracia, el objetivo real de IT es que no haya incidencias y para eso necesitamos poder analizar los datos y determinar que es necesario mejorar.

SCSM cuenta con muchos informes, pero para hacer análisis rápidos y ver la situación general del servicio desde el punto de vista de la gestión no hay nada como el dashboard del que os voy a hablar.

Podéis descargar el dashboard de SCSM gratuitamente desde http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4efb9d76-99e7-4bfe-b6f6-a58469bdcf27&displaylang=en 

El dashboard requiere Sharepoint Services v3 o Sharepoint Server 2007.

En la descarga viene un fichero readme con las instrucciones detalladas por si tenéis algún problema con algún parámetro, permisos, etc.

El dashboard recoge la información de la base de datos de datawarehouse, así que tendréis que tener instalada esa parte de SM tal y como ya explicamos en un post anterior.

Ff758669.image1(en-us,TechNet.10).jpg

Durante esta instalación he usado un usuario que es administrador de sharepoint y administrador local y para el pool de aplicación y acceso a la base de datos he usado la cuenta de servicio que cree para  SCSM.

La instalación sobre un servidor que ya tengo el sharepoint montado es sencilla:

En un CMD ejecutado con Run as Administrator ejecutáis la siguiente línea:

Msiexec /I ServiceManagerDashboard_x64.msi /L*V setup.log

image

image

image

image

image

image

En la descarga viene una guía de usuario con mucha información sobre como podéis cambiar la información que muestra la dashboard para adaptarla a vuestras necesidades:

image

Si no veis datos en el dashboard aseguraros que vuestros jobs de datawarehouse en SM han corrido adecuadamente y que hay datos de verdad.

image

image

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager: Instalando y usando el portal Web

 

El portal web de System Center Service Manager, nos permite tener un punto mas de interlocución con los usuarios.

Desde el portal podemos:

  • Permitir que los usuarios:
    • Crear y ver el estado de sus incidencias y otras solicitudes
    • Solicitar software
    • Acceder a artículos de conocimiento, FAQs, etc.
  • Anunciar a nuestros usuarios problemas o cambios
  • Si tenemos FIM, también podemos permitir que los usuarios cambien sus contraseñas.

Siempre he dicho que estratégicamente de cara al ITSM en lo relativo a incidencias conseguir que sean los propios usuarios los que introduzcan las incidencias a través de un portal de este tipo es un objetivo muy importante.

Cuando los usuarios se educan a introducir la incidencia obtenemos indudables ventajas:

  • La trazabilidad de la incidencia comienza de la mejor manera, esta claro y no es discutible el momento en el que el usuario comunico el problema.
  • Este método consume menos tiempo y recursos en el call center.
  • Funciona 24/7
  • Ofrece un canal estructurado

La instalación es muy sencilla, en un servidor Windows Server 2008 o 2008 R2 con el rol de IIS desplegado y habiendo generado un certificado SSL si vamos a querer usar HTTPs, solo tenemos que seguir los siguientes pasos:

image

image

image

image

image

image

image

image

image

En realidad habremos instalado dos portales, uno para usuario final y otro para operadores/analistas.

image

El portal es multi-idioma, aqui os enseño como se muestra el portal para usuarios cuando detecta una configuración regional española.

image

Los datos que veis que muestra, son recogidos de la CMDB, en este caso además están alimentados por un conector con el directorio activo.

Ahora por ejemplo podemos publicar un anuncio desde la consola de SCSM para que se muestre también en el portal:

image

image

Como decía también podemos publicar artículos de conocimiento

image

Por supuesto podemos incluir, comentarios, elementos relacionados, contenido interno con formato, contenido externo, enlaces, etc.

image

Para que salga en el portal, el articulo tiene que estar publicado:

image

image

image

Si el usuario lo desea puede realizar una solicitud que se materializara como un cambio o incidencia segun lo que indique

image

image

image

image

Por supuesto se puede configurar que le llegue un correo automáticamente al usuario, que se tipifiquen cosas automáticamente, la prioridad en caso de que el usuario sea VIP, etc, etc. todo eso lo iremos explicando en mas posts o si tenéis dudas con algo especifico dejar un comentario.

La incidencia ya nos aparecerá en la consola

image

El usuario puede ver el estado e incluso cerrarla si se ha resuelto de alguna forma.

image

Los usuarios tambien pueden pedir software, esta parte os la mostrare en un post especifico.

image

También esta el portal de operador/analista que se puede ver o no según los permisos que tengas en Service Manager

image

Una parte muy interesante del portal de analista es que te permite ver de una forma muy rápida si hay alguna actividad dentro de ITSM que este esperando por ti.

Para aquellos que queráis os comento que todas las partes del portal son en realidad web parts y que podéis añadirlas a vuestras intranets de sharepoint si lo preferís.

Espero que os haya resultado interesante este post.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager: SCOM CI Connector

 

Este es el ultimo de los conectores que os voy a explicar en esta serie de posts.

Mientras que otros conectores como los del AD o SCCM nos aportan CIs imprescindibles podríamos decir que el conector de SCOM para CIs nos va a permitir dar mucho valor añadido a nuestra gestión del servicio especialmente permitiéndonos establecer todas las implicaciones de cambios, incidencias y problemas gracias a que vamos a poder contar en SM con todos los CIs monitorizados por SCOM.

Como sabéis SCOM sabe que tiene que monitorizar y como gracias a los management packs, pues bien, SCSM nos permite importar los mismos management packs, acción esta imprescindible si queremos sincronizar CIs con la CMDB de SM.

Por tanto lo primero que tenemos que hacer es determinar que clases de CIs monitorizados por SCOM queremos tener en la CMDB, luego determinar que management packs son los que describen esos CI, averiguar si esos management packs tienen dependencias en otros management packs y finalmente importar todos esos management packs en SCSM.

Para este ejemplo, me voy a centrar en incorporar a la CMDB todo lo que tenga que ver con servidores windows y virtualización.

Una forma rápida de obtener los ficheros de los management packs, es desde la consola de SCOM.

image

Buscamos los management packs que queremos

image

Una vez descargados, nos vamos a la consola de SCSM para importarlos.

image

image

image

Como os decía antes, los management packs suelen depender unos de otros, en este caso nos faltan mas management packs.

image

Nos apuntamos todas las dependencias y nos los bajamos.

Nota: Algunos de los MPs relativos a SCVMM no los encuentras en el catalogo, los tenéis en el CD de SCVMM.

Nota: Los manament packs de systemcenter.datawarehouse estan en el directorio de SCSM en program files, en el servidor de SM.

image

image

Ya podemos crear el conector:

image

image

image

image

image

Si llegado a este paso no te han salido los management packs que has importado, entonces revísalos bien, posiblemente no coinciden con los que tienes en el SCOM, por ejemplo yo importe el de SCVMM 2008 y en realidad en el SCOM tenia el de SCVMM 2008 R2.

Recordar que siempre que añadáis un management pack nuevo, tendréis que venir al conector y añadirlo.

Supongo que en siguientes versiones mejoraran esto añadiendo acceso al catalogo, la verdad es que ahora no es lo mas cómodo añadir management packs a SCSM, encontrar las dependencias, etc., pero con un poco de paciencia lograreis lo que queréis, luego el esfuerzo merece la pena.

image

image

Forzamos la sincronización para probarla

image

Fijaros como ahora podemos al relacionar elementos a una incidencia seleccionar una base de datos concreta de SQL Server por ejemplo:

image

Por supuesto ya tenemos tambien las maquinas virtuales:

image

Por supuesto nos podemos crear una vista de todos los ICs de un tipo determinado, agrupar por lo que queramos, buscar, etc.

image

Como veis ya se ha traído toda la información de las VMs, numero de micros, etc.

La vista es muy fácil de configurar y se pueden activar los filtros que sean necesarios, cost center, owner, etc:

image

No suele ser necesario tocarlo, pero por si acaso os explico que con la siguiente secuencia de comandos powershell, podéis ver que clases se importan, hay que tener en cuenta que Microsoft.Windows.ApplicatonComponent se sincroniza por defecto y esta es una clase bastante genérica.

image

Si queréis añadir alguna clase mas basta con correr el cmdlet de add.

clip_image053

En otro posts os explicare como crear la definición de los servicios en SCSM y asociar los elementos de diagramas de aplicación distribuida de SCOM.

Espero que os haya gustado.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager: El conector de alertas de SCOM

 

Venimos hablando en varios posts sobre como incorporar información a la CMDB de Service Manager, este post sin embargo trata sobre como podemos conectar las alertas de SCOM con las incidencias de SCSM.

Como sabéis cuando SCOM detecta un problema recibimos una alerta en la consola que además podemos también recibir por correo o en nuestro móvil si así lo hemos configurado.

Hace poco os comentaba en un post como podíamos organizarnos el trabajo con las alertas en SCOM sin embargo en muchas compañías cuando el nivel de madurez operativo es mas avanzado suele requerirse que las alertas de SCOM sean incorporadas al sistema en el que IT gestione las incidencias.

Desde mi punto de vista, esto tiene muchas ventajas, hay una mayor trazabilidad y control de las implicaciones de una incidencia y mas aun cuando la incidencia ha sido motivadora de un problema o mas aun incluso si se esta justificando un cambio para evitar futuras incidencias con la misma causa raíz.

Hay que reconocer que realizar este proceso de forma manual es tedioso y desmotivador, tener que introducir la incidencia en el sistema y meter a mano los datos de la alerta de SCOM es poco productivo y aunque podemos tratar de usar enlaces a la consola web de SCOM como forma de acceder a los datos de la alerta, no habrá trazabilidad una vez cerrada la alerta o pasado el periodo de grooming y lo que es peor no hay un vinculo real entre incidencia y alerta lo cual hace que al cerrar cualquiera de las dos la otra sigue estando abierta.

Aquellos de vosotros que uses Service Manager tenéis la suerte de que este problema esta mas que resuelto y de una forma muy sencilla, SCSM incluye un conector de alertas que es capaz de vincular automáticamente alertas e incidencias.

Este post os muestra como configurar este conector:

El primer paso será dar permisos en SCOM a la cuenta de servicio que uséis en SCSM.

Después desde la consola de SCSM creamos el conector como veis a continuación:

image

image

image

image

En el siguiente paso podemos indicar que plantilla de incidencia queremos usar para las incidencias que se creen con las alertas que vengan de SCOM, podemos especificar diferentes criterios cada uno de ellos puede usar una plantilla diferente, en este ejemplo no voy a especificar ninguna regla especifica y dejare que todas las incidencias se creen con la plantilla por defecto para este tipo de incidencias que es la “operations manager incident template”

image

Ahora indicaremos cada cuanto tiempo tiene que sincronizarse el conector y si queremos que se cierren solas las alertas y las incidencias si hay cambios en el otro extremo del conector.

image

image

image

El siguiente paso lo tendremos que realizar desde la consola de SCOM y consistirá en indicar que alertas queremos que pasen a SCSM a través del conector.

En mi opinión es necesario establecer un criterio en vez de hacer que todas las alertas pasen a SCSM y se conviertan en incidencias.

En general un punto de partida es que se conviertan en incidencias todas las alertas en las que se haya cambiado el estado a los estados que especifiquemos.

Para este ejemplo voy a configurar el conector para que todas las alertas que se pongan en estado “resolviéndose” que es un estado que nos hemos creado nosotros en SCOM pasen automáticamente a SCSM.

Al configurar el conector en SCSM se nos habrá creado automáticamente un conector en SCOM como el que veis en la siguiente imagen, debemos editar sus propiedades.

image

image

Pulsamos sobre “Add” para añadir una subscripción en la que especificaremos el criterio usado para pasar las alertas a SCCM

image

En este ejemplo no vamos a limitar a grupos específicos de objetos en SCOM, cualquier alerta de cualquier grupo podrá pasar a SM si cumple el criterio.

Con la siguiente configuración las alertas pasaran incluso cuando provengan de management packs importados con posterioridad a la creación de esta subscripción:

image

A continuación especificamos el criterio que queramos:

image

A partir de este momento cuando queramos sincronizar una alerta creando una incidencia en SCSM solo tendremos que cambiar su estado al que hayamos seleccionado en el criterio.

image

Pasado el tiempo que hemos indicado al conector, tendremos la incidencia creada en SCSM

image

Como hemos usado la plantilla por defecto y no hemos parametrizado nada la planilla ni el workflow asociado la incidencia esta sin asignar a nadie, no tiene clasificación, etc, todo eso se soluciona como digo parametrizando SM.

Veis como las incidencias ya tienen todos los datos que vienen de SCOM.

image

Incluido por ejemplo los elementos afectados:

image

En otro posts os explicare como importar CIs desde SCOM con lo que también se asociarían servicios afectados, etc.

Si damos por resuelta la incidencia en SCSM y la cerramos, la alerta en SCOM también pasa a estar cerrada.

image

Como veis, es mas que fácil y es una herramienta muy potente para mejorar el servicio y tener las alertas mas controladas e integradas en la gestión del servicio.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager: Configuration Manager Connector

 

Si antes veíamos como crear un conector con el directorio activo para empezar a dotar de contenido a nuestra CMDB en Service Manager ahora veremos como complementar aun mas esta información con todos los datos que tiene SCCM sobre los servidores y ordenadores, además también nos será muy útil para tener la información de las actualizaciones y software.

El proceso es también muy sencillo:

image

image

image

image

image

El usuario tiene que tener permisos en el SQL usado por SCCM (smsroledb_extract y databasereaders)

image

image

image

image

El conector tardara un poco en sincronizar los datos con la CMDB, podéis ver el progreso desde la consola:

image

image

image

image

image

Como veis este conector es muy importante para la CMDB dándonos mucha información muy útil.

En otro post os mostrare como trabajar con los paquetes de software, permitir que los usuarios pidan software a través del portal de autoservicio de service manager, etc.

Aun podemos añadir mas información a los CIs que nos hemos traído del AD y el SCCM y añadir nuevos CI a través del conector de SCOM que será el siguiente que os enseñare.

Un saludo.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager 2010: El Active Directory Connector

 

Hace poco hablábamos de la CMDB de System Center Service Manager (SCSM), vamos a ir viendo uno a uno los conectores mas comunes y como emplearlos, empezando por el conector del directorio activo.

Tal vez los CI (Configuration Items) mas comunes y numerosos en una CMDB son los usuarios y ordenadores, precisamente estos CI mas otros como grupos e impresoras son los que sincronizaremos entre el Directorio Activo y Service Manager.

Crear el conector es realmente sencillo como veis en las siguientes capturas:

image

image

image

Podemos seleccionar el dominio y OU a partir de los cuales se realizaran las sincronizaciones, si lo necesitamos podemos tener varios conectores.

También es posible especificar con que cuenta queremos realizar el acceso al AD

image

Por defecto se importaran todos los objetos de los tipos soportados, si queremos podemos seleccionar objetos manualmente.

image

image

image

Los objetos del AD sincronizados se importaran en la CMDB como CIs, en caso de eliminar el conector todos los CIs que no tengan otras relaciones o que no hayan tenido incidencias, cambios, problemas, etc. relacionados serán eliminados de la CMDB.

Una opción que tenemos es la de forzar la sincronización cuando queramos, por defecto el conector se sincronizara automáticamente cada hora.

image

En el panel de “Configuration Items” podéis ver todos los CIs

image

Ahora, ya podemos por ejemplo relacionar una incidencia con su usuario

image

image

image

Al vincular un usuario o un ordenador podemos ver todas sus propiedades rescatadas del AD:

image

Si tenéis cualquier problema con el conector, los eventos están en el registro de “operations manager” en el event viewer del servidor de Service Manager.

image

En un próximo post hablaremos sobre como crear un conector para configuration manager de forma que tengamos para cada equipo toda la información de inventario hardware y software, actualizaciones, etc.

Un saludo.

Crossposting from blogs.technet.com/dmatey

¿Que es el datacenter toolkit for hosters?

 

Cada empresa es un mundo, para todas ellas es interesante algún tipo de sabor mas o menos descafeinado de nube privada, Microsoft es consciente de esto y por eso ha desarrollado un conjunto de soluciones que permiten a cada empresa construir su nube privada de la forma mas conveniente, siendo el punto de entrada mas comun a estas nubes privadas el Self Service Portal 2.0 de System Center Virtual Machine Manager.

Existe un tipo de empresa denominada Hosters, que tiene muchas peculiaridades, por ejemplo mientras que para la mayoría de las empresas un portal de autoservicio es la entrada a la nube privada para sus clientes, los hosters suelen requerir algo mucho mas personalizado y si cabe mas potente a lo que se denomina usualmente panel de control.

El datacenter toolkit for hosters es un proyecto de Microsoft cuyo código fuente esta disponible y que esta orientado a que los hosters puedan a partir de el construir su panel de control de forma rápida en base a este código de Microsoft, lo que reduce drásticamente los costes de desarrollo y el time to market.

El kit permite ofrecer servicios basados en virtualización sobre Hyper-V y gestión basada en system center, además el kit también permite interactuar con otros servicios como el DNS, el directorio activo, etc.

El kit no es una solución para instalar con next-next-next, es un punto de partida, los hosters están acostumbrados a construir y desarrollar portales y por eso esto no supone un problema si no una ventaja que les permite adaptarlo a sus necesidades.

Esto quiere decir que si no tenéis conocimientos de programación el kit no os valdrá de mucho y que seguramente este no es vuestro sitio para empezar con la nube privada, os recomiendo ver el Self Service Portal 2.0 de System Center Virtual Machine Manager que os puede ser de muchísima ayuda sin requerir hacer una sola línea de código.

El kit no es solo interesante para los hosters pues también permite a aquellos que no tengan miedo a la programación o a aquellos que en algún momento requieran una fuerte interacción programática con System Center tener un punto de partida.

¿Como funciona?

Microsoft ha desarrollado una serie de servicios web a los que podemos llamar en base a unos contratos preestablecidos.

Estos servicios web atienden en función del modulo al que pertenecen (SCVMM, SCOM, SCCM, SCDPM) y exponen un montón de métodos que podemos agrupar en 3 grupos:

-Aprovisionamiento

-Administración

-Consultas

Por supuesto los servicios cuentan cada uno con contratos de fallos preestablecidos y con contratos de datos para el intercambio de información.

image

Por ejemplo aquí tenéis un diagrama UML de algunas de las clases del servicio de monitorización

image

¿Como es el interfaz del panel de control?

Como os decía el kit esta mas pensado para que lo personaliceis que para que lo uséis tal cual viene, aun así trae dos ejemplos de panel de control, uno sobre silverlight y otro sobre ASP.net.

Este es un ejemplo del portal silverlight

image

image

image

image

image

image

¿De donde puedo descargar el toolkit?

Puedes descargar el toolkit y toda la documentación desde: http://code.msdn.microsoft.com/ddc/Release/ProjectReleases.aspx?ReleaseId=5127

En cuanto tenga un segundo y lo termine os publico un ejemplo de panel de control en el que estoy trabajando.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Trabajando con Alertas en SCOM desde el punto de vista del operador

 

Es muy común que después de desplegar SCOM, especialmente si nunca antes se ha trabajado con un sistema de monitorización experto, los operadores tengan algún problema en su día a día gestionando las alertas, usualmente estos problemas vienen dados principalmente por no establecer previamente un criterio consensuado por todo el equipo encargado de la monitorización con respecto a como gestionar las alertas.

¿De donde vienen las alertas?

Lo primero y mas importante que tenemos que entender es que SCOM no es sistema orientado a las alertas si no a la monitorización de estados de salud, las alertas son un medio, no el fin.

Si dentro de la consola pulsáis sobre cualquier elemento en rojo, veréis un menú que se llama explorador de salud.

image

Dentro del explorador veis como esta la salud de todos los elementos monitorizados organizados jerárquicamente a partir del objeto que seleccionasteis.

image

Cada uno de los elementos que veis en el explorador recoge su estado de lo que denominamos un “monitor” o bien representa el estado de varios monitores agregados.

Si pulsáis sobre uno de ellos podréis acceder a las propiedades del monitor.

image

Dentro de las propiedades del monitor tenéis la configuración de la alerta, no todos los monitores tienen por que emitir alertas:

image

Así que tenemos que entender que toda alerta viene de un monitor que ha cambiado de estado.

Nota: En realidad las alertas pueden también venir de conectores con otros sistemas de monitorización o de procesos de orquestación, pero eso es otra historia.

Si damos por resuelta/cerrada una alerta que no hemos resuelto, tener de seguro que si el problema sigue pasando el monitor seguirá en rojo y no tendremos de nuevo una alerta hasta que el monitor se reevalué.

Algunos monitores como es el caso del que os estoy enseñando son capaces de resolver ellos solos las alertas, pero no deis esto por supuesto.

Por tanto, la regla mas importante del trabajo con alertas en SCOM es que  NUNCA deis por resuelta una alerta por quitárosla de encima sin haber resuelto el problema y sin revisar los monitores, haciéndolo escondes el problema durante un lapso de tiempo para tener que volver a el mas tarde lo que es frustrante, además haces que la consola de alertas no represente fielmente el estado de los monitores lo que es desconcertante.

¿Como puedo organizar las alertas?

En SCOM existen por defecto dos estados para las alertas, lo cual es claramente insuficiente:

image

Os recomiendo que como mínimo creéis dos mas, aunque podéis establecer los que queráis según vuestro criterio.

image

Como decía, yo suelo crear los estados “En resolución” y “conocido”, notar que el numero o ID es cualquiera libre de los 255 que podéis escoger y que no tiene importancia cual seleccionéis.

En las propiedades de cada alerta hay dos campos que son muy importantes para organizarnos:

image

El campo dueño nos permite indicar quien tiene que trabajar sobre la alerta o quien esta trabajando sobre ella, el campo estado nos facilita un medio de comunicar al equipo si el tema ya esta controlado.

De esta forma nos podemos crear un pequeño esquema de como podemos trabajar en equipo con las alertas de SCOM:

SCOM_Alertas

 

Os recomiendo que personalicéis las columnas de la vista general de alertas a través del menú de la misma de forma que se muestre el dueño de las alertas:

image

image

Ahora de un solo vistazo cualquier compañero que mire las alertas sabe que yo me estoy encargando de esta y que ya estoy en ello.

¿Como puedo crearme una vista con mis alertas?

El mejor sitio es “My Workspace” espacio que ves tanto en la consola de siempre como en la consola web.

image

Crea una vista de alertas

Configura las propiedades de la vista como ves en la siguiente imagen pero con tus parámetros.

image

image

¿Que hago entonces con las alertas con las que no estoy de acuerdo o que no se ajustan a nuestros criterios?

Una cosa buena de SCOM es que cada vez que cargamos un management pack introducimos en el sistema un montón de conocimiento, varemos y reglas ya parametrizadas.

Esto nos quita mucho trabajo y hace el sistema muy potente, sin embargo a veces un management pack puede decir por ejemplo que se nos avise cada vez que una unidad de disco tiene menos del 10% de espacio libre y puede que siguiendo con el ejemplo tengamos algunos servidores donde sabemos que esta condición se da y que no queremos que se nos avise pues conocemos el problema y no lo vamos a solucionar porque para este servidor no es un problema.

En estas situaciones emprender una guerra con SCOM por dar por resuelta la incidencia del espacio en disco es una perdida de tiempo y dejar la alerta no nos ayudara tampoco, cada X tiempo SCOM limpiara solo las alertas antiguas y la alerta volverá otra vez a salir.

La solución es realmente muy simple, solo tenemos que indicarle a SCOM lo que consideramos un problema y lo que no.

La siguiente vez que salga la alerta nos iremos a su monitor de la forma que os he enseñado antes, siguiendo con el ejemplo aquí tenéis el monitor de espacio libre en disco.

image

Nos vamos a la tab de “Overrides”

image

Ahora viene algo muy importante, cada vez que hagáis un override tenéis que pensar muy bien en hacerlo para el menor ámbito posible.

En nuestro caso solo queremos modificar cuando se nos avisa del espacio en disco libre de un disco en concreto de un servidor en concreto, así que seleccionamos la opción que nos permite crear el override limitándolo a ese ámbito que será “For a specific object of class: Windows Server 2008 Logical Disk”

Ahora nos saldrán todos los discos duros monitorizados por SCOM, seleccionar el que nos preocupe.

image

Ahora nos aparecen todos los parámetros del monitor que podemos modificar para este objeto concreto.

Como nosotros no queremos que se nos avise al 10% si no al 5% lo modificamos:

image

Fijaos que abajo del todo en la pantalla nos dice que el override se guardara en el default management pack, mi consejo es que nunca los guardéis ahí y que os creéis un management pack propio por cada uno que importéis para guardar este tipo de cambios.

Insisto en que hay que ser muy cuidadoso con los overrides, hacerlos sin criterio puede implicar que el día que pase algo de verdad no seremos avisados.

¿Como puedo saber todos los overrides que se han hecho?

En los informes tienes uno que te permite ver los overrides que hay activos para cada management pack.

image

Conclusiones:

  • No cierres las alertas sin resolverlas de verdad, si no puedes trabajar ahora con ellas, cámbialas el estado y asígnalas un dueño.
  • Si la alerta no es correcta no la cierres ni ignores, haz un override para que no de mas trabajo ni a ti ni a tus compañeros
  • Ten criterio y piensa dos veces los overrides antes de hacerlos
  • Se consciente de mirar siempre los monitores de salud antes de dar por resuelta una alerta, si algún monitor sigue en rojo, recalcula la salud del mismo desde su menú, si sigue rojo, es que el problema sigue ahí.

Espero que este post os haya sido de alguna ayuda.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Trabajar con unidades de disco sin letra:

 

Me hace una pregunta un amigo que trabaja en un partner desplegando soluciones de virtualización y gestión y como ya me lo han preguntado otra veces voy a contestar desde aquí.

Hoy en día cuando montamos un cluster de virtualización es común usar CSV para poder tener mas de una VM por LUN(Disco).

Sin embargo hay situaciones en las que podemos preferir dedicar una o varias LUN de disco a una VM por motivos de aislamiento, control, rendimiento, por requisitos de algún software, etc.

En estas ocasiones si a cada disco le damos una letra de unidad nos encontraremos con que si el cluster llega a tener muchos casos así, nos quedaremos sin letras de unidad.

Desde hace ya bastante tiempo Windows y por supuesto los clusters nos dejan trabajar con unidades de disco que no tienen letra.

Cuando una unidad no tiene letra, accedemos a ella mediante un identificador único al que llamamos GUID.

Existe el malentendido de que para trabajar sin letras de unidad es necesario inicializar el volumen con el estilo de formato de partición GPT en vez de MBR, deciros que esto es falso y que salvo en maquinas con arquitectura Itanium debéis de dejar el estilo de formato de partición GPT para aquellos volúmenes que vayan a tener mas de 2TB.

image

Para que un volumen no tenga letra solo tendremos que quitársela o no asignársela durante la creación.

image

Para mi la etiqueta del volumen es muy importante, en un cluster es una herramienta clave para tener trazabilidad en los discos desde todas las herramientas, suelo aconsejar que si es un disco SAN uséis la misma etiqueta que hayáis usado en la SAN, si ya además es una etiqueta que nos de información añadida pues mejor que mejor, como por ejemplo la SAN de la que viene, el tipo de discos, etc.

Bien, ya tenéis creado el disco, ¿ahora como accedéis?, desde el disk manager veréis que no podéis abrir la unidad, si vais al explorer la unidad no sale.

Para abrir la unidad lo primero que necesitáis es saber el GUID, para ello abrir el Powershell y ejecutar el siguiente comando:

“gwmi win32_volume|where-object {$_.filesystem -match “ntfs”} |fl Label, name”

image

Selecciona el GUID, cópialo, abre un “ejecutar” y pega el GUID, pulsa OK y tu volumen se abrirá en el explorador.

image

image

Espero que os sea útil.

Un saludo.

Crossposting from blogs.technet.com/dmatey

La CMDB en System Center

 

Puede que alguno no este familiarizado con lo que es la Configuration Management Database (CMDB), permitiros daros una definición: la CMDB es un repositorio de información donde podemos encontrar todos los componentes de los sistemas de información gestionados por un departamento de IT dentro del contexto de ITIL.

Si bien decimos que la CMDB es un repositorio, en realidad podemos también considerarlo un elemento abstracto que puede formarse a partir de información que resida en múltiples bases de datos.

Cualquiera que haya intentado aplicar ITIL en mayor o menor medida, sabe que el éxito de este reto esta estrechamente vinculado a la CMDB, sin esta información será imposible relacionar adecuadamente las actuaciones, solicitudes,  incidencias, problemas y cambios a los elementos de configuración (CI) que se vean afectados por ellos y de esta forma será muy difícil que consigamos la excelencia en el servicio pues no conseguiremos que la información nos sea útil.

Una CMDB que esta viva y descubra automáticamente los CIs, sin tener que empeñar la empresa, meterse en largos proyectos o vivir para ello es el sueño de muchos.

System Center como sabéis esta compuesto de varios productos, cada uno de ellos contiene información tremendamente importante para la CMDB.

En System Center el producto que expone la CMDB, que agrupa el conocimiento de System Center y el directorio activo y sobre la que podemos federar la información de CIs que pueda residir en otros sistemas es System Center Service Manager que además también es el que os permite trabajar con incidencias, cambios, solicitudes, problemas, etc.

El siguiente diagrama os muestra como System Center es sin duda una alternativa que tenéis que valorar si queréis conseguir una buena CMDB de forma fácil.

SM_CMDB 

 

Como veis la CMDB de SCSM esta construida sobre SQL Server e incorpora información de las siguientes fuentes:

  • Directorio Activo:
    • Importa automáticamente la información de usuarios, grupos, computadoras, servidores, impresoras, shares, etc.
  • System Center Configuration Manager
    • Importa automáticamente toda la información de inventario, hardware y software así como gestión de la configuración deseada y cumplimiento de normativas como la ley de protección de datos, etc.
  • System Center Operations Manager
    • Todos los CI monitorizados pueden ser incorporados automáticamente a la CMDB, esto incluye:
      • Cualquier tipo de producto monitorizado sea de Microsoft o no, como por ejemplo routers, servidores linux, bases de datos Oracle, lo que sea.
      • A traves de la conexión entre SCOM y SCVMM todo lo relativo a los CIs relacionados con la virtualización tanto de VMWare como de Hyper-V.
      • Información relativa a backups proviniente de SCDPM
  • A través de System Center Opalis podemos integrar en la CMDB de Service Manager
    • Otras CMDB (HP, IBM, BMC) federando de forma sencilla y trabajando las relaciones
    • Datos de cualquier otra base de datos, sacados de scripts, etc.
  • Finalmente a través del CSV connector del resource kit de SCSM es posible incorporar información a CIs o crear nuevos CIs con información en ficheros separados por comas.

Service Manager se encarga de agrupar los datos de los CIs desde las diferentes fuentes.

Una vez que tengamos los CIs con toda su información en la CMDB de Service Manager ya podremos comenzar a trabajar con ellos.

Espero publicar nuevos posts explicando como instalar Service Manager y como trabajar con los CIs, gestionar incidencias, problemas, cambios, etc.

Espero que os haya gustado el post y que construyáis vuestra CMDB sobre Service Manager.

Un saludo.

Crossposting from blogs.technet.com/dmatey