Update for new Ubuntu 24.04 and Windows 2025 DW images

src/pages/docs/best-practices/octopus-administration/worker-configuration.md

@@ -23,25 +23,26 @@ The leasing algorithm is not round-robin.  It looks for the worker with the leas
 :::
 
 Some important items to note about workers:
+
 - Unlike deployment targets, workers are designed to run multiple tasks concurrently.  
 - **Octopus Server 2020.1** added the [Worker Pool Variable Type](/docs/projects/variables/worker-pool-variables) making it possible to scope worker pools to environments.
 - **Octopus Server 2020.2** added the [execution container for workers](/docs/projects/steps/execution-containers-for-workers) feature, making it easier to manage software dependencies.
 - We provide a [Tentacle Docker image](https://hub.docker.com/repository/docker/octopusdeploy/tentacle) that can be configured to run as a worker.
 
 ## Provided Workers
 
-The Octopus Server includes a [built-in worker](/docs/infrastructure/workers/built-in-worker).  When you configure a deployment or runbook to run tasks on the server, it is handing off that work to the built-in worker.   
+The Octopus Server includes a [built-in worker](/docs/infrastructure/workers/built-in-worker).  When you configure a deployment or runbook to run tasks on the server, it is handing off that work to the built-in worker.
 
 :::div{.hint}
-Octopus Cloud is running the Octopus Linux container.  To ensure maximum cross-compatibility with both Windows and Linux, the built-in worker is disabled on Octopus Cloud.  Instead, we provide you with the ability to choose from 2 [dynamic workers](/docs/infrastructure/workers/dynamic-worker-pools), Windows Server 2019 and Ubuntu 22.04.  Each worker type is a different worker pool.
+Octopus Cloud is running the Octopus Linux container.  To ensure maximum cross-compatibility with both Windows and Linux, the built-in worker is disabled on Octopus Cloud.  Instead, we provide you with the ability to choose from 2 [dynamic workers](/docs/infrastructure/workers/dynamic-worker-pools).  Each worker type is a different worker pool.
 :::
 
 The built-in worker and [dynamic workers](/docs/infrastructure/workers/dynamic-worker-pools) were created to help get you started.  Using them at scale will quickly expose their flaws.
 
 - The built-in worker will run under the same account as the Octopus Deploy service.  By default, that is `Local System`.  You can change it to run under a different account, but it can only run under one account.  You cannot change that account during a deployment or runbook run.
 - The built-in worker may or may not be in the same data center as your deployment targets.  You could experience some significant latency.
 - Dynamic workers and built-in workers are limited to the software installed on the host servers.  This includes specific software.  Upgrading to a newer version results in a "big bang" change in your CI/CD pipeline which increases risk.
-- The IP address assigned to dynamic workers will change at most once an hour and at least once every 72 hours. 
+- The IP address assigned to dynamic workers will change at most once an hour and at least once every 72 hours.
 - Dynamic workers are assigned to an entire instance, not just a space.  We have seen cases where a deployment blocks on one space, blocking a deployment on another space because they both used the same dynamic worker.
 - There is only one dynamic worker per pool.  Workers have some blocking tasks (install Calamari and downloading a package).  If a process needs to acquire a mutex for that blocking task, it has to wait until other tasks are done.
 

src/pages/docs/infrastructure/workers/dynamic-worker-pools.md

@@ -97,6 +97,20 @@ Each `Ubuntu Server 22.04` worker is provisioned with a baseline of tools includ
 Ubuntu workers are designed to use [execution worker containers](https://octopus.com/blog/execution-containers) for tooling like `kubectl` and `helm`. This makes it much easier to choose the appropriate runtime environment with the tools you need for your use case.
 :::
 
+### Ubuntu 24.04
+
+Each `Ubuntu Server 24.04` worker is provisioned with a baseline of tools including (but not limited to):
+
+- .NET (10.0, 8.0)
+- Docker (29.5.3)
+- PowerShell Core (7.6.2)
+- Python 3 (latest for Ubuntu 24.04)
+- GCloud CLI (566.0.0)
+
+:::div{.hint}
+Ubuntu workers are designed to use [execution worker containers](https://octopus.com/blog/execution-containers) for tooling like `kubectl` and `helm`. This makes it much easier to choose the appropriate runtime environment with the tools you need for your use case.
+:::
+
 ### Windows Server Core 2022
 
 This is the default for the Windows operating system, referenced as `Windows (default)`.
@@ -110,7 +124,7 @@ Each `Windows Server Core 2022` worker is provisioned with a baseline of tools i
 - Chocolatey (latest)
 - Docker (latest)
 - Helm (3.19.4)
-- Kubectl (multiple versions)
+- Kubectl (1.35.1, 1.34.4, 1.33.8, 1.32.12)
 - Microsoft Service Fabric (10.1.2338.9590)
 - Microsoft Service Fabric SDK (7.1.2338)
 - Nuget CLI (latest)
@@ -126,16 +140,37 @@ Windows 2022 workers are capable of running [execution worker containers](/docs/
 We recommend execution containers as the preferred option for steps requiring external tools. This allows you to control which version of the tools will be used as your scripts will rely on a specific version that they are compatible with to function correctly.
 :::
 
+### Windows Server Core 2025
+
+Each `Windows Server Core 2025` worker is provisioned with a baseline of tools including (but not limited to):
+
+- .NET (10.0, 8.0)
+- .NET Framework 4.8 (Default for Windows Server 2025)
+- AWS IAM Authenticator (0.7.17)
+- Chocolatey (2.7.2)
+- Docker (29.5.2)
+- Helm (3.20.1)
+- Kubectl (1.36.1, 1.35.5, 1.34.8, 1.33.12)
+- Microsoft Service Fabric (10.1.2338.9590)
+- Microsoft Service Fabric SDK (7.1.2338)
+- Nuget CLI (latest)
+- Octopus Client (latest)
+- Pip (latest)
+- PowerShell Core (7.6.2)
+- Python (3.14.5)
+- GCloud CLI (566.0.0)
+
+Windows 2025 workers are capable of running [execution worker containers](/docs/projects/steps/execution-containers-for-workers).
+
+:::div{.hint}
+We recommend execution containers as the preferred option for steps requiring external tools. This allows you to control which version of the tools will be used as your scripts will rely on a specific version that they are compatible with to function correctly.
+:::
+
 ## kubectl on Windows Images
 
 Windows dynamic worker images come with many versions of `kubectl` available.
 
-A specific version can be used by [specifying a custom kubectl location](/docs/deployments/kubernetes/kubectl) of `c:\tools\kubectl\{{version}}\kubectl.exe`, where `{{version}}` is one of the following:
-
-- `1.32.12`
-- `1.33.8`
-- `1.34.4`
-- `1.35.1`
+A specific version can be used by [specifying a custom kubectl location](/docs/deployments/kubernetes/kubectl) of `c:\tools\kubectl\{{version}}\kubectl.exe`, where `{{version}}` is one of the versions specified above for your dynamic worker version.
 
 ## Installing Software On Dynamic Workers