How to prevent Windows 10 feature updates from creating a recovery partition?

In our lab, we have a few dozens of dual-boot computers installed with Windows 10 and Ubuntu, using either legacy (CSM) or UEFI boot depending on the machine. In both cases, GRUB2 is used as a bootloader. All the machines have a custom partitioning scheme without a Windows recovery partition, as the latter is not needed for Windows to properly boot/work. If a machine has issues, we rather reimage it from the network (using a PXE booted Linux).

Now the problem comes with Windows feature updates, the latest being version 2004 (EDIT: at the time this question was written, but the problem continues with more recent updates like 21H1). When one of these updates installs, it somewhat shrinks the Windows system partition to add back the recovery partition. Given its reduced size it would be fine to leave it alone, but this operation breaks GRUB as the Linux partition changes number, and the first stage of GRUB doesn't understand partition labels to find its second stage (even on UEFI machines). If a machine is hanged on a GRUB rescue prompt, there's no way to remotely correct the issue... sometimes leaving offline for hours (if not more) machines that must remain remotely accessible.

As we don't have any use for the recovery partition, the question is how to prevent the updates from creating it in the first point? Of course we could have it there when imaging the machines, but given that we don't actually want it, it seems just a waste of disk space.

EDIT for clarity: (a) The partition I'm mentioning is not the FAT32 formatted UEFI system partition (ESP), without which Windows could not even boot on UEFI setups. It is NTFS formatted and has a size of 400-500 MB. We don't have any reasons of getting rid of ESP on UEFI systems, it is also required by UEFI-GRUB by the way... (b) I've observed a few cases where the recovery partition doesn't get created, while the update succeeds. It might be related to the available space on the system partition, or from the number of primary partitions on MBR systems (4 being the maximum—if there are already 4, Windows could not add another one so easily). (c) Mainly looking at how to prevent this on currently installed systems. For future installations, we can include a precreated recovery partition to prevent updates from changing the partition scheme.

EDIT: after observation of the issue on several machines for several months, it appears that (a) the update process properly works without the recovery partition, and (b) the partition is never created on MBR-formatted disks that already have 4 primary partition and no extended one. One solution could therefore be to have the PXE-loaded code running pre-boot to create placeholder partitions to fill the MBR table... but modifying the MBR can always be source of trouble. On UEFI machines though, I don't see a clear solution as the GPT always has enough entries for the recovery partition to be created.

Windows 10 requires the system partition to function properly. One of the reasons is the upgrade process which requires it.

Rather then fight against how the system works you should repartition your disks. As you are deploying centrally from the server, this shouldn’t be an issue.

When you deploy Windows to a UEFI-based device, you must format the hard drive that includes the Windows partition by using a GUID partition table (GPT) file system. Additional drives may use either the GPT or the master boot record (MBR) file format.

System partition

The device must contain a system partition. On GPT drives, this is known as the EFI System Partition, or the ESP. This partition is usually stored on the primary hard drive. The device boots to this partition. The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format.

Source: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions