wyliec2

New Member
Joined
Mar 31, 2025
Messages
12
New Windows Server 2022 installed as a Workgroup without a Domain Controller.

4 client PCs connect to shared folders on the server.

The PC clients keep getting mapped shares disconnected - red X in File Explorer.

This is not a network issue - the PCs are able to connect to the Windows Server via Remote Desktop without issue.

When trying to reconnect the shared folders, have to keep changing from hostname to ip address and/or changing credentials.

When connected, the shared folders work fine but eventually revert to a disconnected red X.

Looking for any resolution to get reliable shared folder access from PC clients.
 

Solution
This is a common frustration with workgroup servers and modern Windows clients—especially on Windows 10/11. Here’s a breakdown of what’s causing the mapped drives to disconnect and proven ways to achieve reliable access:

1. Why This Happens

  • Session Timeout: Windows will often disconnect idle SMB (network share) sessions after 15-30 minutes by default if no traffic flows, resulting in the “red X.”
  • Credential/Name Resolution Conflicts: Changing between hostname and IP, or being prompted for credentials, usually means Windows is holding onto stale/cached credentials or is confused between multiple network/authentication contexts.
  • Workgroup Annoyances: Without a domain, there are no...
This is a common frustration with workgroup servers and modern Windows clients—especially on Windows 10/11. Here’s a breakdown of what’s causing the mapped drives to disconnect and proven ways to achieve reliable access:

1. Why This Happens

  • Session Timeout: Windows will often disconnect idle SMB (network share) sessions after 15-30 minutes by default if no traffic flows, resulting in the “red X.”
  • Credential/Name Resolution Conflicts: Changing between hostname and IP, or being prompted for credentials, usually means Windows is holding onto stale/cached credentials or is confused between multiple network/authentication contexts.
  • Workgroup Annoyances: Without a domain, there are no Kerberos “tickets” for persistent authentication. Windows falls back to NTLM and cached credentials, which are not always handled robustly.
  • Mapped Drives Not Set as Persistent: By default, mapped drives may not auto-reconnect after sleep, reboot, or a logoff/logon cycle.

2. Best Practices to Fix and Prevent Disconnects

A. Use the Same Credentials Everywhere

  • Create a local user account on the SERVER (not just a share permission) that matches the username and password of the user account on each client PC. That way, Windows passes credentials automatically, which is far more reliable for persistent connections.

B. Map Drives with Explicit /Persistent and /User

  • Map the drives with:
    net use X: \\ServerName\ShareName /persistent:yes /user:server\user
    Replace server\user with the username on your SERVER that matches or you want to use, and execute this in an elevated Command Prompt.

C. Clean Up Old Credentials in Credential Manager

  • On each client PC, go to Control Panel > Credential Manager > Windows Credentials and delete any saved references to the server (both hostname and IP).
  • Then, remap the drive, entering the credentials and checking “Remember my credentials.”

D. Registry Tweaks on the Client

  • Prevent sessions from timing out by increasing the autodisconnect timer.
    • Open cmd as Administrator and enter:
      net config server /autodisconnect:-1
    • You can also set the following registry key on clients (run regedit as Administrator):
    • Navigate to:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
    • Set (or create as DWORD):
      KeepConn = 3600 (decimal, for 1 hour; set higher if desired)

E. Disable “Offline Files”/CSC on Clients

  • Windows sometimes caches network shares. Go to Control Panel > Sync Center > Manage Offline Files and disable this feature if you don’t intend to use it.

F. Use Static Server IP and Hostname Resolution

  • Add an entry for the server in each client’s C:\Windows\System32\drivers\etc\hosts file, e.g.:
    192.168.1.100 SERVERNAME
  • This avoids random DNS/WINS hiccups.

G. Reconnect Drives on Logon

  • If the share is mapped via logon script/GPO or as part of Windows startup (Scheduled Task for net use with “Run with highest privileges”), it’s much more robust.

3. What NOT to Do

  • Don’t rely on just clicking in File Explorer and “reconnecting” every time—with workgroup SMB, that’s like playing roulette.
  • Don’t use the same share but swap between hostname/IP—pick ONE and stick to it.

Summary

  • Always use a matching local user (or synchronize credentials).
  • Use net use with /persistent:yes and specific /user.
  • Clean out old credentials in Windows Credential Manager.
  • Extend autodisconnect timeout on clients.
  • Optionally, configure hosts file for name stability.

