miércoles, 30 de noviembre de 2022

Solventar el error en VMware "the ovf package is signed with an invalid certificate"

 Seguro que os ha pasado alguna vez que desplegando un OVA os encontráis con el siguiente aviso:

Esto es debido a que, como bien dice el mensaje, el certificado que está incluido no es válido por algún motivo. Una faena que no tiene remedio si por ejemplo, no hay una nueva version para una OVA concreta, o hay que utilizar una versión específica que por antigüedad, trae el certificado caducado.

Tenemos una solución para esto, facilitada por una herramienta de VMware: las OVF Tools, disponibles en este enlace: https://code.vmware.com/tool/ovf/4.1.0

Una vez hagamos login en la web de vmware para su descarga, descargamos la versión que más nos interese,


Instalamos,


y ejecutamos con el siguiente comando:

C:\Program Files\VMware\VMware OVF Tool>ovftool --acceptAllEulas <SOURCE_OVA.OVA>  <DESTINATION_OVF.OVF> --skipManifestCheck

Puede pasar que de fallo el agregado final, en cuyo caso, también parece funcionar sin esa sentencia:

Finalmente, genera la imagen:



Hay otra solución que se muestra válida, y es realizar la importación desde la interfaz html5. Avisa del certificado inválido, pero permite continuar:



Ambas soluciones son efectivas.

domingo, 20 de noviembre de 2022

Tenemos de nuevo VMware Converter

 El 2 de febrero de este año nos llevamos un susto considerable cuando VMware retiró de su zona de descarga VMware Converter. La razón es que el producto no se actualizaba desde 2018, y el soporte oficial finalizó en diciembre de 2019. Por estas fechas teníamos nuevos productos llegando como vSphere 7 por parte de VMware, y la llegada de un nuevo SO no soportado como Windows 11. Luego le sumamos la llegada de Windows Server 2022, y tenemos las razones oportunas para su retirada, con el fin de preparar un producto acorde al mercado, y a la calidad a la que nos tiene acostumbrados VMware.

En Septiembre VMware nos dio la sorpresa liberando la RC para pruebas, versión VMware-converter-en-6.3.0-20451666, y tan solo un mes después, publicando la nueva versión oficial, VMware-converter-en-6.3.0-20575345.

Cosas a tener en cuenta:

No permite actualización de la version antigua. As ique mejor, desinstalar, e instalar la nueva versión.

Importante: Converter 6.3.0 no admite version de de hardware virtual superiores a la 11. Para versiones de hardware superiores a la 11, ten en cuenta que las funciones de hardware se liminaran a la version 11

Puede instalar VMware Converter Standalone 6.3.0 en las siguientes plataformas:
  • Windows Server 2012 (64 bits)
  • Windows 8.1 (32 bits y 64 bits)
  • Windows Server 2012 R2 (64 bits)
  • Windows 10 (32 bits y 64 bits)
  • Windows Server 2016 (64 bits)
  • Windows Server 2019 (64 bits)
  • Windows 11 (64 bits)
  • Windows Server 2022 (64 bits)

VMware Converter Standalone puede convertir máquinas virtuales fuera de línea desde los siguientes servidores Hyper-V:
  • Windows Server 2012 (64 bits)
  • Windows Server 2012 R2 (64 bits)
  • Windows 10 (64 bits)
  • Windows Server 2016 (64 bits)
  • Windows Server 2019 (64 bits)
  • Windows 11 (64 bits)
  • Windows Server 2022 (64 bits)
VMware Converter Standalone puede convertir máquinas virtuales fuera de línea de los siguientes productos y versiones de VMware:
  • VMware vSphere 6.5 (Actualización 3)
  • VMware vSphere 6.7 (Actualización 3)
  • VMware vSphere 7.0
  • VMware vSphere 7.0 (Actualización 1)
  • VMware vSphere 7.0 (Actualización 2)
  • VMware vSphere 7.0 (Actualización 3)
  • Estación de trabajo VMware 16.x
  • VMware fusión 12.x
