• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 603
  • Last Modified:

DOS commands to open & close a network share

A handful of my users are experiencing a problem when they login. Their home folder is mapped to a network share (U: drive). Unfortunately, it seems that when the user logs on the system brings the drive up as disconnected. This causes problems with applications that need to write to this U: drive as it believes the U: drive is disconnected. If I have the user open their U: drive and run the application again the system recognizes it as connected and the application works.

I'm looking for DOS commands that I can add to their respective logon script that will open up their home folder (the U: drive) and then close it. If this can be transparent to the user that is great as well.
0
dowhatyoudo22
Asked:
dowhatyoudo22
  • 4
  • 3
  • 3
  • +1
3 Solutions
 
Gerwin Jansen, EE MVETopic Advisor Commented:
You can start an explorer with a parameter, like this:

explorer u:\

This will open a standard windows explorer with the (mapped) U: drive
0
 
pony10usCommented:
Are you sure the drive is disconnected as soon as the login script runs or after a period of time like say 15 minutes?

Couple of suggestions:

1. You could try doing a directory listing right after mapping

     dir u: > NULL  

This will send the output of the directory to NULL so that it doesn't show up. If the U: drive contains a lot it could slow down the login script.

2. You could open and close the folder as you ask but I am not sure how transparent it would be and there may be some potential for issues.  

    REM Open U: drive    
    explorer u:    

    REM Close most recent explorer window
    TASKKILL /IM EXPLORER.EXE

Option 2 should only close the most recently opened explorer.exe task which should be the U: drive
0
 
Gerwin Jansen, EE MVETopic Advisor Commented:
You could also force a disconnect and connect, like this:

net use u: /d /y
net use u: \\<server>\<share
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Steve KnightIT ConsultancyCommented:
Could it be you need to use a group policy in there to "wait for the network" etc.   is this being mapped in the login script, or hung over from before?  Can't give you link at the moment from here but if you google "wait for network" policy should get it.

Steve
0
 
dowhatyoudo22Author Commented:
Performing the directory listing after creating the mapping sounded like a good idea up until you mentioned the size of the user's home directory and it slowing down logins. Some of my users have a couple of GB in the home directory.

I tried the "explorer U:"  which works but when I try to run the "taskkiller /im explorer.exe" command it gets confused. Sometimes it closes the window that was just opened. Other times it presents a screen preparing to shutdown the entire machine.

The disconnect & reconnect might do it. Looking into the issue further it appears that some of my users has mapped drives that pointed directly to the server where the home directory was located. One of my engineers before he left was working on changing these pointers to a DFS server. It appears that I may have a conflict with these user's current/previous mapping to thier home directory and this login script attempting to creating the new mapping.
0
 
pony10usCommented:
As long as the root of their U: drive is small (they keep their files in separate folders right?) then the directory feature would work. However we all know that that never happens.  

The problem with the other method that I mentioned is that it will attempt to close the most recently opened explorer window so if the previous command does not function then it will close the root explorer which is the system.
0
 
Gerwin Jansen, EE MVETopic Advisor Commented:
After the disconnect/connect, you could add a basic dir command that lists a 'non existing' file, instead of listing the whole directory (which could take some time).

Like this:

net use u: /d /y
net use u: \\<server>\<share
dir u:\*.ybx

(ybx is an extension not likely to find, choose another if you like)
0
 
pony10usCommented:
Good idea looking for something that you know won't exist.  I would still send the output to NULL since you don't really care about the response.

dir u:\*.ybx > NULL
0
 
Gerwin Jansen, EE MVETopic Advisor Commented:
>> I tried the "explorer U:"  which works but when I try to run the "taskkiller /im explorer.exe" command it gets confused.

This is true, I tried and saw same behaviour. The explorer is started as a separate task and the kill will just kill any explorer it will find. You can select the 'right' explorer by searching for the window title but again it takes some time for the explorer process to 'appear'.

You could try this:
(in a batch file, otherwise use single % instead of double ones)

@echo off
:: Open explorer
explorer U:\
:: Wait 3 seconds
@ping -n 1 -w 3000 1.1.1.1 >nul:
:: kill the window with title U:\
FOR /F "tokens=2" %%a IN ('tasklist /fi "windowtitle eq U:\\" ^| findstr explorer') DO taskkill /pid %%a

Open in new window

0
 
dowhatyoudo22Author Commented:
Think the issue is tied to a concflict in GPOs and login scripts. User's mapped drive in question is configured one way. But GPOs and login scripts are attempting to map them another. This appears to be causing some sort of conflict and the drive is coming up disconnected.
0
 
Steve KnightIT ConsultancyCommented:
Well, manually disconnect all drives in one of the users machines - net use * /delete from command prompt or disconnect them in explorer.

Then do a

gpresult /scope user  /h user.html
start user.html

or

gpresult /scope user /v > gp.txt
start gp.txt

and look for any scripts or group policy preferences issues re: drive mappings.

Also check the user's home drive and login script properties in their user object in AD.

And also if you search on SYSVOL for *.cmd, *.bat, *.vbs are likely to be any script locations, e.g.

dir \\domain.local\sysvol\*.cmd *.bat *.vbs /s /b > scripts.txt
start scripts.txt

And take a look at those for drive mappings.

Also as suggested earlier make sure your logins aere waiting for the network to become active before logging in, i.e. check that this policy has been set in AD GPO:

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

Steve
0
 
dowhatyoudo22Author Commented:
Deleting/removing the mapped drive in question manually and then having the user log off and then back in allowing group policy to take affect appears to be my best option at this point. The pool of affected users is unknow but to small to start removing/deleting mapped drives to user in particular OUs.

Thanks everyone!
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now