Windows 10 computer will not automatically reconnect to mapped drive

Hey all, dealing with a really stubborn problem in an office environment. I have one workstation running Windows 10 21H2 (10.168.10.186) that refuses to automatically reconnect its mapped U: drive to a folder shared off of a virtual Server 2008 R2 instance (10.168.10.2) after rebooting. This is annoying because the employee uses a program that requires this drive to be mapped and accessible to operate. I am able to click on the mapped drive in File Explorer to re-establish the connection but this is irksome and I'd like to get it fixed. This particular office is NOT on a domain (the workstation and the server are on the same workgroup), and this is the only computer in the office for which this happens. To describe the process:

1. I disconnect the mapped drive and nuke all existing logins in Credential Manager as well as mount points in the registry, then reboot the computer.
2. I navigate to the shared folder at \\SERVER\Folder and enter the proper administrator credentials while clicking "remember me".
3. I map the drive to U: which is where the aforementioned program is set to look for it.
4. I reboot the computer. Upon first reboot, when attempting to access the mapped drive, File Explorer will prompt me for the password to the share even though I've already entered it. It does remember the username. I re-enter the password.
5. From this point on, I no longer have to enter the password, but the mapped drive will not establish itself unless I click on it in File Explorer

Here is what I have tried so far:

• Mapping the drive by IP rather than name
• Enabling the local group policy option for waiting for a network link
• Trying this registry fix
• Rebooting the server
• Creating a new user profile/account on the workstation and connecting from that
• Creating a different admin user to supply credentials for
• Making all the usual NIC tweaks to stop intermittent connectivity problems
• Making sure all network discovery options on both computers are as they should be
• Checking the permissions of the shared folder
• Ran SFC on the workstation and the server
• Performed a netBIOS name cache purge on the workstation
• Performed a "Network Reset" on the workstation
• Specifying both "localhost\username" and "server\username" when supplying credentials
• Turned off fast boot in both Windows as well as the BIOS (this computer does still boot up VERY fast)
• Made sure that offline files were turned off on the workstation

Here is the start of a Wireshark capture I performed after clicking on the mapped drive to re-establish its connection:



Any help at this point would be appreciated. I suspect the fact that the server instance is 2008 R2 might have something to do with it, well maybe anyway.

EDIT: Almost forgot. For reasons that are unknown to me, the server actually has a mapped drive on it pointing to the same resource, i.e. a mapped drive pointing to itself. And this mapped drive is ALSO broken unless it is clicked on. Pretty weird.

EDIT 2: Performed a test where I created a shortcut on the workstation desktop to a file located on the server share. When I clicked the shortcut the file opened without issue. I then opened the aforementioned application and it worked without a problem.

Have you tried making the drive via CMD prompt use its IP not name and use / persistent switch it's likely NetBIOS is slow so it takes time to resolve using IP would fix that

If its the whole drive by default its shared with a $ ie d$ to access it you need admin and password for user on the server

Its shared by default if you setup another share on same drive it can get confussed