Ya está disponible Windows Server 2022

 En silencio, sin publicidad, Microsoft anunció en su blog la disponibilidad general de su nuevo sistema operativo para servidores, Windows Server 2022. No es la versión RC, es la versión definitiva, LTCS, con sus habituales 5 años de soporte y 5 años extendidos

Esta nueva versión llega en 3 versiones diferentes, como la anterior edición. Si Windows Server 2019 vino con las versiones Essential, Standard y Datacenter, Windows Server 2022 viene con las versiones Essentials, Standard, y Datacenter, aunque se comentó una Datacenter Azure Edition, pero no aparece en la pagina de precios (la agrego más abajo). 

Está claro que esta nueva versión permitirá una conectividad total con herramientas y funcionalidades de Azure. Para ello, traen Azure Arc, que ayudará a simplificar la administración de distintos entornos con los que se pueda trabajar, ya sea multicloud, entorno on-prem, o hibrido. También se potencia la herramienta Admin Center que nos lleva acompañando desde Windows Server 2016, mejorando su gestión con VMs.

Se ha mejorado la compatibilidad de hardware, así como la cantidad máxima de recursos que puede gestionar, llegando ahora a 48 TB de RAM y 2048 núcleos lógicos sobre 64 sockets

Luego hay mejoras varias en el uso de contenedores en todas sus facetas, e indican que también están trabajando fuerte en la mejora de compatibilidad, gestión y rendimiento de su AKS (Azure Kubernetes Service)

En temas de seguridad también hay avances, como una mejora del protocolo HTTPS con un cifrado AES-256 y soporte para el protocolo SMB con compresión en tránsito

Para ir comenzando las pruebas con Windows Server 2022, podemos realizar la descarga desde su Centro de Evaluación de Windows Server.

O bien podemos ir al Centro de Servicios de Licencias por Volumen, si somos clientes de licencias.

La página de precios por ahora muestra solo las versiones Essentials, Standard y Datacenter, ni rastro de la Datacenter Azure Edition (pero dejo enlace de esta versión, de la propia Microsoft, para que veáis que no me lo invento). También puedo ir adelantándolo:

Click para ampliar

Adjunto también un enlace al Evento de Presentación de Windows Server 2022 el 16 de Septiembre. Por supuesto, online.

Agregar el servicio COM+ en Windows Server 2016

Lo primero de todo: ¿qué es COM+?

COM+ (Component Object Model: modelo de objeto componente) es una tecnología de Microsoft cuya finalidad es posibilitar la interconexión de procesos entre si y ofrecer un entorno de desarrollo de objetos (aplicaciones). COM+ no es más que una extensión de COM y este servicio es el que se encarga de gestionar los procesos y aplicaciones basados en esta tecnología. Aunque el servicio sigue presente tanto en Windows Vista como en posteriores, parte de las funciones de COM están siendo sustituidas por Microsoft .NET y por Windows Communication Fundation. Viene bien explicado en este LINK.

Entonces, ¿para qué lo queremos instalado en el servidor? Por lo de siempre en el entorno Microsoft, no hay obsolescencia, las aplicaciones duran décadas. Aunque las aplicaciones ya no hagan uso de esta extensión, al estar incluidas en otros elementos como .NET, las aplicaciones antiguas siguen requiriéndolo. Y hasta Windows Server 2012 es fácil instalarla, solo tenemos que seguir los siguientes pasos:

Desde instalación de Roles y Características, agregamos el rol de Servidor de aplicaciones,

Y posteriormente en los servicios del rol, Acceso a red COM+

Como decía, hasta W2K12 R2, es facil. El problema viene a partir de Windows Server 2016. El servicio ya está obsoleto, y Microsoft no lo incorpora en sus nuevas versiones de Windows. Entonces, ¿Cómo instalarlo?

Podemos instalarlo en dos pasos:

1º Habilitamos el "acceso a red COM+" en el firewall de Windows. Para ello, le damos acceso en la ventana de "apps permitidas" en el firewall:

