Tales from a Solution Architect vMotioning from Solution Engineering to Solution Architects

Conexiones a SQL Server desde Powershell

Desarrollando scripts para mi actual empresa, me he visto en la necesidad de añadir datos a un SQL Server desde Powershell (sin poder utilizar las herramientas de SQL Server, como sqlcmd). Todo esto implica entrar en el mundillo de .Net y conjugarlo con Powershell para poder realizar labores de reporting, siendo increíblemente potente:

Primero haremos un script que nos permitirá probar si esto realmente funciona o solo os estoy vendiendo humo :)

$servidor = "10.1.0.2"
$database = "smoke"
$usuario = "smokeUser"
$password = "SomeRandomP@ssword"

$connectionString = "Data Source=$Servidor;Initial Catalog=$database;Connect Timeout=3;User ID=$usuario;Password=$password"
$sqlConn = new-object ("Data.SqlClient.SqlConnection") $connectionString
trap
{
Write-Error "Cannot connect to $servidor.";
continue
}
$sqlConn.Open()

if ($sqlConn.State -eq 'Open')
{
$sqlConn.Close();
"Opened successfully."
}

Bien! Esto funciona y no todo es humo... Vamos a pasar a la parte más divertida, que es la de introducir los datos a la DB correspondiente.

Cogeremos y modificaremos el código antes puesto:

$connectionString = "Data Source=$Servidor;Initial Catalog=$database;Connect Timeout=3;User ID=$usuario;Password=$password"
$sqlConn = new-object ("Data.SqlClient.SqlConnection") $connectionString
trap
{
Write-Error "Cannot connect to $servidor.";
continue
}
$sqlConn.Open()

$sqlQuery = $sqlConn.CreateCommand()
$sqlQuery.CommandText = "INSERT INTO dbo.Tabla (Ok) VALUES ('SI')"
$sqlQuery.ExecuteNonQuery()

$sqlConn.Close()

Ejecutamos y... bingo :) si todo va bien, desde línea de comando nos devolverá un "1" como output, lo que significa que hemos introducido correctamente el valor en la tabla. Esto nos abre un mundo de posibilidades, como poder adjuntar el log de nuestros scripts en un SQL Server, por ejemplo.

Hasta aquí este post, espero que lo disfrutes :)

Windows Server 2012 R2, NLA y cambios de contraseña

Recientemente me he encontrado con una incidencia usando Windows 2012 R2 entre dos dominios sin relación de confianza (por ejemplo remote.local y office.local), estando el usuario en office.local y el equipo en remote.local

Esta es una incidencia por la que de repente una cuenta no podía acceder, haciendo referencia al críptico mensaje de "The Local Security Authority cannot be contacted". Revisando el event viewer veo que el login es erróneo, pero en la razón da una pista:

Failure Information: Failure Reason: The specified account's password has expired. Status: 0xC0000224

Así que raudo y veloz cambio la contraseña extrañado porque no haya presentado el proceso de cambio de contraseña al que todos estamos acostumbrados. Le reseteo la contraseña y el usuario intenta acceder de nuevo. Nada, cero. Sigue sin funcionar.

