Disable SMB v1 Completely on Windows Server 2022 Using PowerShell

If you're hardening a Windows Server 2022 environment, disabling SMB v1 is non-negotiable. I've seen too many breaches start with this outdated protocol, especially in flat networks where lateral movement is trivial. In my environment, I treat SMB v1 like telnet — if it's enabled, it's a finding. Here's how I fully disable it using PowerShell and confirm the state.

Why SMB v1 Must Be Disabled

SMB v1 is outdated, inefficient, and critically vulnerable. It lacks modern security features like encryption and secure negotiation. WannaCry and NotPetya exploited it directly. Microsoft has marked it as deprecated since Windows 10/Server 2016, and it's removed by default in Windows Server 2022 — but only if you're doing a clean install. Upgraded systems or those with certain roles (like File Server or Print Services) may still have it lurking.

I always check during baseline builds. Leaving it enabled violates STIG, CIS Benchmarks, and basic hygiene. Even if you think you don't use it, some legacy apps or third-party tools might trigger a fallback.

Disabling SMB v1 with Set-SmbServerConfiguration

The primary cmdlet to manage SMB server settings is Set-SmbServerConfiguration. To disable SMB v1, you set the EnableSMB1Protocol flag to false. This requires admin rights and a restart to take full effect.

Here’s the command I run:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

The -Force flag skips the confirmation prompt, which is essential in automation or remote sessions. Without it, you’d get a warning about needing to restart — which is true, but I’d rather script it.

After running this, you must restart the server for the change to apply fully. While the service might stop listening immediately, some components cache the old state until reboot.

Verifying the State with Get-SmbServerConfiguration

To confirm SMB v1 is off, I use Get-SmbServerConfiguration. This shows the current effective settings, not just what’s in the registry.

Run:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

If the output shows False, the protocol is disabled. If it’s still True, either the command didn’t apply (check permissions) or the server hasn’t rebooted.

I like to include this in my hardening scripts and log the result. For example:

$smb1Status = (Get-SmbServerConfiguration).EnableSMB1Protocol
if ($smb1Status) {
    Write-Warning "SMB v1 is still enabled. Reboot required or check for conflicting policies."
} else {
    Write-Host "SMB v1 successfully disabled."
}

This gives me a clear pass/fail in automation.

Common Pitfalls and Checks

Even after disabling via PowerShell, I double-check a few things:

• Group Policy: Domain-joined servers might have SMB v1 re-enabled via GPO. Look under Computer Configuration > Policies > Administrative Templates > Network > Lanman Workstation → Enable insecure guest logons (indirect) or check for legacy SMB settings in newer policies.

• Windows Features: Although disabling via PowerShell should suffice, I confirm the feature isn’t installed:

  Get-WindowsFeature -Name FS-SMB1

If Installed shows Yes, remove it:

  Remove-WindowsFeature -Name FS-SMB1 -Restart

Note: On Server 2022, this feature is often removed by default, but upgrades or missing patches can leave it.

• Client Side: Disabling the server doesn’t stop the client from attempting SMB v1. To fully lock down, I also disable the client:

  Set-SmbClientConfiguration -EnableSMB1Protocol $false -Force

Then reboot. This prevents the server from acting as a client to legacy devices — useful if you're jumphosting or managing older gear temporarily.

When You Might Temporarily Need It (and How to Mitigate)

I’ve seen cases where a legacy scanner or industrial device only speaks SMB v1. In those cases, I don’t re-enable it globally. Instead:

1. Isolate the device on a VLAN with no route to production.
2. Enable SMB v1 only on a jump server with strict firewall rules.
3. Use SMB v1 → SMB v2/3 proxy tools (like a hardened Samba gateway) if absolutely necessary.
4. Log and monitor all SMB v1 attempts — I’ve seen ransomware test for it first.

Re-enabling should be a last resort, time-bound, and documented. Never leave it "just in case."

Integration with Hardening Baselines

I include this check in my Windows Server 2022 baseline script, alongside disabling LM auth, enabling SMB encryption, and configuring firewall rules for SMB ports (445). After disabling SMB v1, I verify:

• No listening on port 445 for v1 signatures (via netstat or Wireshark in lab)
• Event ID 3000 in Microsoft-Windows-SMBServer/Operational (if auditing is on) — absence confirms no v1 activity

As I mentioned before in my post about securing network backups, reducing the attack surface isn’t about one tool — it’s about layering. Disabling SMB v1 is one of the simplest, highest-impact layers you can apply.

Final Verification Checklist

Before I consider a server hardened, I run this quick validation:

• [ ] Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol returns False
• [ ] Get-WindowsFeature FS-SMB1 shows Available (not installed)
• [ ] No Group Policy overrides enabling SMB v1
• [ ] Server has rebooted since the change
• [ ] Client side also disabled if applicable

If all boxes are checked, SMB v1 is effectively neutralized. It’s not glamorous, but turning off old protocols is where real security starts.

Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6042704/photo-image-public-domain-free