After making these changes, reboot the clients and the server, remap the drives using the improved net use command, and your “red X of doom” should disappear for good.
If you want a ready-to-copy set of scripts or batch files for automating this across your PCs, just ask!
If the issue still happens after this, let me know which step didn’t “stick”—there may be something niche (like security policies or antivirus meddling) to dig into.
 

Solution
This is a common frustration with workgroup servers and modern Windows clients—especially on Windows 10/11. Here’s a breakdown of what’s causing the mapped drives to disconnect and proven ways to achieve reliable access:

1. Why This Happens

  • Session Timeout: Windows will often disconnect idle SMB (network share) sessions after 15-30 minutes by default if no traffic flows, resulting in the “red X.”
  • Credential/Name Resolution Conflicts: Changing between hostname and IP, or being prompted for credentials, usually means Windows is holding onto stale/cached credentials or is confused between multiple network/authentication contexts.
  • Workgroup Annoyances: Without a domain, there are no Kerberos “tickets” for persistent authentication. Windows falls back to NTLM and cached credentials, which are not always handled robustly.
  • Mapped Drives Not Set as Persistent: By default, mapped drives may not auto-reconnect after sleep, reboot, or a logoff/logon cycle.

2. Best Practices to Fix and Prevent Disconnects

A. Use the Same Credentials Everywhere

  • Create a local user account on the SERVER (not just a share permission) that matches the username and password of the user account on each client PC. That way, Windows passes credentials automatically, which is far more reliable for persistent connections.

B. Map Drives with Explicit /Persistent and /User

  • Map the drives with:
    net use X: \\ServerName\ShareName /persistent:yes /user:server\user
    Replace server\user with the username on your SERVER that matches or you want to use, and execute this in an elevated Command Prompt.

C. Clean Up Old Credentials in Credential Manager

  • On each client PC, go to Control Panel > Credential Manager > Windows Credentials and delete any saved references to the server (both hostname and IP).
  • Then, remap the drive, entering the credentials and checking “Remember my credentials.”

D. Registry Tweaks on the Client

  • Prevent sessions from timing out by increasing the autodisconnect timer.
    • Open cmd as Administrator and enter:
      net config server /autodisconnect:-1
    • You can also set the following registry key on clients (run regedit as Administrator):
    • Navigate to:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
    • Set (or create as DWORD):
      KeepConn = 3600 (decimal, for 1 hour; set higher if desired)

E. Disable “Offline Files”/CSC on Clients

  • Windows sometimes caches network shares. Go to Control Panel > Sync Center > Manage Offline Files and disable this feature if you don’t intend to use it.

F. Use Static Server IP and Hostname Resolution

  • Add an entry for the server in each client’s C:\Windows\System32\drivers\etc\hosts file, e.g.:
    192.168.1.100 SERVERNAME
  • This avoids random DNS/WINS hiccups.

G. Reconnect Drives on Logon

  • If the share is mapped via logon script/GPO or as part of Windows startup (Scheduled Task for net use with “Run with highest privileges”), it’s much more robust.

3. What NOT to Do

  • Don’t rely on just clicking in File Explorer and “reconnecting” every time—with workgroup SMB, that’s like playing roulette.
  • Don’t use the same share but swap between hostname/IP—pick ONE and stick to it.

Summary

  • Always use a matching local user (or synchronize credentials).
  • Use net use with /persistent:yes and specific /user.
  • Clean out old credentials in Windows Credential Manager.
  • Extend autodisconnect timeout on clients.
  • Optionally, configure hosts file for name stability.

After making these changes, reboot the clients and the server, remap the drives using the improved net use command, and your “red X of doom” should disappear for good.
If you want a ready-to-copy set of scripts or batch files for automating this across your PCs, just ask!
If the issue still happens after this, let me know which step didn’t “stick”—there may be something niche (like security policies or antivirus meddling) to dig into.
I would like a script or batch file to automate reconnecting the shares with net use
 

Absolutely! Here’s a batch file template you can use to automate reconnecting your mapped drives using net use. This script will:
  • Remove any existing mapping for the chosen drive letter.
  • Map the drive using the server’s hostname (or IP), share name, and credentials.
  • Ensure the mapping is persistent.

Sample Batch Script (MapDrives.bat)​

Code:
[USER=35331]@echo[/USER] off
REM ======== CONFIGURATION ========
REM Set your server and share info below

SET DRIVE=Z:
SET SHARE=\\SERVERNAME\Sharename
SET USER=SERVERNAME\youruser
SET PASS=yourpassword

REM ======== DO NOT EDIT BELOW THIS LINE ========

echo Removing any previous mapping on %DRIVE% ...
net use %DRIVE% /delete /yes

echo Mapping %DRIVE% to %SHARE% ...
net use %DRIVE% %SHARE% /user:%USER% %PASS% /persistent:yes

IF %ERRORLEVEL% EQU 0 (
    echo Drive mapped successfully!
) ELSE (
    echo Failed to map drive. Check credentials or share path.
)

pause

How to Use​

  • Edit the variables at the top (DRIVE, SHARE, USER, PASS) to match your environment.
  • You can duplicate the net use section for multiple drive letters/shares.
  • Save as MapDrives.bat and run as administrator on each client PC.

Best Practice Pro Tip

  • For even greater security, omit the %PASS% variable and the password on the command line so users are prompted to enter it. For example:
    net use %DRIVE% %SHARE% /user:%USER% /persistent:yes
    This keeps your password out of the script file.
  • You can schedule this batch file to run at startup (via Task Scheduler with “Run with highest privileges”).

Let me know if you need the script to handle multiple shares and letters in a loop, or want it in PowerShell format for more advanced credential management!
 

Absolutely! Here’s a batch file template you can use to automate reconnecting your mapped drives using net use. This script will:
  • Remove any existing mapping for the chosen drive letter.
  • Map the drive using the server’s hostname (or IP), share name, and credentials.
  • Ensure the mapping is persistent.

Sample Batch Script (MapDrives.bat)​

Code:
[USER=35331]@echo[/USER] off
REM ======== CONFIGURATION ========
REM Set your server and share info below

SET DRIVE=Z:
SET SHARE=\\SERVERNAME\Sharename
SET USER=SERVERNAME\youruser
SET PASS=yourpassword

REM ======== DO NOT EDIT BELOW THIS LINE ========

echo Removing any previous mapping on %DRIVE% ...
net use %DRIVE% /delete /yes

echo Mapping %DRIVE% to %SHARE% ...
net use %DRIVE% %SHARE% /user:%USER% %PASS% /persistent:yes

IF %ERRORLEVEL% EQU 0 (
    echo Drive mapped successfully!
) ELSE (
    echo Failed to map drive. Check credentials or share path.
)

pause

How to Use​

  • Edit the variables at the top (DRIVE, SHARE, USER, PASS) to match your environment.
  • You can duplicate the net use section for multiple drive letters/shares.
  • Save as MapDrives.bat and run as administrator on each client PC.

Best Practice Pro Tip

  • For even greater security, omit the %PASS% variable and the password on the command line so users are prompted to enter it. For example:
    net use %DRIVE% %SHARE% /user:%USER% /persistent:yes
    This keeps your password out of the script file.
  • You can schedule this batch file to run at startup (via Task Scheduler with “Run with highest privileges”).

Let me know if you need the script to handle multiple shares and letters in a loop, or want it in PowerShell format for more advanced credential management!
A script to handle multiple shares and letters in a loop would be extremely helpful!
 

Absolutely! Here’s a batch script template that will loop through multiple drive-letter/share/username/password combinations and handle each mapping automatically:

Batch Script: Map Multiple Drives (MapMultipleDrives.bat)​

Code:
[USER=35331]@echo[/USER] off
REM ====================== BEGIN CONFIG ======================
REM List drives, shares, usernames, and passwords here as parallel lists—make sure the lines match up.
REM Modify/add as needed.

setlocal EnableDelayedExpansion

REM ":DRIVE:SHARE:USER:PASS"
set "MAPLIST=^
Z:|\\SERVERNAME\Share1|SERVERNAME\user1|password1;^
Y:|\\SERVERNAME\Share2|SERVERNAME\user2|password2;^
X:|\\SERVERNAME\Share3|SERVERNAME\user3|password3"

REM ======================= MAIN SCRIPT ======================

for %%M in (%MAPLIST%) do (
    set "line=%%M"
    set "drive=!line:|="&set "rest=!"
    set "share=!rest:|="&set "rest=!"
    set "user=!rest:|="&set "rest=!"
    set "pass=!rest!"

    echo.
    echo === Mapping !drive! to !share! ===
    net use !drive! /delete /yes >nul 2>&1
    net use !drive! !share! /user:!user! !pass! /persistent:yes
    if !ERRORLEVEL! EQU 0 (
        echo [SUCCESS] !drive! mapped to !share!
    ) else (
        echo [FAILED] Could NOT map !drive! to !share!
    )
)

pause
endlocal

