Windows 11 folder sharing problem

[HCHTech]

This is a small manufacturing client. All new PCs recently, Win11Pro 24H2. Workgroup of about 8 PCs. All PCs are using local user accounts. One computer runs Quickbooks Desktop 2024, and holds another shared folder, and 3 others access QB over the network, all PCs access the separate shared folder. Everything worked when setup in the middle of August, but things started breaking in late September. "John can't get into Quickbooks", "Mary can't access the shared folder", etc.

Went through all of the sharing setup (not our first rodeo), and all seemed correct. Killing the sharing altogether and setup again from scratch seemed to solve the problem, but problems returned in a couple of days. Eventually, we found MS Update KB5065426 was causing this problem for others. We uninstalled it and everything worked again. After blacklisting this update in our patch management, we thought we were done, but no such luck. Problems returned again.

I spent quite a bit of time this past weekend trying to figure this out:

• The offending update did not reinstall, although new updates have (KB5065789 is one)
• All PCs have a Private network profile.
• File and printer sharing is enabled on all PCs
• Ignoring Quickbooks for now, I have just been trying to access a shared folder from another pc on the network. When trying, I get a credentials dialog, and no username/password combination is accepted, dispite confirming they are correct, even creating a new user.
  • I've tried creating a new shareuser on the main pc
  • I've tried creating a user account that is the same as the user on the computer trying to access the share
  • Disabling the Windows firewall on both the computer holding the share and the computer trying to access did not change the symptom
  • Clearing out all entries in credential manager on both computers did not change the symptom
  • Attempting access via IP address vs. computer name did not change the symptom
  • Disabling security software did not change the symptom
  • creating an entirely new testshare folder did not change the symptom
  • Disabling password-protected sharing did not change the symptom
  • Both PCs have the same workgroup name
  • I can ping both ways
  • SMB1 is NOT enabled, but grasping at straws, I enabled it as a test. THIS WORKS. But obviously, this isn't the preferred setup
  • After re-disabling SMB1, I confirmed that SMB2 was active with Powershell
  • I found a post suggesting creating a "ValidateAdminCodeSignatures" DWORD in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key with a value of "1", but that didn't help
  • I found a post suggesting to make a change to the local security policy: ComputerConfiguration\WindowsSettings\SecuritySettings\LocalPolicies\SecurityOptions to set the "Microsoft network client: Digitally sign commmunications (always)" to DISABLED. this did not help.

Since I could find no other recommended change to address this issue, I have re-enabled SMB1 so my client can work. This let computer #1 access the shared folder on computer #0 and open Quickbooks. Going to the next computer, after enabling SMB1 and rebooting, I could NOT access the shared folder. That one started working after I uninstalled KB5065789 and rebooted.

Oh, and one of the as-yet-unreturned voicemails from this morning is another customer saying they can't get to their shared Quickbooks. I don't know exactly what I did to piss off Satya Nadella, but I'm about ready to change professions here.

 

[lan101]

I had to enable SMB1 in a similar situation recently with win11. Seems to be no other solutions that I'm aware of either. It sucks but it's the only thing that worked.

 

[Philippe]

Try to force the authentication protocol to Kerberos only or NTLM only...

 

[HCHTech]

Try to force the authentication protocol to Kerberos only or NTLM only...

That's something I didn't think of. Some cursory review puts NTLM in the same "would prefer to avoid" column as SMB1. Kerberos only would be preferred, but I'm wondering if that would break network printing as well - I'll need to read up on that to see if it's worth a swing.

 

[Sky-Knight]

What I have to do in these cases is write a logon script that maps a drive with the user context I want.

I cannot rely on the saved password, or default windows credential shuffle. The only time I don't have to do this for peer-to-peer Windows 11 networks is when every device is natively joined to Entra ID.

Quickbooks internally should use a UNC path to find its file, but the mapped drive to that machine still needs to be there. If the user cannot connect, they open explorer, see the mapped drive with a red X on it, click on it, and BAM... things are fixed.

Falling back to SMBv1 doesn't really fix the problem.

The credential bounce is also generally corrected by putting the username into the field as computername\username. If you don't do this, it will try the local machine context which probably includes M365 and now it's trying AzureAD\M365@UPN.COM behind the scenes and you're getting failures. You'll see this behavior in the security log on the "Server" machine if you go digging... but seriously, who has time for that?

Another thing? Some machines utterly refuse to resolve names, and I wind up connecting to \\IPaddress\share instead.

The last one... and this one is universal but I swear I'm FOREVER FORGETTING IT...

DISABLE IPV6!

Seriously, it fixes so many absurd issues. And it's a far softer impact than doing SMBv1.

 

[HCHTech]