2º Modificamos el registro. Para ello, vamos a la siguiente subclave: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3. Allí, hacemos doble click en la clave RemoteAccessEnabled y cambiamos su valor a 1.

Con esto, ya tenemos el servicio funcionando en las nuevas versiones de Windows.

Si te ha gustado el articulo, puedes invitarme a un café  ;)

Repite conmigo: los snapshots no son backups

Estamos en 2021, hace 11 años apareció ESXi 4.0. Entonces ya hacia snapshots, y por aquella época, se consideraban una forma de backup. Esto cambio en torno a 2014, con ESXi 5.0. Entonces los snapshots eran un medio de tomar una foto al equipo en un momento dado, para revertir pequeños cambios, pero de ninguna manera podían considerarse ya como copias de seguridad.

¿Y por qué este mini salto en el tiempo en referencia a los snapshots de VMware? 

En una charla sobre limpieza de snapshots todavía a estas alturas me indicaban que un snapshot es un backup. Que es lo que hacen las compañías de backup, un snapshot, que copian a su sistema. Y si, eso es lo que hacen, pero...¿y si se corrompe el vmdk original? Solo por poner solo un ejemplo. La respuesta es que el archivo delta del snapshot no te sirve de nada. Se pierde la VM.

Pero la mejor forma de demostrar estas afirmaciones es con hechos y documentación, y a ello vamos:

VMware

Para ello os dejo el siguiente LINK, de las best practices de VMware. Primer punto de las best practices: Do not use VMware snapshots as backups. Se puede decir mas alto, no mas claro. Ya de paso, es bueno seguir el resto de recomendaciones. Si bien originalmente los snapshots se vieron como backups, al ser algo revolucionario en sus origenes, con el tiempo, se consideran solo como solución de seguridad para una marcha atrás rápida. Por ejemplo, un parcheo fallido.

Veeam

En el siguiente articulo de Veeam explican muy bien las razones por las cuales un snapshot no es un backup. Aquí el LINK, y a continuación un breve spoiler: no es un backup principalmente por la razón indicada al comienzo: Sin una copia de todos los archivos originales que componen la VM, una corrupción o perdida de uno de estos hacen que el snapshot sea inútil. La propia Veeam reconoce que hacen uso del sistema de snapshots para sus copias, pero que se trata la copia completa de la VM como una Full, y posibilidad total de restores, mientras que los snapshots se consideran copias incrementales. Adicionalmente, dejan muy claro que cada snapshot es un SPOF en si mismo. Y por supuesto, la frase: It is important to note that the snapshot by itself is not a backup

Veritas

Esta compañía tiene solera en el tema del software de backup. Cuando empresas como Vembu, Veeam o Nakivo ni siquiera existian, ellos ya eran los "Windows" del sector de backups. Al grano, LINK, y paseo al punto 6 de los backups en vSphere. De nuevo, Snapshots are not backups. Luego agregan que, y traduzco, "las instantáneas de máquinas virtuales, si bien son útiles, nunca deben usarse como su medio principal de respaldo. Las instantáneas están bien para copias de seguridad a corto plazo de máquinas virtuales, pero tenga en cuenta que incurrirá en sanciones cada vez que las utilice". Con sanciones entra en una serie de problemas que indica vmware en sus best practices relacionadas con el rendimiento.

Vembu

Ya que les he mencionado, les agrego. LINK. Aunque no dicen explícitamente que los snapshots no son backups, sí dicen que no son una solución completa, sino que son un complemento, y que una copia incemental la consideran un snapshot, no un backup. De hecho, hay una parte de su documento muy correcta: While performing a backup you want your backup to be independent of your Virtual Machine that you are safeguarding.

Como se puede ver, todas las soluciones toman el snapshot como una especie de copia incremental que debe desaparecer en el tiempo, y ninguna lo toma como una solución válida ni segura. Y todas inciden en la copia completa de los archivos de la maquina, a otra ubicación no dependiente del sistema que la sostiene. Lo que viene a ser un backup de toda la vida de los archivos, vaya.