Sistemas Operativos invitados soportados:
Supported Operating SystemsConverter Standalone SupportSource for Powered On Machine ConversionsSource for Virtual Machine ConversionsConfiguration Source
Windows Server 2012 (64-bit)YesYesYesYes
Windows 8.1 (32-bit and 64-bit)YesYesYesYes
Windows Server 2012 R2 (64-bit)YesYesYesYes
Windows 10 (32-bit and 64-bit)YesYesYesYes
Windows Server 2016 (64-bit)YesYesYesYes
Windows Server 2019 (64-bit)YesYesYesYes
Windows 11 (64-bit)YesYesYesYes
Windows Server 2022 (64-bit)YesYesYesYes
CentOS 6.x (32-bit and 64-bit)NoYesYesNo
CentOS 7.x (64-bit)NoYesYesNo
CentOS 8.x (64-bit)NoNoNoNo
Red Hat Enterprise Linux 6.x (32-bit and 64-bit)NoYesYesNo
Red Hat Enterprise Linux 7.x (64-bit)NoYesYesNo
Red Hat Enterprise Linux 8.x (64-bit)NoNoNoNo
Ubuntu 14.04 LTS (32-bit and 64-bit)NoYesYesNo
Ubuntu 16.04 LTS (32-bit and 64-bit)NoYesYesNo
Ubuntu 18.04 LTS (64-bit)NoNoNoNo
PRECAUCIÓN: Durante la clonación de máquinas Linux encendidas, Converter Standalone conserva los siguientes sistemas de archivos de origen en el destino: ext2, ext3, ext4, reiserfs, vfat y xfs. Todos los demás sistemas de archivos de origen se convierten en sistemas de archivos ext3 o ext4 en la máquina virtual de destino.

El link de descarga de la aplicación está AQUI, pero ten en cuenta que tendrás que estar registrado en VMware.
El manual de la aplicación, AQUI.

viernes, 7 de octubre de 2022

¡Llegó vSAN 8! Estas son sus novedades

 Como era de esperar, y despues de vSphere 8, llega vSAN 8. Y los cambios recuerdan a su manera a los realizados en vSphere 8: sin ser exageradamente disruptivos, introducen muchos cambios focalizados en la mejora del rendimiento. Pero resumiendo mucho, estas son las novedades:

Llega vSAN ESA

Complementando a vSAN OSA (me encantan estos acrónimos), tenemos a vSAN ESA, que viene de vSAN Express Storage Architecture, que es el gran cambio de esta versión, otra opción sobre vSAN OSA, que viene de vSAN Original Storage Architecture. Cada una hace lo siguiente:

  • OSA optimiza el uso del hardware de dispositivos SAS y SATA, pues eran los dispositivos de almacenamiento rápido de entonces. 
  • ESA optimiza el uso del hardware de dispositivos NVMe, que vienen a ser el reemplazo de los discos SAS y SATA por este nuevo formato basado en tarjetas flash TLC, usualmente, y que permiten alcanzar velocidades muy superiores.

Así que nos encontramos con una actualización del almacenamiento que se puede utilizar, permitiendo un incremento de rendimiento notable.

vSAN Express

Si utilizamos vSAN ESA, podremos optar por un nuevo sistema de almacenamiento, vSAN LFS, que incluyen un nuevo administrador de objetos con estructura de registro optimizado para escritura y un nuevo formato de objeto. Se resume en que el rendimiento del almacenamiento rallará en un rendimiento cercano al del dispositivo.

Rendimiento de vSAN 8 LFS

Englobado dentro de vSAN Express se encuentran una serie de mejoras de RAID de alto rendimiento, donde prometen que un RAID 5 o 6 tendrá un rendimiento de RAID 1, y un RAID 5 adaptativo, que hará que los datos ocupen menos espacio, sean más resistentes, y más fáciles de administrar. 

Y esto es, en resumen, lo más importante, los cambios más notables de la nueva versión.

Si quereis ampliar información, os dejo 2 enlaces de referencia a la presentación del producto, AQUI y AQUI:

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

lunes, 19 de septiembre de 2022

Ahora si, se acabó vCenter 6.7

 Ahora sí, no queda ni un mes para el fin del soporte general de vSphere 6.5 y 6.7. Cuando debería haber finalizado el año pasado, VMware optó por prorrogar un año mas el soporte, hasta el 15 de Octubre de 2022. Ya no queda ni un mes para el fin del soporte extendido. Aunque el soporte técnico todavía se alarga un año mas, ya no habrá, por ejemplo, parches de seguridad para estas versiones, lo que hace totalmente desaconsejable mantenerlas, recomendándose la actualización a, como poco, la v7.

