Un Vistazo a Windows Server 2025: Evolucion y ciclo de vida

En el dinámico mundo de la tecnología, Microsoft ha lanzado oficialmente Windows Server 2025, una versión que promete revolucionar la gestión de servidores con mejoras significativas en seguridad, rendimiento y flexibilidad en la nube. Este lanzamiento marca un hito importante en la evolución de Windows Server, que ha visto transformaciones notables desde la versión 2016 hasta la actualidad. 

Bueno, eso dice Microsoft. Realmente, esta version se centra en la estabilidad, mientras sigue hibridando con la nube.

¿Que hay de nuevo?

Windows Server 2025, disponible desde el 1 de noviembre de 2024, introduce una serie de características avanzadas diseñadas para enfrentar los desafíos modernos de la ciberseguridad y la gestión de datos. Entre las novedades más destacadas se encuentran:

• Seguridad Multicapa: Con mejoras en Active Directory, servicios de archivos y cuentas de servicio gestionadas delegadas, Windows Server 2025 refuerza la protección contra amenazas cibernéticas Más info en ESTE LINK.
• Agilidad en la Nube: La integración con Azure Arc permite una mayor flexibilidad operativa, facilitando la gestión de entornos híbridos y multicloud. Mas info en ESTE LINK.
• Rendimiento y Escalabilidad: Con soporte para cargas de trabajo de inteligencia artificial y aprendizaje automático, y mejoras en el rendimiento de almacenamiento NVMe, esta versión está preparada para manejar las demandas más exigentes. Mas info, en el link de arriba, tambien. 

Ciclo de Vida de Windows Server 2025

Siguiendo la política de ciclo de vida fijo de Microsoft, Windows Server 2025 tendrá soporte principal hasta el 9 de octubre de 2029 y soporte extendido hasta el 10 de octubre de 2034 (https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2025). Este ciclo de vida asegura que las organizaciones puedan planificar sus actualizaciones y mantenimientos con anticipación, garantizando estabilidad y soporte a largo plazo.

¿Qué pasa con las versiones anteriores? Windows Server 2016 a 2022

Para entender la evolución de Windows Server, es crucial revisar las versiones anteriores y sus ciclos de vida:

• Windows Server 2016: Lanzado el 15 de octubre de 2016, con soporte principal hasta el 11 de enero de 2022 y soporte extendido hasta el 12 de enero de 2027
• Windows Server 2019: Introducido el 2 de octubre de 2018, con soporte principal hasta el 9 de enero de 2024 y soporte extendido hasta el 9 de enero de 2029
• Windows Server 2022: Disponible desde el 18 de agosto de 2021, con soporte principal hasta el 13 de octubre de 2026 y soporte extendido hasta el 14 de octubre de 2031

Conclusión

Windows Server 2025 apuesta por seguir hibridando sus productos clásicos, con el fin de facilitar a transicion a la nube, mientras redondea un producto que ya es un referente y piedra angular en la mayoria de entornos.

Links adicionales de consulta, sobre todo del ciclo de vida:

Windows Server 2016 - Microsoft Lifecycle | Microsoft Learn.

Windows Server 2025 pricing and licensing options - 4sysops.

Windows Server 2025 - Wikipedia.

Microsoft Windows Server 2025: Everything you need to know - Q-Advise.

How long will windows server 2016 be supported?

Windows Server Lifecycle Dates | ServersPlus.

Windows and Office configuration support matrix - microsoft.com. (en PDF).

Desplegando una nube privada de VMware en Azure, parte 3: Conectando la infra on-prem con AVS

 Ahora que hemos visto como instalar Microsoft AVS y que hemos accedido al vCenter para ver que todo esta correctamente desplegado, vamos a ver cómo configurar ExpressRoute para permitir la conectividad con los recursos de AVS desde nuestro datacenter on-prem.

Partimos suponiendo que tenemos ExpressRoute ya montado que conecta nuestra infra on-prem con Azure, y que la parte responsable de ese circuito ExpressRoute nos puede facilitar el identificador de recurso y una clave de autenticación.

Empezamos desde Azure, en nuestro recurso AVS. En el menú izquierdo pinchamos en connectivity, y en la ventana principal, en las pestañas que tenemos a nuestra disposición, pinchamos en "ExpressRoute Global Reach":

