How to Fully Disable SMB v1 on Windows Server 2022 with PowerShell

SMB v1 is a legacy protocol with known vulnerabilities like WannaCry and should not be exposed on any modern network. In my environment, I treat it as a critical finding during internal audits — even if no legacy systems are known to exist, the risk of accidental exposure or lateral movement is too high. The good news is that Windows Server 2022 makes it straightforward to disable SMB v1 completely using PowerShell, and you can do it without rebooting in most cases. Before you disable it, however, you should verify whether any devices or applications still depend on it to avoid breaking production services.

Check Current SMB v1 Status

The first step is to confirm whether SMB v1 is currently enabled on the server. You can do this by querying the Windows feature state using PowerShell. Run this command with administrative privileges:

Get-WindowsFeature FS-SMB1

If the State field shows Installed, SMB v1 is active and needs to be removed. If it shows Available or Removed, it’s already disabled. In one of my recent hardening passes, I found SMB v1 enabled on a domain controller that had been upgraded from Server 2016 — an oversight during migration that went unnoticed for months.

Disable SMB v1 Using PowerShell

To disable SMB v1, you remove the FS-SMB1 feature. This can be done online without requiring a reboot in Windows Server 2022. Use the following command:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -NoRestart

The -NoRestart flag prevents an immediate reboot, which is useful if you're managing the server remotely or during business hours. However, a reboot may still be required later for the change to take full effect, especially if any services are actively using SMB v1. After running this, verify the status again with Get-WindowsFeature FS-SMB1 — it should now show Available or Removed.

Confirm Disabling with Registry and Scanning Tools

While PowerShell reports the feature state, I like to double-check using the registry and network scanning. SMB v1 is controlled by the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

The SMB1 value should be set to 0 to disable it. You can check it like this:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name SMB1

If the value is missing or set to 0, SMB v1 is disabled. Additionally, I use nmap from a Linux jump host to scan for SMB v1 responsiveness:

nmap -p 445 --script smb-protocols <windows-server-ip>

If the script returns nothing or only shows SMB v2/v3, the disable was successful. In my lab, I’ve seen cases where the feature was removed but the registry still showed remnants due to incomplete cleanup — always verify both sides.

Measure Impact on Legacy Clients

Before disabling SMB v1 in production, assess whether any legacy devices or applications rely on it. Older systems like Windows XP, Server 2003, or certain NAS appliances may still use SMB v1. You can monitor SMB version usage using built-in logging:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Then enable SMB v1 logging temporarily:

Set-SmbServerConfiguration -EnableSMB1ProtocolLogging $true

Check the logs under:

Applications and Services Logs > Microsoft > Windows > SMBServer > Operational

Look for Event ID 3000, which indicates an SMB v1 connection attempt. In one case, I discovered an old backup appliance still using SMB v1 only after enabling this logging — it had flown under the radar for over a year.

Re-enable Only If Absolutely Necessary

If you find a critical dependency, re-enabling SMB v1 is possible but should be a temporary workaround:

Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

After enabling, apply strict network restrictions: limit SMB v1 access to specific IPs using firewall rules, and never expose it to untrusted networks. Document the dependency and create a plan to upgrade or replace the legacy system. In my experience, most SMB v1 dependencies can be eliminated within 60 days once identified — often just a firmware update or client reconfiguration away.

Final Verification and Hardening Tips

After disabling SMB v1, include it in your baseline security checks. I add a simple validation step to my server hardening scripts:

if ((Get-WindowsFeature FS-SMB1).Installed) {
    Write-Warning "SMB v1 is still enabled!"
    exit 1
}

This ensures the setting doesn’t drift back due to policy changes or manual overrides. Also, ensure SMB v2 and v3 are properly configured — encryption, signing, and dialect filtering should be enabled where possible. As I mentioned before in my post about securing external writes with Spark Structured Streaming, disabling legacy protocols is just one layer — but it’s a foundational one that prevents entire classes of attacks.

Disabling SMB v1 isn’t just about checking a box; it’s about removing a persistent attack surface that has caused real-world damage. With PowerShell, the process is fast, reversible if needed, and verifiable. Take the time to check, disable, monitor, and confirm — your network will be significantly safer for it.

Cover image: Negative Space · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/macbook-laptop-X0CYLUO8E0