Resulta que estábamos migrando un servidro físico con sistema operativo Windows 2003 R2 SP2 x86 a un ambiente de virtualización de Hyper-V.

El proceso P2V transcurre correctamente y la máquina virtual es creada sin problema, pero al querer ejecutar la secuencia para poder ingresar credenciales y validarnos, no funciona. Ninguna función del teclado funciona.

Probamos, según otras experiencias, variando opciones del Hyper-V para permitir combinaciones de teclas ALT+…, con vista Full Screen, en lugar de CTRL+ALT+DEL con CTRL+ALT+END y nada de esto funcionó.

La ventaja que tuvimos, es que el virtual switch del servidor Hyper-V podía dar acceso a la red a la pertenecía el servidor físico original. Así que ingresamos a la VM por medio de RDP.

Revisando en el Device Manager, los controladores de Teclado y Mouse estaban alertados. Los desinstalamos, los volvimos a instalar y volvieron a trabajar las funciones del teclado.

Al parecer, en medio del proceso de P2V los controladores quedaron en un estado inconsistente.

Espero esto le sirva a alguien.

Saludos,

Felipe Román

Primero que todo, de este proceso yo sé que hay mucha documentación, pero el caso que les expongo es bastante particular.

• Virtualizador Origen: Virtual Server 2005 SP1 sobre Windows Server 2003 R2 SP2.
• Máquina virtual origen: Windows Server 2000 Standard. Disco de 320Gb SCSI, donde sólo son utilizados 50Gb.
• Virtualizador Destino: Clúster Hyper-V R2 SP1 con Cluster Share Volume.

Las trabas que teníamos para migrar este servidor eran:

• SCVMM no permite máquinas virtuales con discos de sistema SCSI.
• Aunque convirtiéramos el disco de SCSI a IDE, no se puede levantar la máquina en Virtual Server pués este soporta discos IDE de hasta 127Gb.

Ahora sí, cómo lo resolvimos?