No hay muchas opciones más allá de hacer click en "Add". Eso nos abre una ventana lateral en la que indicamos nuestra suscripcion y resource group, y donde tenemos que introducir también nuestro "Circuit ID" y nuestra "Authorization key". Una vez los introducimos, pulsamos "create"

Cuando se completa la conexion, vamos a "manage / Identity" donde como ya vimos en el anterior post, podemos ver la IP de conexion a nuestro vCenter, asi como el user y pass. Asi que accedemos a nuestro vCenter, donde podemos ver nuestro cluster sin problemas y sin necesitad de  maquina de salto.

¡No tiene mas complicaciones! Ahora, ¡a trastear con ese cluster AVS!

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

Desplegando una nube privada de VMware en Azure, parte 2: Instalando Microsoft AVS

 Anteriormente, ya vimos como solicitar cuota de hosts en Azure, así como la creación del Resource Group, como preparación previa para el despliegue de Microsoft AVS (Azure VMware Solution). Vamos ahora con AVS.

En nuestro Resource Group, pulsamos sobre "Crear",

Y hacemos una búsqueda para "Azure VMware Solution".

Pulsamos sobre "create", y llegaremos a un breve wizard para el despliegue. La primera pestaña que muestra nos indica los pre-requisitos para el despliegue, consistentes en el Enterprise Agreement para la cuota de host, y una red /22 disponible.

Pulsamos sobre "Next: Basics". Seleccionamos nuestra suscripcion y Resource Group para el despliegue, y en el apartado de detalles de la Private Cloud, indicamos el nombre que le vamos a dar, la region en la que se va a desplegar, y el tamaño del host, donde lo normal es que sea un nodo AV36. Movemos el manejador para seleccionar el numero de hosts. Lo ultimo que pide es facilitar un bloque de direcciones /22 que se utilizara para la gestión del cluster. Hay que tener especial cuidado en que sea un bloque de direcciones unico y que no se solape con otras vnets o redes onprem a las que luego conectemos.

Podemos ir a la pestaña de tags, o directamente "review and create". Veremos un resumen de los "agreements" y de las opciones seleccionadas para la creacion del servicio. Asi que le damos a Create, y esperamos unas horas a que termine de desplegarse.

Ahora conectaremos el AVS Private Cloud a una Azure Virtual Network para que podamos acceder a vCenter y NSX Manager desde un jumpbox que implementaremos en esa red virtual. Crearemos una nueva red virtual de Azure y conectaremos nuestra nube privada AVS a ella con la característica Azure vNet Connect. Asignaremos espacio IP no superpuesto para esta nueva red virtual y crearemos tres subredes dentro de ella.

Así que accedemos al recurso creado, y pulsamos, en el menú izquierdo, en "connectivity"

Abrirá directamente en el panel de "Azure vnet connect". DOnde el menú desplegable de Virtual Network, pulsamos en "create new"

Esto genera una ventana para la configuración de la red virtual. Vamos a utilizar como rango una 192.168.96.0/24, y la vamos a dividir en 3 subnets /27, para gateway, otra para AzureBastion, y otra para management, tal y como puedes ver en la imagen:

Pulsamos OK, y seguidamente, Save:

Con esto, está creada la red que utilizaremos para AVS, dentro de su RG. Si entramos en el RG, veremos algo similar a esto:

A continuación, implementaremos Azure Bastion y una máquina virtual de Windows 10 para usarla como jumpbox administrativo, luego iniciaremos sesión en la máquina virtual de Windows 10 con Bastion para acceder a vCenter.

De nuevo, entramos en nuestro Resource Group, y pulsamos "create", como en la imagen superior. Buscamos "Bastion", y le damos a "create". 

En Project details indicamos la suscripción en la que nos encontramos trabajando, y el Resource Group, el que hemos creado para todo lo que estamos desplegando.

En Instance details, indicamos el nombre que le vamos a dar a Bastión, la región sobre la que se despliega, y el Tier, donde seleccionamos Basic.

En configure Virtual Network, seleccionamos la Vnet que creamos anteriormente, y la subnet que generamos para Bastión (3 imágenes más arriba).

En Public IP Address, seleccionamos "create new", y le damos un nombre reconocible, como se ve en la imagen inferior:

Pulsamos "review & create", donde vamos al resumen de la configuración deseada, y de nuevo, create.

