Windows Update

[mtelvers]

There are four Windows containers available on the Microsoft Container Registry (MCR), they are:

• Windows (aka Windows Workstation)
• Windows Server
• Windows Server Core
• Nano Server https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images

C:\Users\Administrator>docker exec --rm -it mcr.microsoft.com/windows:ltsc2019
Microsoft Windows [Version 10.0.17763.5458]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>systeminfo

Host Name:                 484C716DA479
OS Name:                   Microsoft
OS Version:                10.0.17763 N/A Build 17763
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation

The Windows (Workstation) images have many tags, but the current ones are these (and are all the same image):

• ltsc2019
• 10.0.17763.5458
• 1809
• 1809-KB5034768
• ltsc2019-amd64
• 10.0.17763.5458-amd64
• 1809-amd64
• 1809-KB5034768-amd64

ltsc2019 is always the latest edition.

PS C:\Users\Administrator> docker run --rm -it mcr.microsoft.com/windows/server:ltsc2022
Microsoft Windows [Version 10.0.20348.2322]
(c) Microsoft Corporation. All rights reserved.

C:\>systeminfo

Host Name:                 77E7714D53CC
OS Name:                   Microsoft Windows Server 2022 Datacenter
OS Version:                10.0.20348 N/A Build 20348
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Server
OS Build Type:             Multiprocessor Free
Registered Owner:          N/A
Registered Organization:   N/A
Product ID:                00454-60000-00001-AA992

The Windows Server images also have many tags, but the current ones are these (and are all the same image):

• ltsc2022-KB5034770
• ltsc2022
• 10.0.20348.2322
• 10.0.20348.2322-amd64
• ltsc2022-KB5034770-amd64
• ltsc2022-amd64

ltsc2022 is always the latest edition.

Interestingly, Server Core still supports LTSC 2016, 2019 and 2022.

In src-opam/distro.ml we have tried to maintain a list of Windows 10 releases which historically could be used to map to the tag on MCR, however, the current version of Windows is 22H2 but there is no tag. There are some other tags such as 20H2 and 2004 but they have been deprecated since 2022. We cover this discrepancy by having win10_latest_image and win10_latest_release.

We have also have a table of Latest Cumulative Updates (LCU) dates and Knowledge Base (KB) article numbers in win10_lcus. This table is a mix of Windows Server and Windows workstation releases. Given the fragment below:

• KB5032198 applies to Windows Server 2022
• KB5032189 applies to Windows (Workstation) 21H2 and 22H2
• KB5032196 applies to both Windows Server 2019 and Windows (Workstation) 1809

let win10_lcus : ('a * int * win10_release list) list =
  [
    (`LCU20231114, 5032198, [ `V21H2 ]);
    (`LCU20231114, 5032189, [ `V21H1 ]);
    (`LCU20231114, 5032196, [ `V1809 ]);

We have been treating Windows Server as a later build of Windows (Workstation).

This PR acknowledges this difference by adding WindowsServer as a type in os_family_of_distro. Then updates distro to recognize the two variants:

@@ -554,81 +327,15 @@ let distros : t list =
     `Ubuntu `V23_10;
     `Ubuntu `Latest;
     `Ubuntu `LTS;
+    `Cygwin `Ltsc2016;
+    `Cygwin `Ltsc2019;
+    `Cygwin `Ltsc2022;
+    `Windows (`Mingw, `Ltsc2019);
+    `Windows (`Msvc, `Ltsc2019);
+    `WindowsServer (`Mingw, `Ltsc2022);
+    `WindowsServer (`Msvc, `Ltsc2022);
   ]

In summary, rather than having a table of Windows editions and loosely mapping that on to the available Docker images, this approaches it from what Docker images are available and surfacing those as the Windows releases. This approach more closely matches that of the Linux distributions and standardizes much of the file layout.

This will also simplify maintenance as the base image builder will automatically pull the latest revision on the weekly rebuild cycle.

[mtelvers]

I am struggling to get the KB number: from within Windows, we can list the installed hotfixes and the associated KB numbers, e.g. Get-Hotfix, but the commands don't return a single KB. They return several, such as the latest SSU, and .Net CU and the Windows CU.

The Microsoft Container Registry API (aka the Docker API) doesn't directly provide a way to list tags which point to the same image. We can list tags with curl -s -H "Accept: application/vnd.docker.distribution.manifest.list.v2+json" https://mcr.microsoft.com/v2/windows/manifests/ltsc2019 and iterate over them curl -s -H "Accept: application/vnd.docker.distribution.manifest.list.v2+json" https://mcr.microsoft.com/v2/windows/manifests/$tag to find images with the same digest.

We could use ver to get something like 10.0.17763.5576. This is published as a tag; thus, FROM mcr.microsoft.com/windows/servercore:10.0.17763.5576 would work.

The next issue is getting that value into the base image builder. OCaml-CI has the same issue as it wants to obtain various opam vars from a Docker image, and we do that by running the image on the OCaml-CI server. The challenge is that Microsoft Windows containers can't be executed on a Linux server.

We can create an obuilder job spec as below and submit that to the cluster. Ocluster/obuilder jobs don't return anything other than the image ID, so we would need to parse the log output. ocluster-client -c ~/mtelvers.cap submit-obuilder --pool windows-1809-x86_64 --local-file ver.spec

 ((from mcr.microsoft.com/windows/servercore:ltsc2019)
 (run (shell "ver")))

However, it occurs to me that, in terms of repeatability, even if we say from windows:ltsc2019, providing the log indicates the actual version/image that was used, anyone trying to reproduce the exact set of conditions would be able to do so. As it stands, this information is available:

Step 1/56 : FROM mcr.microsoft.com/windows:ltsc2019 as winget-builder
ltsc2019: Pulling from windows
Digest: sha256:5a7c981ca39d069ae40bd344fe464494465b329d19c2fa262c4a556780008c7d
Status: Image is up to date for mcr.microsoft.com/windows:ltsc2019

At some future point, when the tag ltsc2019 has moved forward, we could reproduce this step with:

FROM mcr.microsoft.com/windows:ltsc2019@sha256:5a7c981ca39d069ae40bd344fe464494465b329d19c2fa262c4a556780008c7d as winget-builder

We could add a specific RUN step to output the current KBs, Windows version or the entire output of systeminfo.