Si te ha gustado el articulo, puedes invitarme a un café  ;)

Mover múltiples usuarios a una OU

 Aquí dejo un script para poder mover un listado de usuarios, ubicados en cualquier OU, a la OU que se indique. Muy cómodo si tienes usuarios desperdigados por todo el directorio activo con alguna característica identificable, como por ejemplo que estén deshabilitados, o creados en una fecha determinada. 

Se puede hacer una búsqueda previa, y generar un listado con ellos. Posteriormente, con este script movemos dichos usuarios. 

Ahí va:

# Import AD Module Import-Module ActiveDirectory # Leemos los usuarios del archivo para meterlos en una variable $Archivo = get-content -Path "C:\Users.txt" # Se especifica la OU a la que quieres mover los usuarios $TargetOU = "OU=Old Users,OU=User Accounts,DC=midominio,DC=com" $Archivo | ForEach-Object { # Obtiene el DN del Usuario $UserDN = (Get-ADUser -Identity $_).distinguishedName Write-Host "Moviendo cuenta... ." $userDN # Mueve el usuario a la OU indicada Move-ADObject -Identity $UserDN -TargetPath $TargetOU } Write-Host "Movimiento de usuarios completado"

Y con esto tenemos el movimiento hecho, de todos los usuarios dentro del archivo users.txt.

Peculiaridades:

• En el archivo de texto  debe ir un UserDN por linea (el ID con el que hacen login).
• El "Write-Host "Moviendo cuenta... ." $userDN" es un "punto de control" que muestra el usuario que va procesando el script, por pantalla. De esta manera, se puede eliminar, pero asi tienes idea por pantalla de por donde va, sobre todo si el listado lo has organizado por orden alfabetico.
• Igualmente el  "Write-Host "Movimiento de usuarios completado"" es por dejar el script finalizado mostrando algun tipo de aviso en pantalla. Saber que ha finalizado despues de ejecutar el bucle.

Si te ha resultado útil el articulo, puedes invitarme a un café  ;)

Localizar software instalado en servidores con PowerShell

Vamos as ver cómo localizar software instalado en servidores, o equipos en nuestra red, a partir de PowerShell y el uso de WMI.

Partimos de la premisa que no tenemos una herramienta más potente para estas labores de detección e inventariado como SCCM, que nos permite sacar unos informes más completos que solo el nombre de la aplicación. 

El script es el siguiente:

$list = get-content c:\listadoservidores.txt

foreach($PC in $list){

    $data = Get-WmiObject -ComputerName $PC -Class Win32_Product | sort-object Name |

    Select-Object Name | Where-Object { $_.Name -like "*Zoom*" -or $_.name -like "*McAfee*"}

    if($data){

            Write-Output "$PC tiene $($data.name) instalado" |

            out-file c:\temp\maquinasconsoft.txt -Append

    }

}

Si, es el tercer post con un bucle foreach, lo siento... Pero vamos con la explicación del funcionamiento.

Con el $list = get-content c:\listadoservidores.txt metemos en la variable $list el listado de las máquinas que queremos analizar. Otras opciones válidas serian por ejemplo, $list = 'server1','server2' o bien $list = Get-ADComputer -Filter * lo que nos permitiria directamente meter en la variable realizando la búsqueda de maquinas con filtrado directamente en AD.

Luego, desde el foreach hasta la linea del write-output tenemos la búsqueda en si. Es importante indicar que la búsqueda con el parámetro -like y los ** nos permite buscar un nombre que contenga la palabra indicada, no es necesario que sea el nombre completo. Eso si, si se meten varias aplicaciones a buscar, el script te dice si ha encontrado algo o no, pero ni especifica cual, asi que normalmente del -or hasta el } suelo eliminarlo, dejando un solo término.

Finalmente, el  out-file c:\temp\maquinasconsoft.txt -Append lo que hace es indicar en el fichero de salida "maquinasconsoft.txt" en qué maquinas ha encontrado el software instalado. En estos bucles es importante agregar el -append, porque si no, cada ejecución del bucle machaca el archivo, mostrando finalmente sólo la ultima vuelta. En cambio con -append va incorporando, sin machacar el texto previo.