Una vez creado, volvemos de nuevo al RG, y de nuevo, create. Esta vez buscamos "Microsoft Windows 10", seleccionamos un desktop Windows 10 u 11, y le damos a Create.

Seleccionamos la suscription y RG de este despliegue.

En instance details, damos el nombre a la máquina, en availability options no requerimos redundancia, pues será solo una maquina de salto, y en imagen, seleccionamos la más moderna que encontremos. En la captura, la que habia en este momento para Windows 10:

Introducimos username y password para la VM, y en Public inbound ports, seleccionamos "none", y hacemos click en la casilla de "confirm", justo debajo de inbound ports, y vamos a la pestaña Networking:

En Networking seleccionamos la subnet de management, en Public IP seleccionamos "none", en Network Security Group selecionamos "Basic", y en Public inbound ports, None.

Marcamos "review & create", nos sale el resumen habitual de configuración, y de nuevo, create.

Una vez desplegada la VM, nos dará la opción "go to resource". Pulsamos ahí, y nos llevará a la VM recien creada. Pulsamos en Connect, y seleccionamos Bastion, y Use Bastion:

Nos llevará a la pantalla de conexión de Bastión. Introducimos User y pass, lo que introducimos en la creación de la VM, y marcamos el "abrir en nueva ventana":

Por ahora dejamos la conexión en la nueva ventana, y volvemos a Azure. Pinchamos en Home, accedemos a nuestro AVS Private Cloud, vamos a "Identity", y ahí podremos ver nuestra dirección web de acceso:

Introducimos esta dirección en nuestro navegador, aceptamos los mensajes de seguridad, y nos cargará una ventana muy conocida:

Lanzamos el vSphere Client en HTML5. Nos cargará la pantalla de user y pass. Tenemos estos datos en la ventana "identity, que vimos 2 imágenes atrás, justo debajos de la ip de conexión. Copiamos user y pass, y accedemos al entorno. Esto nos mostrará nuestro entorno:

Si pinchamos sobre los hosts podremos ver en summary sus procesadores lógicos y demás detalles.

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

Desplegando una nube privada de VMware en Azure, parte 1: Solicitar cuota de host para Microsoft AVS

Igual que en el post anterior vimos cómo crear un SDDC en AWS, mi intención es explicar cómo hacerlo en Azure. Lamentablemente, en Azure el alta del servicio no es que sea más complicada, es que esta...digamos, menos trabajada que en AWS. Asi que en vez de simplemente generar una VPC para conectar con el SDDC que creamos en AWS, aquí primero hay que generar una suscripción asociada a un Enterprise Agreement, para desde ahí solicitar una cuota de host AVS en la regioon en la que queramos desplegar nueva nube privada.

Los hosts AVS son servidores dedicados y bare-metal, y hay un número finito disponible. La solicitud de cuota de host nos asignará el numero de host que solicitemos. No facturarán por estos hosts hasta que se implementen. Lo que sucede es que puede llevar hasta 5 días en producirse la asignación de los mismos, de manera que hay que planificar bien, y con tiempo, lo que se va a solicitar.

Vamos con los pasos para solicitar esta cuota. Lo primero de todo accedemos a nuestra suscripción de Azure. Seguidamente pinchamos en el menú del portal (las 3 rayitas de la parte superior izquierda), abajo del todo veremos la opcion "Help + support" (ayuda y soporte tecnico). Pinchamos en ella, y en la ventana que aparece, pulsamos en "create a support request.

En la primera pestaña, Basics, En Summary, marcamos "need capacity". En "issue type", marcamos "technical". Esto abre nuevas opciones a marcar. En "suscription" indicamos la suscripción sobre la que requeriremos la cuota de hosts. 

En servicio, marcamos "all services, y selecionamos en los menus desplegables, las siguientes opciones:

- Service type: Azure VMware Solution.

- Resource: General question.

- Problem type: Capacity management Issues.

- Problem subtype: Customer Request for Aditional Host Quota/Capacity.

Pulsamos Next, y vamos a la siguiente pestaña. En "Solutions" no hay mucho que hacer, son enlaces informativos. Pulsamos Next, y continuamos en Details:

Aquí sí tenemos varios elementos sobre los que actuar:

