Ansible Playbook修改SKU后执行失败：VM部署遇致命错误

Hey there, let's break down this issue and get your Playbook back on track!

First, let's decode that error: exit code 1618 is a standard Windows Installer (MSI) error that means another MSI-based installation is already running on your corest-tsir00 VM. Windows blocks concurrent MSI installs by design, so your JRE installer can't launch because another setup process is still active in the background.

Here's how to troubleshoot and fix this:

Step 1: Check for active MSI processes on the VM #

RDP into the corest-tsir00 machine, open Task Manager, and navigate to the Details tab. Look for any running msiexec.exe processes. If you find any, end them gracefully, then re-run your Ansible Playbook to see if the issue resolves.

Step 2: Add a retry loop to handle transient race conditions #

This error often stems from timing issues (other infrastructure setup tasks finishing up in the background). Update your Ansible task to automatically retry the install, giving ongoing processes time to complete:

- name: Install Java Runtime Environment
  win_package:
    path: C:\ExeSources\jre8u191windowsx64.exe
    state: present
  register: jre_install
  until: jre_install is succeeded or jre_install.rc != 1618
  retries: 5
  delay: 30

This will retry the install up to 5 times, waiting 30 seconds between each attempt.

Step 3: Verify SKU changes didn't introduce parallel installs #

Double-check your modified Playbook to ensure you didn't add any other win_package or MSI-based tasks that run in parallel with the JRE install. Ansible runs tasks sequentially by default, but if you're using async/poll for any tasks, that could trigger conflicting concurrent MSI operations.

Step 4: Rule out pending system restarts #

Even though the error output says reboot_required: false, sometimes a prior installation can leave MSI locks that only a restart clears. Try manually restarting the VM, then re-run your pipeline.

Step 5: Validate the JRE installer file #

Ensure the jre8u191windowsx64.exe file on the VM isn't corrupted (a possible side effect of SKU changes or re-provisioning). You can add a task to re-copy the installer to the VM before the install step, or manually verify its checksum against the original file.

内容的提问来源于stack exchange，提问作者user12886057