Winds of change

It's been a while since the last time I updated the blog, and after much thought about the topic I've decided the moment for the change has arrived. Two obvious options arise to me: abandon the blog or keep writing.

If I'm writing this post is because I've decided to bet on the blog once again, but I think that it needs a change of approach. So I would like to start with a new line of work, making a real change of approach. First of those measures I'll take to achieve my purpose is write all my post in both languages, English and Spanish. I'll translate slowly all entries already posted. So I must apologize for my English, I'm quite sure that it will make someone cry.

Vientos de cambio

La verdad es que llevo bastante tiempo sin actualizar el blog, y después de pensar detenidamente sobre el tema he decidido que ha llegado el momento del cambio. Se presentan dos caminos obvios, abandonar el blog o continuar manteniéndolo.

Si estoy escribiendo esta entrada es porque he decidido volver a apostar por el blog, pero creo que necesita un ligero cambio de enfoque, por lo que la nueva linea de trabajo que quiero iniciar irá en este sentido, en hacer realidad ese cambio de enfoque. La primera de las medidas que voy a tomar para conseguir mi objetivo es escribir todas las entradas en Español e Inglés. Iré traduciendo poco a poco las entradas ya existentes. Así que debo pedir perdón por mi nivel de inglés, que seguro que a más de uno le hará saltarse las lágrimas.

One Liner 4: Detección de las interfaces de red desconectadas

Hoy me he levantado "perro", que le vamos a hacer. Tengo que revisar la conectividad de las interfaces de red de mi granja de VMware y no tengo ganas de levantarme a ver las interfaces que tienen problemas físicos, así que he hecho un pequeño One Liner que comparto con vosotros:

