You should be able to raise the threshold of slow link detection to compensate. If you dont allow ping to traverse, the link will always register as slow.
-- Espi On Wed, Aug 23, 2017 at 7:21 PM, Kurt Buff <kurt.b...@gmail.com> wrote: > 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 > >> > > > > >
