That's interesting. So, if it detects a slow link the GPO "unapplies", and the mapped drive stops working?
I shall take a look at that. Kurt On Wed, Aug 23, 2017 at 3:57 PM, Joseph L. Casale <jcas...@activenetwerx.com> wrote: > Default behavior of slow link detection? > >> -----Original Message----- >> From: listsad...@lists.myitforum.com >> [mailto:listsad...@lists.myitforum.com] On Behalf Of Kurt Buff >> Sent: Wednesday, August 23, 2017 4:47 PM >> To: ntsysadm <NTSysADM@lists.myitforum.com> >> Subject: [NTSysADM] Odd problem with GPO-mapped drives and SSL VPN >> >> I've got a user in the field out of our AU office. >> >> We have a SonicWall SSL VPN to which he connects. >> >> We map a drive for him to the DFS share (\\example.com\au\share) via >> GPO, but it doesn't work well while he's in the field. >> >> While in the field, if he opens a command prompt, and does a 'gpupdate >> /force', the drive mapping works for a while, then he says it >> disconnects after about an hour or so. >> >> When he's in the office, it's solid. >> >> While in the field, if he maps another drive letter to \\machine\share >> that works either in or out of the office. >> >> I've not seen anything in particular in the event logs that seems >> relevant, but I'm going to look again when he's free. >> >> Has anyone seen behavior like this, and can point me in the general >> direction of an answer? >> >> I understand that drive mappings via GPO over a VPN connection are >> problematic, because the GPO is applied at login, and before VPN >> connection is made, but the fact that it fails after a 'gpupdate >> /force' is truly weird. >> >> Kurt >> >
