Muito tempo/primeira vez... Usando a AMI oficial do AWS Windows 2019 ("ami-0229f7666f517b31e" em "us-east-1"), criamos uma nova instância e executamos algumas tarefas básicas (usando a opção "user_data") através do PowerShell:
- Iniciar o registro
Start-Transcript -Path "c:\user-data.txt"
- Altere a senha do "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
- Habilite o RDP:
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -name "fDenyTSConnections" -value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
- Configurar nome de host:
Rename-Computer -NewName "${name}" -Force
- Pare de registrar:
Stop-Transcript
- Reinicialize o computador (para que a alteração do nome do host seja aplicada):
Restart-Computer
Coisas bem básicas, na verdade, nada que possamos ver como um problema aqui e verificamos que cada tarefa está funcionando conforme o esperado.
Neste ponto, executaríamos um manual do Ansible que faz algumas coisas (configurar serviços, ingressar no domínio, instalar o chocolate, etc.), mas a tarefa que sempre falha é a parte do Windows Update.
No processo de solução de problemas, removemos tudo do manual do Ansible, exceto chamar o Windows Update usando oansible.windowscoleção. Portanto, neste ponto, a instância é implantada, as tarefas básicas do PowerShell são executadas por meio de "user_data" e, em seguida, o Ansible se conecta e tenta executar o Windows Update.
A tarefa do Ansible em si também é 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
Então é aqui que fica estranho/irritante... Quando executamos isso, vemos esta resposta:
Failed to search for updates: Exception from HRESULT: 0x80240438
Isso acontece TODAS as vezes que tentamos usar o fluxo de trabalho desejado... No entanto, o que descobrimos é que, se interagirmos uma vez antes de a tarefa do Windows Update ser executada, ele funciona! Toda vez!!!
Meu último trabalho foi 99,9% Linux, então estou um pouco enferrujado com isso, mas sei que há coisas malucas/não documentadas que acontecem no primeiro login (interativo). E eu tentei várias coisas diferentes (IPv6 desativado, executou wsreset.exe, excluiu entradas de registro da Windows Store, reiniciou os serviços de atualizações do Windows, etc.) com base na pesquisa desse código de erro ... Mas a única coisa que posso ver é contanto que eu faça login interativamente uma vez ANTES da tentativa do Windows Update ser executada, tudo estará bem.
Mas obviamente não queremos fazer isso;)
Novamente, para ser claro:
- Implante a instância (com ajustes de "user_data" - que inclui uma reinicialização), execute o playbook Ansible que executa a tarefa do Windows Update:
Failed to search for updates: Exception from HRESULT: 0x80240438
- Implante a instância (com ajustes de "user_data" - que inclui uma reinicialização), faça login interativamente (usando RDP), execute o playbook Ansible que executa a tarefa do Windows Update:
Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.329.1737.0)
OBSERVAÇÃO:Essa é apenas a resposta atual, já que falta apenas essa atualização na AMI...Então, poderia/deveria mudar no futuro
Além disso, isso não inclui nenhuma adesão de domínio nem nada... Embora eu tenha notado um padrão semelhante lá. Se eu usei o manual completo, desde que tenha feito login interativamente usando um usuário de domínio antes de executar a tarefa do Windows Update, ele funcionou.
Devo mencionar que quando faço login de forma interativa, não estou fazendo absolutamente nada... Basta fazer login via RDP e não aceito nenhuma solicitação nem clico em nada.
Obviamente o objetivo é fazer com que não haja necessidade de login manual, pois isso vai contra o objetivo principal deste projeto. Então minhas perguntas são:
- Alguém sabe que WTF está acontecendo?!? Existe uma maneira de simular/replicar quaisquer alterações realizadas em um login interativo? Eu vasculhei os registros, mas não vi nada óbvio.
- Supondo que não consigo consertar da maneira "certa", alguma idéia de como usar o Ansible para realizar um login interativo? Estou pensando em ter uma tarefa que efetue login interativamente e, em seguida, outra tarefa que efetue logout... Confuso, mas não posso continuar perdendo tempo com isso. Um ajuste "user_data" também funcionaria.
Disposto a tentar qualquer coisa neste momento, a única coisa que posso dizer é que não podemos alterar a AMI que está sendo usada (além de atualizá-la para a versão mais recente), e o resultado final do processo "user_data" precisa ser alcançado (Mas pode ser feito de outras maneiras, se esse for o problema). Há um proxy envolvido, mas não vejo como isso seja um fator, já que a origem do problema parece ser o login interativo.
Responder1
eu já tive esse problema antes. Não tenho certeza sobre uma correção, mas uma solução alternativa foi configurar o login automático para o usuário ansible. Reinicie a instância. Execute a atualização e remova o login automático.
Uma solução muito ruim, a minha fazia parte da criação de uma imagem do Packer, então eu poderia simplesmente adicionar o login automático e removê-lo após as atualizações.
Responder2
fwiw, abri um relatório de bug sobre isso:
https://github.com/ansible-collections/ansible.windows/issues/193