Add Windows Server 2025

[Kichura]

Tool name

Windows Server 2025

Tool license

Windows EULA (same one used in previous windows versions)

Add or update?

• Add
• Update

Desired version

26100.2605

Approximate size

No response

Brief description of tool

Windows Server 2025 has been released as a new server product, It would be nice if GitHub users could utilize this server version as the Windows OS for their own repositories in order to test new software for any failures and also to check out tools that currently exist in Windows Server 2022 for any possible impacts.

However what is notable is that Windows Server 2025 also supports the ARM64 architecture which could be used to make specific repositories fully ARM-related instead of being forced to use AMD64 in terms of windows specifically, See the OS' What's New page for more infos.

URL for tool's homepage

https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025

Provide a basic test case to validate the tool's functionality.

No response

Platforms where you need the tool

• Azure DevOps
• GitHub Actions

Runner images where you need the tool

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022

Can this tool be installed during the build?

No.

At the moment, You can only use Windows Server 2025 outside of GitHub under a self-hosted virtual machine or by deploying the OS through Docker instead which adds extra time to the actions script.

Tool installation time in runtime

No response

Are you willing to submit a PR?

No as i am not experienced with PowerShell at this time.

However, there is a PR that may resolve this issue.

[erik-bershel]

Hey @Kichura!

We are working on this major change. We will post updates as soon as available.

[Kichura]

Updated the main post to resolve grammar errors, bump OS build to newest available and marked Azure DevOps as needed platform.

EDIT 2: Windows Server 2025 is out of beta/preview and is ready for reproduction use.

[billywr]

@erik-bershel I'd like to pick up this issue if no one is actively working on it

[erik-bershel]

@erik-bershel I'd like to pick up this issue if no one is actively working on it

Work is in progress now. 🧑‍🏭 Unfortunately, this kind of change cannot be developed by the community. 😞

[billywr]

@erik-bershel I'd like to pick up this issue if no one is actively working on it

Work is in progress now. 🧑‍🏭 Unfortunately, this kind of change cannot be developed by the community. 😞

Well noted, is there a tag for the tasks/issues meant for the community?

[erik-bershel]

Well noted, is there a tag for the tasks/issues meant for the community?

Well, the problem here is not that we prohibit doing this. The problem is that the community has no simple opportunity to do this - the relevant processes and tasks are not in the public domain due to the security reasons. Answering your question more directly, I can say that we do not accept edits from the community to the macOS branch only by the same security reasons.
If you can develop all the necessary changes to create a base image of Windows 2025, we will be happy to have you participate. It will just be more labor-intensive for you to do this than for a team.

[chadgolden1]

Hi there! 👋

With Windows Server 2025 introducing Dev Drive as a native feature, this presents an opportunity to significantly improve Windows runner I/O performance, possibly addressing concerns such as those in #8755 and #7320.

I've benchmarked the I/O performance of C:, D:, and ReFS-based virtual hard disk drives (E:) on windows-2022 runners, and the performance differences (IOPS) are quite remarkable (30X faster ‼️):

💾 Drive	🚀 IOPS
C:	4261.64
D:	83587.64
E: (C:\dev_drive.vhdx)	127822.75
E: (D:\dev_drive.vhdx)	124335.26

These results demonstrate that ReFS-based virtual drives provide significantly better IOPS compared to the C: drive. Dev Drive, being purposely built for development workloads, should provide similar performance benefits, perhaps without requiring manual VHDX creation.

Would the team consider implementing Dev Drive or similar I/O improvements as part of the Windows Server 2025 runner image configuration?

[Kichura]

Hi there! 👋

With Windows Server 2025 introducing Dev Drive as a native feature, this presents an opportunity to significantly improve Windows runner I/O performance, possibly addressing concerns such as those in #8755 and #7320.

I've benchmarked the I/O performance of C:, D:, and ReFS-based virtual hard disk drives (E:) on windows-2022 runners, and the performance differences (IOPS) are quite remarkable (30X faster ‼️):
💾 Drive 🚀 IOPS
C: 4261.64
D: 83587.64
E: (C:\dev_drive.vhdx) 127822.75
E: (D:\dev_drive.vhdx) 124335.26

These results demonstrate that ReFS-based virtual drives provide significantly better IOPS compared to the C: drive. Dev Drive, being purposely built for development workloads, should provide similar performance benefits, perhaps without requiring manual VHDX creation.

Would the team consider implementing Dev Drive or similar I/O improvements as part of the Windows Server 2025 runner image configuration?

Not sure if possible given that the windows images are using NTFS at the moment mainly due to stability reasons but this is interesting.

[erik-bershel]

Would the team consider implementing Dev Drive or similar I/O improvements as part of the Windows Server 2025 runner image configuration?

Technically unfeasible at the moment due to architectural reasons. We will return to this issue when such an opportunity arises and not earlier.

[chadgolden1]

Not sure if possible given that the windows images are using NTFS at the moment mainly due to stability reasons but this is interesting.

Technically unfeasible at the moment due to architectural reasons. We will return to this issue when such an opportunity arises and not earlier.

Thank you for these responses. That's fair. The performance differences, 20X in the previous benchmark, between C: and D: are astounding to me. I look forward to this major change. Cheers!

[Kichura]

Closing this issue because image is now available to the public.