rgl / packer-plugin-windows-update

Packer plugin for installing Windows updates
Mozilla Public License 2.0
307 stars 71 forks source link

Always installing the same update #137

Open ricardofalc opened 12 months ago

ricardofalc commented 12 months ago

Why do my logs indicate that this update is found on an image ive recently updates with this provisioner, every single time? Other updates are installed perfectly, if i use the updated image 1 minute later to search for updates, it always finds the same one.

Is this by design from Microsoft?

Update: [2023-12-01T08:59:48.028Z] --> azure-arm.vm: Found Windows update (2023-09-21; 17.94 MB): Update for Windows Security platform antimalware platform - KB5007651 (Version 1.0.2306.10002)

Full log: [2023-12-01T08:59:08.576Z] --> ==> azure-arm.vm: Running Windows update... [2023-12-01T08:59:17.965Z] --> azure-arm.vm: Searching for Windows updates... [2023-12-01T08:59:48.028Z] --> azure-arm.vm: Found Windows update (2023-09-21; 17.94 MB): Update for Windows Security platform antimalware platform - KB5007651 (Version 1.0.2306.10002) [2023-12-01T08:59:48.029Z] --> azure-arm.vm: Downloading Windows updates (1 updates; 17.94 MB)... [2023-12-01T08:59:52.754Z] --> azure-arm.vm: Installing Windows updates... [2023-12-01T08:59:52.759Z] --> ==> azure-arm.vm: Provisioning with Powershell... [2023-12-01T08:59:52.760Z] --> ==> azure-arm.vm: Provisioning with powershell script: scripts/Start-GuestAgent.ps1 [2023-12-01T09:00:04.277Z] --> ==> azure-arm.vm: Provisioning with powershell script: scripts/Start-Sysprep.ps1

packer build block:


build {
  sources = [
    "source.azure-arm.vm"
  ]

  #The plugin automatically restarts the machine after Windows Updates are applied. Packer is aware that a shutdown is in progress.
  provisioner "windows-update" {
    search_criteria = "IsInstalled=0" # To install updates that are not yet installed
    filters = [
      "exclude:($_.Categories -contains 'FeaturePacks')", # Exclude feature updates
      "exclude:($_.Categories -contains 'ServicePacks')", # Exclude service packs

      "exclude:($_.Categories -like '*Feature*')", # Exclude feature updates
      "exclude:($_.Categories -like '*Service*')", # Exclude service packs

      "include:$true" # If there are no updates to be excluded, install all updates
    ]
  }

  //Sysprep the image and wait for it to complete before capturing the image for reuse.
  provisioner "powershell" {
    scripts = [
      "scripts/Start-GuestAgent.ps1",
      "scripts/Start-Sysprep.ps1"
    ]

  }
}
sykhro commented 8 months ago

Same here, did you ever figure out a workaround?

ricardofalc commented 8 months ago

Same here, did you ever figure out a workaround?

It appears to be intentional on Microsoft's part. Packer utilizes the API provided by Microsoft, so the behavior might not be specific to Packer alone, sometimes the version behind the KB seems to differ aswell.

Also noticed the same updates in other patch systems, and forum posts dating back to 2020 with the same KB identifiers and update name, so it must be by Microsoft design..

sykhro commented 8 months ago

Same here, did you ever figure out a workaround?

It appears to be intentional on Microsoft's part. Packer utilizes the API provided by Microsoft, so the behavior might not be specific to Packer alone, sometimes the version behind the KB seems to differ aswell.

Also noticed the same updates in other patch systems, and forum posts dating back to 2020 with the same KB identifiers and update name, so it must be by Microsoft design..

Pretty bad design: I build a base image and it pulls in a 24GB update. Build another image on top of it not even 10 minutes later and it redownloads the same update. Wondering if perhaps something around the build process strips out update information that aggressively that Windows Update has no clue