Local Private Network - Can't Connect to It

[glennpm]

I am unable to see my Windows 10 laptop from my Windows 11 Main computer in the file explorer network. I can ping it but even though I have both computers set to share without passwords I get the "Enter Network credentials". I have tried entering my user and password of the laptop but it is rejected. I can ping the WIN10 laptop from WIN 11.

Connection from the laptop TO the Main computer works fine.

Commands below run on the Main computer

On MAIN-PC 192.168.1.3 WORKGROUP HP Inc. BC:E9:2F:A4:11:3E MAIN-PC\glenn
On DELL-LAPTOP 192.168.1.71 WORKGROUP Dell Inc. 34:17:EB:82:0E:AE

ping 192.168.1.71

Pinging 192.168.1.71 with 32 bytes of data:
Reply from 192.168.1.71: bytes=32 time=2ms TTL=128
Reply from 192.168.1.71: bytes=32 time=2ms TTL=128
Reply from 192.168.1.71: bytes=32 time=2ms TTL=128
Reply from 192.168.1.71: bytes=32 time=2ms TTL=128

Ping statistics for 192.168.1.71:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms

********

Both computers have dedicated IPs

S C:\WINDOWS\system32> test-connection -ComputerName DELL-Laptop
test-connection : Testing connection to computer 'DELL-Laptop' failed: Error due to lack of resources
At line:1 char:1
+ test-connection -ComputerName DELL-Laptop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (DELL-Laptop:String) [Test-Connection], PingException
+ FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand

test-connection : Testing connection to computer 'DELL-Laptop' failed: Error due to lack of resources
At line:1 char:1
+ test-connection -ComputerName DELL-Laptop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (DELL-Laptop:String) [Test-Connection], PingException
+ FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand

test-connection : Testing connection to computer 'DELL-Laptop' failed: Error due to lack of resources
At line:1 char:1
+ test-connection -ComputerName DELL-Laptop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (DELL-Laptop:String) [Test-Connection], PingException
+ FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand

test-connection : Testing connection to computer 'DELL-Laptop' failed: Error due to lack of resources
At line:1 char:1
+ test-connection -ComputerName DELL-Laptop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (DELL-Laptop:String) [Test-Connection], PingException
+ FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand

 

[glennpm]

UPDATE 8-20-25

Working for days trying to add my DELL to the network, I found that the prompts for a user and password were being rejected. The reason was that when I did the new installation on the Dell, I must have selected signing in with my Microsoft account instead of a local one.

I had the inverse of this, “Based on your description, it seems the issue you're encountering might be due to changing your Microsoft account password while your Windows account is still using the old password”

This was the fix:

Change From a Local Account to a Microsoft Account in Windows - Microsoft Support

“Change from a Microsoft account to a local account

You can use the Settings app to switch your Microsoft account to a local account.

Important: Microsoft recommends using a Microsoft account, not a local account, when signing in to Windows. Using a Microsoft account in Windows allows for seamless integration of Microsoft services, enhanced security, and sync across devices, unlike a local account.

1. In the Settings app on your Windows device, select Accounts > Your info, or use the following shortcut:

Your info

1. Select Sign in with a local account instead. You'll see this link only if you're using a Microsoft account
2. Type the username, password, and password hint. The username must be different than any others on the device
3. Select Next, then select Sign out and finish. Sign back in with your new local account”

I also checked in an Admin CMD:

net user

net user glenn <my password>

Working seamlessly now.

 

[ChatGPT]

Excellent — thanks for the clear update and for posting the exact fix. Nicely found.
Short summary of what happened and why your fix worked

• Root cause: your Dell was using a Microsoft account to sign into Windows while your MAIN PC was attempting to authenticate with a local account name (MAIN‑PC\glenn). SMB file sharing in a workgroup needs either:
  • a matching local account on server and client (same username/password), or
  • explicit credentials that the server accepts (e.g., DELL‑LAPTOP\<localuser>), or
  • guest/anonymous allowed (insecure).
• Because the Dell account was a Microsoft account, the server was rejecting the MAIN‑PC credentials (Event ID 4625 showed the attempted account was MAIN‑PC\glenn and the failure reason was bad user/password). Switching the Dell login to a local account (or creating a matching local account) resolved the mismatch and allowed the SMB session.

What you did (correct)

• You converted the Dell sign‑in from a Microsoft account to a local account (Settings → Accounts → Your info → Sign in with a local account instead).
• You then ensured the same local username/password was used or created matching accounts, and mapping worked (net use Z: \192.168.1.71\PublicShare succeeded).

Nice work — that’s the clean, secure fix.
Recommended follow‑ups (short checklist)

• If you created temporary shares/users during troubleshooting, remove them now (cleanup):
  • On DELL (Admin):
  • Remove temporary share: Remove-SmbShare -Name "PublicShare" -Force
  • Delete temporary user: net user shareuser /delete
  • Remove NullSessionShares or any registry keys you added (if you used them).
  • On MAIN (Admin):
  • Delete temporary user if created: net user shareuser /delete
  • Remove saved credential: cmdkey /delete:192.168.1.71
  • Remove any AllowInsecureGuestAuth change:
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 0 /f
    Restart-Service -Name LanmanWorkstation -Force
• Make a persistent mapped drive (if you want convenience): use Credential Manager or cmdkey + net use as we walked through earlier. (You already confirmed it works.)
• Create a fresh system image now (Clonezilla/Macrium) while everything is clean.
• Keep a short note of the changes you made (users/shares/registry) so you can revert easily in future.

If you prefer a single “revert everything I changed” command block, I can paste it for you now.
Optional improvements (security & convenience)

• Long‑term: create a dedicated local share account (strong password) on the server and store that credential in the client’s Credential Manager. That’s more secure than enabling guest/anonymous access and avoids the Microsoft‑vs‑local mismatch.
• If you prefer Microsoft accounts across devices, you can still share — but SMB auth then requires explicit MicrosoftAccountyouremail@domain.com credentials (less common). Matching local accounts is simpler for workgroups.
• Consider enabling Offline Files or using a secure SFTP/WinSCP workflow if you frequently copy big data between machines.

Anything else I can do now?

• Paste “yes” and I’ll generate a one‑click cleanup script to remove temporary shares/users and undo any insecure registry changes.
• Or I can walk you through setting up a permanent, secure mapped drive and the Credential Manager entry (I can paste the exact cmdkey + net use lines).

Congrats again — excellent troubleshooting and persistence. Want the cleanup script now?

 

[glennpm]

All set now, thanks!

 

[ChatGPT]

Excellent — you’re welcome, Glenn! Glad it’s all sorted.
If anything else comes up later (image guidance, reverting the temporary changes, setting up an SFTP alternative, or making a one‑click cleanup script), just post here and I’ll help — happy to jump back in.
Enjoy a well‑earned break.