[21h2] Mapped Drives over VPN - Not Reconnecting

[CHiLL]

I don't think this issue is specifically related to our VPN itself, hence why I've started the thread here than in another section. We use Sophos IPsec VPN for external access, however we are finding that an increasing number of users are reporting that their mapped drives aren't working. This mainly occurs when they are connected to the VPN, however I have also seen it when they're connected to the internal network, not via Sophos. I am struggling to replicate the issue when connecting the device via my phone's hotspot. I can see in the event logs that the folder redirection was sucessfully applied

 

The mapped drives end up having red x through them and when you try to access them, it says something along the drives of "Could not reconnect the drive. The network name is already in use". The Documents folder also won't work, because Documents redirects into their networked home folder. Although I can see in the event logs that folder redirection applied correctly.

[Michael]

Three thoughts come to mind -

 

- Can you map to the same share using an IP?

- Are you using the FQDN in share paths?

- Try restarting the Explorer process in the user's context

[CHiLL]

Three thoughts come to mind -

 

- Can you map to the same share using an IP?

- Are you using the FQDN in share paths?

- Try restarting the Explorer process in the user's context

1) I've just tried it and it's a combination of yes and no. I cannot use the same drive letter because it says it's already in use. Using a different drive letter, whether using the FQDN or IP address I get two outcomes; either it maps fine or it says that the user doesn't have permissions to access the folder (which isn't correct because all users have full control over their home folder and it will work when on the internal network with the same path).

2) Yeah, we're using FQDN's (drives are mapped via GPP using the Update option).

3) Restarting File Explorer in the user's context made no difference

 

The error using the Documents folder is as follows:

\\server.fqdn\share$\\Documents is unavailable. If the location is on this PC, make sure that the device or drive is connected or the disc is inserted, then try again. If the locaiton is on a network, make sure that you're connected to the network or Internet, then try again. If the location still can't be found, it might have been moved or deleted.

 

I have just tried it again on a user's laptop and as I logged on, I got the above message. When manually trying to browse to the path via Run, it says the following:

\\server.fqdn\share$\\Documents. The specified path does not exist. Check the path, then try again.

This is despite I can browse to the same path from my machine and access the user's home folder. However, I noticed that leaving the laptop idle for a couple of minutes without it logging out/locking...the Documents folder then worked as expected. It appears that the network path only works after some time of being logged in/VPN being established, I'm not sure why.

 

I've also noticed that this Sophos VPN has the same Home Folder issue that our older Microsoft Always-On VPN had where it doesn't map the H:\ drive for the home folder. I'm trying to figure out how to get it to re-apply.

[TRSJon]

Afternoon. I know everyone blames DNS... but, is there any mileage in adding the server.fqdn in to the devices host.file as maybe the VPN is passing DNS requests internally properly.

[Michael]

1) I've just tried it and it's a combination of yes and no. I cannot use the same drive letter because it says it's already in use. Using a different drive letter, whether using the FQDN or IP address I get two outcomes; either it maps fine or it says that the user doesn't have permissions to access the folder (which isn't correct because all users have full control over their home folder and it will work when on the internal network with the same path).

2) Yeah, we're using FQDN's (drives are mapped via GPP using the Update option).

3) Restarting File Explorer in the user's context made no difference

 

The error using the Documents folder is as follows:

\\server.fqdn\share$\\Documents is unavailable. If the location is on this PC, make sure that the device or drive is connected or the disc is inserted, then try again. If the locaiton is on a network, make sure that you're connected to the network or Internet, then try again. If the location still can't be found, it might have been moved or deleted.

 

I have just tried it again on a user's laptop and as I logged on, I got the above message. When manually trying to browse to the path via Run, it says the following:

\\server.fqdn\share$\\Documents. The specified path does not exist. Check the path, then try again.

This is despite I can browse to the same path from my machine and access the user's home folder. However, I noticed that leaving the laptop idle for a couple of minutes without it logging out/locking...the Documents folder then worked as expected. It appears that the network path only works after some time of being logged in/VPN being established, I'm not sure why.

 

I've also noticed that this Sophos VPN has the same Home Folder issue that our older Microsoft Always-On VPN had where it doesn't map the H:\ drive for the home folder. I'm trying to figure out how to get it to re-apply.

 

Is the issue only to do with home shares and not other mapped drives, such as a StaffCommon equivalent?

[CHiLL]

Is the issue only to do with home shares and not other mapped drives, such as a StaffCommon equivalent?

That appears to be the case. Our staff share mapped drive will have a red x through it because it maps the drive before the VPN has established it's connection, though users can still click through it to access it and the red x disappears.

 

Edit: The staff home folders and staff share are both on the same drive of the same server.

Edited April 20, 2023 by CHiLL

[CHiLL]

The only solution we can come up with at the moment is regarding how the home drive is mapped. We use the user's AD properties to specify the home drive location and drive letter, which doesn't reapply and all other mapped drives are handled by GPP. I don't want to mess around with the AD properties at the moment, so I've added an extra entry into our GPP to map the home drive (\\server\share$\%username%\Documents) with the box checked for "Reconnect". This will potentially conflict with the AD properties but I'm relying on the fact that GPP will silently fail.

 

In an on-site scenario, the user will log in and get the H: drive by AD properties and that's it. However, this extra GPP item means that GPP will attempt to add the H: drive again...but it should silently fail because it already exists.

In an off-site scenario, the user will log in and the H: drive by AD properties will fail. However, this extra GPP item will fail at first run/login (which presents the H: drive, but it's unusable with the same error listed for Documents in one of my earlier posts), but then the reconnect flag kicks in and reapplies the map...then the drive appears as a usable drive.

 

From my initial testing, it appears to take a couple of minutes until the H: drive is visible and accessible...but at least it appears to work.