Connecting to mapped shares - most of the time very, very slow

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Connecting to mapped shares - most of the time very, very slow

L1 Bithead

I work with a company that uses Global Protect as their VPN solution.  When I work from my offsite office, I'll fire up the VPN, login and get to work.  For the past year, I've suffered from very long connection times re-establishing access to an important shared folder.  In mapping this share, I usually go through Windows Explorer and just click on it.  I've saved my credentials, so I full expect it to just connect as if I was on the LAN.  Most of the time (> 90%), this connection can take anywhere from 5-15 minutes to establish. On very rare occassions, connection occurs immediently.

 

What's interesting is that I can immeditely ping the server hosting the share.  I also can remote desktop into it.  It's just the shared folder that won't mount (has the red x)

 

Pertinent info:

 

  • ATT&T UVerse provides my internet;
  • My laptop is not a member of the company domain and runs no scripts;
  • Windows 10 Professional using a direct cable connection into the cable modem has the delay.  A wireless connection shows the same behavior;
  •  Tried using my hotspot service with t-mobile - same delay issue.

 

I'm just an engineer trying to get his work done.  I have no access to any of the IT side of things, but they've made no progress.  Any suggetions for checking things on my end (client, laptop) so that I could offer clues to the support people?

 

Thanks

7 REPLIES 7

Cyber Elite
Cyber Elite

@CharlieG,

There are far to many variables here that could cause a delay in connection that are dependent on seeing logs or knowing how the firewall providing the GlobalProtect connection is configured for anyone to help you at all. If your companies IT doesn't see this as enough of an issue to actually address things you'll simply have to live with the delay. 

Dude - brutal 🙂

 

That said, if I can ping the server supplying the share, and query it for things like SVN and RDP, there is yet another layer of protocol for the share?

 

Okay, I'll get them to look at the logs.  They don't seem to be excessively engaged 🙂

 

thanks


@CharlieG wrote:

Dude - brutal 🙂

 

That said, if I can ping the server supplying the share, and query it for things like SVN and RDP, there is yet another layer of protocol for the share?

 

Okay, I'll get them to look at the logs.  They don't seem to be excessively engaged 🙂

 

thanks


From you description I assume the global protect configuration is set to "on-demand" so we can exclude the possibility of a policy problem with the pre-logon user. As you can ping and connect to the server I would also say this definately isn't a global protect issue - but this you could verify with a tcp connect to port 445 when you aren't able to open the share.

 

Do you have offline synced folders configured for this share?

remo,

 

  I would agree with you, and no matter how many times I point out the obvious, IT does not take the bait.  I cannot speak to the GP configuration, but I will try your tcp connect suggestion.

 

  As for synced folders, no, none of that exists for me.  Most of the time, I'm just trying to move files that someone else needs, usually in a hurry, so the issue is annoying.  I suppose it could be something on my laptop.  IT threatens to check my logs from time to time.  If they ever figure out what is going on, I'll post a closure to my question.  Might help someone in the future.

 

cg


@CharlieG wrote:

As for synced folders, no, none of that exists for me.  Most of the time, I'm just trying to move files that someone else needs, usually in a hurry, so the issue is annoying.


Is it correct that you have mapped this share persistent so that it is configured also after reboot? If yes I assume this problem is related to a weird windows behaviour that checks the availability of the share already when you haven't connected to GP and then it keeps this state until it automatically checks again. (Did you try to open the share even if it shows this red cross?)

 

Why don't you write a one line bat/powershell script that you execute manually after connecting to GP instead of the persistent configuration?

I'll give the bat a try when it starts acting up again.  This morning, the connection is instantaneous, and the net use command fails with the "already mounted" message.  I'll keep playing with it.

 

Thanks

L1 Bithead

it's 11pm est.  Both Windows Explorer and net use are completely stalled.

 

just a data point for those of you who might be curious or have nothing better to do.  I'm convinced it's not a gp thing.

 

  • 3945 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!