How to Use

  1. Update the MAPLIST section with as many drives as you want, following the pattern:
    Z:|\\SERVERNAME\Share1|SERVERNAME\user1|password1;Y:|\\SERVERNAME\Share2|SERVERNAME\user2|password2;...
    Separate mappings with a ; (no semicolons at the end).
  2. Save as MapMultipleDrives.bat.
  3. Run as Administrator on each client.

Security Note

Passwords in scripts are always a risk—see the earlier post's tip for making the script prompt for a password instead, or leave the password field empty and let the user fill it in as prompted (delete the password section in the net use call).

If you want a more advanced (and secure) PowerShell version where credentials are prompted/used securely, just ask! But this batch file gets the job done for quick, multi-share mapping.
 

Absolutely! Here’s a batch script template that will loop through multiple drive-letter/share/username/password combinations and handle each mapping automatically:

Batch Script: Map Multiple Drives (MapMultipleDrives.bat)​

Code:
[USER=35331]@echo[/USER] off
REM ====================== BEGIN CONFIG ======================
REM List drives, shares, usernames, and passwords here as parallel lists—make sure the lines match up.
REM Modify/add as needed.

setlocal EnableDelayedExpansion

REM ":DRIVE:SHARE:USER:PASS"
set "MAPLIST=^
Z:|\\SERVERNAME\Share1|SERVERNAME\user1|password1;^
Y:|\\SERVERNAME\Share2|SERVERNAME\user2|password2;^
X:|\\SERVERNAME\Share3|SERVERNAME\user3|password3"

REM ======================= MAIN SCRIPT ======================

for %%M in (%MAPLIST%) do (
    set "line=%%M"
    set "drive=!line:|="&set "rest=!"
    set "share=!rest:|="&set "rest=!"
    set "user=!rest:|="&set "rest=!"
    set "pass=!rest!"

    echo.
    echo === Mapping !drive! to !share! ===
    net use !drive! /delete /yes >nul 2>&1
    net use !drive! !share! /user:!user! !pass! /persistent:yes
    if !ERRORLEVEL! EQU 0 (
        echo [SUCCESS] !drive! mapped to !share!
    ) else (
        echo [FAILED] Could NOT map !drive! to !share!
    )
)

pause
endlocal

How to Use

  1. Update the MAPLIST section with as many drives as you want, following the pattern:
    Z:|\\SERVERNAME\Share1|SERVERNAME\user1|password1;Y:|\\SERVERNAME\Share2|SERVERNAME\user2|password2;...
    Separate mappings with a ; (no semicolons at the end).
  2. Save as MapMultipleDrives.bat.
  3. Run as Administrator on each client.

Security Note

Passwords in scripts are always a risk—see the earlier post's tip for making the script prompt for a password instead, or leave the password field empty and let the user fill it in as prompted (delete the password section in the net use call).

If you want a more advanced (and secure) PowerShell version where credentials are prompted/used securely, just ask! But this batch file gets the job done for quick, multi-share mapping.
That seems quite foolish to expose the passwords in plain text! Shouldn't key secrets be used with PowerShell and/or a key vault?!
 

You are absolutely correct—storing passwords in plain text within batch scripts is a significant security risk and should be avoided in any production or sensitive environment. Batch files are, by design, insecure for handling credentials, and anyone with access to the script can easily retrieve the passwords.
For secure handling of secrets on Windows, PowerShell is vastly superior. It allows:
  • Secure prompts for credentials (without ever writing passwords in scripts)
  • Use of the Windows Credential Manager
  • Integration with Azure Key Vault or other secure stores
Here’s how you could securely prompt for credentials and map drives in PowerShell, never writing passwords in the script:
Code:
$drives = @(
    @{ Letter='Z:'; Share='\\SERVER\Share1' }
    @{ Letter='Y:'; Share='\\SERVER\Share2' }
)

$creds = Get-Credential  # Prompts securely

foreach ($d in $drives) {
    Write-Host "Mapping $($d.Letter) to $($d.Share)..."
    New-PSDrive -Name $d.Letter.TrimEnd(':') -PSProvider FileSystem -Root $d.Share -Credential $creds -Persist
}
For even more robust solutions (e.g., using Azure Key Vault), PowerShell modules can retrieve secrets programmatically, never exposing them.
So yes—hardcoding passwords in batch files should only ever be a disposable, low-risk action. For anything important, PowerShell with secured credentials is the way to go.
Let me know if you need a ready-to-go PowerShell script for drive mapping using secure credential storage!
 

Back
Top