Get-VMHost | Sort-Object Name | % { Write-Host -ForegroundColor yellow $_.Name ; (get-view $_.Id).Config.Network.Pnic | Sort-Object Device | % { if ($_.LinkSpeed) {Write-Host -ForegroundColor green ("`t{0} Connected" -f $_.Device)} else {Write-Host -ForegroundColor red ("`t{0} Disconnected" -f $_.Device)}}

La salida del comando es un listado ordenado por nombre de host de las interfaces físicas (pnics) de cada uno de los servidores ESX, donde las interfaces con problemas de conectividad (de cualquier tipo) aparecen en rojo y las pnics operativas aparecen en verde.

Como veis, no es nada del otro mundo, pero te quita de un viajecito al CPD con la libretita de marras contando interfaces y cablecitos.

Lo dicho, que me he levantado "perro"

Despiste 9: Cambiar de usuario en los servicios de vCenter

Este quizá sea uno de los despistes más clásicos, típicos y que dan más coraje de sufrir, sobre todo cuando es la tercera o cuarta vez que le ocurre a uno. A ver, os pongo en situación: uno se pone a hacer el despliegue de una nueva plataforma de vSphere (migración o no) con toda la ilusión del mundo, instala su servidor de base de datos, prepara la base de datos, monta el que va a ser el servidor de vCenter, configura su DSN, instala el software correspondiente (vCenter, Update Manager, Guied Consolidation, etc...), se instala su vSphere client, añade sus hosts y hace las primeras configuraciones de prueba y... Voilá!! todo perfecto, una maravilla, una pasada... (aquí van todos los calificativos que se os ocurran).

En este punto uno reflexiona y dice: "vale, lo he instalado todo con un usuario que es administrador del dominio y esto al de seguridad (o sea YO) no le va a gustar nada, así que vamos a securizarlo un poco" . Activamos el cortafuegos, autorizamos los puertos correspondientes (80, 443, 389,636, 902,903, 8084, 9084 y 9087), revisamos las cuentas de servicios y nos encontramos con la desagradable "sorpresa" (no es tan sorpresa porque el programa de instalación ya nos lo advirtió) de que la cuenta de servicio asociada a los servicios VMware VirtualCenter Server y VMware VirtualCenter Management Webservices tiene asociada la cuenta de administrador con la que hice la instalación (mal royo). Como administradores preocupados por la seguridad vamos y cambiamos la cuenta de servicio por una cuenta sin privilegios que tenemos en el dominio para este tipo de cositas. Vamos a iniciar los servicios de nuevo y... yastá, yalaliaopardadiosmiodemivida!!!! el servicio de VMware VirtualCenter Server no arranca dando un simpático mensajito de error del tipo:

Failed to init tableDef: Column VER_ID does not exist in table VPX_VERSION. Database version may be incompatible.

El problema está en que la cuenta que está autorizada en el servidor SQL Server es la de la instalación original, con lo cual tendremos que toquetear la base de datos. El procedimiento no es original mío, lo he sacado de las communities de vmware, así que podeis ver el post original aquí (en Inglés).

Para los que no queráis traducir, básicamente los pasos a seguir son los siguientes:

1. Abrir el SQL Server Management Studio
2. Buscamos la base de datos de VMware. Si hemos seguido al dedillo el manual de instalación esta será VCDB
3. Navegamos por el árbol de la base de datos hasta VCDB->Seguridad->Esquemas->db_owner
4. Abrimos las propiedades del esquema y le cambiamos el valor del parámetro Propietario del esquema del valor original <vcuser>(el de la instalación inicial) a dbo
5. Eliminamos el usuario <vcuser> de la base de datos. Eso lo podemos encontrar en VCDB->Seguridad->Usuarios. Cuidado de no eliminar el login del servidor con el que se mapea ese usuario.
6. Abrimos una nueva ventana de consulta SQL
7. Lanzamos la siguiente consulta, cambiando <vclogin> por el nombre del nuevo usuario de la cuenta de servicio que le hemos asociado a los servicios de VMware:
1. EXEC sp_changedbowner @loginame = ‘<vclogin>’, @map = ‘true’ 
8. Iniciamos los servicios afectados en el servidor de vCenter
9. FIN

Espero que este POST os ahorre los dos días de dolores de cabeza que me ha llevado a mi solucionar el "problemita"

Despiste 8: Obtener el listado de certificados de una máquina remota

En esta ocasión os dejo un script para obtener el listado de los certificados digitales instalados en el almacén de equipo de una máquina remota. No hay una forma simple de hacer esto con powershell, así que rompiendome bastante la cabeza y navegando por un montón de foros he ido cazando piezas de otros scripts y trozos de código en otros lenguajes para crear este pequeño (aunque creo que útil) script.

El script toma como parámetros el nombre de máquina a la que conectarse (-computerName) y el almacén al que conectarse (-store). Las opciones válidas para el almacén son:

• "Root": para el almacén de certificados raíz de confianza
• "My": para el almacén del certificados personal
• "CA": para el almacén de certificados de entidades emisoras de certificados intermedias
• "TRUST": para el almacén de certificados de confianza empresarial

Es necesario lanzar el script con privilegios de administrador sobre la máquina remota.

Me gustaría también comentaros que el script está en fase alpha y es inestable, por lo que no os puedo asegurar al 100% que funcione en todas las ocasiones, aunque a mí me ha funcionado.

Aquí os dejo el link para que podáis descargar el script: Get-RemoteCerts.ps1

Ver también: social technet

Despiste 7: Aumentar el periodo de evaluación de Windows Server 2008

Seguramente no soy el único que monta servidores Windows 2008 para hacer su pruebas antes de pasar a mayores. El problema de tener estos servidores es que si queremos cumplir con la legalidad debemos instalarle su correspondiente licencia, pero lo cierto y verdad es que a nadie le hace mucha gracia tener que duplicar los costes de licencia simplemente por tener una plataforma para hacer el bestia.

Como sabreis, el periodo evaluación de los Windows Server 2008 (cualquier versión) es de 60 días, pero si ejecutamos el comando slmgr.vbs -rearm, podremos resetear este periodo de evaluación hasta en tres ocasiones más, contando con un periodo de evaluación total de 240 días.

Despiste 6: Cambiar el canal de licencia de un Windows XP

Bueno, después de algún tiempo si escribir nada, ya va siendo hora de ponerse a "currar" un poquito :).
Este quizás sea uno de los problemas clásicos a los que la mayoría de los administradores Windows nos hemos enfrentado en alguna ocasión, la reactivación de la licencia de un windows XP después de un clonado o una virtualización.
A ver, os pongo un poco en antecedentes para que podáis tener una perspectiva completa del problema al que me ha tocado enfrentarme en esta ocasión. Como ya os he comentado en alguna ocasión, me toca administrar una plataforma de VMware más o menos grande, en la que además utilizo VMware View. Pues bien, como era de esperar tenía que llegar el momento en el que se empezaran a virtualizar los escritorios de los usuarios. Si la virtualización de estos escritorios se hiciera desde cero, esto no supondría ningún problema, lanzamos el converter, le decimos la máquina que queremos importar, esperamos un "ratito" y ... voilá, PC virtualizado y listo para ser utilizado.
¿Donde está el problema entonces?, pues en que evidentemente no vivimos en un mundo ideal y que la virtualización de escritorio que se pide es la de los PCs de usuarios que ya tienen instalados, configurados y personalizados a su gusto. Si tenemos mala suerte nos podemos encontrar en el siguiente caso: El PC de usuario tiene un WindowsXP preinstalado (OEM) y queremos virtualizarlo. En este punto me gustaría hacer un pequeño inciso y aclarar un poco los canales de licenciamiento de Microsoft.

Microsoft cuenta con tres canales de licenciamiento:

• OEM, una licencia de coste reducido que se obtiene cuando compramos un ordenador con Windows PreInstalado. Esta licencia está asociada al hardware y no se puede reutilizar en otro hardware diferente.
• Retail (RTL), es la licencia que adquirimos si compramos el software original para instalaciones limpias o actualizaciones. Existen ciertas restricciones en cuanto al movimiento de licencia si hemos adquirido un software de actualización.
• Volume License (VLK), es la típica licencia corporativa donde con una única clave de producto podemos licenciar un gran número de equipos.
  

Pues bien, el problema se presenta cuando hemos instalado Windows XP con un CD de instalación OEM y después de haberle pasado el sysprep y haberlo virtualizado (para los clones pasa lo mismo) intentamos licenciarlo con una clave VLK o RTL. La solución a este problema pasa simplemente por obtener un cd del canal de licenciamiento apropiado y hacer una reparación del sistema desde el CD de instalación, es decir, arrancando desde el CD e iniciando el proceso de instalación, pero en lugar de machacar la instalación antigua, le decimos que la repare. Tened cuidado de no entrar en la consola de reparación que nos ofrece al principio el programa de instalación.

Tened cuidado en el caso de las máquinas virtuales, que la controladora SCSI que configura VMware por defecto no viene soportada por el programa de instalación de Windows XP, así que tendreis que añadir el controlador de forma manual.

Referencias:

Determinar el canal de licencia de un CD

Información ampliada de los canales de licencia

Driver SCSI de VMware para la instalación de Windows XP