Y aun así, VMware ofrece una alternativa de parches de seguridad hasta el 2024, pero solo cubre esto mismo, actualizaciones de seguridad, ni mejoras, ni soluciones de producto con terceros. Concretamente, si miramos la información facilitada en la web de fin de soporte de VMware, podemos encontrarnos esto:

  • VMware ofrece soporte extendido de 2 años para VMware vCenter Server 6.7.
  • Puede comprar soporte extendido para VMware vCenter Server 6.7 hasta 2 años.
  • Los SKU de soporte extendido estarán disponibles para su compra a partir de la primera semana de abril de 2022.
  • Con soporte extendido de 2 años, puede reclamar soporte hasta el 2024-10-15.
  • Debe comprar Soporte extendido antes de que finalice el Soporte general para obtener soporte continuo de VMware.
  • Durante este soporte extendido, los paquetes de software de terceros no se actualizarán. No habrá mejoras arquitectónicas, de rendimiento ni características adicionales a 6.7 durante el soporte extendido.
  • Los parches de seguridad están limitados a un paquete acumulativo por año.
  • No hay actualizaciones para el sistema operativo Photon del dispositivo vCenter. Consulte https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/support/vmware-extended-datasheet.pdf para conocer los términos y condiciones del soporte extendido.

 Esto deja apenas 3 semanas todavía para poderse adquirir dicho soporte.

Hay que tener en cuenta que el EoGS (Fin del Soporte General) afecta a más productos similares o muy entrelazados con vCenter, como son vSAN:

Puedes comprobar el listado completo de productos de VMware en https://lifecycle.vmware.com/#/

¿Afectará a productos generados a partir de estos, como por ejemplo, VXRail? Es de suponer que sí. AQUI dejo un enlace para comprobar el EOL de los productos de Dell.

Sale en breve la nueva versión de vCenter, así que es un buen momento para renovar producto, o bien si tienes la V7, disfrutar de la actualización a la nueva versión, vSphere 8.

viernes, 2 de septiembre de 2022

¡Ya tenemos VMware vSphere 8!

 Por fin sale la nueva versión de vSphere, dando el salto de la 7 a la 8, sin pasar por la 7,5, como sí ocurrió con las versiones anteriores. Y aunque parezca que esta nueva versión a priori no implica grandes cambios con vSphere 7 en cuestión de nuevas funcionalidades, lo cierto es que es la culminación de un largo proyecto para presentar una de sus grandes ventajas.

Supercharge Workload Performance. O lo que es lo mismo, el famoso Proyecto Monterrey del que se lleva escuchando hace años. Básicamente, lo que se busca con esta solución es trasladar la carga de trabajo de determinados procesos de la CPU a la DPU. Esto consigue que, en aquellos host sobre los que se pueda realizar este traslado de carga (y VMware se lo ha currado para que sea compatible con una gran cantidad de hardware), la mejora de la eficiencia en CPU sea de un 30% de media. Es cierto que reducimos esa carga de las CPUs y la traspasamos a NSX, o las tarjetas de red, pero éstas tienen instrucciones de aceleración especializadas para sus procesos, con lo que consecuentemente el numero de instrucciones procesadas por ciclo en las DPUs aumenta, posibilitando por tanto el descenso de carga de CPU y el aumento de rendimiento de las VMs.

Las DPU son las Unidades de Procesamiento de Datos que se encuentran como SmartNICs usualmente en tarjetas formato PCIe. O mas simplificado todavía: Un SoC, tipo tarjeta de red "smart", porque lleva algún procesador ARM programable capaz de procesar datos, y cuya función suele ser la de aceleración del hardware para el tratamiento de las instrucciones. Normalmente estas tarjetas tienen un mínimo de 2 puertos de entre 10 y 100 Gb, y una pequeña capacidad de almacenamiento que permite instalar cosas, como, por ejemplo, una instancia adicional de ESXi en la DPU, que será administrada por el vCenter Server, igual que el resto de hosts.

Esquema de T. de red PCIe

Todo esto son realmente cambios bastante transparentes para el administrador, fundamentalmente operativos, con lo que no debería haber mucho problema para familiarizarse con ellos. Me quedo con que se han trabajado la parte de mejora del rendimiento.

Otro cambio importante se ha realizado en Tanzu. Ahora con Tanzu Kubernetes Grid 2.0, que permite generar "zonas de disponibilidad de cargas de trabajo", o lo que es lo mismo, permite implementar un cluster de Tanzu en clusteres de vSphere, con la consiguiente mejora en estabilidad que nos da un sistema clusterizado. Se ve bien en el siguiente gráfico:

Otras mejoras se han dado en Lifecycle Management, permitiendo ahora (como es logico) compatibilidad con DPUs, También se dispone ahora de la posibilidad de guardar el estado de cluster de vCenter Server en un almacén de clave-valor distribuido que se ejecuta en los hosts ESXi del clúster, lo que nos permitiría retroceder al ultimo estado conocido desde la ultima copia de seguridad.

