Давно/впервые... Используя официальный AWS Windows 2019 AMI ("ami-0229f7666f517b31e" на "us-east-1"), мы запускаем новый экземпляр и выполняем несколько основных задач (используя опцию "user_data") через PowerShell:
- Начать регистрацию
Start-Transcript -Path "c:\user-data.txt"
- Изменить локальный пароль «Администратора»:
$admin = [adsi]("WinNT://./administrator, user")
$admin.PSBase.Invoke("SetPassword", "${password}")
- Включение/настройка WinRM для 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
- Включить RDP:
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -name "fDenyTSConnections" -value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
- Настройте имя хоста:
Rename-Computer -NewName "${name}" -Force
- Остановить регистрацию:
Stop-Transcript
- Перезагрузите компьютер (чтобы изменение имени хоста вступило в силу):
Restart-Computer
На самом деле все довольно просто, мы не видим здесь никаких проблем и проверили, что каждая задача работает так, как и ожидалось.
На этом этапе мы запускаем сценарий Ansible, который выполняет несколько действий (настраивает службы, присоединяется к домену, устанавливает Chocolatey и т. д.), но задача, которая всегда завершается неудачей, — это часть Центра обновления Windows.
В процессе устранения неполадок мы удалили из сценария Ansible все, кроме вызова Центра обновления Windows с помощьюansible.окнаколлекция. Итак, на этом этапе экземпляр развернут, основные задачи PowerShell запускаются через «user_data», а затем Ansible подключается и пытается запустить Центр обновления Windows.
Сама задача Ansible также довольно проста:
- 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
Вот тут-то и начинается странность/раздражение... Когда мы запускаем это, то видим такой ответ:
Failed to search for updates: Exception from HRESULT: 0x80240438
Это происходит КАЖДЫЙ раз, когда мы пытаемся использовать желаемый нами рабочий процесс... Однако мы обнаружили, что если мы один раз интерактивно включаем его перед выполнением задачи Центра обновления Windows, то это работает! КАЖДЫЙ раз!!!
Моя последняя работа была на 99,9% Linux, так что я немного заржавел с этим, но я знаю, что есть безумные/недокументированные вещи, которые происходят при первом (интерактивном) входе. И я пробовал кучу разных вещей (отключил IPv6, запустил wsreset.exe, удалил записи реестра Windows Store, перезапустил службы Windows Update и т. д.) на основе исследования этого кода ошибки... Но единственное, что я вижу, это то, что пока я вхожу в систему интерактивно ДО того, как запустится попытка обновления Windows, все в порядке.
Но, очевидно, мы не хотим этого делать ;)
Еще раз, для ясности:
- Разверните экземпляр (с настройками «user_data», включая перезагрузку), запустите Ansible playbook, который запускает задачу Центра обновления Windows:
Failed to search for updates: Exception from HRESULT: 0x80240438
- Разверните экземпляр (с настройками «user_data», включая перезагрузку), войдите в систему интерактивно (используя RDP), запустите Ansible playbook, который запускает задачу Центра обновления Windows:
Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.329.1737.0)
ПРИМЕЧАНИЕ:Это только текущий ответ, так как в AMI отсутствует только это обновление... Так что это может/должно измениться в будущем.
Кроме того, это не включает в себя присоединение к домену или что-то еще... Хотя я заметил там похожую закономерность. Если я использовал полный плейбук, пока я входил в систему интерактивно, используя пользователя домена до запуска задачи Windows Update, это работало.
Стоит отметить, что когда я вхожу в систему интерактивно, я абсолютно ничего не делаю... Просто вхожу через RDP, а затем не принимаю никаких запросов и ничего не нажимаю.
Очевидно, цель состоит в том, чтобы сделать так, чтобы не было необходимости в ручном входе, так как это противоречит основной цели этого проекта. Поэтому мои вопросы:
- Кто-нибудь знает, что за фигня происходит?!? Есть ли способ симулировать/воспроизвести любые изменения, которые производит интерактивный вход? Я просмотрел логи, но ничего очевидного не увидел.
- Если предположить, что я не смогу исправить это "правильным" способом, есть идеи, как использовать Ansible для выполнения интерактивного входа? Я думаю, сделать задачу, которая интерактивно входит в систему, затем еще одну задачу, которая выходит из нее... Грязно, но не могу продолжать тратить на это время. Твик "user_data" тоже подойдет.
Готов попробовать что угодно на данный момент, единственное, что я могу сказать, это то, что мы не можем изменить используемый AMI (кроме обновления его до последней версии), и необходимо достичь конечного результата процесса "user_data" (но это можно сделать и другими способами, если в этом проблема). Здесь задействован прокси, но я не вижу, как это может быть фактором, поскольку источником проблемы, похоже, является интерактивный вход в систему.
решение1
У меня уже была эта проблема. Не уверен насчет исправления, но обходным путем было настроить автоматический вход для пользователя ansible. Перезагрузите экземпляр. Запустите обновление, затем удалите автоматический вход.
Очень плохой способ решения проблемы, моя проблема была частью создания образа Packer, поэтому я мог просто добавить автоматический вход в систему, а затем удалить его после обновлений.
решение2
fwiw, я открыл отчет об ошибке по этому поводу:
https://github.com/ansible-collections/ansible.windows/issues/193