SMB sharing not working after windows 10 update Build 2004 update

Win10 20H2 fixes the issue.

Previously when 2004 broke smb1, I rolled back.

There was no registry change or any other modification made to the system.  After Win10 20H2 upgrade was installed via Windows Updates;  SMB1 worked as it did before the upgrade.

Thank you Microsoft.

I am not sure it is a solution:

I preserve my primary PC from 2004 upgrade and 2 weeks ago system force the upgrade to  20H2. After that problems with SMBv1 appears - sometimes all mapings works well, but some hours after system start File Explorer opening cause endless ''This Computer' refresh with unfinished progress bar. In this case command 'net use' hangs. The only solution is system reboot, but this is unacceptable.

kB

BIG, FINALLY WORKED OUT

Any help is  appreciated

SMB1 mapped drive issue solved.

Adding a summary of all that I tried following a 20H2 upgrade.

This pertains to Window 10 Pro 20H2 in Domain environment connecting to a Windows 2003 member server shared mapped drive.

After upgrade to 20H2, the PC was unable to connect to 2003 SMB1 shares and also had high resource usage causing PC to hang and fail when opening File Explorer. The immediate system hang was maybe due to desktop or quick access links pointing to SMB1 Shared locations or files.

I tried everything I could find to resolve it and here is a summary:

Some of all of these in order may fix the issues.

Remove and Re-add SMB1 using Powershell, Run as Admin

Get-WindowsOptionalFeature -Online -FeatureName smb1protocol

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Reboot

Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Turn on Services:

Run services.msc

Start the "Function Discovery Provider Host" and "Function Discovery Resource Publication services and set to Automatic (delayed start)

Open Explorer Network, enable network discovery if prompted

Edit local policy:

gpedit.msc

computer configuration\Administrative Templates\Network\LanmanWorkstation ENABLE insecure guest logon.

2 Registry settings:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

"EnableLinkedConnections"=dword:00000001

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Network\p]

"ProviderFlags"=dword:00000001

Note: In the above registry entry "P" is the drive letter I use.

Thank you to all contributors who helped me solve my problem.

SMB1 drive access worked and system performance was returned to normal.

Any help is  appreciated

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Hi YuriW (and all unfortunate souls who end up here and are told that 20H2 solves the problem; classic Microsoft style).

I just, after MONTHS of procrastinating because of hearing about problems like this... decided to go ahead and run the latest Windows 10 update, which in my case was directly to 20H2... and that is when my problems STARTED!

So ok, I get it. Goodbye SMB1. Shame on me for leaning on it for so long to power my home network.

BUT HERE IS THE PART THAT MICROSOFT WILL NOT TELL YOU.

I have, for a long time, run a program called HOSTSMAN. It's basically a tray icon utility that does hosts file manipulations to load the MVPS hosts recommended entries to block malicious and tracking domains. As part of the original installation instructions for that program, they recommended disabling your DNS Client service (aka DNSCache).

NO problem with that approach for YEARS... a DECADE or more.

Then... along comes these new updates from Microsoft, and somebody, in their infinite wisdom, decided DNS Client was an ESSENTIAL part of Windows and that users should no longer be allowed to disable their DNS Client, so they greyed out all of the controls.

A second change they included, was that they made the SMB Client (even for SMB version 2) REQUIRE the DNS Client to be running.

Their great fail on this update was that they greyed out the controls for the DNS Client, BUT... did not check for, nor change the Startup status if it did not match their now EXPECTED value of Automatic (load on startup).

As a result, even when SMBClient V1 is disabled, ALL SMBClient V2 operations will fail with a message like:

https://social.technet.microsoft.com/Forums/en-US/1d001951-6985-48cb-be38-e33c60f4fc20/event-id-30800-the-server-name-cannot-be-resolved

"The Server Name Cannot Be Resolved" (event ID 30800)

You can ping the target machine all day long, but because the SMBClient was EXPECTING the DNS Client service to be running, it was incapable of allowing the operation system to resolve the target address the way every other program does. A really stupid update. Countless bad press. Countless people reinstalling their Windows...

when Microsoft could have just checked for the startup state of the DNS Client service, at the time THEY decided it should now be a REQUIRED piece of Windows infrastructure, and re-enable it on machines where it was disabled (since they took away the user's ability to re-enable it with their UI update).

I hope this information may spare someone from having to reinstall their machine (or rollback).

To re-enable the DNS Client service, open your registry and browse to:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache

then look at the value for the Start variable. I switched mine from 4 (Disabled) to 2 (Automatic).

Then reboot your box, and rebuild all of your mapped shares if you had already deleted them like people told you to do to "solve" this problem.

Also... while not required, I recommend making yourself familiar with the Windows Credentials Manager, and make use of it to pre-load the credentials for you target server to make the mapping process smooth as butter.

And for the record, Microsoft developer or manager who made this decision?... DNS Client is STILL... NOT... an "essential" part of Windows. It's sad to see so many people on this thread re-enabling SMB1 or blowing security holes in their SMB2, rather than swinging through to get SMB2 to work the way it should just out of the box (in my example I was just trying to map drives between 2 Windows 10 machines that received the new update).