The credential bounce is also generally corrected by putting the username into the field as computername\username. If you don't do this, it will try the local machine context which probably includes M365 and now it's trying AzureAD\M365@UPN.COM behind the scenes and you're getting failures. You'll see this behavior in the security log on the "Server" machine if you go digging... but seriously, who has time for that?

Another thing? Some machines utterly refuse to resolve names, and I wind up connecting to \\IPaddress\share instead.

The last one... and this one is universal but I swear I'm FOREVER FORGETTING IT...

DISABLE IPV6!

I had tried all of these, unfortunately. IPv6 was indeed enabled at the start, but taking that out didn't really change things. I tried all manor of different username entries, including machinename\username using both the native user on the server computer, a user created to be the same as the share-ee, and a special share user created for that purpose. IP Address was tried very early in the process, so I may not have gone back to that at the end. I will see if I there is a machine unused today to poke around some more, but at some point you have to stop spending time. That's why I ended up with SMB1, it was the only thing I tried that actually worked. Of course NONE OF THIS should be happening. Just because MS wants to make M365 connections easier doesn't mean they should break everything else. Normally when you spend this much time on a problem, you learn the actual THING that isn't working right - in this case logs and trial & error didn't really reveal anything. The fact that I was getting a credentials dialog means the traffic itself was getting to the machine, but that's about all I can confirm. Mostly, I just want my 3 hours back - haha.

 

[Sky-Knight]

I had tried all of these, unfortunately. IPv6 was indeed enabled at the start, but taking that out didn't really change things. I tried all manor of different username entries, including machinename\username using both the native user on the server computer, a user created to be the same as the share-ee, and a special share user created for that purpose. IP Address was tried very early in the process, so I may not have gone back to that at the end. I will see if I there is a machine unused today to poke around some more, but at some point you have to stop spending time. That's why I ended up with SMB1, it was the only thing I tried that actually worked. Of course NONE OF THIS should be happening. Just because MS wants to make M365 connections easier doesn't mean they should break everything else. Normally when you spend this much time on a problem, you learn the actual THING that isn't working right - in this case logs and trial & error didn't really reveal anything. The fact that I was getting a credentials dialog means the traffic itself was getting to the machine, but that's about all I can confirm. Mostly, I just want my 3 hours back - haha.

You're possibly running into a TPM level issue too.

If all of these machines are joined to Entra, none of this happens.
If all of these machines are not joined to Entra, but instead joined to a personal Microsoft account, running local logins, but they use M365... when the users login to M365 the first time they can login to the app, or have Entra manage the machine as a registered device. If the latter is picked, TPM is enrolled, Windows Hello for Business happens, and now those machines will notice someone trying to side step the directory check.

There are no half measures, the way Microsoft security tools work, you're either all in, or all out. And if you try to go halfsies, you will land yourself in all sorts of hot water. That's why I started joining workgroup machines to Entra ages ago, even if the customer only had Basic/Standard.

Another nugget in this space. If the machine is joined to Entra ID, but the user is logging in locally, then you need to use local accounts on that machine for consistent SMB access. The Entra logins will work, until they don't and drive you mad.

 

[HCHTech]

You're possibly running into a TPM level issue too.

I suppose you are correct - I imagine a world where the darned error message might steer you towards a solution, but that certainly didn't happen in this instance. None of these machines are AzureAD joined, they are all using local accounts, and are still on Office H&B 2019. They will be moving to M365 on 1/1, but I couldn't get them to do that with this refresh. Those office installs are registered with an office account, but no OneDrive or anything else is active here. That's part of why I couldn't believe it was so difficult to get it to work. In the end I believe MS updates are at least partly responsible. The list of known issues for several recent updates were SMB1-related. e.g.

KB5065426 (9/9) had SMB1 known issues, supposedly fixed by KB5065789 (9/29)
KB5065429 (9/9) had SMB1 known issues, supposedly fixed by KB5066198 (9/25)

When we started back in mid-August, we weren't using SMB1 at all - it was turned off on all computers. It wasn't until my marathon session this past weekend that I "gave up" and went back to SMB1, and even so, I ended up having to uninstall KB5065789 to get one computer working - which was the update that supposedly FIXED SMB1 problems caused by an earlier update. Now that this setup is theoretically "working", I'm afraid to apply any updates.

I suppose the solution should be just to AzureAD join all non-domain computers, now....but I sure don't love that conclusion.

 

[britechguy]

I imagine a world where the darned error message might steer you towards a solution

I've been imagining that since entering the field in 1985. I suspect I'll still be imagining it up until I draw my final breath!

 

[Sky-Knight]

