Apparently, Windows 11 24H2 removes the following ciphers:

• TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_RSA_WITH_RC4_128_SHA

• TLS_RSA_WITH_RC4_128_MD5

So, these have to be added back and enabled.

PowerShell code to add these ciphers back and enable them

You can use the following PowerShell code to add these ciphers back and enable them. After running, the script calls out that you need to reboot also for these changes to take effect.

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002"
$currentCiphers = (Get-ItemProperty -Path $regPath).Functions

# Legacy cipher suites for SQL 2005
$legacySuites = @(
    "TLS_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_RSA_WITH_RC4_128_SHA",
    "TLS_RSA_WITH_RC4_128_MD5"
)

# Add missing cipher suites to the SSL Functions list
$missing = $legacySuites | Where-Object { $_ -notin $currentCiphers }
if ($missing.Count -gt 0) {
    Write-Output "Adding missing cipher suites: $($missing -join ', ')"
    $newList = $currentCiphers + $missing
    Set-ItemProperty -Path $regPath -Name "Functions" -Value $newList
} else {
    Write-Output "All required cipher suites already present."
}

# Enable legacy cipher algorithms in SCHANNEL
$cipherPaths = @(
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128",
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128",
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128",
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128",
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168"
)

foreach ($path in $cipherPaths) {
    if (-not (Test-Path $path)) {
        New-Item -Path $path -Force | Out-Null
    }
    Set-ItemProperty -Path $path -Name "Enabled" -Value 1 -Type DWord
}

Write-Output "Legacy ciphers are now enabled. Please reboot to apply changes."

Trust me, if you are automating your Windows estate, you likely will get frustrated with WinRM and other native ways to administer your Windows Server. OpenSSH is free, its fairly easy to install, and it allows you to run commands and copy files remotely with only a single network port needed, port 22.

In Windows Server, navigate to Settings > Apps > Optional features and search for OpenSSH. Add the OpenSSH Server option.

Once you have the component installed, then we need to change the configuration of the Windows service to start automatically. By default it is set to Manual. We need to set this to Automatic.

Set the service to automatic.

Setting to automatic will make sure it will start when the server starts. When you start the service, it will create and populate the following directory: C:\ProgramData\ssh.

Install OpenSSH with PowerShell

You can also use PowerShell to install the Windows feature. To install OpenSSH SSH Server using PowerShell, use the following command from an admin PowerShell prompt:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

After you install it with PowerShell, you will need to follow the same steps above to set the service to automatic. You can also do this with PowerShell as well:

Start-Service -Name "sshd" 

Set-Service -Name "sshd" -StartupType Automatic 

SSHD_config file

The sshd_config file is the heart of the solution's configuration. You can open this file up and make changes to configuration settings there. Below is an example of what your sshd_config file might look like. Below, I have enabled public key authentication and commented out the Group Administrators line as this can cause issues with public key authentication. Keep in mind if you change anything in this file, you will need to restart the OpenSSH SSH Service.

Note below, I have changed the SyslogFacility LOCAL0 and LogLevel Debug3. Adding this configuration for logging will allow logging to be captured in the "logs" folder of the c:\programdata\ssh folder. 

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
SyslogFacility LOCAL0
LogLevel Debug3

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

#AuthorizedPrincipalsFile none

# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# GSSAPI options
#GSSAPIAuthentication no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Public key authentication

To get public key authentication to work, you need to perform the following steps:

• Generate a key pair (on the machine you will be connecting from)
  • To do this, you an use the ssh-keygen command. It will step you through creating the public and private key pair
• Copy the public side of the public/private key pair to the target server you will be connecting to
• Make sure you have firewall exceptions for port 22 on your target server and any firewalls in between your workstation and Windows Server
• For the user you want to target to use with the public key authentication, you need to create an authorized_keys file in the path c:\users\<user>\.ssh folder. In this file, you will paste the contents of the public key file you generated with the ssh-keygen file. This will tie the private key and public key components together when you connect. 
• Use the user you have the public key configured with on the target server when you call the SSH command

Connecting using public key authentication

To connect using public key authentication, you can call the private key with the ssh command which will pass along the private key component for authentication against the public key. You will also pass in the user that you are using on the target side:

ssh -i private_key administrator@<ip or fqdn of windows server>

Issue Details

The issue is around servers booting from an iSCSI LUN under NDIS Poll Mode. Microsoft first noted this the bug in late October 2024 and said it affected servers and these would encounter a boot error after completing the installation of Windows Server 2025.

What is iSCSI?
iSCSI or (Internet Small Computer Systems Interface) is a storage protocol that allows ones to connect to remote storage over TCP/IP. It allows it to use SCSI commands over IP networks. This allows remote storage on a storage area network (SAN) to appear as if it were a local disk. This type of storage is commonly used in virtualization, centralized storage, and data center environments.

Fix Released in February Updates

Microsoft has resolved the issue mentioned with the February 11, 2025 update (KB5051987).

🛠️ Solution: Microsoft recommends installing the latest cumulative update. It will include this fix along with other improvements.

Additional Fixes in KB5051987:

• Resolved USB audio and camera issues that occurred after the January 2025 security updates.

Other Windows Server 2025 Fixes

There are other fixes in recent updates as well:
✅ November 2024: Fixed bugs causing installation, upgrade failures, and BSODs on high-core count servers
✅ December 2024: Resolved boot failures on Windows Server 2022 with multiple NUMA nodes

Windows Server 2025 Availability

Windows Server 2025 (LTSC release) became generally available in early November. You can grab a copy to of Windows Server 2025 to play around with from the Microsoft Evaluation Center. This is a really great option for home labs and other test environments.

