久しぶり/初めて...公式 AWS Windows 2019 AMI (「us-east-1」の「ami-0229f7666f517b31e」) を使用して、新しいインスタンスを起動し、PowerShell 経由でいくつかの基本的なタスク (「user_data」オプションを使用) を実行します。
- ログ記録を開始
Start-Transcript -Path "c:\user-data.txt"
- ローカルの「管理者」パスワードを変更します:
$admin = [adsi]("WinNT://./administrator, user")
$admin.PSBase.Invoke("SetPassword", "${password}")
- Ansible 用に WinRM を有効化/構成する:
$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
実に基本的なもので、問題となるようなことは何も見当たらず、各タスクが期待どおりに動作していることも確認済みです。
この時点で、いくつかの処理 (サービスの構成、ドメインへの参加、chocolatey のインストールなど) を実行する Ansible プレイブックを実行しますが、常に失敗するタスクは Windows Update の部分です。
トラブルシューティングのプロセスでは、AnsibleプレイブックからWindows Updateを呼び出す以外のすべてを削除しました。アンシブル.windowsコレクション。この時点で、インスタンスがデプロイされ、基本的な PowerShell タスクが「user_data」を介して実行され、その後 Ansible が接続して Windows Update を実行しようとします。
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 Update タスクが実行される前に対話的に 1 回実行すると、機能することがわかりました。毎回!!!
私の前職は 99.9% Linux だったので、この点については少し鈍感ですが、最初の (対話型) ログイン時に奇妙な/文書化されていないことが起こることは知っています。また、そのエラー コードを調査して、さまざまなことを試しました (IPv6 を無効にする、wsreset.exe を実行する、Windows ストアのレジストリ エントリを削除する、Windows Update サービスを再起動するなど)。ただし、Windows Update の実行前に対話型で 1 回ログインすれば、すべて問題ないということしかわかりません。
しかし、明らかに私たちはそれをしたくありません;)
もう一度明確にしておきます:
- インスタンスをデプロイし (「user_data」の調整 (再起動を含む) を実行)、Windows Update タスクを実行する Ansible プレイブックを実行します。
Failed to search for updates: Exception from HRESULT: 0x80240438
- インスタンスをデプロイし (「user_data」の調整 - 再起動を含む)、対話形式でログインし (RDP を使用)、Windows Update タスクを実行する Ansible プレイブックを実行します。
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、これについてはバグレポートを開きました: