Enrutamiento y acceso remoto no inicia – 8007042a

Bajo algunas versiones de Windows Server 2016 / 2019 el servicio de enrutamiento y acceso remoto no se inicia correctamente después de un reinicio, aparecen mensajes de error relacionados con el servicios de directivas de redes (NPS):

NPS no puede registrar información de cuentas en el almacén de datos principal (C:\Windows\system32\LogFiles\iaslog0.log). Debido a este error de registro, NPS descartará todas las solicitudes de conexión. Información del error: 22.

Si se intentan iniciar manualmente desde la consola o la interfaz gráficas el resultado es el mismo:

En este caso el orden de inicio de los servicios es importante, deberemos parar el servicio de directivas de redes primero, desde consola y conociendo el nombre interno del servicio ejecutamos:

net stop "ias"
net start "remoteAccess"
net start "ias"

Actualización fallida Windows 10 / Windows Server 2019: 0xC1900101 – 0x30018

Aunque la solución parece enfocada en Windows 10, también es aplicable a Windows Server 2019. Después de un par de reinicios en el proceso de actualización aparece el error:

0xC1900101 - 0x30018
Error de instalación en la fase FIRST_BOOT con un error durante la operación SYSPREP
Leer más
0xC1900101 - 0x30018
Error de instalación en la fase FIRST_BOOT con un error durante la operación SYSPREP
Leer más

Deshabilitar actualizaciones de Java en Windows Server

En entornos multiusuario Citrix o Remote App, la ejecución de «pequeños» programas con las sesiones de usuarios pueden llegar a causar sobreutiliziación de recursos de manera innecesaria.

Una de las habituales si el servidor requiere algún tipo de complemento de Java, es el comprobador automático de actualizaciones. Para evitar tenerlo activo en múltiples sesiones, deberemos modificar el registro, para la versión de 64 bits en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy

Y para la versión de 32 bits en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy

«Recuperar» claves privadas de certificados SSL en IIS

En ocasiones es posible tener alguna que otra dificultad a la hora de crear peticiones (CSR) o renovar si no se realizan los pasos con cuidado en IIS. Debemos tener en cuenta que a la hora de crear una petición de certificado, la clave privada se almacena en el equipo que la realiza y solo en este es posible recuperarla.

Pese a ello en ocasiones se producen errores en el proceso, llegados a este extremo podemos intentar dos opciones:

  1. Desde la linea de comandos podemos intentar reparar el almacen de certificados:
    certutil -repairstore my "ThumbprintDelCertificadoConoSinEspacios"

    Si el comando encuentra las claves privadas asociadas al certificado indicado con el thumprint las asocia, en otros casos es posible que muestre errores del tipo «Insertar tarjeta inteligente» ya que busca en todos los medios y proveedores criptográficos existentes, en tal caso no podrá acabar.

    NOTA: este comando también se puede utilizar para asociar las claves privadas con la renovación de un certificado CER de manera rápida dentro del mismo equipo, es decir, certificado completo del año 2010 (PFX) y renovación de 2011 (CER) en el mismo almacén de certificados.

  2. Si hemos solicitado el certificado a una autoridad online, es posible que tenga almacenadas las claves privadas en la solicitud web, en este caso podremos unirlas con el certificado de respuesta para obtener el PFX resultante mediante OpenSSL, puedes probar online pero nunca en producción
    openssl pkcs12 -export -inkey clave.pem -in pki.crt -out certificadoCompleto.pfx

 

NOTA: Una pequeña aclaración rápida, los archivos CRT contienen la información entre las etiquetas —–BEGIN CERTIFICATE—– y —–END CERTIFICATE—– mientras que las claves de ficheros PEM utilizan: —–BEGIN RSA PRIVATE KEY—– y —–END RSA PRIVATE KEY—– habitualmente.