Link to home
Start Free TrialLog in
Avatar of WMIF
WMIF

asked on

mapped drives on vpn

we have a batch script for the users logons that mapped a public folder to f:.  a personal folder (g:) is mapped by active directory from the profile tab of ADUC properties in the home folder section.  the problem is that these folders dont get mapped when a user is using vpn.  we are using cisco vpn.

in the script i should be able to add "/persistent:yes" to the end of the net use command and it will map the folder and keep it there when they arent on the domain, right?

what can i do to keep the g drive mapped?
Avatar of sirbounty
sirbounty
Flag of United States of America image

Hi WMIF,
I'm not sure if you can accomplish this with a /persistent switch...
But perhaps you can by modifying Cisco VPN.

Depending on the version, you may be able to set something up with Application Launcher, under Options on the toolbar.
Perhaps creating a batchfile to map the drive and have it lauch once the vpn is available...
Avatar of WMIF
WMIF

ASKER

that sounds like its a client side setting?  i was hoping to find a way that would be more of a server based solution.  maybe this setting can be applied to a profile that we import to the cisco software (thinking out loud) and that would be alright.  i would just have to get to all the users that already have the profile.

is there a different way of mapping drives that is better served for mobility and vpn access?
The only way to get this working via the server is to connecto to vpn before logon to windows. You can activate this in the VPN Client under Options -> Windows logon properties. Select the checkbox next to "Enable start before logon", then you can establish the VPN connection before logon to the machine and so the machine can connect to the server during logon and run startup scripts or similar.
WMIF,

where is the batch file set and stored? is it via a GPO or on the user account properties itself? On the client side, do you have name resolution cranking?
ASKER CERTIFIED SOLUTION
Avatar of Jay_Jay70
Jay_Jay70
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
This is a common problem with VPNs and Dialup connections.  Generally we tend to create a shortcut to the logon scriipt and place it on the laptop user's desktop.  Then instruct them to double click on it after they connect to the VPN.  Not a technically elligant solution, but it's simple and it always works.
Avatar of WMIF

ASKER

>>The only way to get this working via the server is to connecto to vpn before logon to windows.

this is not how i want to do it.  if these are my only options, i would rather do what i have done for some of the users which is manually disconnecting both drives and mapping them so they dont go away.  they will get confused about how they should log in and sometimes they may not know up front.  i am moving the laptop users over to rpc over https one by one so they dont even have to vpn for email anymore.  

also, i had a user call me earlier about not having his drives.  he is at our remote location which is a wan link.  he logged onto his laptop before connecting to the network so he didnt get his drives.  i asked him and he claims that he didnt, but when he logged off and back on they magically appeared.  i would rather have the drives connected so that in this case they would have been there.


>>where is the batch file set and stored? is it via a GPO or on the user account properties itself? On the client side, do you have name resolution cranking?

the batch file is in the netlogon share of the 2003 dc.  the script is specified in the same tab of the home folder as a logon script.  im not sure exactly what you mean with the name resolution.  when they connect, they are given our dns servers.


>>Generally we tend to create a shortcut to the logon scriipt and place it on the laptop user's desktop.

this is what i have done for a couple people, but its not what i would like to have company wide.  i have some users that can barely turn their computers on.



overall so far it sounds like i actually need to add their personal drive to the batch script along with the persistent flag.  this will make the drive be there, although with a red x indicating its not available, for the user when they are connected through whatever means.  thoughts?
due to the lmitations with logons over a VPN, i think the persistant switch will do the job...however there is a policy that you can set that will make sure that the network is ready before it logs on (common problem with one of xp's "fast logon" features..doesnt apply policies or scripts initiall) if you set this, logons are slower, but policies and scripts run on logon

Administrative Templates\System\Logon      Always wait for the network at computer startup and logon

The persistant switch will do what you need, but i dont beleive you should need it if you are mapping the home drive via ADUC account properties (which could be a viable option)
Avatar of WMIF

ASKER

>>but i dont beleive you should need it if you are mapping the home drive via ADUC account properties (which could be a viable option)

that is what we are doing, and it is not there when the user is not connected to the network at logon.
ok then that policy may help
Avatar of WMIF

ASKER

how does that affect the computers though when they arent on our domain?  does it take a long time to determine that its not available?
well they are still on the domain, just via VPN yes.....you just need to configure the VPN client to connect first (then tick on logon) and then that policy will once cached, wait for network.....it doesnt take that long, but it will be noticeable......persistant switch may be a little easier for end user to cope with
Avatar of WMIF

ASKER

i have made the logon script look like this, and its been running since about my last comment in here (sorry for the abandon).

net use g: /home /persistent:yes
net use f: \\indfile01\shared /persistent:yes

it appears to be working great.
good news :)