Se actualiza a la versión 20 del hardware virtual, y se presenta soporte completo para Windows 11 al facilitar la posibilidad de reemplazar automáticamente el dispositivo vTPM cuando se clona una VM con Windows 11, asegurando que cada VM tenga un dispositivo vTPM único.

Podéis profundizar mas sobre el tema de las DPUs AQUI

Y dejo el enlace de la noticia oficial del blog de VMware AQUI

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

jueves, 28 de julio de 2022

Preparar un disco de Citrix para Azure

Ahora que todas las empresas están moviendo elementos a la nube, evaluando costos y rendimiento, se dará el caso de querer mover VMs antiguas, instaladas, y en sistemas como Citrix, a entornos como Azure.
Tenemos la ventaja que el formato de discos de los XenCenter será un .vhd, igual que el que maneja Azure. Pero aun así si intentamos la subida, obtendremos un error:



The upload size in bytes 17989773824 - 512 bytes for the VHD footer (17989773312 in this case) must be a multiple of MiB.". Esto es debido a que debemos adaptar el tamaño de los bloques de disco a 1 MiB. Para ello, debemos lanzar una serie de comandos de powershell para verificar el tamaño del bloque. Estos comandos son los siguientes:

$vhd = Get-VHD -Path C:\test\MyNewVM.vhd
$vhd.Size % 1MB
Aquí normalmente dará un valor de "0"
$vhd.FileSize - $vhd.Size
Normalmente da un valo entre 512 y algo como 82720062976

También en el caso de que el disco sea un .vhdx, y para arreglarlo, utilizamos el siguiente comando:

Convert-VHD -Path C:\test\MyVM.vhdx -DestinationPath C:\test\MyNewVM.vhd -VHDType Fixed

Tambien puedes utilizarlo siendo un vhd, para pasarlo a vhd, con el sufijo "fixed"

Pero para realizar todo esto, tenemos un problema adicional: no se encontrarán los comandos necesarios en PowerShell:



Para solventarlo, debemos instalar el servicio de Hyper-V en el equipo que lanzará el comando. Vale con los servicios indicados en la captura:



No sirve instalar solamente el modulo de PowerShell, deben instalarse los componentes de Hyper-V indicados, prácticamente todos, menos el hypervisor, que no es necesario. Una vez esté instalado, podremos ejecutar los comandos descritos anteriormente, que ahora si, funcionarán correctamente:



Tras esto, solo queda subir el disco a Azure de la manera que cada uno decida. Tenemos la subida desde consola de PowerShell, la subida desde el navegador, y el uso de Azure Storage Explorer. Pero eso ya es historia para otro post.

Antes de subir el disco, hay que tener en cuenta que debe prepararse también el sistema operativo de forma adecuada, no solo el formato del disco, como hemos visto aquí. Es decir, asegurarse de eliminar las Citrix Tools, deshabilitar firewall, habilitar RDP, eliminar tarjetas de red, hacer un sysprep, etc...

IMPORTANTE: aunque el formato de salida de Citrix es vhd, igual que el que puede utilizar Hyper-V, los discos pueden no funcionar, en base a la BIOS elegida. De manera que aunque el proceso es correcto en base a la documentación y consultas a Microsoft, y el disco sube a Azure, la VM creada con este disco y en base a la eleccion de BIOS, puede no funcionar. 
Para que el proceso funcione, hay que tener en cuenta si en Citrix la VM funciona con BIOS o UEFI. En Caso de ser BIOS, a la hora de montar la VM en azure, deberemos seleccionar una nueva VM Gen1. En cambio, si fuese UEFI, debemos seleccionar Gen2. Adicionalmente y antes de subirla, se puede probar a ejecutar el vhd en Hyper-V, que ya que tenemos instalado el servicio...Si funciona, lo hará igualmente en Azure.

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

jueves, 30 de junio de 2022

Habilitar el modo Internet Explorer en Edge mediante GPO

 Bienvenidos a 2022. Todo Internet está plagado de webs compatibles con Webkit. ¿Todo? ¡No! Unas webs diseñadas con compatibilidad para IE6 resiste, todavía y siempre, al invasor. Y la vida no es fácil para los desarrolladores que trabajan con Chrome, Firefox, Brave, e incluso Edge.

