Fix STATUS_DS_VERSION_CHECK_FAILURE (0XC0000355)

This error pops up during Windows domain join or SMB connections when the client and server can't agree on a supported protocol version. Here’s how to fix it fast.

When This Error Hits

You're trying to join a Windows 10 machine (build 2004 or later) to a domain, or you're connecting to a file share on a Windows Server 2012 R2 or older box. The join fails immediately, or the share access drops with this cryptic code: 0XC0000355. Sometimes you see it in Event Viewer under Microsoft-Windows-SMBClient with a status of STATUS_DS_VERSION_CHECK_FAILURE. I've seen this most often after deploying a new laptop image that's fully patched, only to have it refuse to talk to a legacy file server running Server 2008 R2.

What's Actually Going On

At its core, this error is a version negotiation failure. Windows has a handshake process where the client and server agree on what protocol version and security settings to use. When one side demands something the other can't provide—like SMB 3.1.1 encryption or LDAP signing—the connection gets killed. The most common trigger is a mismatch in SMB protocol versions: modern Windows 10/11 defaults to SMB 3.1.1, but older domain controllers or file servers may only support up to SMB 2.0. Another common cause is LDAP signing requirements on the domain controller that the client won't honor because its policy is too strict or too weak.

The Fix: Step by Step

Skip the wild goose chase with network cables and DNS. Here's what actually works.

Step 1: Check the SMB Protocol Version

Open PowerShell as admin on the client machine. Run this command to see what SMB versions the client supports:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol

If SMB1 is enabled and you're dealing with an ancient server, you might need to disable it (security risk) or enable SMB2 if it's off. On the server side (the machine you're trying to join or access), run the same command. If the server only supports SMB1, you're in trouble—upgrade the server or enable SMB2 via a registry tweak. But honestly, if the server is that old, push for an upgrade.

Step 2: Force SMB 2.0 on the Client (Temporary)

If the server is a Windows Server 2008/2008 R2 box that only speaks SMB 2.0, you can force the client to drop to SMB 2.0 for that connection. Open an elevated PowerShell and set:

Set-SmbClientConfiguration -EnableSMB2Protocol $true -Force

Then reboot. This isn't ideal long-term—you lose SMB 3.x features like encryption—but it gets you connected.

Step 3: Fix LDAP Signing Mismatch

This is sneaky. The error often fires because the domain controller requires LDAP signing, but the client isn't set up for it. On the client, open gpedit.msc and go to: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Find Network security: LDAP client signing requirements. Set it to Negotiate signing or Require signing (match your DC's setting). Then run gpupdate /force. I've seen this fix the error in 5 minutes after hours of other nonsense.

Step 4: Check Group Policy for SMB Security

Another policy can block the connection. Open gpedit.msc again, go to Computer Configuration > Administrative Templates > Network > Lanman Workstation. Find Enable insecure guest logons. Set it to Enabled if you're connecting to a server that allows guest access (not recommended for production). Also check Maximum SMB protocol version; if it's set to something lower than 3.11, bump it up or set to Not configured.

Step 5: Registry Hack as Last Resort

If group policy is locked down by your organization, you can tweak the registry directly. Open regedit and navigate to:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Create a DWORD named EnableSMB2Protocol and set it to 1. Also a DWORD named RequireSecuritySignature set to 0 if the server doesn't sign SMB traffic. Reboot. This is a hammer approach—use it only when you're sure the server is safe.

If It Still Fails

Check a few more things. First, verify the domain controller is reachable and has proper DNS records — run nltest /dsgetdc:yourdomain.local to see if it finds a DC. If it returns an error, DNS is the real culprit. Second, look at the server's event logs (Applications and Services Logs > Microsoft > Windows > SMBClient). Third, try connecting with a different user account that has fewer policy restrictions. Finally, if you're dealing with a cross-forest trust, make sure the Kerberos tickets aren't corrupted — run klist purge on the client and re-authenticate.

I know this error is infuriating because it gives you almost no hint where the mismatch is. But 9 times out of 10, it's either SMB protocol version or LDAP signing policies. Start there, and you'll have it working before lunch.