I suppose you are correct - I imagine a world where the darned error message might steer you towards a solution, but that certainly didn't happen in this instance. None of these machines are AzureAD joined, they are all using local accounts, and are still on Office H&B 2019. They will be moving to M365 on 1/1, but I couldn't get them to do that with this refresh. Those office installs are registered with an office account, but no OneDrive or anything else is active here. That's part of why I couldn't believe it was so difficult to get it to work. In the end I believe MS updates are at least partly responsible. The list of known issues for several recent updates were SMB1-related. e.g.

KB5065426 (9/9) had SMB1 known issues, supposedly fixed by KB5065789 (9/29)
KB5065429 (9/9) had SMB1 known issues, supposedly fixed by KB5066198 (9/25)

When we started back in mid-August, we weren't using SMB1 at all - it was turned off on all computers. It wasn't until my marathon session this past weekend that I "gave up" and went back to SMB1, and even so, I ended up having to uninstall KB5065789 to get one computer working - which was the update that supposedly FIXED SMB1 problems caused by an earlier update. Now that this setup is theoretically "working", I'm afraid to apply any updates.

I suppose the solution should be just to AzureAD join all non-domain computers, now....but I sure don't love that conclusion.

The challenge you're running into is the use case of having workstations talking to other workstations is by design something that's been removed from the flow. I know that will upset many, but we cannot control lateral spread when we have people with admin rights on endpoints, that can access other endpoints. The current model is, no workstations talk to other workstations... period... ever. They talk to servers, or even better services. So the basic ability to simply authenticate in some reasonable way between desktops has been damaged. It manifests typically in the space you're stuck... a workstation service that refuses to communicate with a server service. The points of failure that are present these days to get an SMBv3 session established have been amplified. SMBv3 is now a VPN all on its own! But only if it can authenticate the user, and the machine at the same time. These conditions simply are never met if Active Directory, or Entra ID is responsible for both systems involved.

Toss in a healthy dose of Microsoft the monopoly screwing with people that use out of support products. (Office 2016 and 2019 are dying soon) And things get even worse. For my part I'm just trying to give you some yarn to yank on, because I'm not sure what else to do. There is an error message that tells you what is going on, but it's in the EventVwr somewhere. Where? Your guess is as good as mine, but I'll bet its buried in the no man's land of Applications and Services Logs.

 

[HCHTech]

These conditions simply are never met if Active Directory, or Entra ID is responsible for both systems involved.

I assume you mean if AD or EntraID are NOT responsible, yes? I see a message this morning that it's broken again, so I'm thinking that's my next salvo in this battle.

 

[Sky-Knight]

I assume you mean if AD or EntraID are NOT responsible, yes? I see a message this morning that it's broken again, so I'm thinking that's my next salvo in this battle.

Yes, when all endpoints fall under centralized identity management, the systems' behavior will shift.

Microsoft has long prioritized single sign-on, discouraging repeated logins. This design introduces authentication flows that often clash with peer-to-peer workgroup setups.

Microsoft's assumption is clear, businesses will adopt centralized identity directories. It’s essential for managing technology effectively. While Active Directory once required a server, the cost associated keept peer-to-peer viable, the rise of M365 and Entra ID, along with Windows 11’s enhanced security (TPM, encryption), means Microsoft now expects machines to be managed via AD or Entra. Personal machines are Entra managed via Microsoft Account integration. Business machines are to be joined to an M365 tenant.

The bottom line is join your devices to Entra ID or be left behind. Not because it’s some moral imperative, but because that’s where the development investment, polish, and support are targeted. We have to stay with the herd, or we'll pay for it in increased support costs!

And that last bit, is where you've landed squarely. I've got many little offices with M365 Standard licenses, all machines Entra ID joined, all Windows 11, running Quickbooks, Trimble Estimation, and all other manner of non-cloud LOB applications, all over shares, and most of these offices are peer-to-peer in scope, think 5 machines or less. Permissions are set with AzureAD\UPN manually added to a group, and the group on the folder / share. Some of these machines even have local accounts for special device access, like a scanner. So fully hybrid authentication is online, Cloud and Local identities working seamlessly.

None of these updates triggered anything... no tickets... things just worked. I have to assume that Entra is the difference given your story, I don't see any other reasonable variable.

The tickets I'm getting right now in that community are people freaking out because they waited until the 11th inning to retire Windows 10.

 

[RandyL]

Ran into this yesterday. Setting up new Win 11 Pro system for a small business client. They have 6 users connected to a server running Win 10 pro. Mostly file sharing and 3 using QB. I have installed and supported small to medium size networks for years. So have some experience.. I tried everything. Including removal of one of the latest updates mentioned on line.. In the end, I had to enable SMB1. This is a major problem. I hope MS is aware and addressing this ASAP

 

[Diggs]

I was thinking about adding some personal network archive storage the other day and put my hand on an old Netgear NAS I had on the self. I had a note on top saying SMB1 !!!. You'd think I touched a hot stove the way I jerked my hand back - chuckles.....!