Y esto es un serio problema para esas webs, puesto que Internet Explorer ha dejado, por fin, de recibir soporte el 15 de Junio de 2022. Por suerte, Microsoft deja un "Modo Internet Explorer" en su navegador Edge para soportar estas antiguas webs. Este modo sustituye a la aplicación Internet Explorer 11 de forma oficial, y tiene soporte por lo menos hasta 2029, siguiendo el ciclo de vida de los sistemas operativos de Microsoft. Y aun así, en 2028, irá comunicando el fin del soporte de este modo, con un año de antelación.

Microsoft nos deja esta Guia de Introduccion para el cambio, aunque realmente debería llamarse guía de configuración, puesto que nos informa de todos los pasos a realizar en nuestros sistemas para que no impacte al usuario.

Pero para resumiros la lectura del manual, aunque aconsejo encarecidamente que le echéis un ojo, las buenas practicas de Microsoft recomiendan una re-dirección de las paginas web de IE a Edge en modo compatibilidad IE, via GPO. Para ello, los pasos a seguir son los siguientes:

  • Descargar la ultima versión de los .admx de Microsoft Edge. Los podéis encontrar AQUI.
  • Abrimos la GPO donde queramos realizar el cambio, o creáis una nueva, a vuestras necesidades (de nuevo, las buenas practicas indican que cuantas menos GPOs al inicio, mejor) y vamos a User o Computer configuration > Administrative templates > Microsoft Edge.

  • Tendremos un parámetro con el nombre Configure Internet Explorer Integration, que marcaremos en Enabled. 

Eso nos desbloquea un cuadro de opciones:

  1. Internet Explorer 11: Es la opción de modo de compatibilidad, y la que deberemos escoger si queremos seguir abriendo paginas web desarrolladas para Internet Explorer
  2. Internet Explorer Mode: Aunque esta opción esté en la GPO de Edge, lo que hace es enviaros a Internet Explorer, ¡que precisamente ha dejado de funcionar, para esto es este post!
  3. None: Si quieres impedir que los usuarios puedan configurar el modo IE a traves de Edge, podemos fijarlo en None.

Si dejas la política en Disabled, implica que el modo IE está deshabilitado.

Con esto, dejamos configurado Edge. Ahora vamos con IE, a deshabilitarlo del todo ya que pasa a ser un problema de seguridad. Para ello, seguimos los siguientes pasos:

  • Lo primero de todo, nos aseguramos de tener igualmente el ultimo ADMX disponible para Internet Explorer. Puede descargarse de AQUI. Este paquete es bastante completo, así que recomiendo instalarlo con cuidado, porque lleva un pack bastante extenso de archivos admx, de manera que mejor extraerlo en un sitio seguro, ya que para IE, solo necesitaremos reemplazar los archivos inetres.admx y los inetres.adml de los idiomas que tengamos, en las rutas de las GPOs.
  • Bien, una vez tenemos las ultimas plantillas de políticas, editamos nuestra GPO, como anteriormente, pero esta vez nos dirigimos a Computer configuration > Administrative templates > Windows Components > Internet Explorer.
  • Aqui podemos ver que tenemos la opción "disable Internet Explorer as Standalone browser". Hacemos doble click sobre ella, y marcamos "enable"

Como pasaba con Edge, tenemos 3 opciones distintas, pero esta vez para notificar al usuario del comportamiento de Internet Explorer:

  1. Never, para no notificar a los usuarios que está deshabilitado. Es lo ideal en nuestro caso, porque deberan ser redirigidos a Edge.
  2. Always, si quieres notificarlos siempre de la redireccion.
  3. One per user, que lo que hace es notificarles solo la primera vez que se produce esta redirección.

Recomiendo marcar "never"

Técnicamente, estos son los pasos para realizar esta redireccion de forma automática. Pero queda notificar convenientemente a los usuarios, pues son muchos años de uso de IE, y en muchos casos por necesidad, debido a aplicaciones web que sólo funcionan con este navegador.

¡Espero que os sirva de ayuda! Si te ha gustado el articulo, puedes invitarme a un café  ;)

miércoles, 22 de junio de 2022

Configuracion del proceso de bucle invertido (loopback processing mode) de las GPOs

 Un punto delicado de entender en las GPOs es, ademas de las herencias de políticas y la jerarquía de aplicación, es la opción de proceso de bucle invertido, o loopback processing mode, que ademas se encuentra "escondida", sobre todo si la comparamos con los permisos y jerarquías de aplicación, más accesibles.


Este parámetro de las GPOs lo encuentras en Computer Configuration/Administrative Templates/System/Group Policy/Configure user Group Policy loopback processing mode.