Tras un troubleshooting detallado (todo tan serio como resetear la contraseña otra vez y probar yo), veo que sigue sin funcionar. Creo una cuenta con los mismos permisos y funciona correctamente. Esto ya empieza a ser desesperante. Y de repente se me enciende la bombilla, recordando una KB de Microsoft que leí hace tiempo ( https://support.microsoft.com/en-us/kb/2648402 ) que arrojó la solución que necesitaba:

To work around the issue, use one of the following methods:

Disable the Allow connections only from computers running Remote Desktop with Network Level Authentication option on the RD Session Host server.

Change the password of the user account by using a different method.

El problema radica en que por defecto el remote desktop viene con el Network Level Authentication activado, con lo que CredSSP por diseño no tiene contemplado poder cambiar la contraseña del usuario:

In the protocol specification for CredSSP, there is no reference to the ability to change the user's password while NLA is running. Therefore, the observed behavior can be considered "by design."

Tras esto, solo quedó activar una GPO que desactivara el NLA en los servidores de Remote Desktop.

Empezando con Docker y VMware Photon

Esta semana VMware ha dado un paso adelante en el mundo de los contenedores, publicando VMware Photon, una distribución linux super-ligera (mismo estilo que CoreOS) enfocada a trabajar con contenedores (docker,rkt...) y LightWave, una solución de gestión de identidades para estos contenedores, que sinceramente están muy que muy interesantes.

Ahora quiero empezar a tocar el mundo de Docker debido a un nuevo proyecto en el que me estoy embarcando y qué mejor manera que empezar usando Photon.

Podemos descargarnos la imagen desde aqui y revisar el repo en https://vmware.github.io/photon/ donde van subiendo el nuevo contenido.

Procedemos a instalar la ISO en nuestro software de virtualización (en este caso yo estoy usando VMware Fusion), donde solo tarda 40 segundos, y eso siendo la versión completa. Os recomiendo seguir la guía de VMware

Una vez hecho esto, podemos proceder a encender la máquina virtual y conectarnos a ella por la Remote Console, donde habilitaremos el acceso por el usuario root (no hagas esto en producción, niños) y añadiremos nuestra clave en el listado de authorized_keys del daemon ssh. Por defecto Photon lleva nano como editor de texto, pero podemos añadir vim con el siguiente comando:

tdnf install vim

Una vez hecho esto añadimos nuestra clave pública dentro del usuario root con los siguientes comandos En Photon:

 mkdir .ssh

En nuestro host:

cat .ssh/id_rsa.pub | ssh 172.16.32.159 -l root 'cat >> .ssh/authorized_keys' 

Tras esto ya podremos loguearnos sin contraseña al entrar con el usuario root. Una vez hecho esto, toca meterse con Docker, pero en este artículo lo único que haremos será arrancar un contenedor de Ubuntu 14.04 con Bash :)

docker run -t -i ubuntu:14.04 /bin/bash

Et voilà! Hemos levantado nuestro primer docker. En próximos artículos entraremos más en detalle :)

Como calcular vCPUs y vRAM provisionadas en un cluster de VMware

Muchas veces nos preguntamos cuantas vCPUs tenemos provisionadas para mantener la contención controlada, al igual que la RAM que tenemos provisional (que no activa) en las VMs. Desde la PowerCLI de VMware podemos ejecutar lo siguiente:

Memoria RAM provisionada

(get-datacenter virtualdatacenterName | get-cluster | get-vm | measure-object 'memoryGB' -sum).sum

vCPUs provisionadas

(get-datacenter virtualdatacenterName | get-cluster | get-vm | measure-object 'numcpu' -sum).sum

Con esto, obtentendreis los valores :)

vRealize Automation - Desplegando vRealize Appliance

En este post, procederemos a desplegar la appliance vRealize, tal y como hicimos con la Identity Appliance. Los datos de esta appliance en mi caso son los siguientes:

  • Dirección IP: 192.168.1.246/24
  • Gateway: 192.168.1.2
  • Hostname: vcac.vfondevilla.local

Tras haber desplegado la appliance, nos conectaremos a la VAMI de la misma (https://vcac.vfondevilla.local:5480) y pincharemos sobre vRA Settings En Host Settings marcaremos la opción de Resolve Automatically para que nos rellene el campo con el hostname y Generate Certificate que rellenaremos con los campos que creamos convenientes vRA setup

Aplicaremos los cambios y procederemos a configurar la parte de SSO con el hostname vcac-identity.vfondevilla.local vRA setup

Aceptamos el certificado de la vcac-identity y debería salirnos en verde con el estado Connected. En este paso pueden pasar varios minutos, paciencia vRA setup vRA setup

Metemos la licencia de la aplicación (obviamente aquí no pongo captura de pantalla :)) y esperamos unos minutos mientras aplica los cambios en el sistema.

Tras estos pasos, mirar que en la pestaña Services aparecen registered por lo menos los siguientes:

  • authorization
  • authentication
  • eventlog-service
  • shell-ui-app
  • branding-service
  • plugin-service

Tras esto solo queda acceder a https://vcac.vfondevilla.local/vcac y loguearse con los datos del SSO que se configuraron en el despliegue de la Identity Appliance, para comprobar que la parte de la gestión de vRA está operativa, solo nos quedaría la parte del IaaS, que trataremos en la siguiente parte.