Important Takeaways

📌 If you're running Windows Server 2025 with iSCSI, make sure to install the KB5051987 update. This will help to make sure to prevent boot errors. Let me know if you have seen this issue? Let's discuss it.

Well, that is a good question and in a perfect world, we don’t want to have to do that. In fact, Microsoft is doing a good thing by deprecating old or weak configuration settings and weak ciphers. However, unfortunately, many of us support applications or environments where legacy software and apps may still require old versions of SSL, TLS, and ciphers.

As an example, I recently had an issue with a developer where he was trying to connect a new Windows 11 VM he was running to an old SQL 2005 server (yeah I know SQL 2005, shaking head frustratingly). However, needs like this still exist.

Chasing down the registry keys needed to turn these settings back on can be frustrating as well. It can be confusing what you need to enable and which keys need to be added, etc.

Best SSL and TLS configuration tool for Windows

There is a GUI tool that makes life much much easier for admins and DevOps engineers alike. The tool is from a company called Nartac and is called IIS Crypto. You can download it here: Nartac Software – IIS Crypto.

You can download the IIS crypto GUI tool or the CLI. While the tool is developed for the use case of helping with enabling protocols and ciphers on web servers, it can also be used to configure SSL and TLS configurations on Windows clients as well and I have used it in this way many times. Whatever your need is, it will help either way.

Here, I have downloaded the IIS Crypto tool. One thing I like about it is it is a self-contained executable. You just execute the .EXE and it won’t install anything, it will just run. Everything will look greyed out but you can click the protocols, ciphers, etc that you want.

And, best of all, you don’t have to edit the registry or get into the nitty gritty details of what you need to do to enable or disable protocols and ciphers.

One feature I really like about the program is that it has a best practices button that allows you with a single click of a button to enable the recommended protocols and ciphers based on security recommendations. As we will see below, the template that it works from is configurable.

When you click the Cipher Suites, you will see the Ciphers listed that are configurable and you can simply click the ones you want.

If you click the Advanced button, you will see advanced settings like DHC Minimum Key length, FIPs algorithm settings, etc.

When you click Templates, you will see where you can configure the best practices template that is used to show you the recommended protocols and cipher suites.

Site scanner found in the IIS Crypto tool lets you scan a website/webserver to see which protocols and ciphers are allowed to see if these are set to best practices.

Make SSL and TLS changes cautiously

While taking away weaker and older protocols and ciphers may at worst cause certain clients or apps to stop working, adding old or weak SSL and TLS protocols and ciphers can give attackers what they need to compromise your web server or your network. So, make changes, especially those that add old or weak technologies very carefully and only really as a last resort to satisfy a necessary configuration.

This is a pretty incredible deal I think for home labbers and other enthusiasts who want the benefits of the business edition of Windows 11 Pro. There are a few things that I think make this version of Windows definitely preferable over Home edition. This includes:

• Hyper-V - When you upgrade to Windows 11 Pro, you get access to client Hyper-V which is arguably probably one of the best desktop virtualization solutions. Where most other desktop virtualization solutions are type 2 hypervisors, Hyper-V is a Type 1 hypervisor. It instantiates your operating system as a management operating system so it actually runs the management operating system on top of Hyper-V instead of the other way around.
• BitLocker - You get BitLocker encryption when you go Windows 11 Pro version which is a great way to secure your data
• Azure AD - You can join to Azure AD with Windows 11 Pro
• Active Directory join - You can also join to legacy Active Directory Domain Services (AD DS) which is something that many are playing around with or running in home lab environments.
• Smart App Control - Ability to protect your Windows client operating system from other security threats when apps are launching
• Biometric login - You get Biometric login with Windows 11 Pro as well

There are many great reasons to have Pro over Home version any day in my opinion. You can check out the offer for Windows 11 Pro upgrade for $20 here:

Microsoft Windows 11 Pro | PCWorld

Let me know what you guys think about this deal.

It has had a long run, being introduced in 2005, it is one of those utilities that I think we all agree that we "love to hate". When it works, it works good, but sometimes it doesn't work. However, I would say by in large, it is still the primary tool that enterprise organizations have been using on-premises for decades and are only now starting to see they need to find alternative solutions for.

Updates will continue to be published through WSUS "for now"

Now that WSUS is deprecated, it doesn't mean Microsoft is immediately pulling the plug. Instead, it sounds like they will take a phased approach. 

Microsoft has officially announced that Windows Server Update Services (WSUS) is now deprecated, but plans to maintain current functionality and continue publishing updates through the channel.

It is one of the services that it mentioned in the article:

Features removed or no longer developed starting with Windows Server 2025 (preview) that will be either removed or deprecated in Windows Server 2025 Preview. 

Writing been on the wall for it going away for quite some time

WSUS is one of those services that we really haven't seen an update to in 3 forevers! I mean, I believe we have been on WSUS 3.1 since Windows 2008 or so (don't check me on that), but you guys get the point, it just hasn't much and hasn't really been a service that Microsoft has looked to invest in, in quite some time now.

Microsoft hasn't change or added anything new in quite some time and it looks like now the full plan is written in stone, complete deprecation in favor of other services:

• Windows Autopatch
• Microsoft Intune
• Azure Update Manager

Will it be found in Windows Server 2025?

Yes, it looks like it will still be included as a role in Windows Server 2025, but this looks to be the end of the road Windows Server OS for WSUS.

What do you guys think about this? Any readers here in the VHT forum currently managing WSUS and looking at other solutions or actively migrating to another solution?