Para entender la importancia del loopback processing mode hay que entender cómo funciona una GPO para una computadora y un usuario, y para ello partimos de lo basico: una GPO se compone de dos partes, usuario y computadora. La parte "computer" de la GPO se aplica a la computadora, a pesar del usuario conectado, y la parte usuario de la GPO, al usuario, a pesar de la computadora a la que se conecte.



Tomemos como ejemplo un dominio con un par de OUs, a las que llamamos Blue y Brown. En Blue tenemos un equipo con la GPO1, y en Brown metemos un usuario con la GPO2. 
Tal y como está, el equipo aplica la parte de computer de la GPO1 de la OU Blue, y el usuario recibe la parte de User de la GPO2 de la OU Brown. Asi que si el usuario de la OU Brown hiciera login en el equipo de la OU Blue, normalmente se aplicarian las GPOs de la siguiente manera:
Como vemos en el dibujo, el usuario aplica su configuración de GPO de usuario de la OU en la que se encuentra, y en la maquina se aplica la configuración de la GPO de computer de la GPO de su OU. Esto es una situación en la que no se aplica el loopback processing mode.

Pongamos que habilitamos el loopback processing mode. Tenemos dos formas de aplicarlo, en "merge" o "replace" Supongamos que aplicamos la opcion "replace" para la GPO1, la que aplica la computadora. Obtendríamos este resultado:
Como se ve en el dibujo, la GPO1 de la OU Blue prevalece para user, en lugar de ser reemplazada por la GPO2, que traería el usuario. 
Ahora pongamos que activamos el loopback mode en modo Merge. Esto, lo que hace es combinar las GPOs de usuario, aplicando ambas simultáneamente:
Eso si, en caso de conflicto, la GPO predominante seria la GPO1 sobre la 2.

La utilidad del loopback processing mode se aplica, mas que a entornos de OUs de usuarios, a OUs de servidores o similares, donde si un usuario tiene permisos para hacer login, seguramente no interese que pueda acceder desde ahí a determinados recursos como carpetas de red que pueda tener habilitadas por OU, mas que nada por motivos de seguridad. Igualmente puede ser útil para OUs donde se encuentren equipos con función de terminales de servicio.

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


domingo, 22 de mayo de 2022

Error inesperado en WSUS, ID 7053

 Aquí dejo una solución a un error de WSUS que me he encontrado en los eventos del servidor, evento 7053, "The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists, Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\."

En el propio evento va parte de la solución, no es mala idea eliminar el archivo indicado:

También la causa puede ser que el servicio de publicación www esté configurado para interactuar con el escritorio. Para corregir esta posible causa de error, vamos a los servicios de la maquina (services.msc), buscamos World Wide Web Publishing Service y hacemos clic con el botón derecho /propiedades, y desmarcamos la opción de permitir interactuar con el escritorio:

Tras esto, reiniciamos el servicio IIS, ejecutando desde ventana de comandos "iisreset"

Tras estos pasos, la consola debe abrir de nuevo sin problemas.

sábado, 30 de abril de 2022

Webs especializadas de VMware

 A partir de un fantástico post de Github se ha hecho una recopilación de Micrositios de VMware, o lo que es lo mismo, de apartados especializados de la web de VMware, actualizada a Abril de 2021. Cubre practicamente todos los campos de VMware. 

Realmente merece la pena echarle un ojo, antes de empezar a navegar directamente por la web de VMware en busca de los recursos.

Son los siguientes:

General resources 
  
SiteURL
Find your Digital Transformation Pathhttps://pathfinder.vmware.com/
VMware Documentationhttps://docs.vmware.com/
VMware Solution Downloadhttps://downloads.vmware.com/
VMware Knowledge Basehttps://kb.vmware.com/
VMware Configuration Maximumshttps://configmax.vmware.com/
Ports and Protocolshttps://ports.vmware.com/
VMware Solution Walkthroughhttps://featurewalkthrough.vmware.com/
VMware {code}https://code.vmware.com/
VMware Marketplacehttps://marketplace.cloud.vmware.com/
vExpert Portalhttps://vexpert.vmware.com/
VMware Certified Design Expertshttps://vcdx.vmware.com/
VMware Blogshttps://blogs.vmware.com/
Office of the CTO Bloghttps://octo.vmware.com/
VMware TAM Service Portalhttps://tamservices.vmware.com/
  
VMware Multi-Cloud 
  