Workaround para Vulnerabilidad 0Day Microsoft Windows Print Spool CVE-2021-1675

 Se ha encontrado una vulnerabilidad 0 Day calificada como crítica que afecta al servicio print spooler que permitiría ejecución de código remoto y escalada de privilegios sobre los servidores. Los datos sobre la vulnerabilidad podéis encontrarlos AQUI.

 Por suerte, es una vulnerabilidad que solo afecta al servicio de impresión, que no tiene por qué estar funcionando en aquellos servidores que no ejerzan específicamente este rol.

Por eso, la mejor solución hasta que aparezca un parche de urgencia, y después, porque no tiene sentido dejar servicios corriendo sin uso, es parar y deshabilitar el servicio de impresión allí donde no se utilice.

Para eso, podemos basarnos en el script de mi anterior post. Partimos de que tenemos un listado de las máquinas donde no debe por que estar corriendo el servicio. Después, ajustamos el script para que lea ese archivo:

$archivo = get-content c:\ficheromaquinas.txt

foreach ( $equipo in $archivo ) {

write-host $equipo

Get-Service -Name spooler -ComputerName $equipo  | stop-Service

Get-Service -Name spooler -ComputerName $equipo  | Set-Service -Status stopped -startuptype disabled

} 

Mismo procedimiento de siempre... se mete en un bucle lo que necesitamos ejecutar ,que es, primero una parada del servicio con "Get-Service -Name spooler -ComputerName $equipo  | stop-Service", y luego lo deshabilitamos, lanzando practicamente el mismo comando pero deshabilitando, con "Get-Service -Name spooler -ComputerName $equipo  | Set-Service -Status stopped -startuptype disabled". No le sienta bien al servidor todo del tirón.

¡Cuidado con dejar saltos de linea en el archivo del que toma las maquinas! No pasaría nada realmente, mas allá de un error al final, o allí donde dejemos el salto de línea.

Tratar el contenido de un archivo en Bucle con PowerShell

 A veces es muy útil realizar acciones a partir de algún archivo de datos... Por ejemplo, buscar alguna característica de un listado de equipos o usuarios que te pasan en algún excel, o similar. Bueno, vamos a ver cómo leer un archivo en PowerShell para luego utilizarlo en un bucle. La función es simple, pero lo importante es entender el proceso. 

El script es el siguiente:

$archivo = get-content c:\ficheromaquinas.txt

foreach ( $equipo in $archivo ) {

write-host $equipo

Get-Service -Name spooler -ComputerName $equipo  | Set-Service -Status Running

} 

 La primera línea, $archivo = get-content c:\ficheromaquinas.txt lo que hace es meter en una variable con el nombre "archivo" todo el contenido que hay en el documento "ficheromaquinas.txt" Powershell permite tratar esa variable, que se pasa a llamar $archivo como un único objeto.

El segundo fragmento:

foreach ( $equipo in $archivo ) {....} 

Lo que hace es decir que para cada nuevo elemento que se encuentra en archivo, al que pasaremos a llamar "equipo" haga lo que metamos dentro de las llaves.

Dentro de las llaves hemos metido un script muy simple, 

Get-Service -Name spooler -ComputerName $equipo  | Set-Service -Status Running

Que lo que hace es que mire el servicio spooler (la cola de impresión, vaya) de cada equipo, que metimos en la variable $equipo, y lo arranque, canalizando el comando con el "|" y le pase la orden  Set-Service -Status Running, para arrancarlo.

Igual que podemos obtener ese servicio, podemos hacer lo mismo con, por ejemplo un apache, Oracle Service, RDP...lo que sea, y sólo de las máquinas que tenemos en el archivo. Pero lo importante es el hecho de meter el contenido del archivo en una variable, para a partir de ahí, con un "foreach", pedirle que haga una acción.