El campo más importante es el de "Descripción", donde indicamos de forma concisa lo que necesitamos. En este caso, y como se puede ver en la siguiente captura, se indica en cada linea, el entorno, la región, y el numero de host, con una descripción tan escueta como "Production", "West US" y "3 Hosts". Hacemos click en "yes" en "share diagnostic information", y marcamos la forma preferida de contacto.

Pulsamos sobre Review + Create, 

...Y terminamos en una pantalla resumen, para poder comprobar los detalles de la petición de soporte, y finalmente pulsar en "create:

Veremos que se inicia la tarea, que podemos comprobar en los mensajes de eventos habituales.

En un plazo de 5 días recibiremos un mail indicando que se ha asignado la cuota de host. Para comprobar que los recursos se han asignado a nuestra suscripción, vamos a Home de nuevo, y en el menú lateral izquierdo, seleccionamos "Resource Providers". En el cuadro de búsqueda de la derecha, buscamos "Microsoft.AVS". Veremos el recurso como registrado, pero si no estuviera registrado, podemos pinchar sobre él y pulsar "register"

Bien, con esto, tenemos el Provider asignado a nuestra suscripción. Ahora debemos crear un Resource Group para nuestra nube privada, y demás objetos asociados.

Crear un RG no tiene mucho misterio, seleccionamos Home / Resource Group /Create, y rellenamos los 3 datos que nos piden, que son la Suscripción, el nombre del resource group, y la región. ¡Lógicamente, la suscripción y región, las mismas donde solicitamos los recursos dedicados!

Pulsamos "review & create", y luego "create".

Con esto, estamos listos para crear nuestra nube privada  Microsoft AVS (Azure VMware Solution).

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

CMTrace, la herramienta todo terreno para revisar logs

 A nadie le gusta revisar logs, sobre todo si no se dispone de una herramienta específica para la tarea y la herramienta que los genera, lo que hace que se convierta muchas veces en una tarea de tirar de Notepad++ y dejarse la vista en el proceso. Por eso quiero hablar de CMTrace

CMTrace es una herramienta de apenas 700 KB. que nos permite leer todo tipo de archivos de log, y aunque pertenece al entorno de Windows de SCCM, podemos perfectamente echarle unos hostd.log de VMware, o cualquier otro archivo de las mismas características, que te ayudará con la lectura de los mismos, remarcando los warnings y los errores automáticamente. Ojo, que esto no significa que sean realmente errores, de manera que hay que hacer igualmente seguimiento al error para verificar si lo es, o simplemente es una carencia de datos del proceso que genera el log, reportando finalmente si el proceso se ha completado correctamente.

Una utilidad que tiene CMTrace para seguir los errores es, una vez localizada la posible causa de lo que andas buscando, hacer tu propio resalte. 

Supongamos que buscamos el término que resalto en la captura que tenemos a continuación, "esx.problem". Sólo debemos ir al menú de la aplicación, seleccionamos "tools", a continuación "Highlight", e introducimos el término a buscar. 

Por defecto, nos resaltará automáticamente todas las lineas que contengan dicho término en amarillo, igual que los warnings. Pero para facilitarnos la localización de nuestra búsqueda debemos ir a File / Preferences, en el menú de la aplicación, y cambiar el color del resalte a cualquier otra cosa distinta de rojo o amarillo, por ejemplo, verde.

Esto nos permite movernos por el log rápidamente e identificar los campos que nos interesan.

Otra ventaja que tiene esta herramienta es la revision de los archivos en tiempo real. Si te has fijado en la imagen de la ventana de preferencias, verás que además de highlight tienes un tiempo de refresco del archivo de log.

Un pequeño problemilla con CMTrace es su obtención. Antes podias ir a la web de Microsoft y descargarlo sin problema, pero lo han retirado. Pero que lo hayan retirado no significa que ya no exista. Si utilizas SCCM, es posible que lo tengas en la instalacion cliente. Busca en c:\windows\ccm\cmtrace.exe. Si no está ahí, busca en una instalacion de SCCM, en \\Archivos de programa\Microsoft Configuration Manager\tools. Y si por lo que sea, tampoco lo encuentras ahí, puedes bajarte la ISO de evaluacion de SCCM de microsoft, y buscar en la carpeta de Tools.

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

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é ;)

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é  ;)

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é ;)

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