SiteURL
VMware Core Tech Zonehttps://core.vmware.com/
VMware Cloud Serviceshttps://cloud.vmware.com/
VMware Cloud Providerhttps://cloudsolutions.vmware.com/
VMware Cloud Services Status Pagehttps://status.vmware-services.io/
VMware Cloud Services - GovCloud Status Pagehttps://status.gov.vmware-services.io/
  
VMware Application Modernization 
  
SiteURL
VMware Application Modernizationhttps://tanzu.vmware.com/
  
VMware vSAN 
  
SiteURL
VMware Core Tech Zonehttps://core.vmware.com/
vSAN Ready Node Sizerhttps://vsansizer.vmware.com/
  
VMware vRealize 
  
SiteURL
vRealize Product Walkthroughshttps://vrealize.vmware.com/
vRealize Operations Manager Sizinghttps://vropssizer.vmware.com/
vRealize Log Insight Sizing Calculatorhttps://vrlisizer.vmware.com/
  
VMware Education 
  
SiteURL
VMware Educationhttps://mylearn.vmware.com/
VMware Hands-on Labshttps://labs.hol.vmware.com/
VMware Customer Connect Learninghttps://learning.customerconnect.vmware.com
VMware Tanzu Dev. Center Hand-On Workshopshttps://tanzu.vmware.com/developer/workshops/
VMware Tanzu ModernApps Ninjahttps://modernapps.ninja/
Kubernetes Academy by VMwarehttps://kubernetes.academy/
VMware Podcasts on Soundcloudhttps://soundcloud.com/vmware
Der deutschsprachige VMware Podcasthttps://der-deutschsprachige-vmware-podcast-v2.zencast.website/
  
VMware Digital Workspace (EUC) 
  
SiteURL
VMware Digital Workspace Tech Zonehttps://techzone.vmware.com/
VMware WorkspaceONE Status Pagehttps://status.workspaceone.com/
  
More VMware Sites 
  
SiteURL
App Modernizationhttps://www.vmware.com/uk/app-modernization.html
VMware TAM Labhttps://www.youtube.com/c/VMwareTAMLab
VMware Tanzu Mission Controlhttps://k8s.vmware.com/tanzu-mission-control/
VMworld On-Demand Video Libraryhttps://videos.vmworld.com/
VMware Open Sourcehttps://github.com/vmware
User Group Communitieshttps://community.vmug.com/
VMworld Homepagehttps://vmworld.com/

La entrada original de Github, AQUI.

viernes, 4 de marzo de 2022

Solventar Event ID 512, CAPI2 Error

¡ Vamos con un artículo de limpieza de eventos en Windows! Es importante revisar los eventos de los sistemas que componen nuestra infraestructura para atajar problemas, o bien solventarlos antes de que la cosa vaya a más. Y he aquí que me encuentro con este mensaje:


Esto es lo que dice el cuadro de evento: 
Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object. 

Details: 
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol. 

System Error: 
Access is denied.

El problema resulta que viene causado durante la copia de seguridad por un proceso de VSS que se ejecuta con la cuenta NETWORK_SERVICE y llama a cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), que enumera todos los registros de controladores en la base de datos de Service Control Manager e intenta abrir cada uno de ellos. , La función falla en el registro MSLLDP con el error "Acceso denegado",
debido a que los permisos de seguridad del controlador MSLLDP no permiten que NETWORK_SERVICE acceda al registro del controlador.

La solución pasa por tocar los permisos del servicio MSLLDP, desde linea de comandos, con la utilidad SC.exe

Abrimos una ventana de CMD con permisos de administrador, y ejecutamos lo siguiente:

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP ;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Deberia indicar esto:

[SC] SetServiceObjectSecurity SUCCESS
Tras este mensaje, no debería volver a aparecer el mensaje de error en los eventos.
Esta es la solución rápida.
En ESTE post de Microsoft tenéis todo el proceso del problema.
Si te ha gustado el articulo, puedes invitarme a un café ;)

jueves, 3 de marzo de 2022

Reiniciar el periodo de gracia de 120 dias de RDS

 Supongamos que montamos una infraestructura con servidor de licencias RDS. Por defecto, el servicio de licencias RDS nos da 120 días de periodo de gracia de acceso ilimitado de conexiones, sin necesidad de instalar licencias. Terminado este periodo, deben comprarse CALs (Client Access License).  Pero a veces, no da tiempo a montar la infraestructura que queremos, o lo que tenemos es una laboratorio de pruebas, y necesitamos un poquito mas de tiempo para trastear.