1. Instalamos en la máquina virtual este software Magic Server Partition Manager Software – EASEUS Partition Manager (http://www.partition-tool.com/easeus-partition-manager-server/) y con este redujimos la partición sub utilizada. Luego de aplicar los cambios a la partición, el servidor se debe reiniciar y cuando sarranca realiza el proceso, sin entrar al sistema operativo. Al finalizar, se reinicia de nuevo y cuando se ingresa al servidor este tiene un espacio de disco Unallocated.
2. Muy bien, ya quitamos el espacio de disco que no necesitamos, pero aún tenemos un VHD de 320Gb. Pués apagamos el servidor virtual y con la herramienta VHD Resizer (http://vmtoolkit.com/files/folders/converters/entry87.aspx) le quitamos al VHD el espacio que ya no es necesario.
3. Ahora sí estamos listos para convertirlo de IDE a SCSI. Esto lo logramos ejecutando el script que se encuentra en el siguiente enlace: http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/ffc91290-6353-488d-9bce-a267e0292edd/.
4. Luego de este proceso, se varia la configuración del servidor virtual en Virtual Server. Esto para cambiarle el tipo de controlador del disco y direccionarlo al resultante del proceso anterior.
5. Se levanta el servidor virtual, con el fin de verificar que todo este bien antes de migrarlo a Hyper-V.
6. Se agrega el Host de Virtual Server al SCVMM para poder desde ahí administrar las máquinas virtuales que contiene.
7. Se ejecuta el proceso de Migrate normal hacia el clúster de Hyper-V.

Espero esto les ayude en algún momento.

Saludos,

Felipe Roman

Cuando se realiza un descubrimiento de equipos mediante el wizard de SCOM, este pide verificar si el SQL Broker Service está habilitado.

Me dí a la tarea de buscar como conocer este parámetro, dado que es algo propio de la base de datos que se esté utilizando. Para el caso específico de SCOM, se puede validar ejecutando el siguiente script desde el SQL Server Management Studio:

SELECT is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’

Espero que esto les funcione en algún momento, para realizar la validación.

Saludos,

Felipe Román

Resulta que hay muchas maneras de atacar este problema. Este provoca que no funcione el descubrimiento de equipos, instalación de agentes y comunicación de estos con el Management Server.

Algunos dicen que se puede solucionar reiniciando el servicio: Health Service (OpsMgr Health Service), otros reiniciando el servidor, otras soluciones hablan de verificar si el SQL Browser está habilitado en el servidor de SQL Server, entre otras posibles.

Mi escenario específico es:

• Management Server: Windows 2008 R2 SP1 Standard. SCOM 2007 R2.
• Database Server: Windows 2008 R2 Enterprise. SQL Server 2008 SP1 clúster.

Toda la instalación transcurrió sin problemas, por lo que no pensaba en un problema de instalación. Luego de intentar muchas soluciones, comencé a verificar todos los permisos dados sobre sistemas operativos y base de datos.

Encontré que la cuenta de máquina del Management Server no tenía permiso sobre la base de datos OperationsManager, pero sí sobre las bases de datos de Reportes.

Le di permisos a dicha cuenta sobre la base de datos y mi problema se solucionó.

Parece ser que el instalador no terminó de darle permisos a esta cuenta de máquina, aunque parezca increíble.

Espero estos le sirva a alguien.

Saludos,

Felipe Román

Para mañana miércoles 2 de Junio 2010 está programado un webcast, en el que Jeff Wettlaufer (Senior Technical Product Manager, Microsoft Corporation) estaré dando un vistazo general al nuevo release de Configuration Manager llamado: v.Next

Si tienen oportunidad de verlo sería genial, promete estar bien interesante.

Link de evento: Event ID: 1032453445

Saludos,

Felipe Román

Ya que el soporte para Windows 2000 termina el próximo 31 de julio y tanto MDT 2010 como USMT 4 no soportan la migración de Windows 2000 a Windows 7, estos scripts son realmente un alivio para la tarea.

Estos scripts pueden utilizar como destino del respaldo, tanto un recurso compartido en la red como un dispositivo externo, pero ese destino no es asegurado por el script. Contrario a la seguridad que aplica USMT.

De todas formas, es un buen recurso para automatizar este proceso.

Pueden descarga la documentación y los scripts del siguiente link.

Saludos,

Felipe Román

Esta característica está bien interesante.

Es una mezcla de Service Manager 2010, un management pack de la empresa Absolute Software e Intel v.Pro Anti-Theft system lock.

Se puede bloquear un equipo desde la consola de Service Manager por medio de Internet, cuando se presente un robo o el comprometimiento de la información confidencial. Además, se puede bloquear un equipo por medio de un temporizador, sin necesidad de conectarlo a Internet.

Este puede ser nuevamente activado mediante un password específico del equipo o uno generado en el servidor. Por otro lado, se puede colocar un mensaje, para que cuando alguien encuentre un equipo pueda contactar a la empresa dueña del mismo y devolverlo.

Pueden una pequeña demo en este link.

Saludos,

Felipe Román

Ya me ha pasado en dos implementaciones de SCCM 2007 SP2, que de un momento a otro, se dejan de procesar los mensajes de estado y logs no se ven modificados.

Claro, apliqué una de las soliciones que nunca fallan “workaround por excelencia” un reinicio del servidor de SCCM, la cual funcionó. Luego del reinicio, ya los archivos cambian su fecha de última modificación y se procesan correctamente los mensajes de estado.

Ahora bien, esa clase de soluciones no me gustan para nada, por lo que me puse a buscar por todos lados una solución más elegante y parece que la encontré.

Microsoft liberó el 18 de Mayo de 2010 un hotfix que aplica específicamente para este problema. Si tienen este síntoma pueden solicitarlo y aplicarlo en sus ambientes. El artículo es el siguiente: Article ID: 982399

Saludos,

Felipe Román

Para ir un poco más profundo en este tema y luego de comentarles sobre la mejora en la capacidad de Desired Configuration Manager, quisiera contarles sobre otras características de v.Next

Algo que se quedaba retrasado y en lo cual no se veía un cambio significativo en comparación con SMS, era la consola de Administración. Por supuesto que si hubieron mejoras como el panel Actions, pero la consola en su interior era muy similar. Pués bien, con V.Next la consola MMC es reemplazada con System Center UI Framework, lo cual coloca a SCCM al nivel del resto de herramientas de System Center y por supuesto provee una plataforma de administración más flexible. Por ejemplo, permite recibir alertas directamente en la consola y desde ahí abrir el Log.

En la consola, aunque no se tenga acceso a una instancia igual se podría visualizar, con v.Next se verá sólo a lo que se tenga acceso. De hecho se incorporan roles como por ejemplo el de Software Distribution Administrator con los permisos necesarios para que pueda implementar un programa y crear un aviso para una colección.

El rol de Central Site Server, el cual se daba al primer Primary Site Server de la jerarquía se especializa para la administración y reportería, y el resto de trabajo es trasladado a los Primary Site Servers tanto como sea posible.

La mejora en la administración de los Puntos de Distribución en oficinas remotas, por medio de controles de remitente (sender controls) y throttling directamente para los DP’s, entre otras cosas reduce la necesidad de Sitios Secundarios instalados con el fin de distribuir software de manera más eficiente.

Esta me gusta mucho, para la capacidad de Distribución de Actualizaciones de Software se incorpora la opción de creación de reglas para:

• Realizar auto-implementación, por medio de criterios como categoría, producto, lenguage, id de artículo o boletín. Con esto se mejora mucho la administración.
• Por medio de reglas igualmente definir la sincronización y descarga de las actualizaciones.

Por otro lado, existe una integración de características entre SCCM y Mobile Device Manager 2008, que aún no me satisface, por lo que la paso por alto.

Esto que les voy a decir si es importante y es para que nos preparemos para implementar v.Next.

Algunos prerequisitos:

• Todos los site servers y site roles requieren Windows Server x64, con la excepción de los Branch DP’s que pueden ir en cualquier equipo que cumpla con los requerimientos de v.Next y los DP Standard, los cuales pueden instalarse sobre Windows 2003 x32, pero no serán soportadas funcionalidades avanzadas.
• SQL Server 2008 x64
• Hay que moverse a SQL Reporting Services, adiós al Reporting Point estándar.

Podría seguir, pero mejor les dejo el acceso al doc completo: ConfigMgr vNext Overview

Saludos,

Felipe Román

Unas de las capacidades más importantes de SCCM es Desired Configuration Management.

Esta permite confrontar la configuración de una máquina (recurso) contra la definida ya sea en una plantilla de un tercero o la definida por la organización. Por ejemplo, cuando se debe verificar el cumplimiento de un lote grande de servidores o equipos cliente respecto a una regulación.

Una de las debilidades de esta capacidad, es que no existe una manera automática de realizar la remediación del equipo que no cumple. Claro que por medio de colecciones dinámicas, se puede de manera un poco manual lograr en parte ese objetivo.

Pués cuando esté listo el v.Next se podrá:

• Automatizar la remediación por cumplimiento
• Estado de salud del cliente y auto remediación
• Aprovisionamiento de imágenes de sistema operativo off-line

Estas no son las únicas características que se incluyen, además: centralización la gestión de las aplicaciones de usuarios, nueva administración basada en roles, entro otros.

Para más detalle les dejo este link: The next Generation of Client Management

Saludos,

Felipe Román