Mucho tiempo/primera vez... Usando la AMI oficial de AWS Windows 2019 ("ami-0229f7666f517b31e" en "us-east-1"), creamos una nueva instancia y realizamos algunas tareas básicas (usando la opción "user_data") a través de PowerShell:
- Iniciar sesión
Start-Transcript -Path "c:\user-data.txt"
- Cambiar la contraseña de "Administrador" local:
$admin = [adsi]("WinNT://./administrator, user")
$admin.PSBase.Invoke("SetPassword", "${password}")
- Habilite/configure WinRM para Ansible:
$WinRM = Invoke-WebRequest -Proxy http://"${proxy}" -UseBasicParsing https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 | Select-Object -ExpandProperty Content
Invoke-Expression $WinRM
- Habilitar RDP:
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -name "fDenyTSConnections" -value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
- Configurar el nombre de host:
Rename-Computer -NewName "${name}" -Force
- Dejar de iniciar sesión:
Stop-Transcript
- Reinicie la computadora (para que se aplique el cambio de nombre de host):
Restart-Computer
Cosas bastante básicas en realidad, nada que podamos ver como un problema aquí y hemos verificado que cada tarea esté funcionando como se esperaba.
En este punto, ejecutaríamos un manual de Ansible que hace algunas cosas (configurar servicios, unirse a un dominio, instalar chocolatey, etc.), pero la tarea que siempre falla es la parte de Windows Update.
En el proceso de solución de problemas, eliminamos todo del manual de Ansible excepto llamar a Windows Update usando elventanas.ansiblerecopilación. Entonces, en este punto, la instancia está implementada, las tareas básicas de PowerShell se ejecutan a través de "user_data" y luego Ansible se conecta e intenta ejecutar Windows Update.
La tarea de Ansible en sí también es bastante básica:
- name: os - perform windows updates
win_updates:
state: installed
category_names:
- Application
- Connectors
- CriticalUpdates
- DefinitionUpdates
- DeveloperKits
- FeaturePacks
- Guidance
- SecurityUpdates
- ServicePacks
- Tools
- UpdateRollups
log_path: c:\wu-install.log
reboot: yes
reboot_timeout: 600
Entonces aquí es donde se vuelve extraño/molesto... Cuando lo ejecutamos, vemos esta respuesta:
Failed to search for updates: Exception from HRESULT: 0x80240438
Eso sucede CADA vez que lo intentamos usando el flujo de trabajo deseado... Sin embargo, lo que hemos descubierto es que si lo realizamos de forma interactiva una vez antes de realizar la tarea de Actualización de Windows, ¡funciona! ¡¡¡Cada vez!!!
Mi último trabajo fue 99,9% Linux, así que estoy un poco oxidado con esto, pero sé que hay cosas locas/indocumentadas que suceden en el primer inicio de sesión (interactivo). Y probé un montón de cosas diferentes (IPv6 deshabilitado, ejecuté wsreset.exe, eliminé entradas de registro de la Tienda Windows, reinicié los servicios de Actualizaciones de Windows, etc.) basándome en la investigación de ese código de error... Pero lo único que puedo ver es que siempre que inicie sesión de forma interactiva una vez ANTES de que se ejecute el intento de actualización de Windows, todo estará bien.
Pero obviamente no queremos hacer eso;)
De nuevo, para que quede claro:
- Implementar instancia (con ajustes de "user_data", que incluye un reinicio), ejecute el manual de estrategias de Ansible que ejecuta la tarea de actualización de Windows:
Failed to search for updates: Exception from HRESULT: 0x80240438
- Implemente la instancia (con ajustes de "user_data", que incluye un reinicio), inicie sesión de forma interactiva (usando RDP), ejecute el libro de estrategias de Ansible que ejecuta la tarea de actualización de Windows:
Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.329.1737.0)
NOTA:Esa es solo la respuesta actual, ya que a la AMI solo le falta esa actualización... Entonces, podría/debería cambiar en el futuro.
Además, esto no incluye ninguna unión a un dominio ni nada... Aunque noté un patrón similar allí. Si usé el libro de estrategias completo, siempre que iniciara sesión interactivamente usando un usuario de dominio antes de ejecutar la tarea de Windows Update, funcionó.
Debo mencionar que cuando inicio sesión interactivamente, no hago absolutamente nada... Simplemente inicio sesión a través de RDP y luego no acepto ninguna indicación ni hago clic en nada.
Obviamente, el objetivo es lograr que no sea necesario iniciar sesión manualmente, ya que eso anula el objetivo principal de este proyecto. Entonces mis preguntas son:
- ¿Alguien sabe que está pasando WTF? ¿Existe alguna manera de simular/replicar cualquier cambio que realice un inicio de sesión interactivo? Revisé los registros pero no vi nada obvio.
- Suponiendo que no puedo solucionarlo de la manera "correcta", ¿alguna idea sobre cómo utilizar Ansible para realizar un inicio de sesión interactivo? Estoy pensando en tener una tarea que inicie sesión de forma interactiva, luego otra tarea que la cierre... Desordenada, pero no puedo seguir perdiendo el tiempo en esto. Un ajuste de "user_data" también funcionaría.
Estoy dispuesto a intentar cualquier cosa en este momento, lo único que puedo decir es que no podemos cambiar la AMI que se está utilizando (aparte de actualizarla a la última versión) y es necesario lograr el resultado final del proceso "user_data". (Pero se puede hacer de otras maneras si ese es el problema). Hay un proxy involucrado, pero no veo cómo eso es un factor ya que la fuente del problema parece ser el inicio de sesión interactivo.
Respuesta1
He tenido este problema antes. No estoy seguro de una solución, pero una solución alternativa fue configurar el inicio de sesión automático para el usuario ansible. Reinicie la instancia. Ejecute la actualización y luego elimine el inicio de sesión automático.
Muy mal trabajo, el mío era parte de la creación de una imagen de Packer, por lo que podía agregar el inicio de sesión automático y luego eliminarlo después de las actualizaciones.
Respuesta2
Fwiw, abrí un informe de error sobre esto:
https://github.com/ansible-collections/ansible.windows/issues/193