Bueno, podemos resetear este contador para seguir con nuestras pruebas. Es muy fácil. Sólo debemos ir a HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\RCM\GracePeriod.  Podemos ver un registro llamado TimeBomb que no podremos eliminar, por falta de permisos. De manera que sobre GracePeriod pulsamos botón derecho y vamos a permisos

Aquí tendremos que tomar propiedad de la carpeta con, por ejemplo, la cuenta de administrador local de la maquina, y posteriormente, asignarnos permisos de full control en la carpeta.

Tras estos permisos, podremos eliminar el registro L$RTMTIMEBOMB.

Reinicia el servidor, y veras que el mensaje sigue saliendo, pero con 120 días de periodo de gracia.

Tambien puedes ver en cualquier momentos los dias que quedan de periodo de gracia con el siguiente comando:

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TerminalServiceSetting WHERE (__CLASS !="")

La segunda manera de realizar esto es prepararte el siguiente código en un archivo .ps1 y lanzarlo con un .\Reset-TSGracePeriod.ps1 -force

# This Script is intended to be used for Querying remaining time and resetting Terminal Server (RDS) Grace Licensing Period to Default 120 Days.

## Developed by Prakash Kumar (prakash82x@gmail.com) May 28th 2016

## www.adminthing.blogspot.com

## Disclaimer: Please test this script in your test environment before executing on any production server.

## Author will not be responsible for any misuse/damage caused by using it.

Param(

        [Parameter(Mandatory=$false)] [Switch]$Force

     )

 

Clear-Host

$ErrorActionPreference = "SilentlyContinue"

 

## Check if PowerShell Console has been launched As Administrator

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {

 

## Display current Status of remaining days from Grace period.

$GracePeriod = (Invoke-CimMethod -InputObject (Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TerminalServiceSetting-MethodName GetGracePeriodDays).DaysLeft

Write-Host -fore Green ======================================================

Write-Host -fore Green 'Terminal Server (RDS) grace period Days remaining are' : $GracePeriod

Write-Host -fore Green ====================================================== 

Write-Host

 

## Check if -Force Parameter has been used, If so, It will not prompt for Y/N while executing the script and will simply reset the Grace Period.

If (-not $Force)

{

$Response = Read-Host "Do you want to reset Terminal Server (RDS) Grace period to Default 120 Days ? (Y/N)"

}

 

if ($Response -eq "Y" -or $Force) {

## Reset Terminal Services Grace period to 120 Days

 

$definition = @"

using System;

using System.Runtime.InteropServices;

namespace Win32Api

{

       public class NtDll

       {

             [DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]

             public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled);

       }

}

"@

 

Add-Type -TypeDefinition $definition -PassThru

 

$bEnabled = $false

 

## Enable SeTakeOwnershipPrivilege

$res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)

 

## Take Ownership on the Key

$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey("SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod", [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)

$acl = $key.GetAccessControl()

$acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")

$key.SetAccessControl($acl)

 

## Assign Full Controll permissions to Administrators on the key.

$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("Administrators","FullControl","Allow")

$acl.SetAccessRule($rule)

$key.SetAccessControl($acl)

 

## Finally Delete the key which resets the Grace Period counter to 120 Days.

Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod'

 

write-host

Write-host -ForegroundColor Red 'Resetting, Please Wait....'

Start-Sleep -Seconds 10

 

}

 

Else

    {

Write-Host

Write-Host -ForegroundColor Yellow '**You Chose not to reset Grace period of Terminal Server (RDS) Licensing'

  }

 

## Display Remaining Days again as final status

tlsbln.exe

$GracePost = (Invoke-CimMethod -InputObject (Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TerminalServiceSetting-MethodName GetGracePeriodDays).DaysLeft

Write-Host

Write-Host -fore Yellow =====================================================

Write-Host -fore Yellow 'Terminal Server (RDS) grace period Days remaining are' : $GracePost

Write-Host -fore Yellow =====================================================

 

if ($Response -eq "Y" -or $Force)

        {

            Write-Host -Fore Cyan `n"IMPORTANT: Please make sure you restart following services manually to bring this reset in effect:`n`n* Remote Desktop Configuration Properties `n* Remote Desktop Services"

        }

}

Else

{

    Write-Host -fore RED =====================================================

    Write-host -ForegroundColor RED *`0`0`0`0 Please Launch PowerShell as Administrator `0`0`0`0*

    Write-Host -fore RED =====================================================

}

## Cleanup of Variables

Remove-Variable * -ErrorAction SilentlyContinue

 

##End of Code##

Despues, queda reiniciar los servicios "remote desktop configuration" y "remote desktop services".

Tienes el proyecto de Github original del código AQUI

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